Uae4all Amiga Emulator Port To Gp2x


My batteries died quickly when testing, but so far I noticed mainly a large speedup of the menu, which is now probably too fast. I have not yet noticed any ingame speedup.
 
yeh i agree with whitefalcon the menus are alot faster but ingame theres isnt a noticable increase in speed.
 
critical posted on Feb 5 2006 at 08:38 AM said:
Iorgy77 posted on Feb 5 2006 at 01:31 PM said:
Thank you for your continued work on this critical. :)
No probs - it's a good learning experience for me, as it's my first gp2x app, and I've never used SDL before ;)

SDL is good in a lot of places; on a gp2x, I'd say its just a crutch -- makes it easier to get started, but it likely costs a couple of percent performance and doesn't really help much in the logn run.. so one option is to ditch it. ie: Rlyeh's minilib makes things pretty easy.. it does the basic initialization and gives you the framebuffer pointer, so just draw direct to framebuffer. Using an SDL layer inbetween means you might have extraneous backbuffers if you don't need them, and other light overhead.

So if you dont' need a backbuffer, but SDL is giving you one, you'd lose a lot of performance; if you need one, then onyl a few % lost..

jeff
 
Last edited by a moderator:
skeezix posted on Feb 6 2006 at 04:41 PM said:
SDL is good in a lot of places; on a gp2x, I'd say its just a crutch -- makes it easier to get started, but it likely costs a couple of percent performance and doesn't really help much in the logn run.. so one option is to ditch it. ie: Rlyeh's minilib makes things pretty easy.. it does the basic initialization and gives you the framebuffer pointer, so just draw direct to framebuffer. Using an SDL layer inbetween means you might have extraneous backbuffers if you don't need them, and other light overhead.
I don't have a clue why, but access to the framebuffer through the latest SDL is actually quicker than minilib (well, in my tests at least).
 
Last edited by a moderator:
skeezix posted on Feb 6 2006 at 05:41 PM said:
SDL is good in a lot of places; on a gp2x, I'd say its just a crutch -- makes it easier to get started, but it likely costs a couple of percent performance and doesn't really help much in the logn run.. so one option is to ditch it. ie: Rlyeh's minilib makes things pretty easy.. it does the basic initialization and gives you the framebuffer pointer, so just draw direct to framebuffer. Using an SDL layer inbetween means you might have extraneous backbuffers if you don't need them, and other light overhead.
Thanks for the advice, Skeezix. I might just do that for the main rendering code.
 
Last edited by a moderator:
woogal posted on Feb 6 2006 at 06:02 PM said:
I don't have a clue why, but access to the framebuffer through the latest SDL is actually quicker than minilib (well, in my tests at least).
Which SDL libs are you using? I linked against the pre-compiled ones that were availble for download here:

http://www.gp32x.de/board/index.php?act=ST&f=45&t=23819

I didn't notice a huge difference when using SW_SURFACE, but moving to HW_SURFACE made the menu run on speed. Shame it didn't do the same elsewhere. I don't use the SDL_DOUBLEBUF flag, as that sends things really wild and flickering.
 
Last edited by a moderator:
critical posted on Feb 6 2006 at 05:07 PM said:
woogal posted on Feb 6 2006 at 06:02 PM said:
I don't have a clue why, but access to the framebuffer through the latest SDL is actually quicker than minilib (well, in my tests at least).
Which SDL libs are you using? I linked against the pre-compiled ones that were availble for download here:

http://www.gp32x.de/board/index.php?act=ST&f=45&t=23819

I didn't notice a huge difference when using SW_SURFACE, but moving to HW_SURFACE made the menu run on speed. Shame it didn't do the same elsewhere. I don't use the SDL_DOUBLEBUF flag, as that sends things really wild and flickering.
I'm also using the pre-compiled ones.
If you're using hardware and you get flickering with doublebuf then I'd guess you're setting up a variable that points to screen->pixels and then writing to that. Quake works in that way and it also flickers like hell if doublebuf is used (I'm assuming it's because it's only ever writing to one buffer). I can't be bothered changing it though because I discovered that in quakes case sw_surface is quicker than hw_surface (I think it's always like that if you're writing directly to the pixels).
 
Last edited by a moderator:
My guess:

Double buffering leads to flicker if you're updating one buf and swapping to blank on the other :)

I've never looked into the HW accelerated SDL; it shoudl do good thing.s. draw to offscreen buffer, then use h/w to blit to framebuffer for 'free', so should be as good as drawing right to framebuffer.

