Nestopia 1.39

xamenus · Post by **xamenus** » Sun Oct 09, 2005 12:21 am

After 2 years of silence, this NES emulator was updated the other day. IMO, this release blows all of the other NES emulators out of the water.

http://sf.net/projects/nestopia

Given the fact that it has taken almost two years to complete this release
I've basically lost track of the shitload of changes and fixes I've made
throughout this time, but I'll try to cover the most notable new additions.

But first, I'd like to thank all the beta testers who helped shaping up
this release, especially Hellsbane, Michael Walsemann, Benjamin Siskoo
and Robert Tuccitto for their dedicated time and effort in searching for
bugs.

The Windows port has been rewritten from scratch (which proved to be more
time consuming than I initially thought). The emulation core has gone
through a complete overhaul as well.

Some of the new features:

- DirectDraw kicked out and replaced by Direct3D (DirectX 9.0c now required)
- More video filtering options
- More multitasking friendly
- Configurable menu keys
- Less cumbersome to take screenshots and no more GDI+ requirement
- Selectable auto-fire speed
- Recent directories
- Ability to lock and clear the recent files and directories lists
- Selectable LED source for FDS disk access
- Alternative emulation speed via assignable key/button
- Ability to change the menu color
- Changes to brightness/saturation/hue takes effect immediately
- More logfile (disabled by default now) diagnostics
- Cursor gets auto-hidden
- Many hard-coded strings now moved into the resource section
- Image info for FDS and NSF files
- Can make IPS files out of changes to FDS disk files
- Can edit iNes file headers
- Hq2x/Hq3x filter support
- Additional GUI improvements

New iNes mappers:

53, 56, 142, 158, 164, 165, 193, 203, 204, 205, 206, 207, 208,
209, 210, 211, 212, 213, 215, 217

Fixed iNes mappers:

*many*

New UNIF boards:

Mario 1 Malee 2, Novel Diamond 9999999-in-1, Super Game 8237
Super 24-in-1, WS 40-in-1

New controllers:

Oeka Kids Tablet, Hyper Shot, Crazy Climber, Mahjong, Exciting Boxing
Top Rider, Pokkun Moguraa

Other emu core related things:

- More standard conformant C++ code
- Easier to port to other platforms using a new written API
- Many speed optimizations (but at NO cost of emulation accuracy)
- Save state and movie file formats rewritten, old files will no longer work
- More accurate APU and PPU emulation thanks to RE work by Blargg, Kevtris and Quietust
- Perfectly time-aligned sound sample output by using a common clocking rate
- Uses new updated palette by Matrixz
- Better (but not perfect) NTSC color generation algorithm based on tweaks by AWJ
- ROM database fixes and additions
- Support for phantom stereo sound output
- More accurate FDS emulation
- Better sound quality with the external sound chips
- Auto-selects between Famicom and NES 4-player adapter based on game CRC
- More accurate emulation for several controllers
- More accurate hard/soft reset behaviour

That covers most of it. If you like this release and would like to thank me for
eating Nestopia, sleeping Nestopia and breathing Nestopia during these past two years
consider donating a few bucks through the pay-pal link at http://sourceforge.net/projects/nestopia.

snkcube · Post by **snkcube** » Sun Oct 09, 2005 12:26 am

Awesome. I've been waiting for this.

Neo Kaiser · Post by **Neo Kaiser** » Sun Oct 09, 2005 1:32 am

Yes it is exelent! It took me a while to find the strench image to use at fullscreen (shift+S) but now I am happy with it and it manage the FDS ROMs more easier.

Post by **Nach** » Sun Oct 09, 2005 1:52 am

Excellent. Has it reclaimed it's crown from the few recent emulators that appeared?

Noxious Ninja · Post by **Noxious Ninja** » Sun Oct 09, 2005 1:58 am

Two things:

1) In Super Mario Bros. 3, the blue line that divides the main screen from the status bar flickers on the left side.

2) The default state save keys suck. Shift+ should be save, not load.

