bsnes v0.037a released

Archived bsnes development news, feature requests and bug reports. Forum is now located at http://board.byuu.org/
Locked
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

Excellent, and with that mystery solved, here's another one worth looking at. When I fire up the game "X Zone," the cursor for bsnes and the game are not congruent, so shots are firing like 30px to the left of where the bsnes cursor is. This could be a system specific issue or a bug in super scope emulation, not really sure. ZSNES does not exhibit the issue for me, though.
byuu

Post by byuu »

If the game has a calibration tool, I'd use that. Otherwise, I'll put it on the long-term to-do list.

The support as a whole is somewhat sketchy. The Justifier tends to lose calibration quite easily when you pause, mouse doesn't support speed settings, and now this.

I really just added the light guns + mouse so people would stop asking me about it. I'd definitely appreciate some outside help here.
grinvader
ZSNES Shake Shake Prinny
Posts: 5626
Joined: Wed Jul 28, 2004 4:15 pm
Location: PAL50, dood !

Post by grinvader »

Thanks a lot for clearing up vram is kept through hard reset, byuu.

Oh, and I wouldn't trust the GUI option very much in terms of actually doing reset. It probably powercycles. And my own ported func (powercycle()) was a sad/desperate attempt to port a func to C for ZMV purposes and is probably still mucho inadequate (especially with special chips).

Really one of the worst part of zsnes, along with the rest of the encapsulation layer.
皆黙って俺について来い!!

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
byuu

Post by byuu »

Thanks a lot for clearing up vram is kept through hard reset, byuu.


No problem, it makes sense in hindsight. WRAM and APURAM also hold data. And both VRAM and APURAM are SRAM chips, so they don't even require refresh. Thus, most likely, they'll even hold their contents for a good while with the power off.

Or maybe not ... I'm starting to think this was the gist of the SBB v1.1 revision: there must have been reports of v1.0 holding just enough WRAM from a fast power cycle to skip initialization ... leaving VRAM partially decayed in some instances.

I should also mention ... one test I wrote a long time ago was to enable the display and halt the system. A copier test -- I really just wanted to see how badly the copier trashed the power-on state of the system. When I turned the screen on again, I could see the BIOS loading screen. Even after resetting it was still there. But the scroll registers were off, IIRC.

So ... that makes me believe that OAM, CGRAM and at least many of the basic PPU regs are also kept. We really need someone to go through and test all of it like Overload did with the CPU regs.

Really one of the worst part of zsnes, along with the rest of the encapsulation layer.


Nah, I had no problems understanding the C version of the init code. Really great stuff you guys are doing, porting the non-critical code to C. One of the hardest parts to me was following ZSNES' somewhat-macroless GUI ASM files. It wasn't bad, it was just ... interesting. theoddone33 was very clever working around the NASM issues, but that made it quite tough.

But my main problem is that I use Notepad for my IDE ... so I never know what files contain what functions. Takes forever to find my way around :/
But that's my own fault. Plenty of IDEs would help me with that.
85cocoa
Hazed
Posts: 55
Joined: Sat Jul 22, 2006 8:43 pm
Location: USA

Post by 85cocoa »

EDIT: Removed comment that was caused by my reading the previous page and forgetting about this one

While still on the topic of Super Buster Bros.: v1.0 and v1.1 seem to have subtly different amounts of reverb in the music. (I originally noticed this in Snes9x, and it might be present to some degree in bsnes as well.) Am I hearing things I shouldn't be? Why wasn't this picked up in the code comparisons?

Thank you for all your good work.
neo_bahamut1985
-Burninated-
Posts: 871
Joined: Mon Sep 10, 2007 11:33 pm
Location: Unspecified

Post by neo_bahamut1985 »

Try to test it on another emulator, like SnesGT to see if it's still present...?
俺はテメエの倒す男だ! 宜しく! お前はもう死んでいる...
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

byuu wrote:I really just added the light guns + mouse so people would stop asking me about it. I'd definitely appreciate some outside help here.


Oh, nm then.

Back to the gui:

1. Wouldn't it be better to use intervals of 5 on the "frequency adjust" setting? Since there are more selections than can be represented by pixels in the slider, it skips an integer 9/10 times. I'd rather have -100 as a selection than -99 and -101.

