GP2X Hw Accelerated Sdl

[paeryn]

Hi Paeryn. First of all, thanks a lot for your work!

And now, my small problem. I've recompiled my program using your HW accelerated version of SDL, and if I keep the SDL_SWSURFACE flag in SDL_SetVideoMode everything works fine. But if I use SDL_HWSURFACE|SDL_DOUBLEBUF, bitmaps are not shown on screen. On the other hand, it shows two rectangles drawn using SDL_FillRect. I've read the posts about double buffering and SDL_Flip, and I think my problem is related to it, but I still don't know how to solve it.

The sequence of calls I use to draw every frame is:

if (SDL_MUSTLOCK(screen))
    if (SDL_LockSurface(screen) < 0)
        return;

// Clear the screen
SDL_FillRect(screen, NULL, SDL_MapRGB(screen->format, 0, 0, 0));

<here I draw bitmaps using SDL_BlitSurface and two small rectangles using SDL_FillRect>

if (SDL_MUSTLOCK(screen))
    SDL_UnlockSurface(screen);

SDL_Flip(screen);

As I said before, the rectangles are shown, but not the bitmaps. Any idea of what am I doing wrong?

​

Don't Lock the screen!!! Only do that if you're going to read/write directly to the bitmap. SDL_LockSurface() tells SDL that you're manipulating the bitmap yourself and it isn't to.
FillRect doesn't seem to check, but SDL_BlitSurface should be returning an error, you are checking it's return value aren't you?
From start of SDL_BlitSurface:

	if ( src->locked || dst->locked ) {
  SDL_SetError("Surfaces must not be locked during blit");
  return(-1);
	}

 

[rokdcasbah]

just wondering about interlacing + tv...aren't the fields in a tv frame drawn at a slight angle from horizontal? like less than 1 degree (or so i've heard)?

does that affect things? just curious.

 

[miq01]

Don't Lock the screen!!! Only do that if you're going to read/write directly to the bitmap. SDL_LockSurface() tells SDL that you're manipulating the bitmap yourself and it isn't to.
FillRect doesn't seem to check, but SDL_BlitSurface should be returning an error, you are checking it's return value aren't you?
From start of SDL_BlitSurface:

	if ( src->locked || dst->locked ) {
  SDL_SetError("Surfaces must not be locked during blit");
  return(-1);
	}

Removing the screen lock did. Thanks a lot! I thought SDL_LockSurface was needed each time I wanted to write to any surface, directly or not... :huh: Next time I'll read the SDL doc before asking... Sorry. And no, I wasn't checking SDL_BlitSurface's return value, but I'm working on XP using mingw32 and everything worked fine there.

The funny thing is that my app is much faster (between two and three times, depending on the amount of drawn bitmaps) when using SDL_SWSURFACE (I mean, using your libs of course). Also, when using SDL_HWSURFACE|SDL_DOUBLEBUF, the first 8 pixels on the top-left of the screen blink, while that doesn't happen when using SDL_SWSURFACE.

 

[chimpoid]

I tracked down that .ogg problem to the libSDL_Mixer file in the latest precompiled set.
I went back to an old version of my game source that I knew was healthy and ran the makefile. No .ogg audio. I then replaced theoddbots sdl libs and reset back to SWSURFACE. Recompiled and the audio was back.
Installed all HW_SDL libs except mixer and libSDL_Mixer it ran fine. Reset HWSURFACE. Still fine. Popped back in the HW_SDL mixer libraries and it stopped playing .ogg again.

I'm guessing it must be something got chewed when the libraries were compiled.(it's the precompiled ones I'm using). I'm going to stick with the standard mixer libraries though as it works well (and I have no idea how to cross compile the libs for arm )

Chimpoid

 

[deadlychicken22]

sorry if this sounds stupid, i'm new to c++ and SDL.....

so, with this I can use SDL_HWSURFACE? (and in turn SDL_DOUBLEBUF)

How would I go about setting this up in a windows environment?

thanks
-ben

 

[timbobsteve]

deadlychicken22:

you don't use these libs in windows... they are for the 2X. the windows libs already have support for SDL_HWSURFACE and SDL_DOUBLEBUFF .... if you want to compile these for mingw32 or something for use ON the GP2X then yeh.. try getting ooPo's scripts, opening them up and just using his make flags.

Hope that helps.

 

[deadlychicken22]

i know that these are for the gp2x, i'm sorry if my wording wasn't clear, i will try again:
What do I do under windows to get this linked to my compiler so that I can compile for the gp2x using them? I already have sdl setup following the gp2x user guide, and i am using dev-c++. Do i just copy these over to the same directory i have all of my other sdl files in? Do I have to add anything to my linker?

(warning: My terms may not be correct....)

 

[yaustar]

I would assume you just overwrite the library files (.a)

 

[Hanz™]

...

​

I agree, I would like a n00bs guide.

 

[Flavor]

...

​

I agree at I would like a n00bs guide.

​

Does this count?

 

[chimpoid]

Yes, just pop them in the libs folder overwriting the old versions that are there (referring to the precompiled ones).
For windows, im guessing c:/mygp2xdevfolder/libs/
Then just compile your application again. You can also then set HWSURFACE and double buffering in your application.

Chimpoid.

 

[paeryn]

Removing the screen lock did. Thanks a lot! I thought SDL_LockSurface was needed each time I wanted to write to any surface, directly or not... :huh: Next time I'll read the SDL doc before asking... Sorry. And no, I wasn't checking SDL_BlitSurface's return value, but I'm working on XP using mingw32 and everything worked fine there.

