Author Topic: Uae4All status (Read 20964 times)

Gab1975 · « **Reply #40 on:** May 06, 2014, 09:43:47 am »

In theory a port from the Pandora version should be possible, but it would require a total recompilation (the OpenPandora uses an ARM CPU)... moreover the Dingoo version of UAE4all requires less hardware resources, for now I would be satisfied with a full speed Amiga OCS emulation!

DrChaos · « **Reply #41 on:** May 06, 2014, 02:42:29 pm »

I second that. But the power shoudl be sufficient to do more, and teh Pandora version is much more advanced...

ker · « **Reply #42 on:** May 06, 2014, 03:19:37 pm »

Ok. I don't know what I'm done but I cannot make double or triple buffer work again. I'll upload sources so anyone with better skills can make it work correctly. Now it works but without double buffer.

Quote from: DrChaos on May 06, 2014, 02:42:29 pm

I second that. But the power shoudl be sufficient to do more, and teh Pandora version is much more advanced...

I'm just learning how all this thing works. Do you have a link to Pandora sources?

sm0ky · « **Reply #43 on:** May 06, 2014, 05:54:04 pm »

Quote from: ker on May 06, 2014, 03:19:37 pm

Ok. I don't know what I'm done but I cannot make double or triple buffer work again. I'll upload sources so anyone with better skills can make it work correctly. Now it works but without double buffer.

oh...okay. does that mean that you won't work any further on this port? anyways thanks a lot for your work so far

ker · « **Reply #44 on:** May 06, 2014, 07:13:57 pm »

Quote from: sm0ky on May 06, 2014, 05:54:04 pm

oh...okay. does that mean that you won't work any further on this port? anyways thanks a lot for your work so far

Yes, I will.. but I need more time to understand how all this works. Perhaps someone else has more knowledge and wants to help

sm0ky · « **Reply #45 on:** May 06, 2014, 07:30:07 pm »

alright - glad to hear that

if you need any testers, count me in

maybe one of the guys from hi-ban's post is able to help:

Quote from: hi-ban on May 05, 2014, 05:58:20 pm

If the screen flickers, it may be because of the double-buffering.
There is a way to fix that. Nebuleon, d_smagin or johhnyonflame will be able to explain that more accurately.

DrChaos · « **Reply #46 on:** May 06, 2014, 09:46:03 pm »

Quote from: ker on May 06, 2014, 03:19:37 pm

I'm just learning how all this thing works. Do you have a link to Pandora sources?

I found this:

http://boards.openpandora.org/topic/11236-beta-new-version-of-uae4all/page-7 Post #132

There was an update in January, but I could not find the source..

sm0ky · « **Reply #47 on:** May 10, 2014, 08:39:06 am »

hey ker, any news or progress updates regarding your work?

ker · « **Reply #48 on:** May 10, 2014, 02:08:51 pm »

Quote from: sm0ky on May 10, 2014, 08:39:06 am

hey ker, any news or progress updates regarding your work?

None. I'm following a SDL tutorial to know how it works. I'm still reading C book.

I've been also finishing another Dingux Atari port.

shirohagen · « **Reply #49 on:** May 10, 2014, 07:59:39 pm »

Also happy to test here!

And, as a graphic designer, happy to help with design and graphics...

?

Nebuleon · « **Reply #50 on:** May 10, 2014, 08:20:11 pm »

The way to "fix" double-buffering causing flickering is simply to draw the entire frame every frame, and not rely on pre-rendered areas.

Under single-buffering, you can avoid redrawing unchanged parts of the screen because you know that the buffer you draw into is the same every frame so you can take advantage of optimisations -- but your image may be written-to in the middle of the video driver reading from the screen, so you get epic tearing.

Under double-buffering, the buffer you get cycles between A and B every frame, so you can still take advantage of optimisations, but only if you're on a B frame and you're sure something is on the B frame, or if you're an A frame and you're sure something is on the A frame. It's safer to just redraw everything.

ker · « **Reply #51 on:** May 10, 2014, 11:01:12 pm »

Quote from: Nebuleon on May 10, 2014, 08:20:11 pm

The way to "fix" double-buffering causing flickering is simply to draw the entire frame every frame, and not rely on pre-rendered areas.

Under single-buffering, you can avoid redrawing unchanged parts of the screen because you know that the buffer you draw into is the same every frame so you can take advantage of optimisations -- but your image may be written-to in the middle of the video driver reading from the screen, so you get epic tearing.

Under double-buffering, the buffer you get cycles between A and B every frame, so you can still take advantage of optimisations, but only if you're on a B frame and you're sure something is on the B frame, or if you're an A frame and you're sure something is on the A frame. It's safer to just redraw everything.

Thanks for the advice. I'll take a look at code to find how stuff is beeing written. It's a bit hard for me at the moment, but I'll try

ker · « **Reply #52 on:** May 16, 2014, 11:50:25 pm »

Ok, I'm here again... always learning. I just want to share with you what I've seen so perhaps someone with more knowledfe could explain how to solve this problem.