2. Is it not possible to wrap text in the gui? Is this why you use 3 sentences on separate lines for one note instead of the one we spent time constructing months ago?

3. I suggest a simpler, more uniform name for the paths:

Games:
Saves:
Patches:
Cheats:

"Game file path" connotes pointing to a file or directory. This pluralization avoids that and infers directory alone. The reason I dislike the acronyms are:

1. They're redundant. ROM conveys game. Game conveys ROM.
2. They're confusing. By RAM, you actually mean SRAM, static random-access memory. And neither RAM nor ROM is used as the file extension. Conversely, UPS is not a hardware acronym, it's a software format and file extension. So now we're calling two things by their technology acronyms rather than their file extension acronyms, and another by its file extension acronym.

Now if a person becomes an advanced user and wants to learn where the program and save data were stored on a physical cartridge, fine and dandy. But it's totally unnecessary otherwise.
creaothceann
Seen it all
Posts: 2302
Joined: Mon Jan 03, 2005 5:04 pm
Location: Germany
Contact:

Post by creaothceann »

FitzRoy wrote:1. They're redundant. ROM conveys game. Game conveys ROM.

Not all ROMs are games... </nitpick>
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

creaothceann wrote:
FitzRoy wrote:1. They're redundant. ROM conveys game. Game conveys ROM.

Not all ROMs are games... </nitpick>


And vice versa, but I didn't want to call it "programs" for obvious reasons. The predominant usage of bsnes and the system itself is for games, nobody is really going to care if we lump a few test programs under that label.
byuu

Post by byuu »

What about calling the "Default" button on the paths window "Auto" instead?

And no, label text does not wrap. That's why I have the forced line breaks.

New WIP:
- fixes the tiledata cache glitch for Super Buster Bros V1.0; possibly others
- adds updated nall templates: copy constructor vector class with amortized constant growth being the most notable change. Resisted the CC approach before because it's slower; but the amortized growth avoids most of the overhead, and I'd rather do things through the CC than possibly change the internal object memory base address transparently (invalidating self-pointers and such.)
- adds snes.hide_light_cursors or something similar for Panzer88

Panzer88, I'd appreciate input on the last one. My fear is that because the system is 100% relative, if you move your Wii remote too far to the side, it will appear to "throw off" the alignment after the cursor sticks to one end. Only way around that would be to use absolute positioning.

It'd be really difficult to support both relative and absolute systems at the same time, due to the way the drivers work. Absolute cannot work with the mouse by its very design, and it'd be sketchy with different window sizes and such for the light guns. And even if no game uses it -- it is possible to use a mouse on port 1, and a scope on port 2.
Verdauga Greeneyes
Regular
Posts: 347
Joined: Tue Mar 07, 2006 10:32 am
Location: The Netherlands

Post by Verdauga Greeneyes »

byuu wrote:and it'd be sketchy with different window sizes and such for the light guns.

It might be inconsistent, but doesn't it still make sense? i.e. if you pointed a light gun at a small TV you'd have to be more accurate than if you pointed it at a big one. Mind you I have no real experience with these games, I just felt like pointing it out.

By the way byuu, I'd like to mention that you're exactly right to use a power-of-two size for the surface you create in Direct3D. For the longest time I thought this only applied to older graphics cards, but I ran into this problem yesterday and it took me hours to figure out what was going on. It seems the graphics card will either assign a surface in multiples of 400 or powers of 2, whichever is closer. Of course that doesn't apply to the back buffer which is the same size as the client rect. I can't be entirely sure about this, so in the end I settled for rounding my width and height up to the nearest power of 2 to ensure that's what it would do. Which of course then broke my StretchRect call, as I was using NULL for the source and destination rects, thinking they would be the same size. Ugh. At least I figured that part out quickly.
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

I just realized that the problem with the frequency adjust integer skipping was with my mouse sensitivity being too high. You were probably wondering what I was talking about with that one.

byuu wrote:What about calling the "Default" button on the paths window "Auto" instead?


I don't think auto is very clear either. You raise an interesting issue, though, which is what default actually means for each section. I'll revise my suggestion to this, explanatory values for default instead of nothingness. Because there is a place the program looks by default, and it needs to be represented IMO.

