Brand new OAM size findings

byuu · Post by **byuu** » Wed Apr 26, 2006 10:35 am

Charles MacDonald's OAM sprite test was giving me a fit. He didn't initialize OAM (the two attribute tables) correctly, so sprites were wrapping to the top left of the screen. All emulators seemed to be giving different results when using it, and it lacks vflip/hflip/OAM interlace settings, so I made my own sprite test demo.

byuu.cinnamonpirate.com/files/test_oam.zip -- copy/paste link

My test also lets you set the video mode and character number, has a hex map so you can tell exactly what each tile number displayed's hex value is, and has an easier to use interface.

I found out some brand new hardware quirks in the process.

That said, no publically released emulator gets all tests correct. I've included an updated bppu_render_oam.cpp file that can be used with bsnes v0.016 to pass all tests. Otherwise, you'll need a copier to see the proper results.

Ok, now we all know about OAM base sizes 6 and 7.

6 = 16x32 <> 32x64 and 7 = 16x32 <> 32x32, right?

Yes, unless OAM interlace is enabled. It then becomes :
6 = 16x16 <> 32x64 and 7 = 16x16 <> 32x32.

Yeah, 6 with OAM size clear gets cut in half to 16x16, as does 7. But 6 with OAM size set stays at 32x64, as you'd expect.

And of course, vertical flipping of sprites with height double the width get split into two blocks, such that

12
34
56
78

becomes

34
12
78
56

The same applies with OAM interlace enabled. But obviously only for base size 6, size 1 (32x64), since the other two non-square sprite sizes become square with OAM interlace on.

Sprites do not care whether interlace itself ($2133.d0) is on or off. The Y position is doubled to (line_y - sprite_y) and interlace field is added with OAM interlace on (or subtracted if the tile is flipped vertically).

Now, obviously if you turn on true interlace, the OAM sprites now appear to truly be double-height (or should I say, half-height?), by taking advantage of the interlacing. If you turn off interlacing, you miss every other line of the sprite, and the sprite will flicker as it switches back and forth between the two fields each frame.

Lastly, one thing a lot of emulators miss is sprite tile number wrapping.

Say you have a 64x64 tile, and the first tile is 0xff. The next tile is not 0x100, it is 0x00. Similarly, the next vertical row below 0xff is 0x0f, not 0x10f. This is because the X tile number wraps within 0-15, and the Y tile number wraps within (0-15)*16.

I'll try and post tomorrow with a list of bugs in each of the various emulators.

byuu · Post by **byuu** » Thu Apr 27, 2006 3:19 am

test_oam bugs in all active SNES emulators :

Code: Select all

ZSNESW_0329
- 6,0 = 8x8, 6,1 = 16x16
- 7,0 = 8x8, 7,1 = 16x16
- no character x,y wrapping
- no oam interlace

SNES9x v1.43-wip1
- 6,0 + oam interlace = 16x32
- 7,0 + oam interlace = 16x32
- no oam interlace <and yet it works in the SNES test demo... it's still a bug though, as it isn't working here>

Super Sleuth v1.04e
- Bug in input, unable to test

Super Sleuth v1.03
- 6,0 = 8x8, 6,1 = 16x16
- 7,0 = 8x8, 7,1 = 32x32
- no character x,y wrapping
- no mode0-4,7 interlace

SNEeSew v0.842
- 6,0 + oam interlace = 16x32
- 7,0 + oam interlace = 16x32
- no character x,y wrapping
- no oam interlace

SNESGT v0.205e
- 6,0 = 32x32, 6,1 = 64x64
- 7,0 = 32x32, 7,1 = 64x64
- no character x,y wrapping
- no oam interlace without interlace enabled first
- no mode0-4,7 oam interlace
- incorrect mode5-6 oam interlace

bsnes v0.016
- 6,0 + oam interlace = 16x32
- 7,0 + oam interlace = 16x32
- 6,0 + 7,0 + 7,1 vflip incorrect
- oam interlace incorrect with and without interlace enabled