I've not found the place where surface is partially updated, so I tried to understand what happens. I decided to write a green full rect in main surface after each SDL_Flip. This way I'm sure next SDL_Flip will had all surface changed (I've just found two SDL_surfaces: one for menu and another one for emulation called prSDLScreen). The result is this:
https://www.youtube.com/watch?v=2tFosSeI1R4

Soooo... I'm missing something. Now I'm sure surface is fully updated (at least all pixels are green after SDL_Flip) so I'm pretty sure next SDL_Flip will draw entire frame. Then.. why it's flickering? Perhaps some part of code is writting directly to SDL_Surface memory and SDL didn't know? I decided to create a new surface called real_surface and change all SDL_Flip. Now code just flips this new real_surface. Prior to each SDL_Flip I blit prSDLScreen into real_surface and then flip real_surface. This way I'm sure code don't paints directly to screen memory... and it works.

But, I know this is not the solution. I can now compile with double buffer, but with this two surfaces... I'm doing a quad buffer or what? I've tried some games and framerate doesn't change so now I'm not sure even that I'm using double buffer or not (framerate is low)

I don't know if anyone more clever has already done all this and I'm wasting my time with all this stuff...

If you want to try it,I've uploaded OPK to https://www.mediafire.com/?dckl5fz35t5581r (kick.rom expected at $HOME/.uae4all/roms directory)

sm0ky · « **Reply #53 on:** May 17, 2014, 08:21:21 am »

i couldn't wait to try the version you recently posted. even with "only" double buffering active this is a huge leap! all of the games i found not working on the a320-verison are working now - more or less flawlessly.
the bug that makes the mouse and keyboard go crazy still exists (i thought this to be a compatibility problem) but a restart is all it needs to get rid of this.

thank you very much for this version!!!

pcercuei · « **Reply #54 on:** May 17, 2014, 09:38:57 am »

You have to lock the surface (SDL_LockSurface) before using ->pixels and unlock afterwards (SDL_UnlockSurface before flipping).

toto · « **Reply #55 on:** May 17, 2014, 01:19:46 pm »

I put the kick.rom in the .uae4all/roms folder. It's 1.3 version. The emulator did start but none of the game does, when I load one it stays on hands that holds a disk picture.

EDIT: my games were all in .zip format, big mistake.

ker · « **Reply #56 on:** May 17, 2014, 03:24:27 pm »

Quote from: pcercuei on May 17, 2014, 09:38:57 am

You have to lock the surface (SDL_LockSurface) before using ->pixels and unlock afterwards (SDL_UnlockSurface before flipping).

I've tried to lock and unlock surface when ->pixels is read or write, but pointers to ->pixels are used at a lot of places in code. I've detected all functions that use direct or indirect access to r/w ->pixels and add a lock and unlock at te beginning and end of each function, but screen is still flickering.

Quote from: toto on May 17, 2014, 01:19:46 pm

I put the kick.rom in the .uae4all/roms folder. It's 1.3 version. The emulator did start but none of the game does, when I load one it stays on hands that holds a disk picture.

EDIT: my games were all in .zip format, big mistake.

I've just tested Turrican and Rick Dangerous games. Both work for me. Just to confirm you are doing this:
- Launch OPK
- Select Image Disk (and you select an .adf file)
- Run

isn't it?

pcercuei · « **Reply #57 on:** May 17, 2014, 03:45:19 pm »

Quote from: ker on May 17, 2014, 03:24:27 pm

I've tried to lock and unlock surface when ->pixels is read or write, but pointers to ->pixels are used at a lot of places in code. I've detected all functions that use direct or indirect access to r/w ->pixels and add a lock and unlock at te beginning and end of each function, but screen is still flickering.

Sorry, you should to the opposite

Leave the surface locked all the time, except when you need to blit or flip it. If you render to the main surface, you can just do:

Code: [Select]

if (SDL_MUSTLOCK(screen)) SDL_UnlockSurface(screen);
SDL_Flip(screen);
if (SDL_MUSTLOCK(screen)) SDL_LockSurface(screen);

SuperMarcoVer · « **Reply #58 on:** May 17, 2014, 03:49:44 pm »

Thank you very much for making this! I've tried this version and it works but the sound issue is the same as the previous one. The sound is a bit low in key. Can this be fixed?

ker · « **Reply #59 on:** May 17, 2014, 04:22:17 pm »

Quote from: pcercuei on May 17, 2014, 03:45:19 pm

Quote from: ker on May 17, 2014, 03:24:27 pm
I've tried to lock and unlock surface when ->pixels is read or write, but pointers to ->pixels are used at a lot of places in code. I've detected all functions that use direct or indirect access to r/w ->pixels and add a lock and unlock at te beginning and end of each function, but screen is still flickering.
Sorry, you should to the opposite
Leave the surface locked all the time, except when you need to blit or flip it. If you render to the main surface, you can just do:
Code: [Select]
if (SDL_MUSTLOCK(screen)) SDL_UnlockSurface(screen); SDL_Flip(screen); if (SDL_MUSTLOCK(screen)) SDL_LockSurface(screen);

Ok. Then I just need to wrap SDL_Flip and SDL_BlitSurface calls? Any other SDL function can be called as usual? I thought locking a surface must be done just as an exception.

I've read this at SDL documentation:

Quote

No operating system or library calls should be made between lock/unlock pairs, as critical system locks may be held during this time.

and

Quote

Surfaces that were previously locked using SDL_LockSurface must be unlocked with SDL_UnlockSurface. Surfaces should be unlocked as soon as possible.

Author Topic: Uae4All status (Read 20964 times)

ker (OP)

ker (OP)

ker (OP)

Nebuleon

ker (OP)

ker (OP)

ker (OP)

ker (OP)