NTSC Artifacts

The Uzebox now have a fully functional emulator! Download and discuss it here.
User avatar
lunatic
Posts: 49
Joined: Sun Jul 28, 2013 12:29 am
Location: Horten, Norway
Contact:

NTSC Artifacts

Post by lunatic »

Hi,

In another thread, I someone mentioned a cool ntsc effect for emulators in conjunction to grabbing video.
In light of this, I searched for the ntsc lib mentioned, and I found it. The download links was gone from the original page, but a google search gave me the sources.

The ntsc library is LGPL, so it should not be a problem to use this in the emulator.

I have gotten it to work, but I am having problems with the green color disappearing. Which is weird. If it were red or blue, it could be a matter of shifting one way or the other.
The library is mainly made for 16bit colors. But it "says" it can do 32bit.
Screen Shot 2013-07-30 at 6.25.14 PM.png
Screen Shot 2013-07-30 at 6.25.14 PM.png (169.08 KiB) Viewed 8272 times
Here's how far I am. It is a bit more blurry and a little bleeding. You can adjust a lot of variables to tell the filter how "bad connection" you have, to get a really "real" or "nostalgic" image.

But first I need to get all the colors to work.

Is anyone interested in this by the way? I'm just doing it for my own pleasure at the time :mrgreen:
User avatar
lunatic
Posts: 49
Joined: Sun Jul 28, 2013 12:29 am
Location: Horten, Norway
Contact:

Re: NTSC Artifacts

Post by lunatic »

So, I have realized that the snes_ntsc library that I use, does not support 32 bit at all.
So now I have started to port uzem to 16bit instead of 32bit. uzebox is only 8bit anyways.

It looks much better now. Colors are correct, and the ntsc filter is doing what it should.

Only problem now, is that there is some alignment problems with the scan lines now that I have converted to 16 bit.
Every second scanline starts too early. So i get half correct image, but every odd line is too much left. Almost half the screen to the left.

Here is a screenshot:
Screen Shot 2013-07-30 at 9.37.46 PM.png
Screen Shot 2013-07-30 at 9.37.46 PM.png (104.03 KiB) Viewed 8249 times
This is 16bit mode, with NTSC filtering.

And this is 16bit mode, but without any filtering:
Screen Shot 2013-07-30 at 9.41.58 PM.png
Screen Shot 2013-07-30 at 9.41.58 PM.png (53.65 KiB) Viewed 8246 times
The NTSC filter makes the image a bit wider.

If I only can make the 16 bit mode emulate correctly now.. :?

Here's information about the library I am using btw: http://slack.net/~ant/libs/ntsc.html
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: NTSC Artifacts

Post by D3thAdd3r »

It's great please do it up. When I play classic games on emulators I like scanlines and other options that make it feel more like it did when I was a kid-like there are more details hiding behind the bleeding pixels. This is one of the many features I wish Uzem had.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: NTSC Artifacts

Post by uze6666 »

Awesome, never thought of this one, I love it! :D I second Lee, I'm all for this feature.
I have gotten it to work, but I am having problems with the green color disappearing.
Based on the yellow in picture you showed, it seems to be the blue component that is not present (yellow is red+green).
User avatar
lunatic
Posts: 49
Joined: Sun Jul 28, 2013 12:29 am
Location: Horten, Norway
Contact:

Re: NTSC Artifacts

Post by lunatic »

Hi,

Ok, so now I have figured out how to get the picture correct.

This is without filter:
Screen Shot 2013-07-31 at 11.24.38 AM.png
Screen Shot 2013-07-31 at 11.24.38 AM.png (59.33 KiB) Viewed 8181 times
And this is with filter: (chosen composite filter, with 0.9 sharpness level)
Screen Shot 2013-07-31 at 11.24.46 AM.png
Screen Shot 2013-07-31 at 11.24.46 AM.png (217.9 KiB) Viewed 8184 times
My next problem now is cpu time.

The emulation goes from 29mhz down to 25.5mhz. And I am having problems finding out where the emulator is actually timing it to be ~28mhz.
The interrupts are fired from clock cycles, and I see no delay-calculations in the code.

Ah, seems like it is relying on the SDL audio buffer to do the "idling", since it is clocked to 15khz.
So that means that we are out of spare clock cycles on my computer at least. So to get it going at realtime, I need to optimize the code.

One of the ways to do it would be to get the emulator to only output the "real" horizontal resolution, and let the ntsc library double the pixels. (says the ntsc library documentation)
But I am having problems tracking down how the code makes it 720 lines from the actual amount of lines that comes out from uzebox. But I do have a hunch.

To be continued :D
User avatar
lunatic
Posts: 49
Joined: Sun Jul 28, 2013 12:29 am
Location: Horten, Norway
Contact:

Re: NTSC Artifacts

Post by lunatic »

Ok,

So I have come a bit further. I have now cut the video-generation down to 360 pixels per scanline, and let NTSC filter generate the resulting image, with its own resulting size.
(the filter desides a new output width, since it stretches the image)

But sadly, it didn't help, I'm still a lot under 28Mhz. The filter steals away several mhz of power :cry:

So I think the only way to get this up to realtime again, would be to really optimize the emulator. I'm not sure if David, and the boys who created the emulator has optimized it to the limits?
Have they put the switch() order to the most-used-instruction first?, etc? I'm no emulator guru, so I won't be of much help.

But this guy had a lot of tips in coding 8bit emulators:
http://slack.net/~ant/nes-emu/6502.html

So here's the result:
Before:


After


Unfortunatly, youtube's codec has removed a lot of the fine ntsc-flickering that is visible. But if you look at the energy bar at the top, you might see a bit of the flickering. You might also see a bit of bleed on the floor, etc. In the emulator it is much more visible :ugeek:

