GP2X Hw Accelerated Sdl


Sorry, if I wasnt so retarded I would have seen the link above - tis working now, thanks!
 
Paeryn, thanks for the heads up on SDL_mixer. It worked with a bit of...work. Thanks! This is the best accelerated SDL I've seen across many handhelds I've worked on! Great job. I'll see if I can find some way to help it along sometime. Oh yeah, are you still taking PayPal donations to the email in your sig?
 
I used paeryn's build from the top of the page and usb joystick is definitely working in this release, previous build (ages ago, july or something) it would crash on initialisation.

Great news as usb joystick support was broken in Squares and now I can add four player with usb joystick support :)
 
I just switched over to to using the HW libs in this toolchain:

http://archive.gp2x.de/cgi-bin/cfiles.cgi?0,0,0,0,14,1918

And now I get a crash when I quit my game (grow). I'd like to get them working because I get a pretty nice speed boost with them (I was using the official SDK before), but I can't track down the crash. I set up USB networking last night and the output didn't give me much to go on... However, USB networking is totally buggy as well. I couldn't get it to connect again, so I can't get the output for you.

Any ideas on this? I figured out how to hide the cursor from this thread, but I didn't see anything about crash on quit.

(btw - I also tested the newest libs from this thread but they ran slower for me... probably something to do with HW surfaces since I do a ton of SDL_FillRect calls directly on the screen.)
 
Okay, I'm officially an idiot :)

#ifdef GP2X
chdir("/usr/gp2x");
execl("/usr/gp2x/gp2xmenu", "/usr/gp2x/gp2xmenu", NULL);
#endif

In the process of switching over to this new toolchain I had to write a Makefile and I didn't pass in -DGP2X to gcc... So the game didn't crash, it just didn't start up the menu again. Whoops!
 
Okay, I'm officially an idiot :)

#ifdef GP2X
chdir("/usr/gp2x");
execl("/usr/gp2x/gp2xmenu", "/usr/gp2x/gp2xmenu", NULL);
#endif

In the process of switching over to this new toolchain I had to write a Makefile and I didn't pass in -DGP2X to gcc... So the game didn't crash, it just didn't start up the menu again. Whoops!
There are lots of ways to fat-finger the development and you have just been poked in the eye by one of them. I did the same thing but I passed the define. But in my code I miss-spelled the name in the #ifdef. I just plead temporary insanity.
 
Last edited by a moderator:
hey,

i've run into the problem of having the screen going up with 5 pixels as well as described in some previous posts.

i'm not sure if it's related to the libaries or not but when i compile with an older version i don't have the problem.

If i set tv out mode in the (default) menu and then run the game all is still normal however if i quit the game and don't restart the menu, tv out mode will be lost but u can still run the game from a telnet session back in lcd mode then i get that screen shifted up with 5 pixels problem

The same happens when i rename my "game.gpe" to "game" and use a script to start "game" and then start the using the script in the default menu while being in tv out mode. all is still normal at this point however again if i quit the game and go to the default menu again (using the script) and switch back to lcd mode and then restart the game then i have the screen shifted up problem as well.

thing is it doesn't happen if i recompile with an older version of the libary so it might still be a libary problem. can u test this out ?

i'm using the older version again for the time being till this is sorted out
 
I've now tried to compile the current SDL which I got from the Open2X SVN repository (at revision 236).
If I compile it without GP2X_DEBUG beeing defined i run into problems when I execute my demo application.
Specifically it crashes the whole GP2X when I hit Ctrl-C to terminate my program (I work over a telnet connection).
When I compile with GP2X_DEBUG defined everything works just fine but many text messages are output.

I've looked through the source for GP2X_DEBUG but everywhere there was just a fprintf or a fputs and nothing else.

Does anyone have a clue about what might cause this glitch?
 
you might be overwriting something in memory that the GP2X_DEBUG changes that you dont see, and when its removed you overwrite something required...

since your telnetting in, GDB it..
 
YakumoFuji said:
you might be overwriting something in memory that the GP2X_DEBUG changes that you dont see, and when its removed you overwrite something required...

since your telnetting in, GDB it..
I looked through all the occurences of GP2X_DEBUG in the source and the only code which is between #ifdef GP2X_DEBUG #endif is either a fprintf or a fputs outputting something to stderr. Nothing that is supposed to be required!
How would I GDB it?? I don't have GDB on the GP2X!

--------------------

Something else that might be useful: While writing a software rasterizer I realized that the HW accelerated SDL always waits for vsync when double buffering. Without vsync i can reach a higher framerate.
Following is a patch that adds a SDL_GP2X_Vsync function which allows one to control if vsync should be enabled or disabled. The default is to be enabled just like the unmodified SDL.

CODE

Index: include/SDL_gp2x.h
===================================================================
--- include/SDL_gp2x.h (revision 236)
+++ include/SDL_gp2x.h (working copy)
@@ -31,7 +31,9 @@
void SDL_GP2X_AllowGfxMemory(char *start, int size);
void SDL_GP2X_DenyGfxMemory(char *start, int size);

+void SDL_GP2X_Vsync(int enable);

+
#ifdef __cplusplus
}
#endif
Index: src/video/gp2x/SDL_gp2xvideo.c
===================================================================
--- src/video/gp2x/SDL_gp2xvideo.c (revision 236)
+++ src/video/gp2x/SDL_gp2xvideo.c (working copy)
@@ -182,6 +182,7 @@

device->hidden->mouse_fd = -1;
device->hidden->keyboard_fd = -1;
+ device->hidden->wait_for_vsync = 1;

