TPixmaps broken?

BlitzMax Forums/BlitzMax Programming/TPixmaps broken?

taumel(Posted 2010) [#1]
Hi,

could it be that TPixmaps are kind of broken?

What i tried to:
1) I assigned four TImages via CreateImage (DYNAMICIMAGE is set).
2) I copied them to RAM via creating TPixmaps and LockImage().
3) According to the visibility of the user, i write to the TPixmaps via WritePixel().
4) Then i write them back to VRAM via UnlockImage(), this can happen more than once between the vertical blanks.
5) Afterwards i draw the images on the screen as two tiles each consisting of two layers (Background- and Collisionlayer).
6) Finally i do a collisiontest via ImagesCollide() between the collisionlayer and another sprite.

Everything works fine initially but after a few updates things are broken and it seems that either the RAM or the VRAM doesn't get updated anymore, so either a) the graphics aren't upated properly anymore or b) collisions occur where they should not or don't where they should.

I tried both using SOLIDBLEND as well as ALPHABLEND for the background layers.
I tried to clear the buffers vie ClearPixels() before but that doesn't help anything beside of that it seems that writing an alphachannel with no RGBs results into collisions but clearing without setting the alphachannel results into left out collisions.

Although this all should be superfluous because i update the relevant parts when writing to the buffers via WritePixel(ARGB) already.

All happens on BlitzMax 1.4.1 on OSX 10.6.4 (x86).

It's weird and just doesn't work as expected. Either i'm missing something with the pixelformats, although all use an alpha channel or something seems to be broken.

Any ideas or alternatives?


Thanks,

taumel


ima747(Posted 2010) [#2]
Can you post an example? I would suspect something going wrong in the way you're writing the pixels that just isn't noticeable until you've done it a certain number of times...


taumel(Posted 2010) [#3]
Before whipping up a example which causes the same problems is this enough?

a) Global imgHG1:TImage=CreateImage(weSizX,weSizY,1,DYNAMICIMAGE|MASKEDIMAGE) creates and 32bit per pixel image with the bytesorder ARGB, right?

b) Global pixHG:TPixmap
I can define just the type and then assign any Image like for instance via pixHG=LockImage(imgHG1) to it, right?

c) Then i can write as much as i want like this to the RAM, WritePixel(pixHG,iX,iY,colA) where the colour is set together like colA=colARGB|(rgbR Shl 16)|(rgbG Shl 8)|(rgbB)
colARGB=$ff000000

d) Then i release it via UnlockImage(imgHG1)

e) Drawing
SetScale 1,1
SetBlend ALPHABLEND
DrawImage imgHG1,hgPosX,hgPosY
DrawImage imgPlayer,plPosX,plPosY

f) Collisiontest

If ImagesCollide(imgPlayer,plPosX,plPosY,0,imgHG1,hgPosX,hgPosYscrY,0) Then flaCollision=true


TomToad(Posted 2010) [#4]
When doing a collision test, Max2D checks against the alpha channel, not the actual pixel. When using LoadImage(), Max2D checks each pixel's color against a mask (default 0,0,0) and sets that pixel's alpha to 0 if it matches and to 255 if it does not. When you use CreateImage(), the alpha channel is not set and must be set by hand. One way to do this is to iterate through every pixel and set/clear the alpha based on pixel color

Of course, this could be avoided if you include the alpha with any pixels you want seen and tested against while you draw.

With that modification of the WritePixel(), any black pixel will be rendered with 0 alpha and will not cause collision. Any other color will be rendered with full alpha and trigger collisions. If you want a black pixel to be rendered and to collide, you can use $FF000000 for the color.


TomToad(Posted 2010) [#5]
Also thought I might add, when you use CreateImage() you will not be guaranteed that the pixels will be cleared. So it is a good idea to use ClearPixels() after LockImage() if you are not already rendering to every pixel.


taumel(Posted 2010) [#6]
I am already rendering to each pixel i show, the way i wrote before via $ff000000|color, so i thought this wouldn't be a problem at all but somehow using ClearPixels makes a difference and both the visuals as well as the collisions work different, whilst also providing NOT the wanted result.

*sigh* I thought this would be a quick thing...


Jesse(Posted 2010) [#7]
The only way to tell what you are doing wrong is to look at the actual code. I have used ImagesCollided and never had problems with it as well as using it with modified images through pixmaps.


taumel(Posted 2010) [#8]
I'll see how i can extract the problem.

Just another one, is there a limit regarding the sizes?


TomToad(Posted 2010) [#9]
you're probably doing this, but I thought I'd ask anyway. Are you doing Cls and calling ResetCollisions() between each frame?


taumel(Posted 2010) [#10]
Okay, i got it, it works now.

I wasn't aware of that ImagesCollides() tests against the alpha channel and therefore i wasn't reinitialising leftovers in all layers.

Thanks to TomToad and the others!

Hmm, now that it works i think i will expand the test a bit for ... :O)


Pete Rigz(Posted 2010) [#11]
In my own experience using bmax collisions, if collisions were happening where they shouldn't it was usually because I'd forgotten to use ResetCollisions(), not sure if that's the same problem here though, might be :)


taumel(Posted 2010) [#12]
Nope, thanks, my issue was that i didn't know that the alpha channel is used for the collisions. It works now as my little test shows.