Correct results should be:
- 6,0 = 16x32, 6,1 = 32x64
- 7,0 = 16x32, 7,1 = 32x32
- 6,0 + oam interlace = 16x16
- 6,1 + oam interlace = 32x64
- 7,0 + oam interlace = 16x16
- 7,1 + oam interlace = 32x32

bsnes v0.016 wip1 and above pass all tests.

I'm particularly concerned by the character x,y wrapping failing in all but SNES9x and bsnes. To see this, set base=2,size=1,char=255. It should display :

Code: Select all

FF F0 F1 F2 ...
0F 00 01 02 ...
1F 10 11 12 ...
2F 20 21 22 ...

Whereas all you see is FF and nothing else in other emulators. I don't know of any games that rely on this behavior, but I'm certain there has to be at least one...

Also, there's some sort of hanging bug with the v1.04 preview builds of Super Sleuth, so I can't test that version.

Post by **Nach** » Thu Apr 27, 2006 3:36 am

Why'd you use an old build of Snes9x?
Windows builds of v1.43 are readily available.

-_pentium5.1_- · Post by **-_pentium5.1_-** » Sat May 06, 2006 8:02 pm

Um... Where can I download the most current working version of Super Sleuth (preferably 1.03)? Didn't the website go down at some point?

Clements · Post by **Clements** » Sat May 06, 2006 8:04 pm

http://users.tpg.com.au/advlink/spx/

-_pentium5.1_- · Post by **-_pentium5.1_-** » Sat May 13, 2006 8:54 pm

Thanks.

How high a priority is this OAM issue for the ZSNES team (not bsnes)?

Post by **pagefault** » Sun May 14, 2006 9:01 am

Two of these bugys are now fixed in ther expernimental trunk

I will put them in when I feel they are good enough for public consumption since they are really messily implemented

Thanks for the test byuu, I owe you won.

byuu · Post by **byuu** » Sun May 14, 2006 9:42 am

Why'd you use an old build of Snes9x?

Confusion, as I usually don't increment the version number for WIP releases, whereas SNES9x apparently does :/

Thanks for the test byuu, I owe you won.

No problem. The only big one IMO is the character tile number X/Y wrapping (eg FF->F0 and not FF->100). Probably won't fix anything, but eh.
And the sprite size one should be easy, sans that weird OAM interlace size difference thing.

Anyway, no need to pay me back. With all you guys have helped me with so far (and continue to), I'm the one who owes you :)

Post by **Nach** » Sun May 14, 2006 11:38 am

byuu wrote:
Why'd you use an old build of Snes9x?
Confusion, as I usually don't increment the version number for WIP releases, whereas SNES9x apparently does :/

Everyone asside from you does.
It's a work in progress for the version mentioned, which is the next version. Have a WIP on a version which is completed doesn't make much sense.

byuu · Post by **byuu** » Mon May 15, 2006 2:55 am

Ah well, I like to be different.

Edit: Fine, I now use v0.<n>.<%2w> instead of v0.<n> wip<w>, eg v0.016 wip8 ->v0.016.08. Better?

pkasting · Post by **pkasting** » Tue May 16, 2006 4:13 am

No, because that sounds like minor patch release #08 for v0.016.

Just use the next major version number and call it 0.017 pre8 or 0.017 alpha8 or whatever, it would be a lot clearer. You're working to finish 0.017, not working to make tiny fixes in 0.016...

Edit: and I have way more than 1 post, WTF

You don't post for months and it forgets all about you...

Post by **Nach** » Tue May 16, 2006 4:18 am

byuu wrote: Edit: Fine, I now use v0.<n>.<%2w> instead of v0.<n> wip<w>, eg v0.016 wip8 ->v0.016.08. Better?

I like that, except that two decimal places is inherintly flawed.
But, that's what Linux uses these days I guess.

byuu · Post by **byuu** » Tue May 16, 2006 9:48 am

No, because that sounds like minor patch release #08 for v0.016.

Well, in a sense... it is. Just not a public one. I usually raise it by one each time I get a full days' work in on the program.

Just use the next major version number and call it 0.017 pre8 or 0.017 alpha8 or whatever, it would be a lot clearer. You're working to finish 0.017, not working to make tiny fixes in 0.016...