xamenus · Post by **xamenus** » Sun Oct 09, 2005 2:20 am

Also, the preferences under the "Machine" menu aren't remembered when starting a new session later (or at least some of the options aren't). I've already reported the bug.

Neo Kaiser · Post by **Neo Kaiser** » Sun Oct 09, 2005 6:15 am

I also found a bug in fullscreen that causes the emulator to minimize in the taskbar sometimes when I press Esc to acces the menu. This is annoying!

kamaitachi · Post by **kamaitachi** » Sun Oct 09, 2005 7:40 am

Does anybody know if there is an official discussion forum for this emulator?

kode54 · Post by **kode54** » Sun Oct 09, 2005 10:40 am

Neo Kaiser wrote:I also found a bug in fullscreen that causes the emulator to minimize in the taskbar sometimes when I press Esc to acces the menu. This is annoying!

This is a problem I found when trying to write fullscreen Direct3D code and also use a standard menubar at the same time. The problem is that the display updating code normally resets the display device when the client area is resized, like on the menu toggle. Only it shouldn't be doing that in fullscreen mode.

The only "easy" way to do fullscreen with menu enabled is to do fake fullscreen with an always-on-top window, like VBA. Feel free to point out a nice way of doing system menubars overtop of real fullscreen Direct3D, though.

Clements · Post by **Clements** » Sun Oct 09, 2005 10:43 pm

The biggest problem with Nestopia is the high CPU usage I'm getting. I got 20%+ playing Bomberman in 1x window mode, whereas other emulators typically draw 8%. The emulator can be slow at times using certain settings as a result. The compatibility has increased though and Koei games are now working.

whicker · Post by **whicker** » Mon Oct 10, 2005 12:30 am

Noxious Ninja wrote:Two things:

1) In Super Mario Bros. 3, the blue line that divides the main screen from the status bar flickers on the left side.

Uhm... the real game does this, especially noticable on the Airship and Tank autoscroll levels.

Noxious Ninja · Post by **Noxious Ninja** » Mon Oct 10, 2005 12:36 am

It's been so long since I've played it on a real system, I wouldn't know.

So RockNES (the only other NES emu I tried it on) gets it wrong? Interesting.

ThunderClaw · Post by **ThunderClaw** » Mon Oct 10, 2005 12:53 am

Noxious Ninja wrote:It's been so long since I've played it on a real system, I wouldn't know.

So RockNES (the only other NES emu I tried it on) gets it wrong? Interesting.

IIRC, RockNES uses a hack to get rid of that thing

but yeah, the real game does it, I remember wondering wtf it was when I played the game at 7.

Post by **Nach** » Mon Oct 10, 2005 2:47 am

kamaitachi wrote:Does anybody know if there is an official discussion forum for this emulator?

Yes, right on the official site.

Neo Kaiser · Post by **Neo Kaiser** » Mon Oct 10, 2005 3:56 am

Nach wrote:
kamaitachi wrote:Does anybody know if there is an official discussion forum for this emulator?
Yes, right on the official site.

Official site? Where?

Noxious Ninja · Post by **Noxious Ninja** » Mon Oct 10, 2005 4:00 am

Project navbar, fourth from the left.

Hexlord · Post by **Hexlord** » Tue Oct 11, 2005 3:30 am

Finally... a worthy competitor to FCE Ultra.

Dmog · Post by **Dmog** » Tue Oct 11, 2005 6:45 am

ThunderClaw wrote:
Noxious Ninja wrote:It's been so long since I've played it on a real system, I wouldn't know.

So RockNES (the only other NES emu I tried it on) gets it wrong? Interesting.
IIRC, RockNES uses a hack to get rid of that thing

Lame. Very lame... Hacking your emu to get rid of a "bug" that actually happened on real hardware is 'lame' (did I mention I though it was lame?)
Now many people will mistakenlingly think,as Noxious ninja did, that there's a bug in the emulation somewhere. Honestly that's one of the worst thing you can do for Nes emulation imo.

