Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

put format

Status
Not open for further replies.

Barok

MIS
Dec 13, 2002
134
CA
okay, so of course, when you GET an image, the variables in the array holding the image would look like this.

image(0) = 160 'width times 8
image(1) = 20 'height
image(2) = 2342 'first two pixels
image(3) = 5435 'next two pixels...
...
...

of course, qb adds the first pixel color to the second times 256, like this...

image(2) = color1 + color2 * 256

now, my question is this: how can i find out what one pixel would be? does anyone know how i could learn what, say, color1 would be without using def seg, varseg, and varptr? thanks.
 
Use DEF SEG and PEEK

Code:
FUNCTION GetColor%(x as integer, y as integer, image() as integer)
  DEF SEG = VARSEG(image(0)) 'Set the Segment to the array
  offset& = VARPTR(image(2)) 'Get the Offset of the first pixel (always 4)
  width& = image(0) \ 8      'get the width
  height = image(1)          'get height

  IF x >= 0 AND y >= 0 AND x <= width& AND y <= height THEN
    color = PEEK(offset + x + (y * width&)
  END IF
  DEF SEG                    'Restore Segment
END FUNCTION

Have Fun, Be Young... Code BASIC
-Josh
cubee101.gif

 
I'm not quite sure:

colour1% = (image(2))MOD 256
colour2% = image(2) - colour1% * 256

I think this works, if it doesn't a similar code will, but I'll have to look it up exactly. Why don't you want to use DEF SEG< VARSEG, or VARPTR?
 
thanks cubee, but that' what i'm trying to avoid.

i want to find it out mainly because of speed. if i can find out how to find out what the colours are, then i can save my programs from using lots of useless def segs (they are changed a split second later to &ha000, then back to the varseg of the image, then back to &ha000, etc. etc.)
 
Unless you are using a really slow computer or plan to be doing this ALOT it shouldn't slow down your program too much.

Anyway - I was half right above, but I figured out the rest of the code. First of all, the way you have it written above, it wouldn't be two pixils at a time, it would be four.
Instead of image() use image%()

FUNCTION colour1% (a%)
IF a% < 0 THEN neg% = 1: a% = -a%
colour1% = a% MOD 256
IF neg% = 1 THEN colour1% = 128 + (128 - a%)
END FUNCTION

FUNCTION colour2% (a%)
IF a% < 0 THEN neg% = 1: a% = -a%
colour2% = a% \ 256
IF neg% = 1 THEN colour2% = 127 + (128 - colour2%)
END FUNCTION

Let me explain why this works.
First when you said: image(2) = color1 + color2 * 256 you were right and wrong, remember that computers work in binary actually: image(2) = colour1 + colour2 * 11111111

You have to have the negative handler because if your second colour is more than 127 it will be forced to use the first binary bit to make the number. Qbasic uses that bit as the positive/negative switch, so qbasic reads
1110000110101111 which the computer knows as 57775 as
-25007

 
I suppose you could use Hex$...

H$ = Hex$(image(2))
colour1% = Val(&quot;&H&quot; + Left$(H$,2))
colour2% = Val(&quot;&H&quot; + Right$(H$,2))


you can test it like this...
-----------------------------------
Code:
Dim image(10) As Integer
Screen 13
Pset (0,0),255
Pset (1,0),245
Get(0,0)-(2,2),image

H$ = Hex$(image(2))
colour1% = Val(&quot;&H&quot; + Left$(H$,2))
colour2% = Val(&quot;&H&quot; + Right$(H$,2))

Print colour1%
Print colour2%
-----------------------------------

And to go the other way...
image(2) = Val(&quot;&H&quot; + Hex$(colour1%) + Hex$(colour2%))

Have Fun and Good Luck... ;-)

Have Fun, Be Young... Code BASIC
-Josh
cubee101.gif

 
BTW...

Let me know if it is Faster than the DEF SEG method...

also the reason I use an extra variable H$ instead of using 2 Hex$ functions was for speed... you can also try it the other way and bench mark between those 2 methods also...

The other way is...
colour1% = Val(&quot;&H&quot; + Left$(Hex$(image(2)),2))
colour2% = Val(&quot;&H&quot; + Right$(Hex$(image(2)),2))


Now... It Would Be nice to be able to make a buffer the size of the screen...
Dim Scrn(32000) As Integer
And be able to use inline assembly (Call Absolute) to move the pointer to video memory...
That way you could Write/Read to the screen just by changing the array ;-)

Have Fun, Be Young... Code BASIC
-Josh
cubee101.gif

 
thanks cubee, that helps alot! :D

btw, with your buffer should be this:

dim scrn(32001) as integer

because the screen has 64004 pixels. an integer equals 2 bytes, so that would bring it to 32002, and since we include 0, that makes it 32001.
 
No...

The Screen has 64000 Pixels (320 x 200)
If you are NOT using PUT... You only Need 32000 Integers...

The other 2 integers are to store the 4 bytes used for Width & Height of the Get/Put Array...

But I was talking about writing straight to the screen via an array...

So I Could have actually said...
Dim Scrn(31999) As Integer
But I rounded it up to 32000 just 4 fun ;-)

Have Fun, Be Young... Code BASIC
-Josh
cubee101.gif

 
whoops... completely forgot about that. haven't done anything with buffering for a while... usually you want the buffer to be PUT compatible though. Thanks for correcting me.
 
The Reason I would want to do that, (set an array pointer to video memory) is to have the screen update when you change the array, and bypass the PUT command, then the screen would update when you change the array And would not have to use DEF SEG, Peek, Poke or Put...

Have Fun, Be Young... Code BASIC
-Josh
cubee101.gif

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top