GP2X Ridiculous Drawing Speeds With Sdl

[Entropia]

I have recently acquired my GP2X and started porting some of my old demoscene effects to it, the problem is ridiculously slow rendering speeds with SDL. I am using Octoate's toolchain and AFAIK it includes Paeryn's HW accelerated SDL libs. I have written a simple "fill every pixel one by one" program using pixelRGBA-function (the only one I could find to replace putpixel). With my surface inited as SW_BUFFER, filling a screen takes over 10 seconds and with HW_BUFFER it's still nearly half a second! :blink: I'm guessing the pixelRGBA isn't the fastest function to use? What should I use/do instead?

 

[DrDerekDoctors]

If you're doing things a pixel at a time aren't you meant to lock the surface first for speed (disables clipping so you aren't doing 76,800 "is this pixel inside the screen buffer?" checks)? Either way, doing things a pixel at a time is gonna' be horrifically slow in comparison to just blitting whole sprites.

Of course, I could be talking out my arse with regards to the GP2X as this is just in general terms.

 

[Feeblez]

I have recently acquired my GP2X and started porting some of my old demoscene effects to it, the problem is ridiculously slow rendering speeds with SDL. I am using Octoate's toolchain and AFAIK it includes Paeryn's HW accelerated SDL libs. I have written a simple "fill every pixel one by one" program using pixelRGBA-function (the only one I could find to replace putpixel). With my surface inited as SW_BUFFER, filling a screen takes over 10 seconds and with HW_BUFFER it's still nearly half a second! :blink: I'm guessing the pixelRGBA isn't the fastest function to use? What should I use/do instead?

You code demoscene effects and using putpixel!? :blink:

Sorry, i don't know anything about SDL, but like DrDerekDoctors said, you should be able to lock the screen buffer and get direct pointer access, that should be a lot faster.

 

[Entropia]

I have recently acquired my GP2X and started porting some of my old demoscene effects to it, the problem is ridiculously slow rendering speeds with SDL. I am using Octoate's toolchain and AFAIK it includes Paeryn's HW accelerated SDL libs. I have written a simple "fill every pixel one by one" program using pixelRGBA-function (the only one I could find to replace putpixel). With my surface inited as SW_BUFFER, filling a screen takes over 10 seconds and with HW_BUFFER it's still nearly half a second! :blink: I'm guessing the pixelRGBA isn't the fastest function to use? What should I use/do instead?

You code demoscene effects and using putpixel!? :blink:

Sorry, i don't know anything about SDL, but like DrDerekDoctors said, you should be able to lock the screen buffer and get direct pointer access, that should be a lot faster.

Oldskool! Anyways, I'll try locking my surface before tossing anything on the actual screen.

 

[paeryn]

I have recently acquired my GP2X and started porting some of my old demoscene effects to it, the problem is ridiculously slow rendering speeds with SDL. I am using Octoate's toolchain and AFAIK it includes Paeryn's HW accelerated SDL libs. I have written a simple "fill every pixel one by one" program using pixelRGBA-function (the only one I could find to replace putpixel). With my surface inited as SW_BUFFER, filling a screen takes over 10 seconds and with HW_BUFFER it's still nearly half a second! :blink: I'm guessing the pixelRGBA isn't the fastest function to use? What should I use/do instead?

You code demoscene effects and using putpixel!? :blink:

Sorry, i don't know anything about SDL, but like DrDerekDoctors said, you should be able to lock the screen buffer and get direct pointer access, that should be a lot faster.

Oldskool! Anyways, I'll try locking my surface before tossing anything on the actual screen.

Accessing a HWSURFACE directly is slow, that's the price you have to pay for having quick access by the accelerated methods (Blit & FillRect). HWSURFACEs are not cached and can have memory access times of as low as 40% compared to reading/writing to main memory - worse if you only access with 8 or 16 bit values at a time.

The proper way of writing directly to a surface is as said above:
1: Just before you start writing to a surface call SDL_LockSurface() to make sure that SDL has finished any async operations with it.
2: Grab the surface's bitmap address, stride, anything else you need.
3: Do what you want to the surface's pixels, try to make sure you write 32bit values (2 or 4 pixels at a time).
4: Unlock the surface to allow SDL's async functions to resume.

At no time between Lock() and Unlock() should you make calls to BlitSurface() and FillRect(). Ideally you shouldn't make any calls to SDL functions when a surface is locked to avoid entering a deadlock.

 

[Entropia]

I have recently acquired my GP2X and started porting some of my old demoscene effects to it, the problem is ridiculously slow rendering speeds with SDL. I am using Octoate's toolchain and AFAIK it includes Paeryn's HW accelerated SDL libs. I have written a simple "fill every pixel one by one" program using pixelRGBA-function (the only one I could find to replace putpixel). With my surface inited as SW_BUFFER, filling a screen takes over 10 seconds and with HW_BUFFER it's still nearly half a second! :blink: I'm guessing the pixelRGBA isn't the fastest function to use? What should I use/do instead?

You code demoscene effects and using putpixel!? :blink:

Sorry, i don't know anything about SDL, but like DrDerekDoctors said, you should be able to lock the screen buffer and get direct pointer access, that should be a lot faster.

Oldskool! Anyways, I'll try locking my surface before tossing anything on the actual screen.

Accessing a HWSURFACE directly is slow, that's the price you have to pay for having quick access by the accelerated methods (Blit & FillRect). HWSURFACEs are not cached and can have memory access times of as low as 40% compared to reading/writing to main memory - worse if you only access with 8 or 16 bit values at a time.

The proper way of writing directly to a surface is as said above:
1: Just before you start writing to a surface call SDL_LockSurface() to make sure that SDL has finished any async operations with it.
2: Grab the surface's bitmap address, stride, anything else you need.
3: Do what you want to the surface's pixels, try to make sure you write 32bit values (2 or 4 pixels at a time).
4: Unlock the surface to allow SDL's async functions to resume.

At no time between Lock() and Unlock() should you make calls to BlitSurface() and FillRect(). Ideally you shouldn't make any calls to SDL functions when a surface is locked to avoid entering a deadlock.

Poking the memory directly sounds reasonable. I just don't know how to do it in practice. :unsure: Any examples would be greatly appreciated.

 

[Drag]

The way I do it on PC is by having

u16* FrameBuffer;

and then every time I lock the surface, I do this:

FrameBuffer = ((u16*)[SDL_Surface goes here]->pixels);

And then in my game code (which I generally keep in a seperate file from the SDL code), I fill the screen like this:

for (int x = 0; x < (320*240); x++)
	 FrameBuffer[x] = [some color];

Or I calculate the array index something like this:

FrameBuffer[x + (y * 320)] = [some color];

But I don't know if that's fast at all. Basically, I manipulate the screen completely manually when I use SDL, which probably isn't as fast as it would be otherwise, but whatever.