Btw, I remember reading that Nack implemented a "fix"/hack in the C4 code to get rid of a natively occuring gfx glitch in Megaman X (or X2 or something). Is that still in there? If so,I think that goes against the goals of an emu that's supposed to strive for accuracy

Finally... a worthy competitor to FCE Ultra.

VirtualNes is not only a worthy competitor to FCE,but surpass it in many respects (my opinion)

Noxious Ninja · Post by **Noxious Ninja** » Tue Oct 11, 2005 6:49 am

It's Nach, and he gave the C4 a bit more accuracy than the real thing had.

Dmog · Post by **Dmog** » Tue Oct 11, 2005 8:25 am

Noxious Ninja wrote:It's Nach, and he gave the C4 a bit more accuracy than the real thing had.

Yeah I remember it's Nach. Can anyone confirm if the "fix"/hack is still present in the latest wip?

He gave it "more accuracy than the real thing"...Oh lord... And the author of RockNes "fixed" the NES where it "failed" on SMB3...And UOsnes is the ultimate Snes emulator...uh huh right.

I don't care if the C4's maths were roughly equivalent to that of a monkey on crack, it's still not right.

Again,I think that's the worst thing you can do in emulation...Worst than the N64 innacurate HLE, worst than UOsnes cheap hack galore.

edit: How can Zsnes have a "no cheap hack philosophy" (proof: sound is broken in many games,where in UOsnes they are not but only because UO uses hacks) yet at the same time allows for such "hardware improvement"? Seem contradictory...

Post by **grinvader** » Tue Oct 11, 2005 10:30 am

Dmog wrote:I don't care if the C4's maths were roughly equivalent to that of a monkey on crack, it's still not right.
(...)
edit: How can Zsnes have a "no cheap hack philosophy" (proof: sound is broken in many games,where in UOsnes they are not but only because UO uses hacks) yet at the same time allows for such "hardware improvement"? Seem contradictory...

It's because it's not a hack.

A 'hack' is when your main core params make it impossible to play some games, and you're forced to change these params per-game, or to completely change cores depending on the game you load.

What we have here is a detail so negligeable you can't even remember what it does. It has no impact on emulation itself, and is stable with all other C4 games.
I checked myself, even though one sprite is moved by one pixel down (the only change it makes) the collision detection for this sprite doesn't change compared to the real hardware (at least PAL).

blackmyst · Post by **blackmyst** » Tue Oct 11, 2005 10:56 am

If it's such a negligible detail, why even do it in the first place? Unlike most of Zsnes' features, this actually changes the SNES' video output, and it's not optional, I agree that it does go against Zsnes' principles somewhat.

Not that I care much, just wondering why.

creaothceann · Post by **creaothceann** » Tue Oct 11, 2005 11:29 am

I'd guess it requires much less code, or something like that.

Personally I don't mind these improvements, as long as they can be disabled.

kode54 · Post by **kode54** » Tue Oct 11, 2005 1:14 pm

It's like grinvader said, so. It's really such a negligible change that it's really hard to remember why it's even there, and it hardly makes ZSNES a bad emulator on its own. Why, when you stack it up against all the other glaring flaws, it's hardly worth even considering. Besides, all of the other problems actually have negative effects.

Consider this an "enhancement" to go alongside all those useless extra sound interpolation and filtering modes, and maybe high res mode 7.

Well, usually, you could consider it an enhancement, if it were transparent to the software running inside the emulator.

Post by **Nach** » Tue Oct 11, 2005 6:16 pm

blackmyst wrote:If it's such a negligible detail, why even do it in the first place? Unlike most of Zsnes' features, this actually changes the SNES' video output, and it's not optional, I agree that it does go against Zsnes' principles somewhat.

Not that I care much, just wondering why.

The C4 has 24 bit precision on it's numbers. Our PCs offer 32 bits of precision. Just doing it natively is simple and gives a straighter line because of the greater precision.

I could try to after doing the math make it lose the extra 8 bits of precision, but I didn't really find it worth the effort.

However the math itself used is the same, it's just the output on the screen is more correct (to the math, not to the C4's implementation).