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.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
Improving the framerate to 60pfs
Improving the framerate to 60pfs
This is a follow up of this this post.
Re: Interlace mode issues
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);
// }
Re: Interlace mode issues
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
Re: Interlace mode issues
Well, it annoys me really now for some reasons. Can't leave it like that anymore.If it helps, you will have made my day if I can finally have smooth Uzem; plus games can be better animated then
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.
Re: Interlace mode issues
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 531 times
Re: Improving the framerate
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.
Edit: Just tested it along Arkanoid on my Surface(core i5, 2.5Ghz. And man, definitely a 60hz update rate now.
- Attachments
-
- uzem_1_3.zip
- (451.62 KiB) Downloaded 559 times
Re: Improving the framerate
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!
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.
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];
}
}
- Attachments
-
- flicker.hex
- (23.34 KiB) Downloaded 517 times
Re: Improving the framerate
Great! 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.
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!
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.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.
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!
Re: Improving the framerate
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: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
Great! Now the game can reach a wider audienceuze6666 wrote:I have easily done a score of 14 at GhostyGhost in uzem1.3 vs a miserable 2 in the old version!
Re: Improving the framerate to 60pfs
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.