Image

I think that there are some things where the readme needs to take a bigger role lest the GUI just get cluttered as there is insufficient space there to explain it. Take the fact that save, patch, and cheat filenames need to be identical to their corresponding game file in order to be detected. I've been around the zsnes forums long enough to have seen numerous postings where a user had no idea this was the case.

Take also the plethora of custom filetypes users have to deal with on a per-system basis. There are quite a few filetypes to deal with here alone. Who's to say an average user has any idea what a .rtc file is when one appears in their folder? Or that IPS is not a supported format/extension? Or that .sav is not? What is the difference between all the accepted game extensions SFC, SMC, BS, FIG, ST? This information would be very useful in the readme.

Here is a reconstruction effort along the lines of what I think would be the most pertinent information.

====================
Program Information:
====================
Name: bsnes
Version: 0.037a
Author: byuu
Website: http://www.byuu.org/
License: Proprietary

====================
Supported Filetypes:
====================

SFC: Representative of program data stored on the ROM chip of a standard cartridge or on the EEPROM chip of a "Nintendo Power" cartridge.
SMC: Different only in name from SFC, this extension was used by the "Super Magicom," an unlicensed copying device.
SWC: Different only in name from SFC, this extension was used by the "Super Wild Card," an unlicensed copying device.
FIG: Different only in name from SFC, this extension was used by the "Pro Fighter X," an unlicensed copying device.
UFO: Different only in name from SFC, this extension was used by the "Super UFO," an unlicensed copying device.
BS: Representative of program data stored on the EEPROM chip of a "BS-X" media cartridge.
ST: Representative of program data stored on the ROM chip of a "Sufami Turbo" media cartridge.
SRM: Representative of save data stored on the SRAM chip of a cartridge.
RTC: Representative of real-time clock chip states.
UPS: Representative of user-created data intended to patch or modify original program data.
CHT: Representative of cheat codes used by the "Game Genie" and "Pro Action Replay," unlicensed cheating devices.

================
Standard Behavior:
================

1. The bsnes executable will generate/store its configuration file in a separate directory designated to the active user account. As a result, each user account can access a common executable, but retain its own preferences.
2. The language of the user interface can be changed by downloading the appropriate localization file from the bsnes website and placing it in the same directory as the bsnes executable.
3. Save, patch, and cheat files will go undetected unless the name, excluding the extension, is identical to the corresponding game file.

==================
Known Limitations:
==================

1. Some coprocessors, special controllers, and add-on devices are not fully emulated and games designed for them may not function properly.
2. Some base processes are unemulated due to speed or difficulty concerns, but are inconsequential to game compatibility.
3. Savestates will never be supported due to the way in which the program handles processor parallelism.
4. Netplay is not yet supported.
5. Compressed archives with non-ANSI characters in the filename require UTF-8 support and will fail to load on Windows.

=============
Contributors:
=============

Andreas Naive, anomie, blargg, DMV27, FitzRoy, GIGO, Jonas Quinn, kode54, krom, Matthew Callis, mudlord, Nach, neviksti, Overload, RedDwarf, Richard Bannister, tetsuo55, TRAC, zones


Lastly, before I collapse into bed, I got an e-mail out of the blue a few days ago after being put on a waiting list for SWC DX2 availability last year. He says he has one now for $150. Let me know if you're interested, I'll PM you his e-mail.
Last edited by FitzRoy on Thu Dec 04, 2008 12:34 am, edited 11 times in total.
Justifier!
Hazed
Posts: 51
Joined: Tue Oct 07, 2008 6:27 am
Location: ......
Contact:

Post by Justifier! »

Looking good mate!

Keep up the good work.

:D
henke37
Lurker
Posts: 152
Joined: Tue Apr 10, 2007 4:30 pm
Location: Sweden
Contact:

Post by henke37 »

You probably shouldn't say that the config file is in that location by default, it's not. Do mention the existing user preference sharing system instead.
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

henke37 wrote:You probably shouldn't say that the config file is in that location by default, it's not. Do mention the existing user preference sharing system instead.