But maybe he's tapped into some good stuff; generalyl a s/w buffer is best avoided, since you can usually better manage it yourself; its there in SDL since its handy to have a cross platform always works conveniance..

jeff
 
skeezix posted on Feb 6 2006 at 09:28 PM said:
My guess:

Double buffering leads to flicker if you're updating one buf and swapping to blank on the other :)

I've never looked into the HW accelerated SDL; it shoudl do good thing.s. draw to offscreen buffer, then use h/w to blit to framebuffer for 'free', so should be as good as drawing right to framebuffer.

But maybe he's tapped into some good stuff; generalyl a s/w buffer is best avoided, since you can usually better manage it yourself; its there in SDL since its handy to have a cross platform always works conveniance..

jeff
Squidge suggested in another thread (http://www.gp32x.de/board/index.php?showtopic=25425), using the blitter to do the frame blanking. At the moment the drawing routines are using memcpy and bzero to do their work, but on the dreamcast it uses some assembler instead. Any ideas where I could pinch some code to do that? I've PM'ed squidge about it, but he's a busy man, I'm sure.
 
Last edited by a moderator:
critical posted on Feb 6 2006 at 11:37 PM said:
uses some assembler instead. Any ideas where I could pinch some code to do that? I've PM'ed squidge about it, but he's a busy man, I'm sure.
yay, squidge kindly sent me his blitter code to clear the buffer. i'll have a crack at integrating it sometime today.
 
Last edited by a moderator:
dont have a clue what that means but hey, thaks squidge for the code and thanks critical for your continued work, this emu is getting better alll the time.

thanks
 
WhiteFalcon posted on Feb 9 2006 at 01:42 PM said:
Very anxious to see new version :) How is it progressing?
I've not had time to work on it as much as I'd have liked. This lunchtime I had a bit of a potter with cyclone (lots to do there, though), and yesterday I had the virtual keyboard working (badly).

I've cleared some space on the menu, and added the option to hide the status bar (that might help with some games that had their displays obscured by the bar).

Nothing's going to get released this lunchtime, anyway.

I haven't given up on it :)
 
Last edited by a moderator:
Cyclone, Virtual keyboard...
What great words to hear in this context :)

It is a long time since I have been kept so breathless waiting for every new version of an app ;o)

Good luck!
 
critical posted on Feb 9 2006 at 01:48 PM said:
I've not had time to work on it as much as I'd have liked. This lunchtime I had a bit of a potter with cyclone (lots to do there, though), and yesterday I had the virtual keyboard working (badly).

I've cleared some space on the menu, and added the option to hide the status bar (that might help with some games that had their displays obscured by the bar).

I haven't given up on it :)

sounds great, i was actually playing x-com yesterday, slowly but it was slow on the 500, so amazing, also hiding the status bar will make a couple more of my fave games playable (settlers, space crusade...) so really lookin forwardto this.

Keep it up!
 
Last edited by a moderator:
feddon posted on Feb 9 2006 at 10:32 PM said:
sounds great, i was actually playing x-com yesterday, slowly but it was slow on the 500, so amazing, also hiding the status bar will make a couple more of my fave games playable (settlers, space crusade...) so really lookin forwardto this.

Keep it up!
I don't think Settlers will work until sound support is in. I believe on other UAE-alikes people enable sound while it's loading, then disable it again in order to get it to work.
 
Last edited by a moderator:
I have been trying to get Furry of the Furries working with no luck so far. But the interesting thig is that the game is ECS/OCS and some parts display correctly while other (title screen and other static images) look as if only in 4 or so colors and most of the picture is black. I experienced this before when trying to run an AGA game. It looked very much like this, but Furries is not AGA. Any idea?

PS. The game then is corrupted and quickly causes a halt anyway, just wanted to ask about that.
 
WhiteFalcon posted on Feb 10 2006 at 01:34 PM said:
I have been trying to get Furry of the Furries working with no luck so far. But the interesting thig is that the game is ECS/OCS and some parts display correctly while other (title screen and other static images) look as if only in 4 or so colors and most of the picture is black. I experienced this before when trying to run an AGA game. It looked very much like this, but Furries is not AGA. Any idea?

PS. The game then is corrupted and quickly causes a halt anyway, just wanted to ask about that.
I'm not sure, to be honest. Furry of the Furries needs to write to disk at some point, which may be related to the crashing.

edit: it looks like it needs 2 meg of chip RAM, and I'm only providing it with 1 at the moment. I'll look into it.
 
Last edited by a moderator:
Back
Top