I was just adjusting the timing of the NMI routine in my game so that I could use blank tiles during the top scanlines in order to hide scrolling glitches and then switch in the correct patterns at a very specific time (as soon as the last blank scanline finishes, so that the background is completely blank but the sprites are ready to be fetched for the next scanline) in order for the following scanlines to be rendered properly.
So, there I was playing with the cycles to get the bankswitch to happen exactly at the end of the visible scanline, but the 3 emulators I normally use for testing (Nestopia, Nintendulator and FCEUXD) couldn't agree on what the correct point was.
Then I took 3 different builds to my PowerPak and turns out Nintendulator was the correct one. I guess this is no surprise, everyone always talks about how accurate it is and such. But I was surprised at how wrong Nestopia was. The switch was happening much too soon, almost by the middle of the scanline. FCEUXD was somewhere in between.
I don't know what I plan to accomplish with this post, I guess I'm just writing because I'm surprised. And pissed off, because my game won't look the same across emulators, it will look glitched in some. I guess I will revise my code and look for something that might be throwing the emulators off, but it sure does suck having to take emulation issues into account for my game to look good in most platforms.
You have a right to be pissed off, but this is exactly why it's impossible to rely on emulators to do low-level development. You can "get most things done" using an emulator, but it's important to remember one thing:
Emulators are tested predominantly using games which were originally written + tested on actual hardware. The goal is often "how can I get my emulator to work with X game", and there are all kinds of one-offs in emulators for certain things.
Your post is more or less a present-day rant that follows in the same line of rants people had during the post-Nesticle days. There were no NES development carts, no one doing hardware dev or RE for the NES, so those of us wanting to write stuff for the NES only had Nesticle. We wrote our code so that it worked on Nesticle and assumed it would work on the real thing, or on other emulators -- bzzt, wrong. My FF2j/e intro code for Demiforce is a wonderful example of such a beast (breaking horribly on most present-day emulators and the actual NES, but works fine in Nesticle).
Welcome to emulation.
Yeah I do get what you say. I'm still trying to figure out if I'm doing something wrong, though. I mean, yeah, Nintendulator and the actual NES are showing the same thing, but there is a chance that I'm making a mistake and not taking into account some other factor that is making the error more evident in the other emulators. I'll post back when/if I find out more.
BTW, sorry about the rant. I hate ranting. Feel free to move this to general or whatever, as it doesn't really help emulator development.
On the contrary, I would say your rant *does* help emulator development!
If you've code which works correctly on the real thing and on Nintendulator (which is known for being quite timing-accurate), but not on other emulators, I would say you've got a good test case for emulator authors. :-)
Someone may have to poke at Nestopia's code to see if they can figure out a fix, since it's one of the most popular emulators right now. The Nestopia Forum doesn't get a lot of attention (and AFAIK, the author doesn't visit it), so I'd say maybe contact the author directly.
If I calibrate it by Nintendulator's timing, the worst that will happen on the other emulators is that the patterns will be loaded a bit later, so a few sprites on the first scanline after the border might be transparent, which isn't such a big deal (most people probably won't even notice). Still, when the logic is more organized I guess I will contact Nestopia's author.
Well, your post is relevant because I was under the impression that Nestopia was as much accurate if not even better than Nintendulator, so it shows me that impression was wrong.
It's a kind of worst cycle : As long as we say "I don't want to do this trick because it only works on Nintendulator/real HW", nobody will ever do this trick and it will remain badly emulated. Someone needs to release a really great homebrew game relying heavily on $2004 reads and precise timing so that all emulator authors will be forced to fix them to show correct results. However, since such a game will only work on Nintendulator most people will think "cool I'm going to download it" only to figure it doesn't work on their favourite emulator and delete it without even reading the readme file stating they must use Nintendulator. Nestopia is much more user-firendly and faster, so it's most likely the lambda emu user will be using it.
And unfortunately, we are absolutley forced to use emulators when doing developpement, no matter what everyone says. The real NES doesn't have any nametable viewer, debugger nor CPU tracter. And it's really slow to test your stuff on. Also you can only test your region (PAL in my case), and not the other one arround.
If you can, go test it on the
PocketNES preview version too. I'd like to know which emulator's timing it matches.
Then again though, the emulator rounds all graphics changes to the nearest scanline, so I think it might be a little silly to test it.
- So...
hehehe
- I'd like to test your program/whatever on my private emu, tokumaru... if possible. ^_^;;
Bregalad wrote:
It's a kind of worst cycle : As long as we say "I don't want to do this trick because it only works on Nintendulator/real HW", nobody will ever do this trick and it will remain badly emulated. Someone needs to release a really great homebrew game..
I think the reason we use known games (here we mean Zelda, SMB, ...) to test our emulators is because these are known to work on a real NES
thus if they work in your emulator, you have a chance you're "close" to the real NES.
The homebrew scene is vastly different, much harder to emulate, and shows most emulator developers (myself included) how far away their emulation is from truth. There are those of you out there that are helping us and have created ROMs in two categories:
1. Test ROMs to help emulator developers verify their emulator behavior against what is expected within the real NES. [PPU timing, 6502 operands, sprite hit, etc.]
2. Demo ROMs that exploit the capabilites of the real NES to the extent that most games (Zelda, SMB, ...) never do because they were focused more on gameplay / presentation. [full palettes onscreen, scrolling tricks, etc.]
The first category are VERY useful if the goal is emulation of games (Zelda, SMB, ...). The second category is useful if the goal includes emulation of all possible homebrew ROMs.
As a development tool writer I want people to expect to get coverage of both categories. Thus I would expect both categories of ROMs described above to work in my emulator. I am finding MOST of these ROMs are documented as working on a real NES...but some aren't...so it is hard to know whether a FAIL result in a ROM is a real FAIL on a real NES or not.
As a deeper example, I seem to have conflicting advice from different test ROMs that I've run regarding whether sprite hit detection should be functional when the background and/or sprites are displayed via the PPUMASK. One gives me a fault saying sprite hit detection should work as expected even when sprites are disabled, and the other says the opposite.
Quote:
As a deeper example, I seem to have conflicting advice from different test ROMs that I've run regarding whether sprite hit detection should be functional when the background and/or sprites are displayed via the PPUMASK. One gives me a fault saying sprite hit detection should work as expected even when sprites are disabled, and the other says the opposite.
For a hit to happen there need a nontransparent BG pixel and nontransparent spritepixel, and not in the rightmost column (255). Both must be enabled of course, but since emulating that a hit always happen won't break any games (does anyone know how you could possibly rely on the flag NOT being set without making it on purpose ?), many emulators went that way.
NESICIDE wrote:
There are those of you out there that are helping us and have created ROMs in two categories:
1. Test ROMs to help emulator developers verify their emulator behavior against what is expected within the real NES. [PPU timing, 6502 operands, sprite hit, etc.]
2. Demo ROMs that exploit the capabilites of the real NES to the extent that most games (Zelda, SMB, ...) never do because they were focused more on gameplay / presentation. [full palettes onscreen, scrolling tricks, etc.]
Perhaps games from the NES's commercial era didn't exploit these capabilities because of Nintendo's lot check guidelines. Notice how a lot of the games that rely on exact DPCM IRQ timing and $2004 reads are by Codemasters, a company that was never an NES licensee. There is evidence that Nintendo planned to change the low-level details of the NES PPU's operation until it 1. introduced the MMC5 and 2. abandoned back-compatibility in the Super NES for cost reasons.
Quote:
As a development tool writer I want people to expect to get coverage of both categories. Thus I would expect both categories of ROMs described above to work in my emulator. I am finding MOST of these ROMs are documented as working on a real NES...but some aren't...so it is hard to know whether a FAIL result in a ROM is a real FAIL on a real NES or not.
Give me a list of questionable ROMs, and I'll run them on my NTSC NES + PowerPak if I get time. That should rule out incompatibilities except for power-on state.
Quote:
As a deeper example, I seem to have conflicting advice from different test ROMs that I've run regarding whether sprite hit detection should be functional when the background and/or sprites are displayed via the PPUMASK. One gives me a fault saying sprite hit detection should work as expected even when sprites are disabled, and the other says the opposite.
IIRC, pixels disabled in PPUMASK are treated as transparent. Which ROMs are you talking about?
tepples wrote:
IIRC, pixels disabled in PPUMASK are treated as transparent. Which ROMs are you talking about?
I meant to go back and edit my post but didn't get to it fast enough. The confusion was on my part. I was confusing the sprite HIT tests with the sprite OVERFLOW tests. I now have both test ROM sets passing.
I'll post my test ROM - specific questions as another thread so as not to stomp on this topic more than I already have.
Dwedit wrote:
If you can, go test it on the
PocketNES preview version too. I'd like to know which emulator's timing it matches.
Then again though, the emulator rounds all graphics changes to the nearest scanline, so I think it might be a little silly to test it.
It will probably look fine, specially if it's scanline based. When I calibrate it for Nintendulator, the border displays just fine on the other emulators, but the CHR bankswitch happens too late (i.e. after the sprite patterns for the next scanline start being fetched), so some of the sprites on the following scanline might be transparent.
Fx3 wrote:
- So...
hehehe
- I'd like to test your program/whatever on my private emu, tokumaru... if possible. ^_^;;
Yeah, since I don't have a GBA and (of course) your private emulator, I guess I can post the 3 test ROMs I used on my PowerPak, so you guys can make your own tests.
Don't expect anything fancy though, the only thing you can see is a 16-scanline border at the top of the screen followed by a solid color for the remaining 224 scanlines. And a few glitched sprites at the top left corner (ignore them!). Nintendulator's output matched my NES (except for the sprites, but that's because I don't initialize the RAM used for sprites while the PowerPak BIOS uses it).
I'll post the ROMs later, since they're on my other PC which is turned off at the moment and I'm gonna prepare dinner now.
tokumaru wrote:
Yeah, since I don't have a GBA
VisualBoyAdvance and NO$GBA run PocketNES. There's a warning on PocketNES.org about using PocketNES with emulators, but that's related more to performance than to compatibility, and we're discussing compatibility.
Quote:
I guess I can post the 3 test ROMs I used on my PowerPak, so you guys can make your own tests.
Please do. I'll test it on my Vizio TV, which is the only TV I have where I can clearly see scanlines 8-15. All my CRT SDTVs seem to be calibrated a bit high so that text crawls on the bottom of news channels aren't cut off.
Quote:
And a few glitched sprites at the top left corner (ignore them!). Nintendulator's output matched my NES (except for the sprites, but that's because I don't initialize the RAM used for sprites while the PowerPak BIOS uses it).
That's not hard:
Code:
shadowOAM = $200
clearOAM:
lda #$FF
ldx #0
@oamclrloop:
sta shadowOAM,x
inx
inx
inx
inx
bne @oamclrloop
stx $2003
lda #>shadowOAM
sta $4014
rts
tepples wrote:
VisualBoyAdvance and NO$GBA run PocketNES. There's a warning on PocketNES.org about using PocketNES with emulators, but that's related more to performance than to compatibility, and we're discussing compatibility.
I'm really not sure about testing an emulator inside an emulator.
Quote:
Please do. I'll test it on my Vizio TV, which is the only TV I have where I can clearly see scanlines 8-15. All my CRT SDTVs seem to be calibrated a bit high so that text crawls on the bottom of news channels aren't cut off.
On my current CRT TV I can apparently see scanline 8 onwards also. My old one masked the first 16 scanlines (I could see a bit more at the sides, due to the curvature of the screen or something)!
Quote:
That's not hard:
Of course it's not, I just haven't worried about sprites yet. My sprite code is done but not active in this ROM yet, and since the junk sprites do not bother me I won't care about a temporary "fix". Soon I'll make the sprite system active.
tepples wrote:
Notice how a lot of the games that rely on exact DPCM IRQ timing ...
Time Lord and Qix are a few licensed NES games which use DMC IRQs to get ready for sprite 0 hit.
OK guys, I uploaded
the files.
As I said, it's nothing fancy. The border at the top just needs to look steady and the new patterns be loaded as soon as possible. Now that I think of it, the fact that the one calibrated for Nintendulator looks correct on the NES doesn't mean it's a perfect match, as I can't know how much after the end of the visible scanline the bankswitch happened. Plus, running the other 2 tests on Nintendulator doesn't seem to match what I saw on the NES for them.
I've changed the code a lot since those 3 builds, and I'm adding a sprite test as well. I'll show all 64 sprites (8 at a time) right below the border and see if any of them shows up with a blank pattern.
- I have no clue about the "right" and the "wrong" results. All I can say is that "nestopia.nes" file is around 16 pixels missing on the last brighter line. The other two ones seem ok.
This is not one of blargg's professional tests meant to stress the hardware or anything... =)
Each of these ROMs is calibrated to show 16 bright scanlines and then 224 dark ones on each emulator.
On a real NES, only "nintendulator.nes" has the 16 brighter scanlines complete. The other 2 ROMs have the last bright scanline flickering at some point and it turns dark before the right edge. The one calibrated for Nestopia was the worst one on the NES.
So I guess your timing is better than Nestopia's, because you can see it's error, but you can't see FCEUXD's error.
tokumaru wrote:
OK guys, I uploaded
the files.
Quote:
This file is neither allocated to a Premium Account, or a Collector's Account, and can therefore only be downloaded 10 times.
This limit is reached.
To download this file, the uploader either needs to transfer this file into his/her Collector's Account, or upload the file again. The file can later be moved to a Collector's Account. The uploader just needs to click the delete link of the file to get further information.
RapidShare!
For reals.
Only semi-legit use for rapidshare is porn. Get a googlepages account or something.
I've always found
FreeWebs to be great for file storage. They haven't once told me to cut down on how much I upload. And plus, you get your own site.
EDIT: I don't know if you can upload stuff so much if you have that dumb easy page builder. I stuck with straight up HTML for my site.
I tried to download the timing test and got a javascript error. I dont think rapidshare is a good choice for file downloads.
matt
If anyone is still interested, I extended the test. I now put all 64 sprites at the transition between the border and the non-transparent area for better debugging.
Truth is there are 2 operations that require good timing. I'm use 8x16 sprites in this game, and I'm using CHR bankswitching with transparent patterns to blank the top 16 scanlines, but I don't wanna waste a whole 8KB chunk of CHR (the mapper can only switch that), so I temporally set the sprite height to 8, so I can get away with only 4KB of transparent patterns.
Anyway, the first important operation is switching the sprite height back to 16. The windows for that is pretty wide though (almost 50 CPU cycles), so there shouldn't be any problems.
The second operation is switching the actual patterns in, and the window for that is pretty narrow. If it happens too soon, the last blank scanline is glitched. If it happens too late, sprite patterns on the first non-blank scanline will be wrong (either transparent or junk from the 4KB of CHR I decided not to waste). This shouldn't look so bad, players are used to little glitches in emulators and even on the real NES. Plus, sprites usually flicker anyway... I'll probably calibrate for the real console and hope for the best.
So, with the new test it's easy to see when anything goes wrong. Each group of 8 sprites stays on the screen for a couple of seconds, enough to see if they are transparent (could be because they were evaluated with the wrong height, in which case only the first groups will show the problems, or because transparent patterns were fetched) or have the wrong patterns (colored bright green for easy recognition).
But it's too late now and there are still a few things to do, but as soon as I can I'll post ROMs with this new test, calibrated for different emulators. I'll also calibrate it for a real NES. I'll hopefully post them tomorrow.
There are still things to organize, but
this (I hope MediaFire doesn't suck) is my latest test. Runs perfectly on Nintendulator, FCEUXD, and my NES, but fails terribly on Nestopia.
It can look better on Nestopia. I can easily fix the transparent line of the first few sprite groups, but no matter what I do, wrong patterns will be fetched for the first 3 or 4 sprites rendered.
Looks like this in nemulator:
Haven't looked at it in another emulator... is this correct?
James wrote:
is this correct?
Can't say for sure based on a single screenshot, since all sprites must be tested, and because of the sprite limit they are tested in 8 groups of 8. Your screenshot only shows the 6th group.
It appears to be correct though. It is correct when the top section (light gray) and the bottom section (dark gray) are clearly defined (no flickering between them) and all sprites of all 8 groups of sprites (first four groups are colored black and last four are purple) "touch" the light gray section.
Errors include a flickering scanline between the 2 sections, transparent or green sprite patterns on their first visible scanline (the one that touches the top section).
it's working correctly according to your description
I tried
http://www.mediafire.com/?3qrwyofyimo and that only shows a link to scan for PC viruses.
The download link is right above that. It seems to use JavaScript, so make sure you have it enabled (there's not much you can do on the internet nowadays without JavaScript).
I dont have java or javescript enabled. A simple download should not need any of that.
Oh well. Perhaps when a better upload site is found I can try.
matt
mattmatteh wrote:
I dont have java or javescript enabled. A simple download should not need any of that.
It's a measure against bots that consume bandwidth without displaying the advertisements that fund the service.
mattmatteh wrote:
I dont have java or javescript enabled.
The internet must be a sad place for you if all you have is simple HTML. You're missing a lot, buddy, I'll tell you that.
You're not missing anything without the ROM I uploaded though. It's just an example of code that requires precise timing to run 100% correctly. Unless you're making an emulator and aiming at perfect timing, this shouldn't be of any interest.
I was playing Jurassic Park in Nestopia, which uses a glitch hiding trick similar to tokumaru's, and I noticed it also displays a scanline of the background before it displays a scanline of sprites. Before now I never knew why. That said, it's not very noticeable unless the main character goes beyond the top border of the screen.
Actually I just tested it in Nintendulator, and it also displays sprites 1 scanline later than the background. So maybe this happens with Jurassic Park on actual hardware too?
CartCollector wrote:
So maybe this happens with Jurassic Park on actual hardware too?
I think it does. I don't know why... That game doesn't seem to share tiles between sprites and background, so there is more than enough time to select all the sprite patterns as the last blank scanline is displayed and then, before the first non-blank scanline is rendered select the background patterns, even though the MMC3 requires quite a few register writes to set the whole pattern table.
The mapper I'm using switches the whole 8KB of CHR at once, so I can't treat background and sprites differently. Plus I'm using tiles from both sides of the pattern table for sprites. This makes the very end of the last blank scanline (when all background patterns have been fetched and the sprite patterns for the next scanline are about to be fetched) the perfect point to switch all the patterns, but it seems some emulators are not accurate enough to have that point match the real console. It's a shame, because it works perfectly on the console.
Maybe if I decided to delay sprite rendering for one more scanline (so that the background would be displayed first, like you say happens in Jurassic Park), I'd have a slightly larger window to accommodate timing issues, but I really don't feel like giving up on something just because a few emulators don't show it right.
tokumaru wrote:
The internet must be a sad place for you if all you have is simple HTML. You're missing a lot, buddy, I'll tell you that.
Not missing the ads.
tokumaru wrote:
You're not missing anything without the ROM I uploaded though. It's just an example of code that requires precise timing to run 100% correctly. Unless you're making an emulator and aiming at perfect timing, this shouldn't be of any interest.
I am interested in making sure my emulator is accurate.
matt
tokumaru wrote:
You're not missing anything without the ROM I uploaded though. It's just an example of code that requires precise timing to run 100% correctly. Unless you're making an emulator and aiming at perfect timing, this shouldn't be of any interest.
Or unless someone is still saving up for a PowerPak and, in the meantime, trying to determine which emulator is closest to accurate.
mattmatteh wrote:
tokumaru wrote:
[Without script on the Web,] You're missing a lot, buddy, I'll tell you that.
Not missing the ads.
Most of the annoying ads nowadays are
SWF objects. I put a
filter in my web browser to disable SWF objects for sites not on a whitelist.
mattmatteh wrote:
I dont have java or javescript enabled. A simple download should not need any of that.
Oh well. Perhaps when a better upload site is found I can try.
matt
I could set up an anonymous access folder at
ftp://www.nesicide.com...would that work?
NESICIDE wrote:
I could set up an anonymous access folder at
ftp://www.nesicide.com...would that work? :?:
What ever works with wget is preferred.
Thanks
matt