Sorry, I'm not willing to use the next version number for a WIP. I think of a WIP as an extension upon what's been done, not as a premonition of what will be. Just another pet peeve that I stand up for, much like "all right->alright". It may not be the accepted way of doing things, but in my opinion should be, and change has to begin somewhere, right? That or I just love being difficult, haven't decided yet :)

I like that, except that two decimal places is inherintly flawed.

What? Not according to the decimal system, it isn't. If the second release is .2 and the ninteenth is .19, then .2 > .19. You need to use .02 and .19 to properly express this. I don't ever expect to go above 99 WIPs with no release, but you never know. I'll come up with something clever if that ever happens.

And yes, I very much consider the revision numbers to be decimal numbers instead of whole numbers, as do most people who see .s before numerals. And even if you do consider them to be whole numbers, padding with zeroes results in the same number, so there is no confusion that "02" came before "19", regardless of how one interprets things.

Eh, if everyone's unhappy I'll just go back to what I was doing before.

At least I'm dragging my own thread off-topic for once. If anyone needs clarification / help or anything for my original post, feel free to chime in at any time.

Post by **pagefault** » Tue May 16, 2006 9:57 am

byuu you should consider being hosted by bountysource with us. the management here is great and can do anything pretty much you want requested. I'd give it a try, might make tracking bugs and such easier.

Post by **Nach** » Tue May 16, 2006 11:36 am

byuu wrote:
I like that, except that two decimal places is inherintly flawed.
What? Not according to the decimal system, it isn't. If the second release is .2 and the ninteenth is .19, then .2 > .19. You need to use .02 and .19 to properly express this. I don't ever expect to go above 99 WIPs with no release, but you never know. I'll come up with something clever if that ever happens.

Yes, those two decimal places is fine, and people like the Linux Kernel should be shot for telling us it's a number.

I mean two places with a decimal point.
Imagine this: $6.05.03

So that would be 6 dollars, 5 cents, and um ... a ... potatoe chip?
I've never seen two places with decimal points, or perhaps more correctly phrased as "two decimal points" in a number outside of stupid version numbering. I'm not even sure what such a system is supposed to mean really in math terms.

However as I said before, I think your system is loads better than your old one, and it's fine in general except for . . flaw. And yes .2 is > .19, which is something Linux as of yet seems to not realize.

sinamas · Post by **sinamas** » Tue May 16, 2006 3:17 pm

Version numbers aren't usually meant to be decimal numbers. The dots are simply seperators. (In many countries commas are actually used for decimal numbers.)

major.minor[.revision[.build]]

I should be able to make as many n.x releases as I want to (without making version increments gradually smaller).

0.9.0 < 0.10.0

At least for RCs I think it makes sense to use the current+1 version number, since it's a release candidate of the next version.

Post by **Nach** » Tue May 16, 2006 3:22 pm

sinamas wrote:Version numbers aren't usually meant to be decimal numbers.

Then don't use a decimal

It gets even worse now when they're trying to use them to convey a date.
05-10 or 05/10 would be understandable, but no they have to go with 5.10, which might as well mean 5.1, which isn't what they meant.

sinamas · Post by **sinamas** » Tue May 16, 2006 4:17 pm

Nach wrote:Then don't use a decimal

I'm not. 2.103.34 is not a decimal, it's three numbers with dots between them

byuu · Post by **byuu** » Tue May 16, 2006 4:31 pm

byuu you should consider being hosted by bountysource with us.

My code is open source and I don't mind making WIP changes more convenient for everyone else to see. However, I prefer to manage the main source tree locally. It's easier for me, and realistically I add 95+% of the new code, anyway.

Imagine this: $6.05.03

So that would be 6 dollars, 5 cents, and um ... a ... potatoe chip?

Six dollars, five cents and umm ... 3/100ths of a cent? You make a point that it isn't valid to have more than one decimal place in a number, but they're just superfluous, you take it off and you get the same result. 6.05.03 becomes 6.0503.

0.9.0 < 0.10.0

Not according to most filesystems that sort things alphanumerically. Not according to anyone who interprets the . as a decimal place. Why throw in the added confusion? A padded 0 hurts no one and the intention is always clear.