In places it does read as though you need to lock. When SDL talks about accessing surfaces it really means accessing outside of SDL's routines - very easy mistake to make.

The funny thing is that my app is much faster (between two and three times, depending on the amount of drawn bitmaps) when using SDL_SWSURFACE (I mean, using your libs of course). Also, when using SDL_HWSURFACE|SDL_DOUBLEBUF, the first 8 pixels on the top-left of the screen blink, while that doesn't happen when using SDL_SWSURFACE.

​

Depends on how much work you're doing in each frame. HWSURFACE|DOUBLEBUF locks the frame rate to ~60fps, if you take slightly longer than 1/60th of a second it drops to ~30, etc. The test program I use does 1 blit to the whole screen and blits 100 sprites on top and hits ~75fps without double-buffering.
About the 8 pixels in the top-left, I don't know why it does that sometimes. It's a dummy blit that's causing it, it's supposed to copy the pixels onto themselves but it sometimes gets it wrong. I'm changing the dummy blit in the next version so it'll go away then - don't worry about it.
Unfortunately that 'orrible thing called Real Life(tm) is getting in my way at the moment, I was hoping to have the next release done for last night, but it might have to wait until Monday. I'll see if I can squeeze some time in when I get up in the morning to upload a quick fix.

deadlychicken22: You can either compile and install the src, or if you use gcc4.02 you should get away with copying the pre-compiled ones over that you use now (don't forgget backups).

I really wany to take a week off with no commitments, no phone ringing, no appointments so I can sit down and code to my heat's comtent

 

[Radek]

I have an another question...

Can blitter move data to the cached area of ram?

Or it's working only "physically" so it's bypassing MMU/cache completely?

I have in a mind situation where blitter could be used to preprocess data (I would use mostly shifts) and fill the cache. Then the data could be processed by cpu. Not that the shifts are slow on Arm cpu but... I just used all registers for my routines and would like to have horizontal scrolling by 1 pixel (now have by 2). It's all so because I'm rendering the screen using scanline approach and the framebuffer is only touched once (for a final write).

 

[jbb]

BTW... is there a SDL function that flips the screen WITHOUT waiting for the VBL? Can't find it in the docs.

When your game runs at say 1.1 vbl, it is a shame to drop at 2 (30fps)... it was working great on the GP32, with you able to keep running in "almost a frame" (like 1.1 or 1.2) with still the feeling of being at 60Hz and virtually no tearing/glitching at all.

 

[slygamer]

The blitter only works with physical memory addresses.

 

[Radek]

The blitter only works with physical memory addresses.

​

So it's probably bypasing the mmu/cache entirely. That's good (it's closer to a memory so can get more bandwith) and bad (the cache can not be filled directly by it - extra one read from memory will be necessary anyway).

So back to the 920T/940T programming... I will try to use cache controller directly (via the "MRC") as it there is some potential for increased perfomance.

 

[miq01]

Depends on how much work you're doing in each frame. HWSURFACE|DOUBLEBUF locks the frame rate to ~60fps, if you take slightly longer than 1/60th of a second it drops to ~30, etc. The test program I use does 1 blit to the whole screen and blits 100 sprites on top and hits ~75fps without double-buffering.

My program is not very intensive in terms of the number of bitmaps drawn and its size, and it reaches exactly 60 fps. Now I understand why, thanks.

About the 8 pixels in the top-left, I don't know why it does that sometimes. It's a dummy blit that's causing it, it's supposed to copy the pixels onto themselves but it sometimes gets it wrong. I'm changing the dummy blit in the next version so it'll go away then - don't worry about it.

Well, those 8 pixels don't annoy me at all.

Unfortunately that 'orrible thing called Real Life(tm) is getting in my way at the moment, I was hoping to have the next release done for last night, but it might have to wait until Monday. I'll see if I can squeeze some time in when I get up in the morning to upload a quick fix.

Take it easy. As you'll have noticed, lots of games/ports/emus have been updated thanks to your libraries, so you have already done a great work for us.

 

[paeryn]

BTW... is there a SDL function that flips the screen WITHOUT waiting for the VBL? Can't find it in the docs.

When your game runs at say 1.1 vbl, it is a shame to drop at 2 (30fps)... it was working great on the GP32, with you able to keep running in "almost a frame" (like 1.1 or 1.2) with still the feeling of being at 60Hz and virtually no tearing/glitching at all.

​

Not yet, but I may add another function that'll allow you to disable the vsync. You can always not use DOUBLEBUF, that doesn't require you to call Flip() though it can cause quite bad flickering.

 

[Hanz™]

I would assume you just overwrite the library files (.a)

​

Well I worked it out, and it is all okay. woohoo.

 

[Flavor]

I have been in contact with paeryn about this, but I figured that I should post here just to see if anyone else has seen similar problems.

My game works rather well if I just use SDL_SWSURFACE. I would like to get a little more performance out of it, though, so I can play some background music without hesitations.

The game is all set up to use double buffering, so I have tried SDL_HWSURFACE|SDL_DOUBLEBUF. When I do this, everything works great at first, but after I run through a few levels (which loads new gfx), the graphics start to get corrupted. Usually this results in more and more garbage on the screen, but sometimes the GP2X locks up.

When I switch back to SWSURFACE, it all works great again. I know that paeryn is looking into it, but if anyone else has seen stuff like this, maybe you could chime in. It could help debug the problem.