 |
|
 |
|
| Posts by byuu |
|
|
|
|
|
|
|
|
The video support in MSU1 is only allowed via the large data storage. It doesn't do anything a real SNES cartridge alone could not.
This means that you are limited to roughly 240x160x256 colors@20fps or 224x144x256 colors@30fps. You basically store raw tiledata for each frame inside the MSU1 datafile, and DMA as much as you can while the screen is not rendering. You use Mode 3 for 256 colors.
If you watch the lunar.sfc video from http://byuu.org/21fx , that's pretty close to the limits of quality you can push without really cheating.
To get better quality than that, you'd have to have something like the 32X where the console video output gets connected to your new device, and your new device outputs its own video with the old graphics superimposed or toggleable.
But at that point, not even I am interested. You've essentially created a whole new gaming console. And really, there's nothing wrong with that, either. If making something that will never exist in hardware but furthers the quality of what you're trying to do, by all means, go for it. Just I'm not going to help you with that.
|
|
|
|
> Just because I don't get HOW it works, doesn't invalidate my opinion of how it feels, and that what it seems byuu is doing when people complain that it doesn't feel authentic.
People were saying this wasn't possible on the SNES, despite the fact that the music portion already exists in hardware form. I was explaining the technical details BECAUSE people didn't understand how it worked. I was not trying to convince people that they had to like it.
If I could do something about people's irrational fear of change, I'd get into politics.
> More or less, the point is that we're not being trumped, we're just being thrown away for an easy way out.
So you fear convenience? It's a really cruel world out there. Innovation happens whether you want it to or not. The trick is staying on top of it all.
Self-checkout lanes in stores replace cashiers. Call centers are off-shored. Internet news services replace printing presses. Digital notebooks replace paper notebooks. People even sell bottled water. The mechanic has to adapt.
How you feel about MSU1 is similar to how I feel about guns. The gun is a cowardly weapon that trivializes the act of murder. To me, it would be a much better world had they never been made. But it was something some people wanted, and it ended up being made. Other people love guns and are going to use them, that's life. If the gun inventor didn't do so, someone else would have come up with it later on. Sometimes guns are even a good thing, when used properly for self-defense.
Be happy that someone who fully understands the SNES hardware made a device that could really exist, and you didn't get something like Zsnexbox's method of implementing controller rumble support.
> That is the impulsive thinking that burns the ozone and cuts down the rain forest. That is the careless thinking that dulls our senses and retards our progress in life.
And when I was your age, I had to walk twenty miles in the snow to get to school.
> How is the MSU1-enabled SMW ROM handling "special" music, like the Star theme, P-Switch timer, Time's Running Out!, etc.?
I didn't want to make the MSU1 too complicated so that it could be made into real hardware, but there are a lot of cases where one channel is clearly not sufficient:
One would handle voice acting by playing the voices on another channel.
One would handle things like the star theme by lowering the main music volume and playing the special music on another channel.
One would handle cross-fading tracks by lowering one channels volume as you raise another channels volume.
One would handle custom sound effects through the use of lots of extra channels. You'd want 16-64 channels for that.
There is certainly the possibility to extend register $2007 with d7 set as a special command for channel selection, but I fear that more channels would rule out hardware support.
So is the possibility to push this farther worth the chance that no hardware implementation will ever exist? I could have added a 2GHz Intel Core 2 in there if that were the case.
I really was thinking of the SNES CD at first. Think about how the Sega CD handled its redbook audio: it could only play one track at a time, just like a CD player. In fact, this is where the name change came from.
It was called 21fx because the commands were on the B-bus, at $21xx. By being there, it would have allowed this to be designed as either a base unit that plugs into the bottom of the SNES, or as a cartridge that plugs into the top. The thing that ultimately forced me to change it up and move to $200x was that SNES DMA can only transfer between the two busses, and video RAM is on the B-bus.
In other words, the #1 most impressive feature to me, transferring graphical data without decompression (for movies, high animation games, etc) was neutered in half because 21fx required you to transfer from 21fx->WRAM, and then WRAM->VRAM. And when extending existing games, you probably would not have free WRAM. It was amazing smkdan pulled off that CT video with it.
This is one of the reasons why the SNES CD prototypes also had special cartridges. So you could parallelize a transfer from the CD to the cartridge while transferring from the cartridge to the PPU, etc.
Also consider the SNES Jr and Super Famiclones lack the expansion port, that a base unit device would HAVE to be sold separately from eg ikari_01's flash cart, and that making a female connector for that custom slot is damn near impossible.
I think it's possible to work around these limitations, if you consider the MSU1 to be an ADDITION to the SPC700 and not a replacement. The P-switch and star power music can play on the SPC700, and you can lower the MSU1 audio volume. Sound effects work great on the SPC700. It's even possible to stream voice samples to the SPC700 in real-time, take a look at Tales of Phantasia and Star Ocean. Cross-fading is the only really tough one, but that isn't really necessary.
> Also @byuu and/or BMF, next time simply don't introduce your innovations to SMWC.
I didn't, it's been out for nine months. I figured you guys weren't big on change, seeing as you still use xkas v06 and all. I know, backward compatibility was lost. v06 was written when I was much younger and did not understand concepts like EBNF and LL/LR grammars. v06 is a complex grammar that is a nightmare to parse. v10+ uses an LL(1) grammar.
I am honestly pleasantly surprised by just how many people here like the idea.
That said, I'm absolutely honored that BMF, smkdan and LuigiBlood have used MSU1. It's really a lot of fun seeing it in action. I'm happy for anyone to use it who wants to.
> Also, there has to be some sort of asm-hacking to the original ROM to enable MSU1 support, right? How involved is it? I'm just curious how much patching has to be done (i.e. How "backwards-compatible" is MSU1 support going to be with old ROM hacks?)
For someone skilled, it should only take ten minutes of ASM hacking. You have to know what you're doing is all. The API is really simple.
Not sure what you mean by backward-compatible. You can detect the chip and fallback on existing SPC700 music for non-MSU1 emulators. I will warn that we're discussing changes to enable better looping and consistency between implementations, so the next release will probably use raw PCM instead of WAV files. That's basically WAV sans header. A hex editor can convert them, but we want to have some tools to convert MP3s/SPCs/etc to WAVs for you so you can distribute smaller files.
---
Someone mentioned DVDs for the storage size of MSU1. That wouldn't be necessary, look at the Neo Geo. Remember those games? $250-$500 a game, because the games were 128MBytes and such. ROM chips are very easy to put in parallel, they just cost a hell of a lot more back in the day. Nobody would pay $500 for SMW with nicer audio, so you got the 4MB SMW with SPC700 audio instead for $50.
|
|
|
|
So on a bit of a side-tangent here ...
Okay, we all know bsnes isn't anywhere near as popular as ZSNES or Snes9X. So that begs the question, why not?
I have a feature guide up here: http://byuu.org/bsnes/features
I have virtually every feature that the other two have, and I have a lot of custom stuff that nobody else has. The biggest being Super Game Boy support, MSU1 support, 100% compatibility, 7-zip multi-archive support and a built-in cheat code database. And for you guys, the debugger is top of the line. Not even Geiger's Snes9X fork is as powerful.
There certainly was an issue with speed, but my latest v068.10 release is less than 70% slower than the latest Snes9X, while being about four to six times more accurate.
Obviously, some people are using antiques that need Snes9X, but I sincerely doubt that more than 25% of people are stuck with PCs slower than a Pentium IV in 2010.
And further, there's definitely some fringe issues with certain hardware configurations; same as any emulator though. Nobody explicitly has amazing Vista/Win7 compositor support, and we all fail at some level: ZSNES drops video frames which ruins scrolling, and Snes9X and bsnes can occasionally stutter with audio pops if you don't set the input frequency value just right.
So ... for those of you still using ZSNES or Snes9X, why is that the case? Is there some killer feature that would change your mind?
I understand familiarity and habit are big influencers, but somehow Nestopia managed to overcome Nesticle. So it has to be possible.
Now, mind, I don't really care all that much about popularity or I would have joined the Snes9X team. But it is certainly a problem for things like MSU1 to only be available to a small percentage of people.
|
|
|
|
I always use all CPU time to better handle syncing. If you sleep at all while waiting on Vsync, sometimes you'll end up missing the whole thing. And the sleep command would have to go inside every video and audio driver, all 20 of them, which is awkward. But perhaps I should look into it.
Battery life usage will always be a problem. I can't match ZSNES' speed without losing all the accuracy, and if I do that then there's no reason to switch, heh.
Anyway, goal is to create a feedback loop. More people use bsnes, so more people make MSU1 patches. More MSU1 patches attracts more bsnes users. Both of these would encourage other emulators to add MSU1, and then I win 5,000 internets 
smkdan, I've been meaning to humbly bug you about that. I don't suppose you'd be willing to update your Chrono Trigger intro to use the MSU1 interface? Very sorry it got changed. This one should be more stable. If you're busy, no worries. I can probably hack your hack eventually when I have some time, if that's okay.
|
|
|
|
Thanks for all the bsnes feedback. I'll bring the save state discussion over to my forum as well.
To whoever said it, hacks that don't run on bsnes are because they don't run on real hardware. There aren't many, and I'm never going to acquiesce to them by allowing emulation hacks. I am writing an SNES emulator, not a ZSNES emulator.
Besides that, Snes9X already breaks these hacks as well; as will the next ZSNES. So if you forever want to be stuck on a 32-bit x86 OS with an outdated ZSNES, there's nothing I can do there :/
I am hopeful that when ZSNES "DNF" 2.0 comes out, that people will update these old broken hacks to work correctly, so maybe this will resolve itself in time.
> I should be able to when I get access to my other pc.
Ah, thanks a million
I would like to get that to ikari_01, so he has an MSU1 datafile test ROM.
> Lack of easy savestate loads and saves.
ZSNES has F2 to save, F4 to load. F3 freezes your game but lets you pick one of ten slots.
I have hot key bindings for slot selection, save to explicit slots, save to active slot, select active slot, and save+increment and decrement+load pairs. There's also a state manager window where you can do this with your mouse, but understandably a GUI is annoying when playing fullscreen.
What could I change to make it easier to use?
> Lack of an easy way to increase and decrese speed via buttons.
That's there as well. I have fast forward and slowdown hotkeys, as well as permanent speed up and slow down keys that you don't have to hold. This can be mapped to keyboard, mouse or joypads.
All input settings are under: settings->configuration->input->user interface.
> Is "bsnes" supposed to be capital, lowercase, or a combination of the two?
Lowercase, although Richard ignores this and my versioning scheme with his OS X port.
> No frame skip, no SPC dump option, no keyboard shortcuts for just selecting a savestate...oh, yeah, and the debugger is still version 0.65, ergo, still takes half a minute to load a ROM
I can't imagine anyone using an emulator with frameskip unless they need it to get 60fps. If that were the case, I'd much sooner choose another emulator. In the best case, skipping 9 of 10 frames would only double performance.
If you have a better reason for frame skipping, I can certainly re-add it.
All SPCs have already been dumped and uploaded. And in order to dump an SPC you have to hack the emulator Key On/Key Off emulation to get clean start and end points, and you have to be using an opcode-based emulator because the format is incompatible with cycle-based emulators. kode54 managed to hack it up enough to work, so there are builds of bsnes with it.
That is a really tough one, though. I'm not sure that's something I would ever be willing to add; so if that is your requirement, I can see why you would avoid bsnes.
There are keyboard shortcuts to select save states without actually loading or saving. They are based on increment and decrement. Could you be more specific? Do you want "select state 1" - "select state 10"? That would be 30 keys total to load, save and select; which seems pretty insane. But I can add that pretty easily if you want.
You've seen the "User Interface -> Save States" key mappings, right?
The debugger, that's probably a bug in Qt. I don't experience that on any of my systems. And that's one of those annoying cases where I can't track down a bug I can't reproduce. I believe you have this problem, but I would need the help of someone else who has it to debug it for me :/
I can say that for at least 90% of PCs, it should load instantly.
> it very clearly lacks several of the things that make ZSNES convenient
Any others than those listed above?
> Guess me working on my patch has no point anymore then. I'm looking forward to this. I hope that your system also supports music looping (which uses 2 wavs: one for the intro, one for the 'main loop').
It will be in v069, but I had to change the format to do it. WAV does not have a standardized concept of looping, and hacking playlists+cues to do it is nowhere near universal.
Instead of WAV, the files will be PCM. Which basically means "WAV without the header". Anyone who can use a hex editor can delete 50 bytes off the header to make PCM files, but they won't play in Winamp this way.
But it was not just to add looping, but also to ensure consistency. My fear is that by supporting 16-bit stereo 44.1KHz WAV files, other MSU1 implementations may be more flexible and support other formats. Having that WAV header there makes it ambiguous to outsiders. And if we start getting, say, 48KHz WAV packs for Snes9X, then it won't work in bsnes or on ikari_01's hardware implementation. That's a real problem. Better to remove the header and mandate that file format.
The new format:
Header = "MSU1"
4-byte loop position (in whole samples to prevent data misalignment)
Raw PCM data (16-bit stereo PCM samples @ 44.1KHz; aka redbook)
It's also going to be imperative to make some tools that can convert to and from this format, so that people can distribute a tool+MP3 pack for smaller downloads.
The one thing I won't be doing is adding multi-channel audio.
> Because (I'm not so sure about the Windows version of bsnes, I'm using a Mac) ZSNES and Snes9x have much easier to use savestates. I couldn't find a way on bsnes to savestate with a press of a button.
This is certainly seeming to be a major theme here, interesting. I think a lot of people are overlooking the settings.
Please look here:
http://img835.imageshack.us/img835/3614/savestates.png
Is there a way I could make these controls more apparent? I'd like the advice of someone who had trouble finding them. I do admit they're a tiny bit buried. A natural side effect of having a lot of features.
> Frame advance (and better lag emulation). Pretty much required if you want to make a good TAS.
I've been holding out hope that the tasvideos community would make a bsnes-rr version. I even added movie recording and playback for them, but so far no bites. I bet I could make a mode where you have to press a button to advance one frame, a sort of ultra-slowdown if you will. Boy would it take an eternity to make a TAS that way, heh.
> When I compared the two side by side, bsnes's seems more blurry and less smooth than ZSNES's do.
Algorithmically, that's impossible. Maybe it's a video card issue, can you post some comparison pictures? If I can reproduce it, I can fix it.
> I suppose if you make a better way of using savestates, I'll use it more often
I'd like your advice on how to make an easier save state system as well.
> Well, I guess there are buttons that just decrement or just increment quick savestate slots, but there are none like that for normal savestates.
What I call quick states are what ZSNES and Snes9x call normal save states. The term to me means a state that you don't really care about keeping long-term. Hence there's no description around it. They last between emulator runs and make state files like any other emulator.
The save state manager has the long-term ones, where you keep all your states in an archive file that has proper descriptions for each one. You'd use this for eg "I want a save state right before every robot master fight in MMX2". Much easier to find the fight with the alligator boss when the state is labeled in a list, and much harder to accidentally overwrite.
I could perhaps implement a button that you can press that will freeze emulation, and pop up a quick state selection window. Like ZSNES, but using a native GUI. Would that allay your concerns?
> 10) I want to know just how byuu created a custom enhancement chip anyway. That would mean it's possible to create other chips...! And I wanted to learn how to use SA-1...imagine what, like, the SA-2 chip or something would be like.
It is just code, so you can do anything you want.
With MSU1, I spent months making sure the design was 100% hardware compatible, even down to the "wait" delay bits. This was so that we could have real hardware implementations.
If you try and make something like an SA-2, it will never exist outside of supporting emulators, but it is certainly possible if you're okay with that.
I know that I opened a Pandora's Box by creating a special chip. But I also limited it to a mere 4KB of code. I will say that I have no interest myself in maintaining any other custom chips, so you will have to add that support to a bsnes fork if you want it. I'm also aware that that is how other emulators will feel about MSU1.
|
|
|
|
Quote(except that bsnes seems to give slightly brighter colors for some reason)
There's two things. bsnes has brighter colors by using true 24-bit output. So when you get the color white, you get #FFFFFF. With ZSNES, it uses 16-bit output always, so the low bits of colors become zeroes. So if you use ZSNES on a 32-bit desktop, white is actually 11111000 11111000 11111000 or #F8F8F8, which has a hint of gray. Not applicable in fullscreen or on 16-bit desktops, of course.
There is also TV gamma adjust on by default, that brightens some things while darkening lower colors. Uncheck on the video config tab to remove it. On by default because it's amazing.
http://img651.imageshack.us/img651/6643/compare1.png - off
http://img267.imageshack.us/img267/8345/compare2.png - on
The latter is a whole lot more like a TV looks. That's because TVs and PCs have different gammas. SNES games look washed out with PC gamma. The rain in the above pic looks like fog without correcting gamma.
> What all isn't compatible with bsnes that can still be done in other emulators? Should we make a list? Let's see, there's setting the echo delay over $04, writing to VRAM or certain registers outside of a blank, any part of AddmusicM...what else? Is CG-RAM ($2121, $2122, $213B, etc.) accessible outside of a blank? I never knew for sure....
The echo buffer is an obvious one. ZSNES cheats by using an internal sampler to produce sound. It's what distorts sound effects and what allows maximum echo buffer sizes. The real memory is never written to. That breaks some SMW hacks.
You also can't write to VRAM during active display, which breaks some older fan translations. The most notable is probably Sailor Moon: Another Story's intro. Also affected is DQ12r's DQ1 title screen caption. A lot of the big examples have been updated to fix this. Ys 4, Dual Orb 2 and Lennus 2 received updated patches to fix the text rendering issues.
You can write to CGRAM during Hblank (that is how gradient fades are done), but not during active display. Writes during active display work, but do not go where you want them to. They go to whatever the PPU is fetching to display onscreen.
OAM should not be written during active display, not even during Hblank. The writes will go to whatever sprite the PPU fetched last. The only game that does this is Uniracers, and since they only show two sprites, the write goes where they want it. It's really evil, and other emulators use game-specific hacks to support Uniracers 2-player mode.
MUL and DIV registers ($420x) require time to compute. If you read the results immediately, you get back partially calculated values. The only hack I know of that ignores this is the BS Zelda music hack.
You are also going to want to avoid a DMA transfer with HDMA active. If one stops as the other ends, CPUr1 systems will deadlock completely. It's a major bug in the original hardware. bsnes defaults to CPUr2 though for this reason. They fixed the bug rather quickly, but you have to be aware of the CPU revision 1 systems.
There's lots and lots of other things, but those are the biggest ones.
> Well...in my case, it's usually just impatience. When, say, testing a boss with a 10-second intro sequence, I don't want to have to wait through the intro to get to the main part of the battle.
Ah, you want frame skipping to work with fast forward, then. Yeah, I can do that. Give me another release or two.
> How many quick states did you say one could have? 10?
10 quick states, 32 long-term states.
It is mind numbing that you can keep track of 92 save states just by their numbers alone o.O
When doing something like that, the long-term states sound like a much safer way of doing it. The long-term state limit is only to keep the list box shorter on scrolling. A source change will allow any amount you want. Maybe I should make that a config file option. Would that work?
> I don't think edit1754's Ultimate BG Ripper supports bsnes savestates, either...he should change that.
Save states are usually not compatible between versions. I release new versions every few weeks, compared to every few years for the others; which exacerbates the problem more. I do put all the RAM at the top, so that won't move. But the rest ... I wouldn't advise targeting my save state format.
> when I try to load a ROM, it takes over half a minute before the list of files pops up, and if I press ANYTHING during that time, bsnes freezes up
Aaaaaaaaaaah, you guys are talking about the Qt file loading dialog. I was thinking you meant it locked up after opening the file.
Yeah, there are some serious problems with Qt's QFileSystemModel code. If you're willing to live without the screenshot previews, I can offer a classic Windows-style file load dialog that won't have that problem.
|
|
|
|
Okay. I will add load state and save state submenus to the tools top-level menu item, add frame skipping for fast forwarding, and add an option to use the generic system file open dialog. No promises on how soon I can do all of that, I'm very busy with two of the PPU cores at the moment. Appreciate all the feedback, everyone.
One side note, the only reason I made the custom file dialog was so that I could do something special with folders. You can't stream random MSU1 data and music from compressed archives in real-time without serious performance issues. So when a folder ends with .sfc, it treats it as a game pack. So you could load eg BMF's SMO hack as though the folder itself were a game, complete with all save RAM, cheat codes, save states, screen shots, movies, XML mappings, MSU1 data and music, etc -- all in the same "file". It's the same way OS X applications work. The binary is just inside the folder.
The screen shots and preview info was just a nice side effect. Oh, and another small effect: Windows Vista and above ignores your default folder path suggestion, it saves the last folder used for every app individually, which breaks one GUI element.
But yeah, that custom file dialog has been nothing but trouble outside of that.
|
|
|
|
Never going to add that one, sorry. Not getting into why again.
You can use bsnes_launcher though for that one:
http://board.byuu.org/viewtopic.php?f=3&t=919
|
|
|
|
QuoteThat seems sort of silly, considering that most people always left the last SNES game they were playing stuck in their machine until the next time they played.
Fine, I will elaborate. I have two unique features that complicate this greatly. The first is multi-archive loading. You can load a game inside of a 7-zip archive of twenty games. So the filename history would have to include some special character to let you go inside archives.
The other feature is multi-ROM loading. Other emulators use a fixed BIOS, whereas bsnes lets you control what the base cartridge is. This allows three interesting things: 1) Sufami Turbo can load two data cartridges for the games that support it; 2) BS-X slotted cartridges work (Same Game + Tengai Makyou Zero) - ZSNES gives each game its own data pack path, but misses about 6-8 BS-X slotted carts that way; 3) Super Game Boy has multiple BIOSes with different background arts and effects, it's nice to easily be able to swap them out.
Lastly, all of my ROM loading is based around five different modes (normal, BS-X slotted, BSX, Sufami Turbo, Super Game Boy); so we'd have to save that info and write a loader for each one.
So a history list for me is not a list of filenames. It's a list of multiple filenames that may or may not be inside of archives. And then I somehow have to display an intelligent name in the menu for all that. In other words, it's a ton of work and I don't feel like doing it.
QuoteI think the only thing that bugs me with MSU1 is the fact that the 4 GB file size wouldn't have been very "realistic" for the mid-1990s.
Limit yourself to 128MB and pretend it's a Neo-Geo game 
It was 100% doable then, but a 4GB game would have cost you about $10,000.
Quotebyuu, if you ever make a new xkas version, you should support if-branches in macros.
Macros were separated, idea was for you to use a different program to do macros because they're seriously a pain to code support for.
I wanted to make a universal macro-only tool that could also replace C's piece-of-shit preprocessor, and C#'s non-existent processor. But never got around to it because I couldn't find any easy way to pipe the macro transform to various compilers to automate it all. Plus I'm lazy/overworked enough as it is.
Quoteafaik they just didnt add the fake chip because they didnt see the need to, not because they hate it.
I don't know what the deal is. Lack of man-power, lack of interest, who knows. One of the ZSNES authors is who came up with the idea for XOR-based IPS, which we ended up working together on to make UPS. And yet ZSNES is the only emulator that doesn't support UPS. That's right, they don't support the format they came up with. Snes9X only got it because I added it myself. ZSNES' code is too hard to work with, and they aren't going to release a new version in the foreseeable future anyway.
I've talked for weeks and weeks about adding XML-based mapping so that we could allow for custom and hardware-accurate mapping, which was to appease Nach who was anti-database. All I was met with was arguing about semantics (that name should be "planar" not "shadow"), and no actual progress. I finally gave up and just added it myself.
I've also opened posts asking about the idea of a new cheat file format that gets past their restrictions: ~60 character max descriptions, caps-only descriptions in ZSNES, binary-only so you can't edit by hand, no non-English letter support, no multi-part cheat codes (30% of cheat codes have more than one part); offered to change up my format to match their ideas, and nothing.
Begged them to remove the 40-million ROM file extensions for SNES games, drop it to just SFC+SMC+SWC+FIG, they refused.
So I didn't waste my time asking about MSU1 support.
|
|
|
|
I have BG layer toggle, in fact an even more powerful version because you can control it per priority, so there are 12 total toggles instead of just five. But you have to be using the debugger for it, because the debugger overrides the rendering routines to support it.
The reason that and music channel muting wasn't in the mainstream build is because it violates accuracy. Games can tell when you disable that stuff, and when you skip frames. The SNES electronics test will fail, as will DSP tests.
But now that I have the accuracy core split from the faster DSP+PPU cores, I suppose I'm willing to add that stuff in to those cores. They only affect accuracy when in use, and the accurate cores are the self-documenting ones anyway.
Okay, I'll get layer and channel toggling added too. I have added the load+save state menus that I mentioned I'd do earlier. Still have to make the "ZSNES F3" clone.
|
|
|
|
Both are cool in their own ways.
Targeting the SNES directly gives you serious cross-platform portability, where your hack will run on cell phones, game consoles and computers.
Targeting the PC directly removes any and all limitations, but you've put a ten-year shelf life on your game, tops.
Targeting the MSU1 is a compromise between the two. And you can take that farther in either direction. Closer to the former? Use the SA-1 chip. Closer to the latter? Create your own emulator just for SMW that hooks into everything, monitors and manipulates RAM externally, etc.
Ultimately, pick what you care more about, and then target the path of least resistance. If you just want CD music, MSU1 is an easy way to do it. If you want lores video playback, MSU1 is probably for you. If you want hires video playback, it's easier to fork bsnes with a special register that plays HD videos when you write to a certain register. If you want nine types of guns, it's probably easiest to use a game maker.
---
Oh yeah, screenshot: bsnes with load/state menu and BG/channel toggle.
http://byuu.org/images/bsnes_20100906.png
Still working on the classic file open dialog and state selection popup window.
|
|
|
|
Unless the Wii is faster than a $3 Intel Atom processor from a netbook, no. The support will have to be added to the Snes9X port, and that's not something I can do.
The Xbox 360 and PS3 (via PSGroove now) would be viable targets. PSP2 probably won't be enough, 3DS definitely won't be.
|
|
|
|
Requested features are finished:
http://img203.imageshack.us/img203/505/bsnes20100907.jpg
F3 activates state select, you can press a key on the keyboard to select one (10 = 0), or click them, escape to close the window. Up to you if you want it to pause the emulator or not, based on the input focus policy. Native file dialogs are there as an option. And as before, state load/save options added to the menu, and BG/OAM toggle + DSP channel toggle have been added.
Cannot do most recent files list due to technical complexity, cannot do SPC dumping due to accuracy requirements. New release should be out in a week or two after testing.
|
|
|
|
> I guess there is still the matter of echo and netplay
If it were possible without completely replacing the physical S-DSP chip on the SNES motherboard, I'd make it an option. Don't forget those few VRAM and MUL/DIV hack issues too. I'd say "why not use both?", use the one that works for what you want to play. Or even better, fix those hacks and everyone wins
Netplay, I just don't know the first thing about. If someone would help make it, I would add it.
> Also, @ byuu, do you know if bsnes will ever have a FPS limiter, like what Project64 has?
Settings->Emulation Speed->Sync (Video or Audio, or both.)
Audio syncs to the sound card and the slowest to fastest speed options work with that. Video syncs to vertical refresh of your monitor. If that is 60hz (for NTSC) or 50hz (for PAL), you can do both at the same time with no ill effects.
|
|
|
|
I almost forgot, someone asked for frame-skipping. I explained I won't make it a GUI option because nobody is going to use it over using another emulator that doesn't need it. But the poster brought up a good point about using it for fast forward, so I've added it specifically for that. When you hold down the fast forward key, it sets a frameskip of 9 to give you an extra 60% speedup.
Normal: http://byuu.org/images/bsnes_20100908a.png (274fps)
Fast Forward: http://byuu.org/images/bsnes_20100908b.png (422fps)
QuoteF3 just activates savestate select (with 10 possible savestates)? Can you use F2 to save, F4 to load, and the arrow keys to switch states?
F3 gives you a menu with ten save slots. You can press the corresponding number to select that state, eg F3+4 will select slot 4; or press escape to close the window. It's also a real window so you can click the buttons or use your keyboard keys to move around it. That menu is how to SELECT the active state, not save or load. You can move to different states with the arrow keys if you configure the increment and decrement slots that way. You can also bind F2/F4 to save and load, and in fact I changed the default configuration to this with the addition of F3, to mimic ZSNES' default setup. All the other options are still there as well to mimic Snes9X, or be entirely custom.
QuoteI was testing out bsnes's movie recording function and was rather disappointed to find out that you can't use save states while using it. Without save states, the only thing that separates this from just grabbing a screen recorder and recording a normal playthrough is that you can change the emulation speed.
That requires flushing keyboard input blocks and such. It's basically TASing at that point, and I was really hoping that someone at TASvideos would make a bsnes-rr variant. I even made bsnes core into a simple 10-function DLL for them to use if they wanted, and added the standard movie recording to get them started with the necessary input recording and playback code. But I don't have the time, patience or interest to implement a full TAS system. They really go out of their way with features: frame advance, re-recording, LUA scripting, on and on.
Who knows, maybe if bsnes gets more popular they'll go for it
As it stands though, it's a great system for making speedrun videos with no way to cheat. If someone posts a bsnes video file, you know they really played it by hand, no cheating. Otherwise the video won't play for you. The video files are also ~20KB compressed instead of ~80MB for screen capture tools, and the result is 100% lossless.
QuoteAlso, in regards to the MSU1, do you have plans to expand the looping feature so that we can choose a specific point in the song to jump back to upon ending instead of forcing the song to replay from the start?
Yes, I have added that. v069 will have a DWORD in the header that represents a loop point. Actually, now that I think about it, that will limit your loop point to anywhere in the first 405 minutes of the song, heh. Anyone wanting to play a seven plus hour intro?
QuoteAnd if you are going to make modifications, do you think you could add a way to retrieve a bit more information about the music that's playing?
The modification wasn't to the API, but to the storage format. If you need the position of a song, you can keep a counter of frames in the Vblank routine to tell you that. 21477272/60/44100=samples per frame*frame#=position.
I don't want to add any unnecessary complexities to the API, and I can't change it now or I will undermine support for it if people think it is unstable and will break their hacks later on. I said 21fx was experimental, and I said MSU1 was not.
It's not fair to you since you didn't know about it, but I posted about this on my site and forums and spent months discussing the API before finalizing it.
QuoteLastly (and this might seem like a stupid question, but whatever) where do you get/how do you activate the bsnes debugger?
You have to compile from source or download v065 on Google Code/All Downloads to get it. I did not include it because each binary adds 800KB onto the download and nothing has changed in it since v065.
QuoteLet's all convert useful patches into broken but "better!" XKAS assembly scripts that don't work and call that skill, too.
I don't think that should be mandatory, nor do I think using xkas v06 instead of v10+ should happen at all (macros notwithstanding), but I do think people *should* do this if they are willing. It's nice to have open source so you can see how things were done. No reason for everyone to reinvent the wheel or use black boxes. Ideally, I'd do UPS+ASM. IPS is a disaster as well for many other reasons. But it isn't my site, so it's not my rules.
Quote@SNN: I have had nothing but problems with XKAS
If you mean with peoples' patches having problems, I understand and apologize for the below; but if you mean with the xkas v06 binary itself??
How in the hell can you have a problem with:
xkas filename.asm output.smc ?
Some people cannot be helped, and no amount of ease of use will be enough to help them. Again, I'm sorry if that's not what you meant.
If you were using xkas v12 or something for a v06 patch ... then I guess that's partly my fault. I didn't change the name when I modified the syntax. But that's not quite "nothing but problems", that's more, "whoops wrong version, problem solved."
QuoteAlso, completely off-topic, but...S.N.N., you watched Ponyo?!
That was a good movie.
QuoteAnd that poorly converted XKAS patches are still shitty.
Oh, do you mean people are going IPS->xkas after the fact via a bunch of org $nnnn; db $nn,$nn commands? If so, I agree with you that that is fucking retarded. It's still at least better than IPS because of the copier header issue, but yeah, wow. Turn that stuff to UPS.
If these xkas patches have ASM comments that are USEFUL (eg not: inc ; increment by one), and actual labels so you can move code around if you knew what you were doing, then I disagree.
QuoteI want to play my hack on my own SNES one day, without adding on hardware.
Do you plug in a cartridge when you play Yoshi's Island? MSU1 shouldn't be any different. You want SuperFX, you plug in a cart with SuperFX. You want MSU1, you plug in a cart with MSU1.
If you mean you don't want to buy one of the eventual flash carts, or aren't 100% certain it will be released, I can understand that.
|
|
|
|
QuoteAnd this would theorotically be possible on a SNES if the MSU1 chip existed.
It does, you just can't buy it yet. A semantic difference. For all intents and purposes, the net effect is the same for now.
QuoteI've actually been reading alot of the post in this thread, and many people point out the same things.
Yes, I've answered many questions 2-3x now.
QuoteIt just seem fake to use WAV files that didn't excist back then (I guess)
The Famicom used them. Look up Pro Yakyuu Moero and family.
QuoteIndeed, it would be possible, but have fun mod'n your cartridge.
Have fun mod'n your cartridge to play your non-chipped hack in the first place. People use flash carts and copiers, and hopefully someone can sell you one with MSU1 soon. Or don't use it, I don't care.
QuoteHowever, the original cartridge does not contain a MSU1 chip in it, no game Licensed by Nintendo does. By using the MSU1 patch, you are creating a game that is incompatible with the original SNES Hardware, hence it is not a "SNES" game - and therefore, the original cartridge would have received a title such as Mario Bros. 4 (?)
MSU1 has absolutely nothing to do with the SNES base hardware, so your incompatible claim means nothing. The SNES just puts values on an address bus and reads back results from the data bus. You could similarly argue that the SNES is incompatible with the MAD1 memory mapper used by thousands of games, or the SA-1 used by over a dozen.
So software that is not licensed by Nintendo is okay and gets to use the word "Super", but hardware not licensed by Nintendo is not? I assume that means the Game Genie is not an SNES peripheral?
My brain hurts now 
|
|
|
|
I understood your post. What I'm saying is that there is no objective position that hacked software is legitimate, whereas hacked hardware is not.
Your definition would allow for Tengen Tetris and Super Noah's Ark 3D to be legitimate, but not the Game Genie nor Pro Action Replay. It would allow for some pirate carts, but not all of them, to be legitimate.
Neither are licensed by Nintendo, and frankly, who cares what Nintendo licensed? That is being subjective. "Does it physically exist or not?" is the only relevant detail.
If you really care about Nintendo's approval in the form of licensing, ask them what they think about your SMW ROM hacks.
QuoteI guarantee that byuu could have gotten this licensed back in the day if he could make it affordable and were a legitimate company
If we had enough money we could probably do it today
But I don't need a $50 million stamp of approval to satisfy a few critics, who will probably still reject it anyway. Now if we had a time machine as well, now then we'd be cooking with fire ...
|
|
|
|
Thanks, BMF
It's probably because all my posts are walls of text.
And to clarify my last post. I don't mind if someone is subjective. Case in point, I'm making a complete SNES database and only accepting Nintendo-licensed cartridges. No software hacks. (To do otherwise would make completing the project impossible.)
My concern was that your statement reads as being factual, when it is in fact opinion. And in this case, one I find irrational and contradictory. But everyone has their opinions, and that's cool. Since it's a debate thread I am pointing this out for the sake of others, not to be an asshole to you.
Which is really the crux of it all. Are we here to state our opinions and feelings on MSU1, or to convince each other of why we should or should not use it based on hard reasoning?
|
|
|
|
I stop by here on occasion, I do enjoy some of the hacks made here. I just stay out of ... well, exactly this sort of thread. Oh, the irony!
> I can only imagine how he would react to the whole Addmusic compatibility mess if he had seen it
I thought it was funny, actually. It was just one guy complaining. Funny how much drama a single person can cause, no?
Over time my thoughts on this have changed. I am now in favor of people writing whatever they want. If you don't care about real SNES compatibility, why should I care for you? I also feel that the admins own this site, and they can enforce whatever rules they want. Don't like them? Make your own site. People are ungrateful.
Besides, Addmusic will never work on any real system, but then MSU1 won't work on most flash carts. Although the latter is at least possible ( and has been done: http://www.youtube.com/watch?v=EqXYPvhHMCo , http://www.youtube.com/watch?v=yULkopwR8oA ), it's mildly hypocritical to support one but not the other.
> Why bother to take out features you've already coded in because people are pissing you off?
I discontinued the Qt port because Qt is a buggy piece of shit:
http://byuu.org/articles/qt
I did this at v070. I did my best to maintain the Qt port for four months as I begged someone to take it over for me. Eventually, too many core things changed and it wasn't possible to compile it. Being just one person, I can't maintain two GUIs, three SNES emulator cores, and a Game Boy emulator all by myself. So I forked off the last version and asked one last time for someone to take it over. Nobody did, because it's not popular enough.
You might find more answers here as well, although you may not agree with them: http://byuu.org/bsnes/legacy-formats
|
|
|
|
It's interesting that v06 caught on. It's the only thing I've made to ever catch on, and of course it has to be my most unpolished project. It gives me a bit of reverence to ZSNES v1.51, in fact. I think we'll see the same thing happen even if ZSNES v2 does ever come out. People are going to stick with the old version they like rather than change.
The code for v06 was an insane two-day project. It is impossible for mortals to comprehend. I guess I wrote that before I realized spaces and empty lines were legal in C.
The entire architecture is limited to 65816, whereas the new version can have unlimited archs. Great for SuperFX, NEC DSP and SPC700 assembly in the future.
The old code had weird internal max counts for everything: labels, defines, macros. The new version has none and resizes everything via vectors as needed.
The math is insane, left-to-right, because I did not understand recursive descent / shunting yard back then. Defines are broken by only having a prefix. Express define+b? !ab fails. xkas v14 {a}b works.
Internally v06 had some really broken 'assume' detection code. But either way, no magic is going to tell if lda #0 is a byte or word in all cases. I detect this based on the number of characters. Hex nn = byte, nnnn = word. Anything else and you better specify.
v14 has greatly improved namespaces. It's possible to set and reset addresses via labels through defines, and use these to chain source files together such that you only need one org at the start of your ASM code for all files. And it also allows makes for a great calling syntax. jsr vwf8::render.
The biggest change, to me, is making it a true LL(1) syntax. This required using ; which of course meant comments need //, but different != worse. "label: : nop : rts" is not as nice as: "label:; nop; rts" -- no other character could replace ; for a statement separator that wasn't also used by a popular ASM mnemonic.
Macros are the major missing feature. I left them out because they destroy error message line numbers, they are typically used improperly (not itself a justification for not having them), and doing it right is a monumental task. v06's had all kinds of gotchas, and I am absolutely horrified at how some of you are using them ;)
I had hoped that we could combine a separate macro evaluation program with xkas v14, kind of like how C has a pre-processor. But that hasn't happened. I can't blame people for sticking with v06 if macros are their thing, though. You're right, it's a glaring omission.
Other than macros though, pretty much anything is possible, just perhaps a bit different, and a bit easier on the eyes. Some new stuff is possible in its place, like a special mode to handle any mapper, including the so-called ExHiROM.
QuoteThe define 'char' thing seems to be the only way, nobody is going to want to do that for 50+ characters
A simple regular expression replace can turn one into the other. s/(?)=(*)/define '$1' 0x$2/
It's more descriptive, and allows you to redefine tables in the same ASM file instead of needing a separate file. Not that you should do that often ... but you can.
|
|
|
|
|
|
|
|
|
|
 |
|
 |
The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.
Copyright © 2005 - 2013 - SMW Central
Legal Information - Link To UsTotal queries: 27
|
|
|
|
