Improving the framerate to 60pfs

The Uzebox now have a fully functional emulator! Download and discuss it here.
User avatar
uze6666
Site Admin
Posts: 4778
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Improving the framerate to 60pfs

Post by uze6666 »

This is a follow up of this this post.
D3thAdd3r wrote:Cool I didn't know about the MAME/MESS merger but I like it!

It really does look and feel smoother but right now -i artifacts are so bad it's not worth it.

It looks like it's blending 2 frames together and outputting it as one with the fields shifted up/down 1 pixel. I don't think it's actually tearing that looks so bad, I think Uzem is trying to emulate interlacing...over 2 frames? I run NES emulators in frame by frame all the time for stealing game play timings, and they make no attempt to do that and just output 60 progressive frames(and it looks great, probably faster). I am not sure what the implications are for the pixel scaling(to emulate non-square television pixels on square PC pixels). For emulators on other consoles I always found non-integral scaling twisted things pretty badly. I guess on Uzebox there is not set hardware resolution so that complicates things a bit, probably the only real way to do it would be 1 pixel per cycle or a resolution of around 1440 horizontal.

I hesitate to speculate on something that I have not looked into the code for years now, but a screen capture should always show a non-blurred image if Uzem wasn't actually doing what I think it is:

Only reason it gets under my skin is that I think it does have real gameplay and design effects(Lolo has to appear walking 1/2 NES speed or it looks totally weird) for some games since you only have 1/2 the precision of display<->input response. Ghosty Ghost is likely the most intense timing game and I do think there is a very real difference playing on hardware and emulator....so then make a fix right?...well...too lazy to act on half my "utmost importance" ideas and talk is easy :roll:
I never really gave any thought about it since it was always disabled by default. Right now, I'm not sure anymore if the current update rate (without -i) is 30hz or 60hz. But you are right it seems to emulate it in a wierd way which looks bad. I'll have a look at uzem to see what's going on.
User avatar
uze6666
Site Admin
Posts: 4778
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Interlace mode issues

Post by uze6666 »

