bsnes v0.039 released

[byuu]

Here it is:
http://rapidshare.com/files/199376465/test_oam.zip.html

Thank you very much, I've found the problem.

src/ppu/bppu/bppu_render_oam.cpp:line 42:

Code: Select all

-    sprite_list[i].y              = tableA[1] + 1;
+    sprite_list[i].y              = (tableA[1] + 1) & 0xff;

src/ppu/bppu/bppu_render_oam.cpp:line 69:

Code: Select all

-  int y = line - spr->y;
+  int y = (line - spr->y) & 0xff;

With Y=$ff, Y+1 was going to 256 rather than zero. Looks like that was throwing off the tilemap indexing.

[Jonas Quinn]

Here it is:
http://rapidshare.com/files/199376465/test_oam.zip.html

Thank you very much, I've found the problem.

src/ppu/bppu/bppu_render_oam.cpp:line 42:

Code: Select all

-    sprite_list[i].y              = tableA[1] + 1;
+    sprite_list[i].y              = (tableA[1] + 1) & 0xff;

With Y=$ff, Y+1 was going to 256 rather than zero. Looks like that was throwing off the tilemap indexing.

It still doesn't work if you change y to $F0.
I think the bug is on line 78. If y is negative you will get the wrong value. It's fixed if I change it to:

Code: Select all

y = (y < spr->width && y>=0) ? ((spr->width - 1) - y) : (spr->width + ((spr->width - 1) - (y - spr->width)));

Edit: The second change in your ninja edit fixes the case with y=$F0, too.

[byuu]

Yes, sorry :)

The first one only fixed Y=$ff. Tested with $f4 and noticed it was still overflowing.

The code there is really a mess. That was one of the very first things I wrote back in 2004-5, and it hasn't really been touched since. Honestly I don't even know if I've fixed this properly or not, but it seems to work.

There's probably a lot of unsafe overflows around that area. I keep telling myself I'll rewrite the PPU to be cycle-based and all clean and rainbows and kittens and stuff, but it's 2009 and I haven't even started on that. Terrified to, ... it's going to be hell I'm sure :(

-----------------------------------------

By the way, while you're working with test_oam, please check this out:

Set Y=0, base=6, size=0, then set 2133=3 (eg enable OAM interlace.)

Notice how the sprite is now 16x16? Turn off OAM interlace, eg 2133=0, and the size is now 16x32. It's the only mode I've seen that. Seems to be some sort of hardware PPU bug. Really weird stuff, don't have any explanation for that behavior. See it on the real thing, of course.

[FitzRoy]

For power users / emu loader tools, I allow loading via command-line / file association to hide the menubar automatically.

For general users, when you enter fullscreen with a cart loaded, the menubar disappears. With no cart, you will have to show the menubar anyway in order to load a cart to play, then hide it again. So it should be shown. It even lets you know there's no cart loaded at the bottom right.

If one insists on loading games in fullscreen mode manually, then one extra key hit after is surely not a big deal.

Darn it, byuu, I jumped to conclusions after toggling without a rom loaded for the first time. Okay, so it only disappears when a rom is loaded. Here's the problem with that: if I don't know the fullscreen or menubar toggle, how do I get out? Once I use the fullscreen toggle from the menu with a rom loaded, the menu disappears. What do I do? And then if I manage to guess Esc to bring it back, I create a habit of doing it the long way because there's a good chance I still don't know a fullscreen toggle exists. Wouldn't it be better if only the toggle existed and I was told of its existence on first run?

a) I don't see why we can't have a menu entry as well as a hotkey. We don't remove 'Load Cartridge' because you can do that with a key binding. '[ ] Fullscreen' makes sense under "Video Mode".

The difference is that the action of toggling the mode or the menubars can make the menu disappear. No other actions do that. And the only reason the menubar toggle exists at all is because fullscreen video settings can currently only be set via the fullscreen menu. That entire toggle could get wiped out if menu behavior was standardized.