Ok, here is a HD upload on youtube, be sure to open the video on youtube to see it in full quality:
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: NTSC Artifacts

Post by D3thAdd3r »

I wondered about that, as the Uzem requirements are a bit steep. My brand new(not expensive) laptop runs around 25mhz I know it has to be cycle perfect everywhere but I can emulate Sega Saturn fine, so I feel like Uzebox should be possible too :|
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: NTSC Artifacts

Post by uze6666 »

Really, really cool, great work and thank for making videos! :mrgreen: The bleeding is pretty convincing, although the flickering is perhaps a bit excessive. Can it be configured? I haven't seen such bad picture since using my NES back in the days via a modulator box on my parent's not so good TV! :lol:

On the subject of Uzem itself, well it's been done to just work and here's the story. The coder was David Etherton, a lead software architect at Rockstar games (of the GTA fame). He wrote the thing out in about 2 weeks while traveling for business, I recall him saying this was 100 times exiting than his real job! :lol: So we can't complain much, it really helped propel the Uzebox scene. :)

That said, he was the first to mention tons of optimization could be done. You could try to find and read his thread on this forum for more of his ideas. However, as you noticed, the switch() statements are probably the killer here. Unless i'm mistaken they are really implemented as a series of if-then statements. I've never looked at other emulators code either, but for me it would seems that function pointer jump tables would speed up the thing dramatically.

Btw, Lunatic, I'll add you to the SVN commiters so you can add your work on the uzem NTSC filter. I'll use your registration email address, let me know if I should use another one. I guess you'll add a command line switch to select the desired filter?
User avatar
lunatic
Posts: 49
Joined: Sun Jul 28, 2013 12:29 am
Location: Horten, Norway
Contact:

Re: NTSC Artifacts

Post by lunatic »

uze6666 wrote:Really, really cool, great work and thank for making videos! :mrgreen: The bleeding is pretty convincing, although the flickering is perhaps a bit excessive. Can it be configured? I haven't seen such bad picture since using my NES back in the days via a modulator box on my parent's not so good TV! :lol:

On the subject of Uzem itself, well it's been done to just work and here's the story. The coder was David Etherton, a lead software architect at Rockstar games (of the GTA fame). He wrote the thing out in about 2 weeks while traveling for business, I recall him saying this was 100 times exiting than his real job! :lol: So we can't complain much, it really helped propel the Uzebox scene. :)

That said, he was the first to mention tons of optimization could be done. You could try to find and read his thread on this forum for more of his ideas. However, as you noticed, the switch() statements are probably the killer here. Unless i'm mistaken they are really implemented as a series of if-then statements. I've never looked at other emulators code either, but for me it would seems that function pointer jump tables would speed up the thing dramatically.

Btw, Lunatic, I'll add you to the SVN commiters so you can add your work on the uzem NTSC filter. I'll use your registration email address, let me know if I should use another one. I guess you'll add a command line switch to select the desired filter?
Cool, thanks, and yes, sure I'll add filter selection. I have also added frame-grab possibillity. So it spews out a .bmp file for each frame sent to the screen, and fill a dumpfile with the audio data. Thats how I made the last video with audio :) This way, even if the emulator is not fast enough on your computer, both video and audio will be great once you put all the data in a movie file with ffmpeg (or something similar).

But I'd like to add a few more options to the ntsc filter before pushing it to svn. So you could configure how you want it to look. I agree that the flickering is a bit excessive ;)

About the optimization, I am not sure I understand you. Switch should be pretty fast? The compiler usually optimizes this to a jump table, and will do this the best way possible. Function pointer jump table sounds like something that would be a lot slower. Calling a function is a slow task, and adds a lot of cpu cycles to something that could be done "inline". And iterating a table must also be a lot slower than a bunch of branches in a row? But thats just how I think, you might know more about this stuff than me :)

I might be motivated to start reading about writing emulators and fast code, and start to move around stuff in uzem at one point. But I have a lot on my hands at the moment, so I won't promise anything. If someone else here is awesome at counting cycles in C towards x86 processors and alike, please step up to this task! ;) But I guess we should keep the uzem code free from assembly, to keep it portable.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: NTSC Artifacts

Post by uze6666 »

I have also added frame-grab possibillity. So it spews out a .bmp file for each frame sent to the screen, and fill a dumpfile with the audio data. Thats how I made the last video with audio :) This way, even if the emulator is not fast enough on your computer, both video and audio will be great once you put all the data in a movie file with ffmpeg (or something similar).
Hmm interesting, uzem already have single frame grab with printscreen key. Btw, someone already did some code to export video, but sound was left to be done if I recall. I think it was using ffmpeg. Perhaps you could take on it it if you feel so: http://uzebox.org/forums/viewtopic.php?f=9&t=674. CAMStudio is often used here to record videos for youtube. It's free and open source.
About the optimization, I am not sure I understand you. Switch should be pretty fast? The compiler usually optimizes this to a jump table, and will do this the best way possible. Function pointer jump table sounds like something that would be a lot slower. Calling a function is a slow task, and adds a lot of cpu cycles to something that could be done "inline". And iterating a table must also be a lot slower than a bunch of branches in a row? But thats just how I think, you might know more about this stuff than me :)
Nah, never mind, it was late, brain fart! :lol: What I really meant was a jump table. And for sure it already does that.
I might be motivated to start reading about writing emulators and fast code, and start to move around stuff in uzem at one point. But I have a lot on my hands at the moment, so I won't promise anything. If someone else here is awesome at counting cycles in C towards x86 processors and alike, please step up to this task! ;) But I guess we should keep the uzem code free from assembly, to keep it portable.
Yes, I'd avoid any assembly for portability. And don't take too much at once, a few here did that and quickly got overwhelmed...and didn't delivered much in the end! ;)
Post Reply