GP32 Partially Offscreen Sprites

[pea]

hmm. Starting 0,0 in bottom left would remove a couple of additions/subtractions from the code, but in my opinion would make it way more difficult to visualise for the developer. I like the idea that the developer still creates his sprites the right way up (the loading code rotates it on load) and the developer still works with 0,0 as the top left. All the positional math is transparent. Makes it easier to port other stuff to IMO.

 

[unit3]

hmm. Starting 0,0 in bottom left would remove a couple of additions/subtractions from the code, but in my opinion would make it way more difficult to visualise for the developer. I like the idea that the developer still creates his sprites the right way up (the loading code rotates it on load) and the developer still works with 0,0 as the top left. All the positional math is transparent. Makes it easier to port other stuff to IMO.

​

Yeah, I agree with this, have the APIs deal with things conceptually in a matter that makes the most sense, and then have the functions themselves sort out the positional adjustments that are necessary to deal with the data in the most efficient manner.

Also, I think I've sorted out my overheating problems at home, a can of compressed air through my Vantec Aeroflow later, so I'll see about getting some more actual programming done this week. ;P

 

[Oankali]

hmm. Starting 0,0 in bottom left would remove a couple of additions/subtractions from the code, but in my opinion would make it way more difficult to visualise for the developer. I like the idea that the developer still creates his sprites the right way up (the loading code rotates it on load) and the developer still works with 0,0 as the top left. All the positional math is transparent. Makes it easier to port other stuff to IMO.

​

Yeah, I agree with this, have the APIs deal with things conceptually in a matter that makes the most sense, and then have the functions themselves sort out the positional adjustments that are necessary to deal with the data in the most efficient manner.

Also, I think I've sorted out my overheating problems at home, a can of compressed air through my Vantec Aeroflow later, so I'll see about getting some more actual programming done this week. ;P

​

I don't think Synkro is saying that we have to prepare our functions as if 0,0 was bottom-left. He only says that bitmaps in memory should be like this, exactly as it is actually with the official SDK. That way, if you embed bitmaps in the FXE you don't need to allocate more memory to rotate them. Actually I always embed bitmap in my games as I found it easier to install, and for the moment I didn't find the need to put the bitmaps outside the FXE.
But it's clear that function calls must always have 0,0 at top-left.

 

[pea]

we should change to pre-rotated bitmap at any cost it's just the native mem alignment of the gp32... in my own functions I also use the real (0,0) in the bottom left because it's where mem of the framebuffer begins ....

Well, synchro can confirm, but it does look like he's saying that in my own functions I also use the real (0,0) in the bottom left as well as pre-rotated bitmaps

I have a couple more functions running well now (blitting using an alpha mask, and drawing a rect using an alpha mask - I use this, for example, to draw clouds, where the rect is white, and the alpha mask is cloud shaped). I still need to benchmark them to see if I can get some speed improvements (because, for example, it still uses a multi-level alpha LUT which is probably not as fast as one big LUT for this implementation).