I appreciate you arguing with me on this for so long, I'd have punched me by now. But here's what confused me about not getting that: you wanted the quickness of menu settings for video. Okay, understood... However, let's say the following actions were taken:

(a) the video section added both windowed and fullscreen settings in addition to settings in the windowed menu.
(b)The fullscreen menu was removed
(c) The menubar/statusbar toggle was removed.

That would still give you fast changes for testing in windowed mode, and for everyone else it would vastly simplify fullscreen behavior. It's a win-win for everybody, right?

b) Should we document the ten other GUI hotkeys? That's what the GUI hotkey window is for. Yeah, there's a problem with people finding that. I don't have a good answer for that ... if we list the GUI keys first, people won't find the joypads. If we list the joypads, people won't find the GUI keys.

You understand exactly why I assume people won't find it beforehand. It's not that the input section is poorly designed, it is buried and there is simply no better place for it. You can get around this gracefully without touching that section, that's what I'm trying to help you accomplish.

I kind of take issue with that, but we're just splitting hairs here. You can put anything inside an SNES cart. I'm writing a Super NES emulator, not a game cartridge emulator (even if the latter is the end goal.) The cart special chips I add are icing on the cake, and aren't even focused on strict accuracy (due to time constraints, I'd like them all to be timing/bit perfect of course.)

I'm not trying to offend you, I'm just looking at it from the side of the user who has no idea that you consider savestates to be categorically more important than hardware required for many games. I know it makes your goal seem unattainable, but you had to be thinking of the games before you did this: without software, the hardware is meaningless. Imagine if Der Langrisser had used the DSP1 chip, your view would change overnight, wouldn't it? I don't like it any more than you do that the SNES library used more unique processing units than any other console in history, but it is what it is.

That's what I was going with. I want to list that I don't support SuperFX, SA-1, etc. I know someone who's never heard of the SNES won't know what the hell they are, but I think most people using bsnes would.

Fair enough, but even a fairly knowledgeable user would look at "Unsupported Hardware" and assume an all-inclusive list. You could in some way hint at or explain that it's not.

[grinvader]

I keep telling myself I'll rewrite the PPU to be cycle-based and all clean and rainbows and kittens and stuff

Such a project is obviously doomed from the beginning.

You need better components to pull it. Avoid food and radioactive materials for instance.

[henke37]

If we are going to fantasize about things that are theoretically possible, can I get my savestate by stackframe dumping idea done too?

[Verdauga Greeneyes]

I keep telling myself I'll rewrite the PPU to be cycle-based and all clean and rainbows and kittens and stuff, but it's 2009 and I haven't even started on that. Terrified to, ... it's going to be hell I'm sure

To be fair there has been some progress towards this: you rewrote the way CPU/PPU communication is handled so it wouldn't be horrendously slow.

I think the main problem is whenever you do get a tough SNES hardware problem to focus on, you pounce on it and work yourself to death for a week until you've fixed it, leaving yourself burned out. And so most of the development we've seen has been (important but) boring UI stuff that you can work on at a slower, but steady pace. There must have been a time when you'd work on SNES hardware things in the same fashion because bsnes was still relatively new and there was a lot to do, so maybe you can do the same for the PPU?

[FitzRoy]

A dot-based PPU will have no known tangible benefit on the gaming experience. The GUI does, the special chips do, peripherals do, the the BS-X does, the Super Gameboy does. I wouldn't understand if it got a higher priority than any of these and I'll state why.

Byuu's rationalization is that external hardware behavior never matters as much as internal hardware behavior because endless amounts of external hardware could have been introduced.

The way I see it, a finite amount of hardware was introduced and endless amounts of external and internal hardware could have been introduced. Different versions of the processors were released for NTSC/PAL, different revisions of those processors were released, and Nintendo was perfectly capable of coming out with Super Duper Nintendos where the SuperFX was housed from within. The base environment was not immune to being released with different or additional hardware (but it was less likely to be). When it comes down to it, both external and internal hardware behavior is as important as the games that utilized it. If both PPU and BS-X are equally in need of documentation, but the BS-X gets you a couple hundred new games to play, I'd put the BS-X higher on the totem pole. Maybe byuu agrees with that now, maybe he doesn't.

