Uae4all Amiga Emulator Port To Gp2x

[WhiteFalcon]

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.

 

[feddon]

yeh i agree with whitefalcon the menus are alot faster but ingame theres isnt a noticable increase in speed.

 

[skeezix]

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

 

[woogal]

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).

 

[critical]

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.

 

[critical]

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.

 

[woogal]

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).

 

[skeezix]

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

 

[critical]

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.

 

[critical]

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.

 

[feddon]

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

 

[Fortress Mark]

Thanks Critical for all the work on this, one this once its 100% I will definitly be donating some money your way, this is to good an emulator not to.

 

[WhiteFalcon]

Very anxious to see new version How is it progressing?

 

[critical]

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

 

[WhiteFalcon]

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!

 

[feddon]

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!

 

[critical]

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.

 

[WhiteFalcon]

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.

 

[critical]

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.

 

[WhiteFalcon]

I meant this. Just wondering what the cause is.