nesdev.org

byuu I've never finished WedNESday. I first started writing it back in late 2003 and then quit. Since then its been rewritten about 4 times to the point where sound was the only missing function. I am currently up to this point about now so I assume that I will be releasing it a few months from now (It'd be sooner, but I returned to work this week).

byuu wrote:Apple did it right: it gives your OpenGL apps a "fake" Vsync right after the screen render has finished. That gives you almost an entire frame to get your data into the backbuffer.

And about an entire frame of guaranteed lag. Not that I'm defending it; I'm just trying to reverse engineer the rationale that led to it.

Yeah, I completely understand that. If it's any consolation, I'd love to have the NTSC filter back as well.

Actually, I'm looking for something lighter weight these days. I just want the blending effects, not the color degradation (eg simulate SCART-RGB only, no need to do the RF noise in my book.)

Are the diagonal stripes in Dr. Mario "blending effects" or "degradation" to you?

I thought about using 6502 as the intermediate language for the VM (since all NES emulators have 6502 cores anyway), but it's not going to be easy to write all the mappers that way, and nobody else would support it anyway, so why bother.

Or perhaps you could figure out some practically implementable subset of Verilog, and mappers written in that could be shared among INL-ROM, PowerPak, and your emulator.

People are simply upset because I'm removing all the excess data, generating a board manifest (from an internal database with heuristics fallbacks), and putting the copy of the game itself in another folder. They don't want that copy made. But that's too bad.

So you're caching the translation from iNES and other copier formats to your format. But if I open an iNES ROM, change a few bytes, open it again, change a few bytes, and open it again, do I end up with three copies of the board manifest, PRG ROM, and CHR ROM in an invisible folder? Or does it execute the old cached copy without checking whether it's been updated?

Did you completely miss where I mentioned VRC-n pinouts that iNES 1.0 can't describe? That's a technical reason right there.

Some people would consider that grounds to convert to NES 2.0, not to abandon iNES entirely. I defined a set of disambiguating submappers for the VRC series.

Importing == Playing.

Say I'm developing an NES game, and I'm testing it in your emulator. GNU Make just finished running ld65, and now a ROM has replaced a minutes-older ROM of the same name in the same folder. Or say someone's using a game-specific ROM hacking tool that assumes the ROM is in iNES or NES 2.0 format, and he saves changes to the ROM. I haven't tried your emulator yet, but does it have a command line option to import a two-second-old build temporarily?

If the extra disk space (200MB for NES library, assuming you actually play every game ever made) is that big of a deal, then yes. I'm not going to please you.

200 MB is about 750 builds of a game the size of Battletoads or Battle Kid.

tokumaru wrote:It also seems that FCEUX doesn't show many types of mid-scanline PPU changes, so if you're trying to time scroll changes, palette changes, things like that, so that they happen during HBlank, you can't trust FCEUX. Most of these effects aren't very common in homebrews, so programs that stick to "the rules" (PPU updates only during VBlank, no raster effects) will hardly have trouble with FCEUX, but if you need try new PPU/APU tricks or adjust precise timings, FCEUX is a terrible choice.

Is there a thread outlining the details, or some specific ROMs you might point me to that would demonstrate where it fails? Also, has any of it improved in FCEUX 2.2.0?

I have by no means tried every trick in the book, but I have tried several raster effects with success in FCEUX when compared to hardware, as well as a few things that require very precise timings (mostly audio related). Caling it a "terrible choice" seems contrary to my experience with it, but I'm sure it must have specific things that are emulated incorrectly, and yes it would be terrible for those things.

I'm not trying to deny that it has problems, I just want to know more about what they are. I'd actually like to take accurate stock of this, since FCEUX, unlike Nestopia or Nintendulator, has ongoing collaborative development, and if it needs improvement somewhere I can actually do something to help it.

byuu wrote:If it's any consolation, I'd love to have the NTSC filter back as well.

I'll keep an eye out for it, who knows.

Actually, I'm looking for something lighter weight these days. I just want the blending effects, not the color degradation (eg simulate SCART-RGB only, no need to do the RF noise in my book.)

I completely agree with you here.

Well, in the next release you can put the folders wherever you want, there's a setting added to the GUI for it.

Good move. Applications that scatter data everywhere are really annoying.