[byuu]

The dot-based PPU will have no known tangible benefit on the gaming experience.

Very true. It'd only visibly remove the last global hack in bsnes that fixes Uniracers.

That fix could be back-ported to the scanline-based renderer, but figuring it out without a cycle-renderer would be like determining how quarks behave with only a cursory understanding of molecules.

Byuu's rationalization is that external hardware behavior never matters as much as internal hardware behavior because endless amounts of external hardware could have been introduced.

An improvement to the base is an improvement to all games, even if you can't perceive the difference. An improvement to the SuperFX is an improvement to ten games. Those focused on a hardware emulator are more interested in the former, those focused on a game cartridge emulator moreso the latter.

Your view is definitely more pragmatic. But if it doesn't interest me, it's going to be very hard to keep up the motivation to support these chips.

It doesn't require one to fully understand the base SNES to emulate special chips, surely it'd be better to try and get some help writing generic, hot-pluggable SuperFX / SA-1 / BS-X cores that can be re-used by all emulators. Re-writing 14 chip emulators for each new emu is a major bottleneck to the creation of new SNES emulators.

There has to be someone who'd be interested in seeing SuperFX support added to bsnes+MESS+Schuper+SNEeSe+SNem+all future emulators.

[Panzer88]

the way I see it is that bsnes again, is not about playability but about mimicking the machine.

With this in mind it makes most sense to do all the work, completing each section, from the innermost parts and work your way out.

Sure there are things that I personally would find cool to see myself, like blind super scope option, special chips, being able to force the "wrong region" or super scope plugged in on an SFX game, or even more satellaview stuff, but from the viewpoint of keeping the integrity of this project, it makes most sense to tackle all the core snes hardware first.

There are already several emulators that "just play all games" we don't need another one that does that.

[byuu]

blind super scope option

I added this and sent you the WIP. Never heard back from you on it, but I already knew it wouldn't work. I track the cursor relative to the screen and hold it against the edges so it doesn't go 'infinitely' out of focus of the screen. If you use a handheld pointer, and move too far offscreen, it will throw off your alignment. Too pesky to support both relative and absolute positioning.

being able to force the "wrong region"

Already there.

[Panzer88]

Deleting all my messages.
Don't know if I responded to this or not, but just in case (ignore if duplicated):

Don't give out link please, yadda yadda.

And no, no blind SS option yet, sorry. Will be there eventually.

this is the only PM I got from you on the matter, saying that there was no option yet. I never got a PM from you saying there was any.

and about the wrong region, I guess I was thinking of super scope to SFX, and that won't happen till SFX comes around so no sweat.

[FitzRoy]

An improvement to the base is an improvement to all games, even if you can't perceive the difference. An improvement to the SuperFX is an improvement to ten games. Those focused on a hardware emulator are more interested in the former, those focused on a game cartridge emulator moreso the latter.

How is it an invisible improvement to all those games if only one game utilized the extent of the PPU's unemulated behavior?

[Panzer88]

An improvement to the base is an improvement to all games, even if you can't perceive the difference. An improvement to the SuperFX is an improvement to ten games. Those focused on a hardware emulator are more interested in the former, those focused on a game cartridge emulator moreso the latter.

How is it an invisible improvement to all those games if only one game utilized the extent of the PPU's unemulated behavior?

well of course because when it's implimented the old core will be gone and all games will run on the new core. I'd think that was an obvious question.

[FitzRoy]

Hey Panzer, I'll give you 1 million invisible dollars for 100 visible ones. Deal?

[creaothceann]

There might be other games out there using that specific feature, and we just haven't got a bug report about it yet. Fixing it bug is more about peace of mind than practical use, I guess.

[Panzer88]

there are still discrepancies between bsnes and snes hardware, and little bugs every once in awhile, as creaothceann stated this might help fixing more bugs and creating an environment as identical as possible to real hardware so that those of us without copiers have that experience readily available to us.

