Log In  

Hi zep!

pget seems to use the camera which is kind of strange I think...

This does not do what it looks like it does if camera() is used:

col=pget(x,y)
pset(x,y,col)

Manual correction (if cx and cy are camera position):

col=pget(x-cx,y-cy)
pset(x,y,col)

Is this a known issue or am I misinterpreting something here?
Thanks!

P#11318 2015-06-18 15:45 ( Edited 2015-06-19 00:19)

:: zep

Yeah, it does seem kind of strange! It behaves that way to be consistent with pset(), which in turn should be consistent with the other draw functions.

The problem is that they could be both used meaningfully in world space (e.g. particles distorting the background around them in a scrolling platformer) or in screenspace (a post-frame filter that shuffles some random pixels around).

I figured that by the time you're reading pixels in screenspace, you probably don't care about the camera anymore and have used camera() after your scrolly draw operations. This is very hypothetical though -- I couldn't think of a clear example.

Out of curiosity, what are you using it for? (if it's not hard to summarize here)

P#11320 2015-06-18 17:38 ( Edited 2015-06-18 21:38)
:: zep

Oh, wait.. I read your post too fast. pget() is supposed to respect the camera but doesn't -- that's a bug. Will fix for 0.1.2

P#11321 2015-06-18 17:43 ( Edited 2015-06-18 21:45)

Ok, good to know, thanks!

Your list of examples is good. My case is realtime shadows on a scrolling map (similar to "particles distorting the background around them").

P#11325 2015-06-18 20:19 ( Edited 2015-06-19 00:19)

[Please log in to post a comment]

Follow Lexaloffle:        
Generated 2020-05-31 23:18 | 0.009s | 2097k | Q:15