bsnes v0.039 released

Archived bsnes development news, feature requests and bug reports. Forum is now located at http://board.byuu.org/
Locked
byuu

Post by byuu »

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.
Last edited by byuu on Wed Feb 18, 2009 12:38 am, edited 2 times in total.
Jonas Quinn
ZSNES Developer
ZSNES Developer
Posts: 115
Joined: Thu Jul 29, 2004 9:51 pm
Location: Germany

Post by Jonas Quinn »

byuu wrote:
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

Post by 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
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

byuu wrote: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
ZSNES Shake Shake Prinny
Posts: 5632
Joined: Wed Jul 28, 2004 4:15 pm
Location: PAL50, dood !

Post by grinvader »

byuu wrote: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.
皆黙って俺について来い!!

Code: Select all

<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
henke37
Lurker
Posts: 152
Joined: Tue Apr 10, 2007 4:30 pm
Location: Sweden
Contact:

Post by 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
Regular
Posts: 347
Joined: Tue Mar 07, 2006 10:32 am
Location: The Netherlands

Post by Verdauga Greeneyes »

byuu wrote: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
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by 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.
Last edited by FitzRoy on Thu Feb 19, 2009 7:46 pm, edited 1 time in total.
byuu

Post by 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.
Last edited by byuu on Thu Feb 19, 2009 7:45 pm, edited 1 time in total.
Panzer88
Inmate
Posts: 1485
Joined: Thu Jan 11, 2007 4:28 am
Location: Salem, Oregon
Contact:

Post by 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.
[quote="byuu"]Seriously, what kind of asshole makes an old-school 2D emulator that requires a Core 2 to get full speed? [i]>:([/i] [/quote]
byuu

Post by 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
Inmate
Posts: 1485
Joined: Thu Jan 11, 2007 4:28 am
Location: Salem, Oregon
Contact:

Post by Panzer88 »

byuu wrote: 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.
[quote="byuu"]Seriously, what kind of asshole makes an old-school 2D emulator that requires a Core 2 to get full speed? [i]>:([/i] [/quote]
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by 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
Inmate
Posts: 1485
Joined: Thu Jan 11, 2007 4:28 am
Location: Salem, Oregon
Contact:

Post by Panzer88 »

FitzRoy wrote:
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.
[quote="byuu"]Seriously, what kind of asshole makes an old-school 2D emulator that requires a Core 2 to get full speed? [i]>:([/i] [/quote]
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

Hey Panzer, I'll give you 1 million invisible dollars for 100 visible ones. Deal?
creaothceann
Seen it all
Posts: 2302
Joined: Mon Jan 03, 2005 5:04 pm
Location: Germany
Contact:

Post by 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.
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
Panzer88
Inmate
Posts: 1485
Joined: Thu Jan 11, 2007 4:28 am
Location: Salem, Oregon
Contact:

Post by 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.
Last edited by Panzer88 on Thu Feb 19, 2009 8:26 pm, edited 2 times in total.
[quote="byuu"]Seriously, what kind of asshole makes an old-school 2D emulator that requires a Core 2 to get full speed? [i]>:([/i] [/quote]
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

creaothceann wrote: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
ZSNES Shake Shake Prinny
Posts: 5632
Joined: Wed Jul 28, 2004 4:15 pm
Location: PAL50, dood !

Post by grinvader »

byuu wrote: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>
皆黙って俺について来い!!

Code: Select all

<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
Panzer88
Inmate
Posts: 1485
Joined: Thu Jan 11, 2007 4:28 am
Location: Salem, Oregon
Contact:

Post by Panzer88 »

byuu wrote:
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.
[quote="byuu"]Seriously, what kind of asshole makes an old-school 2D emulator that requires a Core 2 to get full speed? [i]>:([/i] [/quote]
Verdauga Greeneyes
Regular
Posts: 347
Joined: Tue Mar 07, 2006 10:32 am
Location: The Netherlands

Post by Verdauga Greeneyes »

It would be like trying to explain CP violation with only a cursory understanding of nucleons?
adventure_of_link
Locksmith of Hyrule
Posts: 3634
Joined: Sun Aug 08, 2004 7:49 am
Location: 255.255.255.255
Contact:

Post by adventure_of_link »

byuu wrote: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?
<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
NSRT here.
creaothceann
Seen it all
Posts: 2302
Joined: Mon Jan 03, 2005 5:04 pm
Location: Germany
Contact:

Post by creaothceann »

adventure_of_link wrote:plug-in system
Ben wrote:millions of voices suddenly cried out in terror...
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
PiCiJi
New Member
Posts: 7
Joined: Fri Dec 30, 2005 11:42 pm

Post by 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
Trooper
Posts: 376
Joined: Tue Oct 31, 2006 7:17 pm

Post by Snark »

FitzRoy wrote: 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.

PiCiJi wrote: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?
I want to fry~~ Sky Hiiiiiiiiigh~
Let's go-o-o-O~ togeda~
Locked