It's the idea of spreading yourself too thin, don't branch out, till you have the trunk/foundation right.

My statements was just calling you out on the question, you already knew the answer, you just keep asking it hoping for a different one.

don't think for a minute that I don't want what you want too, we just disagree on the order. Byuu is going to do what he started out for with this project and he outlined. Eventually someone will write this stuff, but I think it's clear it's not top on his priority list.

There is no need to beat a dead horse. Time would be better spent searching for another person as byuu stated who has that desire to write for said chips.

[FitzRoy]

There might be other games out there using that specific feature, and we just haven't got a bug report about it yet. Fixing it bug is more about peace of mind than practical use, I guess.

I'm not suggesting never address it, I'm suggesting to address it after larger, known software malfunctions.

[grinvader]

figuring it out without a cycle-renderer would be like determining how quarks behave with only a cursory understanding of molecules.

Err... actually you don't need to know how molecules behave to know how quarks do, because the latter define the former and not the other way.

To make an analogy, you wrote roughly "would be like determining where two rails go without knowing what a train is.". You can see it's quite possible.

</slight derail>

[Panzer88]

blind super scope option

I added this and sent you the WIP. Never heard back from you on it, but I already knew it wouldn't work.

I'm looking in the current WIP and still can't find this feature.

[Verdauga Greeneyes]

It would be like trying to explain CP violation with only a cursory understanding of nucleons?

[adventure_of_link]

It doesn't require one to fully understand the base SNES to emulate special chips, surely it'd be better to try and get some help writing generic, hot-pluggable SuperFX / SA-1 / BS-X cores that can be re-used by all emulators. Re-writing 14 chip emulators for each new emu is a major bottleneck to the creation of new SNES emulators.

Question:

Adding more and more special chips to the internals of an emulator would slow it down, right? Would adding special chips through this system (or perhaps through a plug-in system), and loading/unloading as necessary speed up the other games as well, or would it bog them down?

[creaothceann]

plug-in system

millions of voices suddenly cried out in terror...

[PiCiJi]

Very true. It'd only visibly remove the last global hack in bsnes that fixes Uniracers.

You can't check each game from beginning to the end. Maybe there are more hacks needed. A working ppu cycle based emulation reduces the risk of unknown bugs. If your motivation is high enough, you should try it. I wonder what lowers speed more, accurate SA-1 emulation or accurate ppu emulation.

If we are going to fantasize about things that are theoretically possible, can I get my savestate by stackframe dumping idea done too?

It's much easier to rewrite bsnes as a state machine. So I have done this. It's a non public version with savestate support. It has the same accuracy like bsnes, in particular the bus accuracy between cpu and smp. If I remember right the main cause for using threads in bsnes was to reduce the code complexity to achieve bus accuracy.

[Snark]

How is it an invisible improvement to all those games if only one game utilized the extent of the PPU's unemulated behavior?

That's the point of an accurate emulator, that's the point of bsnes. I understand for some "accurate emulation" is beneficial because it allows a compatibility close to (perceived) 100% as it did in the case of bsnes...and beyond that you don't really see the point as proven by your objections to the possible future PPU renderer... but I think most here disagree on this.

I can appreciate your pragmatic/user oriented POV though. And I think the best argument has been made by creaothceann: How do you know...that is, how CAN you know, that no other games "uses" the dot line renderer?

If you stop developing accurate emulation as soon as you get 'apparent' 100% compatibility, how can you be sure that you really have 100% compatibility? The more accurate the less chance of undetected/unreported bugs.

You can't check each game from beginning to the end. Maybe there are more hacks needed. A working ppu cycle based emulation reduces the risk of unknown bugs.

Very well put.

It's much easier to rewrite bsnes as a state machine. So I have done this. It's a non public version with savestate support. It has the same accuracy like bsnes, in particular the bus accuracy between cpu and smp. If I remember right the main cause for using threads in bsnes was to reduce the code complexity to achieve bus accuracy.

Whow...

Did that incurred significant speed losses?