Like I said, I'm wording it as though this was changed to the way it used to be. I can't simplify the current instructions, it's an inherently confusing and pointless system that everyone hates. If we took a vote, it would lose 25 to 2. And we just learned a week ago that keeping the config separate caches old values despite emulation changes in new versions that can break games unless the user goes into advanced and manually resets something he never touched and thus never would have suspected. Why? To what benefit are 99% of users faced with this? So that the 1% who share a computer, share bsnes, and use different buttons for A and B don't have to perform a 5 second operation out of the box that takes one sentence to explain? Is it just to claim support for the "official" haphazard way in which operating systems have tried to implement this feature?
PiCiJi
New Member
Posts: 7
Joined: Fri Dec 30, 2005 11:42 pm

Post by PiCiJi »

could be a bug in Doom Troopers:

after selecting a hero, there will show a briefing screen. The last display line shows the underlaying text.
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

PiCiJi wrote:could be a bug in Doom Troopers:

after selecting a hero, there will show a briefing screen. The last display line shows the underlaying text.


This has been covered before and it happens on the real thing. Sometimes the last scanline is neglected for display purposes, maybe 3% of games will display garbage there at some point. Probably a good FAQ candidate.
henke37
Lurker
Posts: 152
Joined: Tue Apr 10, 2007 4:30 pm
Location: Sweden
Contact:

Post by henke37 »

We have talked about the issue before, it is not just for complying with the standards (that is a good thing btw), but because normal users plain don't have the rights to use config files in such locations.
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

henke37 wrote:We have talked about the issue before, it is not just for complying with the standards (that is a good thing btw).


Sieg Heil.

but because normal users plain don't have the rights to use config files in such locations.


I'm not following.
henke37
Lurker
Posts: 152
Joined: Tue Apr 10, 2007 4:30 pm
Location: Sweden
Contact:

Post by henke37 »

It is basic computer security, don't let the users do stuff they have no need to do. Take vista for example, no normal user is allowed to write to the programs folder, because that should only happen during program installation.
byuu

Post by byuu »

Looks like I've finally made it big: people are calling it bsnes (btw i am dumb) now :D

http://www.pc-juego.com/emuladores/bsnes (btw i am dumb).html

Also, I added a debugging menu to the UI input config dropdown. So far just five things:
- Export memory (VRAM, OAM, CGRAM, WRAM, APURAM)
- Toggle CPU tracing + CPU trace mask
- Toggle SMP tracing + SMP trace mask

Also added a new path selector for where you want all data files to go. This will include WAV files, screenshots in the future, tracelogs and memory export data. No, I'm not making 30 paths so you can separate your WAV files from screenshots, sorry.
neo_bahamut1985
-Burninated-
Posts: 871
Joined: Mon Sep 10, 2007 11:33 pm
Location: Unspecified

Post by neo_bahamut1985 »

byuu wrote:Looks like I've finally made it big: people are calling it bsnes (btw i am dumb) now :D

http://www.pc-juego.com/emuladores/bsnes (btw i am dumb).html



As if calling Zsnes "zsnes (btw i'm too stupid to learn the name of the emulator)" was bad enough...
俺はテメエの倒す男だ! 宜しく! お前はもう死んでいる...
byuu

Post by byuu »

neo_bahamut1985 wrote:As if calling Zsnes "zsnes (btw i'm too stupid to learn the name of the emulator)" was bad enough...


Yeah, I don't know why they type all that extra stuff in parenthesis all the time.

Yes, this is a joke, certain board members. I know about the filters.
neo_bahamut1985
-Burninated-
Posts: 871
Joined: Mon Sep 10, 2007 11:33 pm
Location: Unspecified

Post by neo_bahamut1985 »

Yeah, it's the Zboard filter that did that, so it's impossible to misspell it. I find it funny that BSNES is to the point that people are already butchering the name; how they messed up the name in a non-English language is beyond me.
俺はテメエの倒す男だ! 宜しく! お前はもう死んでいる...
Verdauga Greeneyes
Regular
Posts: 347
Joined: Tue Mar 07, 2006 10:32 am
Location: The Netherlands

Post by Verdauga Greeneyes »

neo_bahamut1985 wrote:I was the Zboard filter that did that.

Read byuu's post more carefully.
Locked