POINT(x,y) inconsistency

[Muffinman]

This is not a bug per se, but the POINT(x,y) function works with shown/hidden screen pages and NOT images with handles, which is confusing.  Throws error only if no screen statement encountered.  Consider the example

Code:

DIM uno AS LONG, dos AS LONG, pt1 AS LONG, pt2 AS LONG
uno = _NEWIMAGE(640, 480, 32)
dos = _NEWIMAGE(640, 480, 32)
red& = &HFFFF0000
blue& = &HFF0000FF

SCREEN uno
LINE (0, 0)-STEP(9, 9), red&, BF
_DEST dos
LINE (0, 0)-STEP(9, 9), blue&, BF
pt2 = POINT(5, 5)
_DEST uno

pt1 = POINT(5, 5)

PRINT "Result 1"
PRINT HEX$(pt1)
PRINT HEX$(pt2)

SLEEP
CLEAR

uno = _NEWIMAGE(640, 480, 32)
dos = _NEWIMAGE(640, 480, 32)
red& = &HFFFF0000
blue& = &HFF0000FF

SCREEN uno
LINE (0, 0)-STEP(9, 9), red&, BF
SCREEN dos
LINE (0, 0)-STEP(9, 9), blue&, BF
pt2 = POINT(5, 5)
SCREEN uno

pt1 = POINT(5, 5)

PRINT "Result 2"
PRINT HEX$(pt1)
PRINT HEX$(pt2)

(and point(0)/point(1) gives something entirely strange)

[Cyperium]

With POINT you have to use _SOURCE to set the handle unto which to point to.

So instead of _DEST uno, use _SOURCE uno.


Personally I would have liked it better if POINT used _DEST like everything else, but I guess that Galleon could have a cause for this.


POINT without any _SOURCE uses the default screen to point to.

[Galleon]

This isn't a bug, as Cyperium said.

The reason QB64 uses _SOURCE for point is to allow programmers to use various rendering/texture-mapping techniques which read a source image's pixels and put them onto the destination image. Atm PSET & POINT have high overheads but a new QB64 command I've planned called _DOT will allow programmers to read and write pixels just as fast (if not faster) than reading an array. _DOT will do the minimum checking it can, and simply avoid letting you read/write memory outside the screen/image buffer. It may perform clipping but this is yet to be decided.

[Clippy]

Why not call it _PIX or _PIXEL? _DOT does not really sound like a Basic descriptive name to me.

Besides that, I've had enough problems with the Department Of Transportation!

Ted

[Muffinman]

Aaaaah ok.  Then that concludes my grievance!  Thx for reading. :>

[coma8coma1]

...(and point(0)/point(1) gives something entirely strange)

Hi, folks!

I recently upgraded from qb64 v0.841 to v.086 and suddenly POINT(0) is returning a value of 219 no matter what I try. This was not an issue in v0.841. Does anyone know what has changed? I know this is an incompatability issue and will likely be addressed eventually, but it's jacking up my graphics, so is there another way to return the current x position of the DRAW cursor?

If anyone is curious what I'm doing it's kind of explained here http://www.qb64.net/forum/index.php?topic=345.0 at the bottom of reply #1 where I show the three lines of code that I use to determine the horizonal length in pixels of a string of my custom font. Basically, the width of each character is different and this makes the width of a word or sentance hard to determine without actually drawing it, so it draws the exact same string just off the bottom of the screen starting at 100, 210 and figures out how wide the string is by subtracting 100 from POINT(0). Unfortunately POINT(0) is returning 219 instead of the actual cursor position. This is ruining my text graphics.

At first I thought it had something to do with my trying to PSET and DRAW offscreen, but I moved the TextLen test location to a position well within the window (100, 100) and POINT(0) is still returning 219. I'm in SCREEN 13 (320x200) if that's a clue.

I've been debugging and searching the forums for a few hours and I'm stumped! Any ideas??? Thanks in advance! -coma8 

-------------------------

Edit to add: It looks like POINT(0) is actually returning 319 which is the maximum horizontal pixel value. My TextLen() function is simply returning 219 because I subtract 100 from POINT(0). For some reason POINT(0) is returning a value equal to the maximum screen width no matter what I do, even when I draw inside the window. Hope this helps. Btw, this is the only time in my whole program where I need to know the cursor position

[coma8coma1]

Please ignore my previous post    (so embarrased). It was something totally obvious and boneheaded  The kind of thing that takes 10 hours to figure out and all you hve to do it comment out one little statement 

[Cyperium]

That happens to all of us from time to time , glad it worked out and happy programming!

[Muffinman]

I'm glad this topic is still up, because I think POINT(0) and POINT(1) are affected by _DEST the way that they should be affected by _SOURCE. In code like the following example where the only graphics reading command is POINT(0|1|2|3), _SOURCE doesn't do anything at all so it would look like something's definitely happening (in a bad way).  The output might be expected to be the same since _SOURCE is kept the same throughout.  Or else this exception should be documented in BIG letters everywhere.

Code:

g = _newimage (800,600,32)
h = _newimage (800,600,32)

SCREEN g

_DEST h : _SOURCE h
pset (12,12), -1

a = point(0): b = point(1)

_DEST g : _SOURCE h
pset (25,25), -1               ' A different point on g

_SOURCE h
PRINT "    x,y from vars "; a;b
PRINT "    x,y from func "; point(0); point(1)

Good to use for torturing newbs!:

Code:

screen _newimage (800,600,32)
h = _newimage (800,600,32)

_DEST h   :   pset (12,12), -1

'_DEST 0   :   pset (37,37), -1                            ' <------- try comment out

_SOURCE h   ' set to anything - it won't matter
a = point(0) :b = point(1)
circle (25,25), 3, -1

_DEST 0
print "    x,y from before making circle "; a;b
print "    x,y from after making circle"; point(0); point(1)