Code: Select all

            if (scanline_count == 224) 
            {

                // framelock no longer necessary, audio buffer full takes care of it for us.
                if (frameCounter & 1) {
                    currentFrame++;

                    if (visualize)
                      draw_memorymap();

                    /* Tell GUI thread to update screen */
                    SDL_LockMutex(mtxVSync);
	                 currentFrameBuffer ^= 1;
                    SDL_CondSignal(cVSync);
                    SDL_UnlockMutex(mtxVSync);
               // }
Found this around the code that's flipping the frame buffer. It seems to be that page flipping occurs at 30hz. Setting frameCounter to 2,4,8 gets everything more and more choppy, but for some reasons removing that condition does not seem to improve anything visible on my side. Still looks 30hz. :?: This whole thread code added lately makes it harder to troubleshoot since I don't fully understand what it does. I'll have to pull an earlier tag to be sure.
User avatar
D3thAdd3r
Posts: 3170
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Interlace mode issues

Post by D3thAdd3r »

Yeah, threaded emulation...like a miniature nightmare really. If it helps, you will have made my day if I can finally have smooth Uzem; plus games can be better animated then :mrgreen:
User avatar
uze6666
Site Admin
Posts: 4778
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Interlace mode issues

Post by uze6666 »

If it helps, you will have made my day if I can finally have smooth Uzem; plus games can be better animated then :mrgreen:
Well, it annoys me really now for some reasons. Can't leave it like that anymore.

I will attempt to port to SDL2 and remove the threaded code, it's more confusing than anything else. I have looked at the code in mode depth and think I found a couple culprits about the chopiness and low frame rate. More to come.
User avatar
uze6666
Site Admin
Posts: 4778
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Interlace mode issues

Post by uze6666 »

I think I have a found a few fixes. Can you guys try the attached version and compare it to you current version? I've included Ghosty Ghost, and to me it seems like a big improvement. More smooth, less choppy, less stuttering...but it may just be me! Note that it's based on a old version, pre-thread, it will not work with tornado2000.
Attachments
uzem_fix.zip
(479.37 KiB) Downloaded 520 times
User avatar
uze6666
Site Admin
Posts: 4778
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Improving the framerate

Post by uze6666 »

Here's a tests candidate for Uzem 1.3. Should improve the framerate and reduce choppiness. I added some code to regulate the framerate, removed the treaded update code and made a cleanup in the code.

Edit: Just tested it along Arkanoid on my Surface(core i5, 2.5Ghz. And man, definitely a 60hz update rate now. :mrgreen:
Attachments
uzem_1_3.zip
(451.62 KiB) Downloaded 543 times
User avatar
D3thAdd3r
Posts: 3170
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Improving the framerate

Post by D3thAdd3r »

My laptop doesn't always run Uzem at full speed consistently so it makes it hard, but I played a bunch of games and it does seem noticeably smoother. I will try and throw up a simple flicker test and we should have real metrics to avoid confirmation bias I'm prone to though I'm sure you did get it.

Edit - threw a quick and dirty test together...I say great success Alec, sure looks 60hz to me!

Code: Select all

void main(){

	for(uint8_t i=0;i<64*2;i++)
		ram_tiles[i] = (i>63)?0b00000111:0b11100000;

	while(1){
		WaitVsync(1);
		for(uint16_t i=0;i<VRAM_SIZE;i++)
			vram[i] = !vram[i];
	}
}
Run that on the old version and the new version to see the difference. BTW "scientific controls" here are simply clicking the top bar of Uzem window to stall it and checking the color. After about 20 times it seemed pretty even.
Attachments
flicker.hex
(23.34 KiB) Downloaded 499 times
User avatar
uze6666
Site Admin
Posts: 4778
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Improving the framerate

Post by uze6666 »

Great! :D My regular dev machine, a old Core2, it appears smoother, but not by much hence I wanted some double checks. On newer machines though, there's no doubt! Although, whaever I do, it's never 100% smooth, at least in windowed mode. Your flicker demo shows that. Some frames seems to last 1-2ms more or less.
Run that on the old version and the new version to see the difference. BTW "scientific controls" here are simply clicking the top bar of Uzem window to stall it and checking the color. After about 20 times it seemed pretty even.
Yes indeed, on pre v1.3, screen is a solid red and now it clearly flickers between red and blue. So it's pretty much case closed, thanks to Lee and all others who brought up the issue. It feels great to improve such an essential tool.

I need to fix a bug brought by CunningFellow, then I'll push to git.

edit: Another "proof"... I have easily done a score of 14 at GhostyGhost in uzem1.3 vs a miserable 2 in the old version! :P
User avatar
kivan117
Posts: 73
Joined: Sat Mar 14, 2015 5:43 am

Re: Improving the framerate

Post by kivan117 »

uze6666 wrote:on pre v1.3, screen is a solid red and now it clearly flickers between red and blue. So it's pretty much case closed
This is excellent news! Glad to see the behavior of such a crucial development tool become that much closer to the actual hardware. This will definitely help with my work on other projects and I'm glad people without the actual hardware can have a better experience with timing critical games.
uze6666 wrote:I have easily done a score of 14 at GhostyGhost in uzem1.3 vs a miserable 2 in the old version! :P
Great! Now the game can reach a wider audience :D
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Improving the framerate to 60pfs

Post by Artcfox »

Is there a reason why Uzem uses 800x600 as its full screen resolution, while the pixel area it uses is only 630x448, and would fit comfortably inside a 640x480 resolution full screen window? I was able to modify my local copy to use 640x480 with no ill effects, and I suspect that rendering fewer pixels each frame would allow people with older computers (myself included) to maintain a consistent 60fps rendering with fewer hiccups and slowdowns.
Post Reply