GP2X Hw Accelerated Sdl

[Sonic-NKT]

would this also allow a fast or smooth zoom funktion, like scale 640 down to 320 and when you push a button and its scrollable 640... would be good for rts games like TTD.

EDIT:
@DJwillis, are you planning to use this on the fly scaler for for scummvm and games like monkey3?

 

[paeryn]

would this also allow a fast or smooth zoom funktion, like scale 640 down to 320 and when you push a button and its scrollable 640... would be good for rts games like TTD.

​

Scaling seems to be fairly easy, I was playing around with it last night. I've not looked into how SDL handles scaling, but I was thinking along the lines of you specifying an area to show to the full screen via an SDL_Rect. That's pretty near to what the hardware does.
The display scaler shouldn't incur any overhead as it doesn't filter (so zooming in gives you blocky pixels, zooming out skips pixels).
One thing I did notice is with the flickering/visible scanlines, to me it's looking more likely the LCD dithering the colours that's the culprit.

 

[Hanz™]

Nice work, it would be brilliant if you could add support for scaling, and get rid of any of the limitations/bugs that SDL has with the GP2X.

 

[gfoot]

One thing I did notice is with the flickering/visible scanlines, to me it's looking more likely the LCD dithering the colours that's the culprit.

​

Yes, I found the same thing when testing hardware scrolling. If you draw light coloured horizontal lines on a white background, and move them up or down steadily 1 pixel per frame, they totally vanish sometimes, depending exactly when you start scrolling them. Sticking to more solid colours may reduce the effect.

 

[DJWillis]

One thing I did notice is with the flickering/visible scanlines, to me it's looking more likely the LCD dithering the colours that's the culprit.

​

Thats the problem that is bothering me with trying to get virtual surfaces working that scale on the fly. Flickering like mad. Not nice to look at.

 

[zeGouky]

Hello World,

i have tested your lastest version with Nebulus & Airball and here's the result :

- Nebulus : well black screen , doesnt work - 16 bit mode -
- Airball : the game run much more smoothly but the palette is now wrong :-/ - 8 bit mode -

Keep up the good work ^^

 

[paeryn]

Hello World,

i have tested your lastest version with Nebulus & Airball and here's the result :

- Nebulus : well black screen , doesnt work - 16 bit mode -
- Airball : the game run much more smoothly but the palette is now wrong :-/ - 8 bit mode -

Keep up the good work ^^

​

Not sure why 16bit isn't doing owt, any chance of your source-code so I can track the problem down? (My dev version of SDL is not for the faint-heared, or sane)
8bit is only just supported, some of the palette routines don't work (basically only SDL_SetColors).
I'll be re-writing what I've done over the next few days, hopefully any bugs due to my rather ad-hoc style will get sorted.

 

[zeGouky]

Well in Airball im using SDL_SetColors

Sadly i cannot give you the sourcecode, but i can give you much info as i can.

 

[chris_r]

So how do I use this? Do i just exchange SDL_SWSURFACE for SDL_HWSURFACE or have you written some equivalent functions that use the hardware?

 

[paeryn]

So how do I use this? Do i just exchange SDL_SWSURFACE for SDL_HWSURFACE or have you written some equivalent functions that use the hardware?

​

Yup, simple as that. RectFill and BlitSurface will (should) automatically use hardware acceleration when used on surfaces with HWSURFACE (BlitSurface needs both surfaces to be HWSURFACES).
There's still the odd times where it doesn't work properly, if you have any problems with it let me know and I'll do my best to sort it out as quick as I can.

 

[chris_r]

Do I need anything else? It's been a long time since i tried to learn sdl (and didnt get very far) but SDL_HWACCEL springs to mind, despite the fact I have completely forgotten how to use it

 

[slygamer]

paeryn, have you released your latest source yet? I'm using your source and this thread as a reference to get my own code using the hardware blitter. I haven't had much luck yet though.

Edit: Ok, got it working, but only for blits that are wholly within the screen. My clipping to the screen edges must be giving bad values somewhere.

Note: I'm not using SDL. Just getting the hardware blitter working in my own app.

 

[paeryn]

paeryn, have you released your latest source yet? I'm using your source and this thread as a reference to get my own code using the hardware blitter. I haven't had much luck yet though.

Edit: Ok, got it working, but only for blits that are wholly within the screen. My clipping to the screen edges must be giving bad values somewhere.

Note: I'm not using SDL. Just getting the hardware blitter working in my own app.

​

The unreleased source isn't that much different, most of the new stuff was a hack to support 8-bit (/dev/fb doesn't). I'm re-writing it all in a (hofeully) cleaner way, may have it ready for the weekend or just after.

 

[slygamer]

Rlyeh supports 8-bit using /dev/fb in his Minimal SDK. You might want to check out his approach.

http://retrodev.info

Edit: I now have blitter working, but it locks up occasionally. Still trying to track that one down.

 

[paeryn]