I thought about using 6502 as the intermediate language for the VM (since all NES emulators have 6502 cores anyway), but it's not going to be easy to write all the mappers that way, and nobody else would support it anyway, so why bother.

That would be interesting. People not supporting the stuff you come up with doesn't seem to have stopped you before... If you think that's an interesting experiment you should try it anyway. Isn't that how you work now?

Only I do parse iNES. You can load iNES games with higan v092.

I'm sorry, it's been a while since I tried these emulators, so I was using the comments in this thread to keep me up to date. I should have informed myself before criticizing.

People are simply upset because I'm removing all the excess data, generating a board manifest (from an internal database with heuristics fallbacks), and putting the copy of the game itself in another folder. They don't want that copy made. But that's too bad.

Personally, I can deal with that as long as I can pick the folder.

Did you completely miss where I mentioned VRC-n pinouts that iNES 1.0 can't describe? That's a technical reason right there.

I think you misunderstood me. I know iNES is full of flaws, and that other formats are technically better. What I mean is that since the emulator can import an iNES ROM and save it in another format, nothing prevents it from simply running it instead of saving new files to the hard disk, technically.

This is what people have a really hard time with. Importing == Playing. You can choose Load->Import every single time. Again and again. Your saves are kept intact.

I see. I'm not fully aware of how you are handling things now, so I'll be sure to check the latest version before saying anything else.

FCEUX should really be on github IMO.

rainwarrior wrote:Is there a thread outlining the details, or some specific ROMs you might point me to that would demonstrate where it fails?

Most of it I noticed from my own tests, but I do have some examples:

Super Cars uses $2004 trickery to mask scanlines at the top of the screen, so it relies on proper sprite evaluation. It's flickery in the old PPU, but looks fine on the new PPU.

Quietust's demo Copper Bars looks wrong in different ways depending on which PPU core you use.

Blargg's palette demo (the link is broken, since blargg is having hosting issues) used to show stripes of a single color, but since I don't have the ROM at hand I don't know how it behaves in the current version.

Also, has any of it improved in FCEUX 2.2.0?

I don't know... I was under the impression that improving accuracy wasn't a real concern for the maintainers of FCEUX. To me they appear to be focusing on features and such.

WedNESday wrote:@koitsu Timing is a bit of a funny place to put VSYNC, maybe. I did check under video and didn't see it.

Yep, that's my point -- bad UI design. While I understand how Vsync might "affect 'timing'", it's a video-related feature and should really have been put under Options -> Video. Trust me, that one gets (annoys) me too. :-) But there ya go.

Bananmos wrote:I use NESICIDE extensively for source level debugging when I need to single-step my code. But I usually try to do it as a last resort because it's just so frustratingly slow on my netbook.

So personally I'd love it if NESICIDE's emulator could be optimized a bit more. But I realize me and my cheap netbook might not be the main target audience and I appreciate NESICIDE for what it does provide me with when I have to track down bugs. And when time comes to upgrade my hardware again it'll probably run at decent speed anyway...

Thanks for the info! I do still have optimization on my list of things to do...

I thought the developers of FCEUX were focusing on Bizhawk

> I am currently up to this point about now so I assume that I will be releasing it a few months from now

Well, good luck when you do release it.

I'm not wrong on what drives software to be popular, but I'd sure like to be, so if your emulator really is better than everything else, I hope it succeeds.

> And about an entire frame of guaranteed lag. Not that I'm defending it; I'm just trying to reverse engineer the rationale that led to it.

Yes, you're absolutely right there. Adding a compositor adds up to one extra frame of lag. I'd much rather take the extra frame of lag than not be able to Vsync, though. Even better, I'd love to be able to turn the compositor off when gaming fullscreen.