sinamas · Post by **sinamas** » Tue May 16, 2006 5:11 pm

byuu wrote:
0.9.0 < 0.10.0
Not according to most filesystems that sort things alphanumerically. Not according to anyone who interprets the . as a decimal place. Why throw in the added confusion? A padded 0 hurts no one and the intention is always clear.

I think it makes sense to have the major.minor distinction, since I can then change the major number for big changes/rewrites rather than having an arbitrary nubmer that isn't relative to anything but previous versions. It's also nice to have the distinction to mark ABI breakage between major versions.

Of course you could keep the major.minor distinction while staying within the rules of the decimal system, but that would be artificial and ugly imo. For instance you could end up doing 0.7->0.8->0.9->0.91 because of poor planning, while the changes from 0.9 to 0.91 are as big as the changes from 0.8 to 0.9. That's inconsistent and would imply that the step up is smaller relative to the last version than previous releases have been. With a decimal system you'd in general be implying that any change in the version number reflects changes in the software relative to the last number (2.42->2.51=2.92->3.01), which wouldn't be true if you still make the major.minor distinction. It's just flawed imo.

I think it's unnecessary to restrict yourself to numbering rules that don't fit the way the software is developed. Having distinct numbers for major minor and revision is more flexible and more descriptive. I guess I could always use different symbols than dots to avoid the confusion. Using dots is the de-facto standard though.

Well, whatever floats your boat I guess. (And the alphanumeric sorting problem is indeed annoying.)

byuu · Post by **byuu** » Tue May 16, 2006 5:38 pm

And you make good points...

For instance you could end up doing 0.7->0.8->0.9->0.91 because of poor planning, while the changes from 0.9 to 0.91 are as big as the changes from 0.8 to 0.9.

I agree, I've seen this countless times. I think this idea would work if the main version were the one to be incremented with each release, eg 9.0, 10.0, etc but not as 0.9, 0.10, etc.
As a small bonus, most newer file managers will recognize numbers before the decimal place and sort "correctly".

Planning is definitely important, I've seen far too many projects accidentally reach v1.0 too soon by jumping up by over .100 for relatively minor changes in comparison to the project as a whole.

Firefox is a good example of a version numbering system that is out of control. .6, .7, .8, .9, 1.0, 1.5, 2.0 <futurepredict>3.0, 4.0, 6.0, 12.0, 24.0, 48.0, E(n=6 ... +1) { 2.0^n }...</futurepredict> heh. I know they're in a hurry to catch up to 7.0, though.

Then there's all of the v0.99.98b emulators...

I just stick to bumping the major version by one for each release. I don't ever expect to exceed 1000 official releases (~83 years at 1/month), nor do I ever expect to achieve perfection, which in my opinion would be v1.0, so it works out well for me. I also get the benefit of my version number actually meaning something, since in emulation terms you're never going to reach 100% accuracy anyway.

I think it's unnecessary to restrict yourself to numbering rules that don't fit the way the software is developed.

Agreed, it's really a balance of personal preference and not annoying others with it. My idea doesn't seem all that intolerable, makes logical sense, and sorts properly in my file manager, so... it works for me.
All of my WIP releases are even in order as a result of not bumping the number first.

Nightcrawler · Post by **Nightcrawler** » Wed May 17, 2006 1:53 pm

This is really a silly argument. I can't speak for others, but I'm sure there are plenty of people such as myself who really don't care if it's called:

bsnes a-boo-da-be
bsnes 1.2343353533
bsnes super magic special hyper version 4546445454
bsnes 23.2324.22.2.32.32322...23232..232.2.32.32

Get my drift? As long as the versions are different and identifiable in SOME way, that's probably just fine.

Post by **Nach** » Wed May 17, 2006 3:35 pm

It matters if you see multiple versions and can't tell which is newer and which is older.

Post by **pagefault** » Wed May 17, 2006 4:42 pm

We should start applying the SVN revision to the version number in ZSNES. But I don't know if there is some way to automate this, maybe a SVN hook that edits a file or something.

Aerdan · Post by **Aerdan** » Wed May 17, 2006 7:04 pm

It's quite possible. Audacious uses a build-stamp system. See its sources for details.