Rlyeh supports 8-bit using /dev/fb in his Minimal SDK. You might want to check out his approach.

http://retrodev.info

Edit: I now have blitter working, but it locks up occasionally. Still trying to track that one down.

​

Not quite. /dev/fb only ever sets 16-bit mode. The only way to get 8-bit is to poke the hardware directly, after opening /dev/fb. And that's how Rlyeh's doing it.

The blitter seems to be hit-and-miss at times, I've wasted hours battling it - there doesn't seem to be a pattern as to when it locks. I wish MagicEyes would give us up-to-date docs for it.

 

[Firefox]

Yup, don't forget any memory >32mb is out of Linux's grasp, so has the default attributes of no caching whatsoever. It is also the only memory that can be blitted, as it's physical rather than virtual and is guaranteed not to be cached.

Ah, that's a little gem! Thanks Squidge!

 

[slygamer]

The blitter seems to be hit-and-miss at times, I've wasted hours battling it - there doesn't seem to be a pattern as to when it locks. I wish MagicEyes would give us up-to-date docs for it.

​

The blitter is hit and miss alright. I've got a dummy blit function the same as yours, but I had to remove the wait at the start because sometimes it would get there and just wait forever, especially after I had done a blit that was clipped to the right edge of the screen so the width of the blit was not a nice power of two type number.

Also, if I clip the blit to the left or right edge of the screen, I get the blitted image scrolling or folding over itself. It's quite hard to describe, but I am sure I've got something wrong with the source address and the source fraction. I'm just not sure what I've got wrong.

I also have a problem where if I draw anything to the last line on the screen, somewhere between x = 40 and x = 80 (or thereabouts), about 8 pixels of this is duplicated in the bottom right corner of the screen. This is also evident in my effort at getting TinyGL running, so this is not just a blitter issue either. The strangest thing is that it doesn't show up in a screengrab (copy of the frame buffer to a BMP file).

The joys of a badly documented chipset.

 

[paeryn]

The blitter seems to be hit-and-miss at times, I've wasted hours battling it - there doesn't seem to be a pattern as to when it locks. I wish MagicEyes would give us up-to-date docs for it.

​

The blitter is hit and miss alright. I've got a dummy blit function the same as yours, but I had to remove the wait at the start because sometimes it would get there and just wait forever, especially after I had done a blit that was clipped to the right edge of the screen so the width of the blit was not a nice power of two type number.

Also, if I clip the blit to the left or right edge of the screen, I get the blitted image scrolling or folding over itself. It's quite hard to describe, but I am sure I've got something wrong with the source address and the source fraction. I'm just not sure what I've got wrong.

Not seem that problem, I'll check mine on clipping just in-case.

I also have a problem where if I draw anything to the last line on the screen, somewhere between x = 40 and x = 80 (or thereabouts), about 8 pixels of this is duplicated in the bottom right corner of the screen. This is also evident in my effort at getting TinyGL running, so this is not just a blitter issue either. The strangest thing is that it doesn't show up in a screengrab (copy of the frame buffer to a BMP file).
The joys of a badly documented chipset.

​

This I've seen. The images on the menus do this too. From playing around trying to get rid of the scan-lines, I think this may be data left on the bus somewhere as the moment the scaler touches it (even with negligable scaling) it goes away, it's definately not in memory.

I've got a cold that's draining me at the mo, so I'm behind on my SDL upadate, and these problems with the hardware aren't helping. Good luck with what you're upto and let us know if you find anything.

 

[slygamer]

Still working on the clipping problem. With my test case, I have a 32x32 tile that I move around the screen with the joystick. It seems to be only on the right edge of the screen, ie. the width of the blit changes but the source address stays the same. The thing is, if I move the 32x32 tile off the right edge, the tile will seem to scroll within itself. Then I move the tile back onto the screen and it will remain screwed up for perhaps a second, perhaps two seconds, or sometimes much longer. Then it will snap itself back to the correct image. It was while it was screwed up that the wait for idle in my dummy blit routine would sometimes wait forever.

How do you do a blit of width=1? If I move the 32x32 tile off the left edge so that only one column of pixels is left visible, it blits corruption in lines across the screen.

 

[gfoot]

I had similar issues in Allegro. You need to flush the source data before starting a new blit - I posted the flag earlier in this thread I think? basically if the previous blit was not a multiple of 32 bytes (mine were 48) the last few don't get written, and they get written at the start of the next blit instead, offsetting everything else. It's something like adding SRC_FFCLR to your source control register I think.

The hardware blitting in Allegro seems to work really well at the moment, it's basically the same as paeryn's code though so I don't know why there would be discrepencies. I also get the weirdness in the bottom right corner. I have had reports from one person that my parallax demo fails to start, apparently failing during the initial clearing of the screen, which uses paeryn's rectfill method. It always fails for him, but never for me, though it's the same code. Weird.

Edit: Width 1 rectfills work for me, I use them for drawing vertical lines. Just pass... 1. Are you sure you weren't clipping all the way down to zero?