And I used to be able to, and I did just that when going fullscreen with higan. And then Microsoft took the option to disable DWM away in Windows 8. So I just gave up on it and scrapped that feature. It never worked well on Linux anyway (all the windows go blank when you toggle Metacity and Xfce's compositors.)

> Are the diagonal stripes in Dr. Mario "blending effects" or "degradation" to you?

NES is trickier. There was no way to get RGB output from it (shy of the Playchoice which had different colors and that's really an abuse of the system to swap chips like that.) The SNES is more clear cut.

Basically, I want the video output to look like the real thing in the most pristine possible conditions. So that includes emulating NES composite output (staircasing and bleeding), SNES RGB output (bleeding), GB output (vomit green), GBA output (motion blur, horrendous and dim color palette), etc.

> Or perhaps you could figure out some practically implementable subset of Verilog, and mappers written in that could be shared among INL-ROM, PowerPak, and your emulator.

Yeah, it's all a matter of where to draw the line. You can take this down to the transistor level. Or you could just have Python mappers and bundle an interpreter with your emulator.

> But if I open an iNES ROM, change a few bytes, open it again, change a few bytes, and open it again, do I end up with three copies of the board manifest, PRG ROM, and CHR ROM in an invisible folder? Or does it execute the old cached copy without checking whether it's been updated?

If it gets an exact SHA256 match on an input file, it will name the file according to the database entry, and generate a 100% perfect board mapping.

If not, the game folder gets the same filename as the ROM you loaded. So if you have lots of generic names, like "test1.nes", you'd be in trouble there. It'll overwrite the old ROM if the file has changed (newer timestamp.)

If you really want to develop with higan, you should use the game folder format and load the games that way. Write a simple shell script to dd copy chunks from a merged file after building it if you must. Developers are more capable of working with the limitations.

> Some people would consider that grounds to convert to NES 2.0, not to abandon iNES entirely.

And that's fine, too.

I emulate the NES, SNES, GB, GBC, GBA, and NDS. I want a consistent format that can tackle the challenges of every system.

Again, it's just me trying some new things in my own way. There's a twelve-page bitchfest about me on ngemu for it, and it's just ridiculous. I don't understand why people are so bothered by me trying something different with my own software.

RetroArch uses bsnes v092 and runs regular game files directly, no game folders period. As does OpenEmu, Mednafen, Bizhawk, and lsnes. You have options, even with my own code.

I want to have technical discussions on the best way to handle this. But I don't want to deal with people who simply don't like that I am doing things differently. It's my software, until you start paying me, I will do what I want with it.

> People not supporting the stuff you come up with doesn't seem to have stopped you before... If you think that's an interesting experiment you should try it anyway. Isn't that how you work now?

Well, yes. But the only benefit to external mappers would be for more than one emulator to use it. Not all, of course, but a few.

Otherwise, if it's just for one emulator, they may as well be internal C++ implementations.

SNES has chips inside the carts, too. Only its coprocessors are 10-20x more complex than even the MMC5.

> nothing prevents it from simply running it instead of saving new files to the hard disk, technically.

You're right. It's doable. It's just that every single file handling routine would have to have a lot more code wrapped around it to choose between loading a game folder file, and loading a chunk of a merged file. The former with the game folder path and fixed filenames, the latter with user-definable paths for each file type, based off the game filename. And the GUI would have to re-add user selectable paths again.

It would be a lot of work to write, and a lot of work to maintain. I have done it before in bsnes v070-089. So I'm speaking from actual experience.

> Yep, that's my point -- bad UI design.

I'll unfortunately have to agree. But in Marty's defense, Nestopia is absolutely filled to the brim with features galore.

Developing software and designing user interfaces are really two different mindsets. I make my own GUI with myself in mind, and I'm painfully aware of how it's confusing to new users.

We need more people who are willing to write just the GUI portions for emulators. Every time someone tries to do this for my emulator, they end up forking off and making a multi-system, multi-emulator codebase. Eg RetroArch.

> I thought the developers of FCEUX were focusing on Bizhawk

BizHawk is fun. But they load up their imported emulator codebases with snarky comments on their design

byuu wrote:GBA output (motion blur, horrendous and dim color palette)

There's no doubt about motion blur on the GBA, but please don't try to force a crappy palette like NO$GBA did before. The NDS Lite has a really good screen for playing GBA games, and so does the Game Boy Player.

tokumaru wrote:Quietust's demo Copper Bars looks wrong in different ways depending on which PPU core you use.

Thanks for the info!

koitsu wrote:Or it's just another case of a) badly-designed UIs (Vsync setting in Nestopia is under Options -> Timing, not Options -> Video

(*ﾉ＿<*)

tokumaru wrote:I'm not sure how many people use blargg's filters (I'm a big fan, whenever an NTSC filter is available I use it - even if just for fun on systems that didn't have composite output to begin with), but I imagine more than 10 people do.

30-bit displays. Unless you're in a professional field, good luck finding a monitor that can do more than 24-bit.

Dwedit wrote:There's no doubt about motion blur on the GBA, but please don't try to force a crappy palette like NO$GBA did before. The NDS Lite has a really good screen for playing GBA games, and so does the Game Boy Player.

Actually this seems like something that should be better as a setting given that some games overcompensated for the screen's lack of brightness x_x; (and don't get me started on how Shantae uses different palettes depending if it's running on a GBC or GBA because of how different the screens look like)

byuu wrote:Even better, I'd love to be able to turn the compositor off when gaming fullscreen.

And I used to be able to, and I did just that when going fullscreen with higan. And then Microsoft took the option to disable DWM away in Windows 8.

DWM is disabled in fullscreen mode (with my DX10 app at least). Verified with gpuview on Windows 8 (and I'm pretty sure I've verified this on Windows 7 as well, but can't double check right now).

> 30-bit displays. Unless you're in a professional field, good luck finding a monitor that can do more than 24-bit.

It is indeed a -very- complex thing to accomplish.

First, I needed a 30-bit capable monitor. Look for the ones that advertise 1.07 billion colors. These are going to be IPS panels. Mine is the HP ZR30w. You'll be paying a minimum of $500 for your monitor.

Second, you have to use DisplayPort. There is no option here. DVI does not support 30-bit (there's a hack for sending two images to the card, but it's a real hassle and not well supported.) HDMI supports it, but I've never seen a graphics card that allows 30-bit color over HDMI.

Third, you have to use an nVidia Quadro or an ATI FirePro. This is absolutely required. I use an FX 580 Quadro. Just having DisplayPort is not enough. The GeForce and Radeon series do not support 30-bit color. Period. I think I've heard musings of the $600+ GeForces supporting it, but I wouldn't count on it. My bet is you'll only get 24-bit color over their DisplayPorts. Even more fun, for some fucked reason, the red/green/blue channels are reversed on my Quadro/Linux setup. So I have to generate a BGR palette for output.

Fourth, Windows can only do 30-bit color with DirectX 11+ when in fullscreen exclusive mode, with all the above conditions met. OS X can't do it at all. Linux can do it with a depth of 30, but you will run into numerous problems. Most applications do not support 30-bit color. Basically, I had to install an experimental version of Metacity and replace my Xfce window manager with it, otherwise my window decorations were entirely corrupted gibberish. My desktop wallpaper did not show up, I could only get solid black. So I wrote my own desktop application to display wallpaper (and I can show 48-bit PNGs at true 30-bit, whee. Now I just have to find one.) Next, any app that uses a GTK+ pixmap (24-bit) doesn't work. So things like Ristretto photo viewer, Audacious splash screen, etc just show solid black.

Finally, I had to enumerate my Xorg Visual by hand for XShm, and get OpenGL to use its ARGB1010102 texture mode attached to aforementioned Window with 30-bit Visual, to actually get true 30-bit color.

After finally getting this all setup, I wrote some test apps to display 1024 color shades of gray, with all dithering disabled, to truly and accurately verify that I was really running at 30-bit, and confirmed that I was.

For all that work ... it really does help with gradients. I literally can no longer tell the difference between two color shades. It also greatly helps with the SNES at luminance=0, I can show a lot more detail while still having the image as dark as it is on a real TV. There, but you really have to look closely. Exactly like the real thing. It's also a huge help with my NTSC TV gamma ramp simulation. With 24-bit, the colors are too narrow at the dark end, so you end up losing detail in really dark scenes like inside Lavos in Chrono Trigger. Now only the poor contrast of LCD in general is an issue.

So yeah ... probably no more than 10 people actually using higan's true 30-bit output.

> DWM is disabled in fullscreen mode (with my DX10 app at least). Verified with gpuview on Windows 8 (and I'm pretty sure I've verified this on Windows 7 as well, but can't double check right now).

Yeah, that's the thing. I don't have a true fullscreen mode. I just stretch the window over the entire display. I like avoiding the mode switching delays, and at least having the -option- to show the menubar is nice, even if I don't do it. But I have no choice now, so I'll have to implement a true fullscreen, exclusive mode.