can probably dig one up from work machine @ some stage after w/end.
just libsdl or ttf && mixer etc?
Last edited by a moderator:
GP2X Hw Accelerated Sdl
- Thread starter paeryn
- Start date
just libsdl or ttf && mixer etc?
zodttd
Solving your premature emulation since the Tapwave
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?
Guyfawkes
Certified Idiot :)
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
Great news as usb joystick support was broken in Squares and now I can add four player with usb joystick support
dockthepod
Member
- Joined
- Jun 15, 2006
- Messages
- 250
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.)
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.)
dockthepod
Member
- Joined
- Jun 15, 2006
- Messages
- 250
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!
#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!
gmiller1018
Member
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.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!
Last edited by a moderator:
joyrider
Active Member
thanks for the latest version been out a while, have had no problems with it so far
joyrider
Active Member
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 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
Trenki
Member
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?
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?
YakumoFuji
Member
- Joined
- Sep 30, 2005
- Messages
- 189
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..
since your telnetting in, GDB it..
Trenki
Member
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!YakumoFuji said:
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:
Orkie
Super Duper Mega GP Mania
Yes, that certainly is useful. I've been wondering how to disable vsync for a while, thanks .
.Trenki
Member
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.Orkie said:Yes, that certainly is useful. I've been wondering how to disable vsync for a while, thanks
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:
paeryn
Reclusive maniac
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 ;-)
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 ;-)
Trenki
Member
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.
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.
paeryn
Reclusive maniac
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.
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.
Trenki
Member
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?
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?
Hooka
That Guy!
Trenki: read the readme in mmu_fixed, it will explain how to do what you want
Trenki
Member
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?
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?