// Set the function pointers
device->VideoInit = GP2X_VideoInit;
@@ -803,11 +804,13 @@
GP2X_DummyBlit(this);
do {} while (data->fio[MESGSTATUS] & MESG_BUSY);

- // wait for vblank to start, choose transition type by polarity
- if (data->vsync_polarity)
- do {} while ((data->io[GPIOB_PINLVL] & GPIOB_VSYNC));
- else
- do {} while (!(data->io[GPIOB_PINLVL] & GPIOB_VSYNC));
+ if (data->wait_for_vsync) {
+ // wait for vblank to start, choose transition type by polarity
+ if (data->vsync_polarity)
+ do {} while ((data->io[GPIOB_PINLVL] & GPIOB_VSYNC));
+ else
+ do {} while (!(data->io[GPIOB_PINLVL] & GPIOB_VSYNC));
+ }

// Wait to be on even field (non-interlaced always returns 0)
// do {} while (data->io[SC_STATUS] & SC_DISP_FIELD);
@@ -1548,3 +1551,9 @@
SDL_PrivateVideoData *data = current_video->hidden;
data->allow_scratch_memory = 0;
}
+
+void SDL_GP2X_Vsync(int enable)
+{
+ SDL_PrivateVideoData *data = current_video->hidden;
+ data->wait_for_vsync = enable;
+}
Index: src/video/gp2x/SDL_gp2xvideo.h
===================================================================
--- src/video/gp2x/SDL_gp2xvideo.h (revision 236)
+++ src/video/gp2x/SDL_gp2xvideo.h (working copy)
@@ -97,6 +97,7 @@
int x_offset, y_offset, ptr_offset;
int w, h, pitch;
int vsync_polarity;
+ int wait_for_vsync;
int phys_width, phys_height, phys_pitch, phys_ilace;
int scale_x, scale_y;
float xscale, yscale;




Maybe this is useful and might be integrated into the hw accelerated SDL.
 
Last edited by a moderator:
Yes, that certainly is useful. I've been wondering how to disable vsync for a while, thanks :).
 
Orkie said:
Yes, that certainly is useful. I've been wondering how to disable vsync for a while, thanks :).
Damn! I tested it previously but had the wrong setup in my program. When you disable vsync, use doublebuf and directly render to the screen surface I get heavy flickering.

So all this is unneded. Just don't request SDL_DOUBLEBUF and render to a different surface instead and then blit that to the screen. This also circumvents any vsync as we don't have double buffering and does not flicker.
 
Last edited by a moderator:
That's why double buffering always v-syncs, without it you end up drawing on the buffer that is visible a lot of the time which kind of defeats the object of double buffering.
If people really want to be able to disable vsync with double buffering I'll add it, but I'll enforce a no-writing to the visible buffer so all drawing to the screen will be done to a back surface which will be blitted on a Flip() like you (Trenki) said. Bear in mind that tearing can (will) happen, but it's better than the flickering.

As to the GP2X_DEBUG, I defined it with the sole intention of using it to section off the outputs to stderr. So either I've unintentionally put some other code into a DEBUG section or the compiler is making some optimisation that messes up - I'll look into it, and having GDB on the GP2X is very useful ;-)
 
So the flickering I am experiencing is caused by screen->pixels pointing to the visible memory area?
When double buffering screen->pixels should always point to the currently unvisible memory area. This should avoid the flickering and so you could also avoid the Blit(), which might be marginally faster.
 
Just disabling v-sync like you tried prevents SDL from ensuring that screen->pixels won't be pointing at the visible surface.
Decoupling v-sync from the double-buffering as I've implemented it requires a separate method which won't be able to take advantage of the hardware's ability to change the start address of the screen, but instead requires blitting a working surface onto the visible surface which will have the side-effect of the display showing the previous frame in the top part of the screen and the new frame in the bottom. Where this division is will be dependent on how far away from the v-sync the call to Flip() is.
 
paeryn have you found out something regarding the crash when SDL is compiled without GP2X_DEBUG defined?

Also a question regarding the used of the mmuhack kernel module with SDL: From looking at the latest SDL source from the open2x svn i can tell that SDL always mmaps the whole upper 32MB of memory. If i then use the mmuhack all the upper memory will be marked as cachable. But when I want to execute something on the second CPU (e.g. gpu940) which requires some memory for communication I will run into problems since the memory is cached, won't I? Also using the flush_uppermem_cache function will probably not always work when I need to read back results from the second CPU.

How would I go about preventing these problems? Recompile SDL in a way that it does not use all the upper 32 MB of memory? Any other/better solutions?
 
I've read the readme but one point is still unclear!

What if I initialize SDL (which mmaps ALL the upper memory), and then apply the mmuhack -> now all the upper memory is cachable/bufferable. If i then mmap some region in the upper memory (which was already mapped by SDL) I suppose this region will be cachable/bufferable without applying the mmuhack again (since it is a part of the already mmapped memory of SDL).
Is this true or will this second mmap return a pointer which will not be cached/buffered? If so why/how?
I will try this out with the example program from the mmuhack but at this time I don't have access to my GP2X.

Edit: I tested it now with the example program included in the mmuhack_fixed archive. It seems that even if mmapping exactly the same memory region a second time but this time after the mmuhack has been applied does not automatically make this new region also cached. So all problems solved. Another question that arises: What if I SDL_CreateRGBSurface after applying the mmuhack? I suppose it will be cached since it will point somewhere in the memory that SDL mmapped?
 
Back
Top