mirror of https://github.com/bsnes-emu/bsnes.git
312 Commits
| Author | SHA1 | Message | Date |
|---|---|---|---|
byuu
|
f6a04682f5 |
Update to bsnes v036r02? release.
Finally got belegdol's Polish locale up. Thank you again for that! New WIP. The main thing is that all of the "Load N Cartridge ..." options have been merged into one. Here's how it works: - Load a normal cart, and the game starts right away. - Load a BS-X slotted cart, and you get a window with the slotted cart set to base, and the slot section empty. You can use Same Game + SG- FEoEZ or whatever to test. - Load a Sufami Turbo cart, and you get a window with the BIOS set to whatever was used last (blank for the first time), the ST cart assigned to slot A, and slot B blank. The ST won't actually play any games with a cart only in slot B ... but it does display a unique error message if you try. You can always clear slot A and then assign again to slot B if you want. Another benefit is this works with command-line loading, too. Before, it was impossible to load BS-X / ST games from the console / bsnes executable association. There is a bit of a lag in startup, as always, so that's a bit noticeable. Right now, I'm missing the algorithm for BS-X flash cart detection ... Nach, I don't suppose you'd mind posting that for me, please? Further, in the future I'd like to also detect the BS-X and ST BIOS files, and assign those and show windows with all slots empty. FitzRoy, if you want to mess around with the System menu layout again, that's cool. Just keep in mind that "Power Cycle" is still there in advanced mode. It looks tacky with load+unload+reset+powercycle with no separator. Unload cart does appear to have limited use, so if necessary, we can consider removing that, I suppose :/ [No archive available] |
|
|
byuu
|
87b91f0ace |
Update to bsnes v036r01? release.
Posted a new WIP. The biggest change was that I rewrote nearly all of the cheat code system, so heavy testing on that would be appreciated. Someone was mentioning over at Snes9X that it was limited to 300 cheats or something, so someone bumped it to 3,000. Not to be outdone (v036 is limited to 1,024), I vectorized the cheat table, meaning you can have infinite cheats now (limited only to available memory.) Actually cleans up the code quite a bit, too. Removed all the ugly strlcpy() stuff, the limitations on description text length, etc. Looks like I had a bug with deleting codes, too. I wasn't copying the actual cheat codes. That would corrupt the descriptions on every code after the one you deleted, I think. Strange nobody caught that. I also cleaned up the OBC-1 code, and added a "Fullscreen" checkbox after "Correct Aspect Ratio". Sorry for the delay with that, FitzRoy. Hopefully the checkbox is good enough for now, as I can't change the text to "Switch to ..." just yet. [No archive available] |
|
|
byuu
|
0114e10ede |
Update to bsnes v036 release.
This release fixes a somewhat serious bug introduced in v035, and also vastly improves Windows support for non-ANSI filenames. The bug was triggered when HDMA would occur during DMA. If the DMA were long enough, subsequent HDMA transfers would be blocked. This caused graphical glitches in Star Ocean, Super Mario Kart, and possible more games. If you noticed any regressions from v034 to v035, this was almost certainly the cause. Once again, we're operating under the assumption that there are no known bugs currently, so please let us know here if you find any. I've also rewritten the file handling for the emulator. On Windows, attempting to load a file with non-ANSI characters (eg Russian, Japanese, etc) would cause these characters to be removed. This meant that no version of bsnes thus far could load these files. This problem was exacerbated when I ported the user interface to Unicode (UTF-16), this caused even config and locale file loading to crash the emulator. The root of the problem is that Windows only accepts non-ANSI strings in UTF-16 format, whereas bsnes' UI wrapper converts strings to UTF-8 interally. When passing these file names to the standard file functions (fopen(), std::ifstream, etc), file loading would fail. To fix this, I replaced all file access functions with a new version that would convert the UTF-8 filenames back to UTF-16, and use appropriate access functions (_wfopen(), _wmkdir(), etc.) ... but there is still one limitation to this: ZIP and GZ support use zlib, and JMA support uses libjma. Neither of these libraries convert UTF-8 strings to UTF-16 before attempting to open files. Due to licensing issues, as well as technical issues, I am unable to correct this at this time. What this means is that loading ZIP, GZ and JMA files; on Windows only; and with Unicode characters in the file name only; will cause the image load to fail. Loading uncompressed images (SMC, SFC, etc) will work with or without Unicode on all platforms. I tried to be as thorough as possible with this fix: command-line arguments (via CommandLineToArvW + GetCommandLineW), user path (via SHGetFolderPathW), real path (via _wfullpath),folder creation (via _wmkdir) and file access/existence checks (via _wfopen) were updated in all cases. I also updated file loading for ROMs (SMC, SFC, etc), save RAM (SRM), real-time clock save (RTC), cheat files (CHT), UPS patches (UPS) and both configuration files (bsnes.cfg and locale.cfg.) Configuration file loading should work even if your username contains non-ANSI characters, and it should also detect config files put in the same folder as the bsnes executable, even if the path to the executable contains non-ANSI characters. Still, if you spot any bugs, aside from the ZIP/GZ/JMA loading issue, please let me know via e-mail at setsunakun0; at hotmail. Lastly, I'd like to apologize for the poor support for non-ANSI filenames in the past. Using an English version of Windows didn't expose the problems to me. I'll be more thorough in the future with this. |
|
|
byuu
|
8c591ce44a |
Update to bsnes v035 release.
Changelog:
- Added video synchronization support at long last [blargg, byuu].
- Added audio panel to control volume, latency, frequency and SNES input frequency settings.
- Added driver panel to select APIs to use for video, audio and input.
- Added crash handler for driver initialization.
- Xv and SDL video drivers now work with compositing enabled on Linux/Xorg.
- Improved ALSA audio driver for Linux.
- Now using a fixed output frequency, along with a 4-tap hermite resampler.
- Improved header detection; fixes Batman: Revenge of The Joker and a few fan translations.
- Frameskip will now randomly choose a frame in each set to display; helps with animations.
- Locales now support meta-data, which allows for unique translations of the same English input.
|
|
|
byuu
|
e2cc164f70 |
Update to bsnes v034r06 release.
This will probably be the last public WIP, so get it now if you want
it.
http://byuu.cinnamonpirate.com/temp/bsnes_v034_wip06.zip
I used the same "create a child window inside the output window" trick
for Xv that I used for OpenGL, so Xv will now work even with a
compositor enabled.
I also added Video::Synchronize support to OpenGL for Windows. My card
seems to force it on regardless of my driver settings, but maybe
you'll have better luck. That driver had the same issue with
allocating 16MB of memory instead of 4MB (that was due to copy and
pasting of code), so that's fixed too.
This version lowers the CPU<>SMP drifting by an order of magnitude.
You shouldn't notice the speed hit. I can't really get any lower
latency with that, though.
I also restricted the latency range to 25 - 175, with the default
being in the center, 100ms. Quite conservative, given the average we
see is 70-80ms. But you won't notice the difference, and this way we
ensure no popping even in exceptional circumstances by default. 25ms
is doable without video sync and with OSS4+cooked mode, but I
seriously doubt any Windows user will get lower without something
crazy going on with the sound card drivers.
Lastly, I've replaced the 2-tap linear resampler with a 4-tap hermite
resampler. You won't be able to tell the difference, but it's quite
pronounced if you use a waveform analyzer on much higher output
frequencies:
Linear:
Image
Hermite:
Image
Hermite is essentially better than cubic (for which cubic spline is an
optimized version of), as it is better at not going too far away from
the points, so you get a bit less clamping in the extreme cases. But
the difference isn't audible to humans anyway. It's still clearly
inferior to band-limited interpolation, as it will still have
noticeable aliasing of things like square waves and such, but it's
orders of magnitude less complex to implement.
Keep in mind that nobody could tell the difference even with linear
interpolation from the last few WIPs.
----------
Aside from that, I'm pretty much ready to release a new version. If
anyone has any show stoppers, _now_ is the time to say something.
Otherwise I'll probably post something tomorrow or Friday.
|
|
|
byuu
|
d09e54149b |
Update to bsnes v034r05 release.
http://byuu.org/temp/bsnes_v034_wip05.zip OpenGL/Linux now destroys the window and colormap it creates, and it also avoids allocating 16MB of memory when only 4MB are actually needed. Forgot to remove the * sizeof(uint32_t) from the buffer allocation after changing it from malloc to new. I use 4MB because the internal buffer size is 1024x1024@32bpp. I make it larger than needed to support both present and future filter requirements (eg HQ4x would need 1024x960 minimum.) The X-Video driver will now look for XV_SYNC_TO_VBLANK and add the video synchronize option when it exists. Unfortunately, that doesn't stop the binary nvidia driver from ignoring the setting anyway, but it should be nice for those using the nv driver or somesuch, especially as it lacks OpenGL support. For whatever reason, I was able to get my latency in DirectSound down to 70ms. Not sure if it's related to these changes or not, but I won't complain. I also needed to set 32150hz / -50 for the input frequency adjustment. Probably just differences between the monitor timings on Windows and Linux. That said, let's get some averages. With the new WIP, be sure to reset all of your audio and driver settings. It may even default to no driver at all if you were using a custom one before. From there, please post the video driver, audio driver, latency and SNES input adjustment values that work best for you. > BTW, were you able to look into that status bar bug? Thanks for pointing that out. The status bar properly restored its state, but the menu bar did not. Rather than save the menubar state (I wanted to avoid that for people who accidentally hide the menubar and then close the app, and don't remember how to re-enable it), I just made it not save the status bar state at all. Apologies to those who hate the status bar, you'll have to turn it off more frequently now. Direct your pitchforks at FirebrandX :P [No archive available] |
|
|
byuu
|
8e4f1be189 |
Update to bsnes v034r04 release.
14 hours of straight programming brings you this:
http://byuu.cinnamonpirate.com/temp/bsnes_v034_wip04.zip
Windows binary and source included, binary does not have ZIP+JMA
support enabled, as it's a WIP release.
Yes, vsync works both on Windows and Linux. In fact, it actually seems
to work better on Linux, in that it requires lower audio latencies and
has no troubles at full 5x scale on my 1920x1200 monitor.
Overview of new features:
Most importantly, I've added a new menu group to the settings menu
group, "Synchronize", containing "Synchronize Video" and "Synchronize
Audio" checkboxes. You can have neither, one or both checked. Up to
you. That made the "Uncapped" speed setting redundant, so that was
removed.
Next, there's a new audio configuration panel with lots of new
goodies.
Volume lets you scale audio from 10% to 200%. Note that going over
100% will obviously cause aliasing. It's a much better idea to turn up
your speakers first. But who knows, it could come in handy. On one
machine with OSS4, I couldn't adjust volume in Audacious, and it
always bothered me that it was so much louder than bsnes, so I saw no
reason to cap the volume to 100% here.
Latency lets you control the number of milliseconds between adding
data to the sound buffer and it being played. Note that this is _not_
the absolute latency. Any sound servers and resamplers will obviously
add to this. It increments in steps of 5ms, because I don't want
people wasting their time trying to get it absolutely perfect. 5ms is
a small enough increment that no human being will notice. I also have
to re-create all the buffers and/or device itself when that changes,
so I want to keep it from changing too frequently. Not that there's a
memory / resource leak, but just in case.
PC output frequency let's you control the master frequency for the
sound card output. You can set this to 22050hz (not a good idea, loses
precision, there as a last resort), 32000hz (for purists), 44100hz
(for most cards), 48000hz (for higher end cards -- set as default
because it's a nicer multiple of 32000 than 44100 is) and, yes,
96000hz. And I'm sure all the audiophiles will remark how much better
it sounds, right?
Believe it or not, there's actually some value to higher frequencies
for the vsync. Higher rates lower the rounding errors with
interpolation and such, so you can use lower SNES input rates. And
speaking of which ...
SNES input frequency is what the base SNES input is skewed to. The
basic idea is that you want to get the value as low as possible
without sound crackling. The lower it is, the less video frames
duplicated, the less jerkiness of the video. The higher it is, the
less likely an audio breakup is.
Once again, Linux seems to come out on top here. Because of it's non-
ring buffer approach to audio, both ALSA and OpenAL can insert blank
samples in a way that DirectSound simply cannot. Whatever it does to
BS underflows, it works really well, because you can barely even
notice it.
The default is a tad on the dangerous side. If anything, you may need
to increase it.
Get the right values for everything, and you can easily play games and
never notice any video tearing or audio crackling whatsoever.
Lastly, I removed the "Show Statusbar" option from the misc menu, per
FitzRoy.
Oh, also note that with Linux (both for OpenGL and Xv) and Win/OpenGL,
you have to toggle the vsync enable in your video driver's control
panel. Pain in the ass, that. Linux/SDL and Win/GDI do not vsync. No,
I'm not even going to bother trying to add that to them.
My settings:
Hardware:
nVidia 8800 GTS 320, Intel HDA audio, 24" LG @ 1920x1200x24bpp@60hz
Windows:
Direct3D, DirectSound, Latency = 120ms, PC freq = 48000hz, SNES freq =
32050hz; 4x scale always works, 5x scale misses vblank every few
seconds
Linux:
OpenGL, ALSA, Latency = 60ms, PC freq = 48000hz, SNES freq = 32050hz;
4x and 5x scale always works
I'd be interested in hearing what works best for you guys. I'm
especially interested in how PAL works on a monitor running at 50hz. I
don't have any that can handle that resolution, nor 100hz. I don't
expect scrolling to look great at 100/120hz, as I have no special
handling for it.
> Even if it is wondows-only, you may want to add the option of using
> a short sleep in the advanced options panel.
No, I really can't :P
I tried just to see what would happen, calling Sleep(1) a single time
is enough to jump over the entire vblank period. In the worst case
scenario, you get stuck in a loop, never hitting vblank, and the
framerate drops to 1fps. Trust me, you don't want a sleep in there.
Now, I know you're thinking, "why not let the video card do the sync
for you?" -- well, one, some drivers still eat up all the CPU time in
their loops, and two, by polling the vblank status repeatedly, I
actually get better results with 5x scale in D3D on my system. And I
don't have to destroy the video device to toggle the video sync
enable.
[No archive available]
|
|
|
byuu
|
f529a84fd1 |
Update to bsnes v034r03v release.
For Windows / Direct3D / DirectSound _only_.
http://byuu.cinnamonpirate.com/temp/bsnes_v034_wip03v.zip
Leave it at 100% speed, play NTSC games, leave frameskip off. I don't
care if any of that is broken or not right now.
There are two special variables this time: system.vsync_magic and
system.latency_magic.
The former is the skew for the resampler, you create that many samples
per 32000 samples of output. The latter is the latency in samples. It
will tell you how much total latency you'll end up getting when you
start the emulator.
Note that the system requirements are much greater with the CPU<>SMP
desync trick disabled. It's something like 10-20% slower. So leave off
the filters, please.
If vsync_magic is too low / high, it will tell you on the terminal by
printing an underflow warning. If latency_magic is too low, you'll
hear crackling.
The bad news: no matter what values I plug in, I still get crackling.
I can get it to be pretty rare, but I'm completely unable to get
smooth audio. Maybe you'll have better luck, who knows.
For me at least, the vsync_magic value that sounds best keeps varying
every few minutes between 32100 and 32250. The latency is through the
fucking roof. I've got it over 120ms and it's still not enough to
prevent occasional audio crackling. It's already much too high to be
practical for a release.
Note that without vsync, it only needed to be 60ms, and that was a
conservative number. We could get it down to 20-40ms with the right
hardware.
[No archive available]
|
|
|
byuu
|
567d415290 |
Update to bsnes v034r03 release.
New WIP, with _major_ changes to internal header detection.
This should get everything working, if we're lucky. It does get
Batman: RotJ working for the first time, as well as all the fan
translations.
I'm releasing it publicly, as I need all the help I can get with this
one. Windows binary with ZIP+JMA support included along with source
for the penguins.
byuu.org/temp/bsnes_v034_wip03.zip
Do note that I left the console enabled in the binary. It's not a
release-grade version, anyway. But the main reason was to print the
scoring information. If any games fail, I'd like that information
posted. Might be good to note really close passes, as well, so we can
keep an eye on them for future changes. Right now, I'm only aware of
SFA2 that gets really really close.
Basically, it prints the address it tests for a header at, the score
it ended up getting, and the reset vector's first opcode. If the
values are equal, it defaults to LoROM, then HiROM, then ExHiROM. If
the reset vector is invalid, or the ROM is too small to contain a
header at a certain offset, you won't see any output for that line!
That means a lot of times, you'll only see one line output, and
sometimes you'll see two or three. No worries, just assume missing
means total fail. It only prints output for "possible" header
locations.
If you do test, you don't have to play in-game or anything. The second
you see any visible output whatsoever, that's good enough.
Many thanks to everyone who tests in advance :D
----------
Hunter and tukuyomi, thank you for the kind words and localizations :)
I really hate that table on the download page, and I need to go
through and get names out of all of the locales, but I'd like to get
an "Author:" field in that table on the download page. Sorry it's not
there just yet.
----------
Fes, thanks for the feedback.
> Apparently it has a limit of 65535 bytes for string literals.
I don't have a workaround for that. For whatever reason, ISO didn't
add an "incbin"-style command, and I need a platform-agnostic way of
encoding binary data.
Not for v035, but maybe a while after that, I'll use a more advanced
compressor to get the controller below 64kb of string data. Maybe I
can rig my order-0 arithmetic coder onto the end of LZSS for a quick
and dirty size cut. The reason I don't use 0xnn, 0xnn, is because that
takes 5 bytes of source to encode one byte of input, whereas base-64
strings only take ~1.25 bytes. I didn't want those files to slow down
compilation much.
> # Next, in dictionary.hpp, the first for loop uses 'i' as its
> counter, then declares 'i' again inside the loop body for additional
> work.
Oops, sorry. Didn't get a warning on GCC, so I overlooked it. This is
now fixed.
> # Cartridge::get_base_filename and Cartridge::apply_patch both claim
> to return a value, but don't seem to do so.
First should return the filename, it's just a convenience thing to
allow chaining commands. The second should return result of patching.
I've fixed both now, thanks.
> # spc_dsp.h, nal/file.hpp, and ups.hpp all attempted to include
> stdint.h, which isn't part of vc++. Are those files perhaps meant to
> include nall/stdint.h instead of the standard one?
Microsoft really pisses me off by intentionally ignoring stdint.h.
nall/stdint.hpp was meant as a workaround, so that I didn't have to
special case Visual C++. The idea was to not require you to get one of
those third-party add-ons.
So yes, two of those were a mistake on my part, I used stdint.h on
them before I created my own stdint wrapper. I've corrected both.
As for spc_dsp.h, that shouldn't be compiled. That is for blargg's
reference, unmodified S-DSP emulator. The ones modified to work in
bsnes do not require it. And in fact, only src/dsp/sdsp will compile
at the moment due to memory map changes.
> # pEditbox::get_text seems to declare a dynamically sized stack
> array, which CL balked at.
Hahah, yeah, that would be C99 syntax. Very nice, that.
Looks like I was allocating length*2 wchars, too. I don't know why I
was doing that ... I don't think Microsoft's system even supports the
extended Unicode symbols that need more than 16-bits, and even if so,
they aren't likely to appear in the emulator.
Dropped that back to length+1, and made it use new[]/delete[],
instead. That's one horribly inefficient routine by the way, but
whatever, it works for now.
The rest I can't do much about, sorry. Hopefully it'll make it easier
for you to compile in the future. Sorry for letting the port slip, I
just don't have the patience to load VS2k5 again. Software takes like
three hours to install >_< and creates slower code than GCC4 anyway.
If they'd fix their damn PGO support, I'd be all over it again,
though.
|
|
|
byuu
|
435a194ccd |
Update to bsnes v034r02 release.
New WIP. First, the internal ROM header detected was enhanced. Nach was right, so I went ahead and did it the right way ... it'll score all three regions individually now, and then use some heuristics for those annoying games that duplicate the header entirely in multiple places. The hardest games to detect, that I recall, are Double Dragon and Street Fighter Alpha 2, which seem okay. In fact, all ~50 of the games I have seem to be working fine. Please let me know if any games fail to start as of this WIP. Second, finished updating all of src/memory to convert uint -> unsigned. Yeah, I like the former more, but the latter is a built-in type. Did the same to hiro, and converted Event to event_t, looks nicer in code. Part of namespace libhiro, so no worries about other things named event_t. Third, added the frameskip cycling code. It just randomly chooses which of the set of frames to display (random() % (frameskip + 1)). Seems to work as expected, you can see Link blink when hit even with FS=1, but obviously it stutters a bit more. Fourth, I finally added RedDwarf and Nach's latest ALSA code. ALSA will now with at 75% speed and with speed uncapped. It has the same overhead as OpenAL. So, unfortunately, due to OpenAL's issues with completely destroying echo / reverb for some reason, I'm going to have to recommend Linux users set system.audio to "alsa" from now on :/ FreeBSD users should rely on "libao". I'd like to release an update this weekend to address the ToP issue, as well as a missing string in the translate[] hooks and to distribute the new ALSA updates. I'm worried about the header detection changes breaking some other games, though. So if you guys wouldn't mind throwing a bunch of random games at it, I'd appreciate it. It _should_ be fine, though. In theory, the LoROM / HiROM detection is identical to the last release still, but I did restructure it, so you never know ... Oh, and I updated the website with new locales from Hatsuyuki, Itol, khiav and wushu. Thanks, guys! [No archive available] |
|
|
byuu
|
df9de289b9 |
Update to bsnes v034r01 release.
New WIP (yes, already.) Nothing that affects emulation, just a bunch of core changes I didn't want to make last-minute before the release. All of the APURAM / VRAM / OAM / CGRAM memory blocks have been moved to the Memory class, and I've added operator[] bindings and such so that I don't have to add .read(), .write() around everything. Required several dozen individual changes, and I was afraid of introducing a new bug. Everything looks good so far, anyway. I also missed the translate[] call around "Paused", so it's not possible to localize that in the new version. Oops. > edit and thanks to Jonas Quinn for the $4810 register/Super Power > League 4 fix. Definitely, I wasn't going to release a new version this week because of that bug. Speaking of which, I just tried SPL4 on the Windows port. Holy hell, that completely changed my opinion of OpenAL. Seriously, those on Linux ... compare that game with OpenAL and ALSA. With DirectSound / ALSA, the game actually has echo / reverb. It's _completely_ missing with OpenAL. The woman announcer sounds like she's speaking over a megaphone, but OpenAL makes her sound like she's two feet away from you. Wild stuff. And SDL video is going crazy on me now, it seems to be setting each pixel's alpha value to some sort of inverse of chroma. Eg you can see the background through the emulator window, and it's completely transparent on full white / black screens. Really trippy looking. Definitely be sure to set system.video to "glx" or "xv" if you use the Linux port. [No archive available] |
|
|
byuu
|
dd83559786 |
Update to bsnes v034 release.
For this release: SPC7110 emulation speed has been greatly optimized, massive improvements to HDMA timing have been implemented, Multitap support was added, and the user interface was polished a bit more.
Changelog:
- SPC7110 decompression code updated to latest version by neviksti and converted to a state machine; SPC7110 overhead is now identical to S-DD1 overhead (eg ~5% speed hit over standard games)
- Fixed a major bug in SPC7110 data port emulation that was crashing Super Power League 4 [Jonas Quinn]
- HDMA trigger point corrected to H=1104, bus sync timing corrected
- All illegal DMA A-bus accesses should now be properly blocked
- DMA state machine rewritten, greatly simplified
- Major corrections to HDMA run timing; fixes flickering bugs in Mecarobot Golf and Super Mario Kart
- Emulator now defaults to 2/1/3 SNES (CPU/PPU1/PPU2 revision numbers)
- Multitap emulation added, can be attached to either or both controller ports; user interface updated to reflect this
- Status messages (cartridge loaded / unloaded, UPS patch applied, etc) now appear in status bar
- Added advanced configuration option, "input.analog_axis_resistance", to control gamepad analog stick sensitivity
Also, the SPC7110 emulator download link below was removed: if you are looking for this, please download the bsnes v034 source code, which has the most up-to-date version in the src/chip/spc7110 folder.
|
|
|
byuu
|
100ef3a271 |
Update to bsnes v033r09? release.
New WIP, probably not worth downloading. For the sake of completeness, I finished optimizing the SPC7110 code. I've converted the pixel buffer rotation from swaps to moves, which should double the speed of the slowest part. I've also added reverse morton lookup tables (2x8-bit and 4x-8-bit deinterleaving), which are 8-10x faster than doing it using pure bit logic, I removed the redundant comparisons from the pixel context lookup (though a compiler would've done the same anyway), and lastly I've cut the mode2 context table in half, since the refcon add bit was only set on context 1 anyway. I could've replaced the other half with 5-6 if/else statements, but I didn't see much of a point in that since it'd only make the code harder to understand. That results in a 1-2fps speedup, at best. Really, the code is simply not a bottleneck. It's pointless to optimize anymore, as any changes from this point on will just make it harder to understand what's happening. I only added the morton tables because it does seem to aid readability. Also added translate[] wraps around all the new status messages, and moved the two checkbox options on the paths window to the advanced options list. No sense cluttering up the UI with near-useless settings. > It's hard going back to "Are you sure you'd like to exit?", no > multiplier eyeball stretching, etc. Heh, yeah. I never understood the floating point multiplier setups in some emulators. I guess it's useful if you want your video output size to be π x _e_. I thought about the "Are you sure?" thing, it'd be nice if you accidentally close the emulator, so you don't lose your save. But I quickly realized that despite using emulators for ten years, I've never _once_ actually done that. The only point where it might be appropriate is if I add mouse / SS support, since you may want to have the cursor near the top right of the window with the menubar off in windowed mode (though you're just asking for trouble at that point, honestly.) To be fair though, you helped design at least half the bsnes GUI, so obviously you should like it :P > I should offer a bounty at this point to anyone who can find another > bug that isn't PPU based. Super Power League 4 seems to die after an inning or two with a S-SMP crash. I still need to try screwing with the CPU/SMP scalars and try substituting with anomie's DSP core to see if it still dies. If neither of those affect it, it could very well be due to a timing issue with not emulating the delays of the SPC7110 chip or something. If someone wants to rule out the DSP core, they could try playing a SPC dump from the game in one of the plugins that use blargg's core. I doubt it's that, personally. The usual rules about special chips apply, but you can list it as a bug if you like. I probably will with a note. Maybe I can figure it out before release. Probably not, but who knows. Sigh, it's always the god damn baseball and golf games, isn't it? I'd probably half-ass the game too, if it were my job to work on one. > Two minor things that have probably been forgotten in all this > excitement that could make the next release: libui is still not > changed to "hiro" in the license, both online and text based. And > mudlord wanted to be added to the contributors for his OpenGL stuff. Ah, thanks. Updated the license file. Decided against listing all the libraries there for now, as they're getting quite numerous. As for credits, mudlord is already listed in the source file, and the contributors list is for people who have submitted code to the core of the emulator. It's not a good system, I admit. That obviously excludes you and tetsuo55, despite the fact that your testing has been one of the most helpful things I've received. It's not that I mind listing people, but I don't want that window to become cluttered with 100+ names of everyone up to and including people pointing out spelling mistakes in WIPs. That would make the window really onerous to look at. I really don't want to come off as rude here, I'm really truly grateful to everyone who has helped out even a little, and I'm happy to thank them all in some perpetual fashion (eg website thank yous tend to disappear as the news falls off the page.) That's the second time someone's brought that list up. I was afraid that adding such a list would just end up causing problems. Maybe I should just remove the contributors list on the about screen, and put everyone in the readme.txt file, so that everyone who ever contributed anything is listed? [No archive available] |
|
|
byuu
|
bccc5b5a12 |
Update to bsnes v033r08? release.
I wish I could post the new WIP, I really need it tested. But it looks like vstech.net (cinnamonpirate.com's host) got sucked into a black hole, literally. You can't even nslookup it. So ... sorry. What I did today was: - remove an unnecessary ternary condition in HDMA CPUsync (no visible effect on emulation or speed.) - move controller ports from settings to system. - rewrite SPC7110 decompression engine from scratch. The last one obviously the most important. I took neviksti's most recent decompressor code, made the essential variables static, added a bool init parameter you can use to start a new decompression sequence, and built up a dual-indexed (read+write cursor) ring buffer to stream byte sequences. I set the buffer to >= 32 bytes at a time. I also simplified a few parts, like the swap sequence for pixel ordering; and I took out the end of each function that computes length, since that's no longer needed (nor is bot.) The result is you can stream an infinite number of bytes safely from decompression, and nothing will ever go out of bounds of the data ROM. Speed results on Core 2 Duo E6600 @ stock 2.4GHz: FEoEZ cart riding sequence - 91fps (was 40fps) MDH title screen - 111fps (was 29fps) SPL4 title screen with players running across screen - 118fps (was 35fps) For comparison, Star Ocean in-game gets ~95fps. I didn't think we would need that many optimizations to get SPC7110 support running at full speed (how complex could a low-cost IC from 1995 be?), good to see I was right. As soon as vstech comes back (hopefully tomorrow), I'll post the PD / BSDL source, and get it sent over to GIGO. Hopefully he can add it to SNESGT. Speaking of which ... neviksti: In your updated DecompMode0.c file, you declare NUM_CONTEXTS as 15, but it should be 30. I'm guessing it runs fine in isolation (memory initializes to zero and all that), but when mode 2 ran and set contexts up to 32; only clearing 15 was resulting in corrupted graphics all over. No big deal, just mentioning it. > I don't really understand your (or byuu's) point. If the game does > indeed works on 99.9% of units...on what do you base yourself to say > their programming suck or that the game is "broken"? I mean, it > works, it works right? This is the problem I have with the black-and-white "bug" label ... it implies a game is broken to a casual observer, or there is at least noticeable corruption on at least one screen. In truth, bsnes has a few visible bugs. Street Racer will flicker one frame on the title screen, but only one time, and only once every ~4-8 runs. Adventures of Dr Franken and Winter Olympics show one black scanline because the games update OBSEL at very unusual points mid- frame. And there are countless "anti-bugs", eg Battle Blaze on the fighter select screen is supposed to show some garble up at the top due to mid-scanline PPU writes. Because bsnes renders an entire scanline at once, you don't see this. Lots and lots of games will have 1-16 pixels on one scanline at the left (usually not even visible on TVs) that flicker due to writing PPU regs past the end of hblank. BoF2 German detects emulators by reading the division register early. Since no emulator supports that, you don't see the anti-piracy splash screen. All of those could be considered bugs to varying degrees. I suppose what would be nice is a bug severity ranking system. "Severe" if it's game ruining, "Moderate" if it's more than one scanline / frame that glitches graphics or something, and "Minor" for the stuff 95% of people probably won't even notice. Or something like that. My point is that it doesn't make a lot of sense to work on the minor stuff. Most of that will probably go away with a cycle-based PPU anyway, and the rest will probably continually appear and disappear with infinitesimal timing changes. [No archive available] |
|
|
byuu
|
acee547da9 |
Update to bsnes v033r07? release.
And another one. I've re-written the DMA state machine. I decided to keep it in one FSM instead of two separate ones, because they honestly share so much. But I rewrote it to be a lot cleaner, and to handle some really exceptional edge cases. Due to the design, I was even able to make the HDMA during DMA edge case "transparent", eg the same codepath is used for normal HDMA and for HDMA during DMA :D New WIP passes the last four tests in test_hdmatiming.smc. The ROM posted doesn't validate the last four yet, so you have to compare the SRAM file to the source logged values if you care to. That should be everything with DMA and HDMA timing now, thankfully. Really happy with that codepath for the very first time. Such an improvement from the "don't even worry about HDMA syncing" code I had a few versions ago. I also reduced the DRAM refresh rotation from 7-lines of code testing against the NTSC color burst case to 1-line, using the DMA counter (dram_refresh_pos = 530 + 8 - dma_counter()) Lastly, I added a flush command to the status bar. Any important messages will now flush all buffered ones to display the new one. Eg load 10 games back-to-back and it'll say the name of the new game immediately, instead of scrolling through the other 9. It will still buffer lesser important ones, like unsupported chip and UPS patch applied messages. I also removed config / locale path display, because it annoyed me. Nearing a release. I want to state machine neviksti's SPC7110 decompression code, and I should be ready on my end. FitzRoy, I'll give you the final word. If you want controller port selection moved to "System", I'll do so. Any show stoppers should be mentioned now. I can't fix the "crash with Unicode characters in the executable path" issue just yet, so that'll have to wait. [No archive available] |
|
|
byuu
|
b1b146fd7d |
Update to bsnes v033r06? release.
New WIP. Adds some more HDMA timing improvements, DMA bus hold simulation, and hopefully proper detection for ST011, which should mean that every unsupported game will now notify you of that fact. Also, I finally got around to writing that status bar message queue system I mentioned a long time ago. Should make Deathlike happy. It'll tell you whenever any UI event occurs (load, unload, reset, power cycle, UPS patch applied, unsupported chip detected, config file / locale file load, etc.) Obviously if you turn off the status bar, you won't see them. Not a problem for me personally: if you want to see status messages, leave it on. With that, I removed the annoyingly bland message window, and muted the terminal message printing, putting it all inside the statusbar instead. I also got rid of some now-unused config variables, misc.status_text (it was kind of overkill to let that be customizable) and cpu.hdma_enable (it's always enabled now.) Opinions on the new status bar system welcome. I've also set the SNES to report itself as 2/1/3, rather than 1/1/1. Since I don't emulate things like the HDMA conflict crash, I figured I may as well set it to the CPU revision that doesn't have it. > Probably the best it's ever been, but Street Racer's track does > still flicker on "Head to Head" mode. With the above changes, I was able to eliminate the flicker in-game in all modes, as well as get rid of it ~80+% of the time on the title screen. Only once every ~5 restarts will you see it for _maybe_ one frame. That's really the best I can do, I'm afraid. It's so subtle I doubt anyone will even notice it now. Like Winter Olympics and Adventures of Dr Franken, I'm not going to consider it an active bug (yes, how convenient), but I'll watch the game closely with future timing changes. Hopefully it'll go away entirely with more refinements in the future. [No archive available] |
|
|
byuu
|
53e913e225 |
Update to bsnes v033r05? release.
New WIP.
After some more hardware testing, it seems my theory from before was
correct. See the HDMA thread for more info if you care.
With those changes plus a few others, I'm now able to get everything
in my "known troublesome" games list to work properly and with no
flickering:
- Breath of Fire 2 (G)
- Earthworm Jim 2 (U+E)
- Energy Breaker
- Jumbo Osaki no Hole in One
- Mecarobot Golf
- Secret of Mana
- Street Racer
- Super Mario Kart
I still can't get Street Racer to flicker, maybe you guys can?
Hopefully not, such a hard-to-trigger bug will be even harder to
debug.
Image
(ignore the framerate, from a pause/resume screen capture.)
And fucking _hell_ that game is hard.
Note that to get BoF2 (G) to work, I had to modify S-SMP cycle timing
from 32040hz*768 to 32041hz*768. It seems the game is very sensitive
to S-CPU <> S-SMP timing, and the improved HDMA timing was just
unlucky enough to just _barely_ miss the handshake. This was further
compounded by there being no input before the point in question to
vary timing.
It's not really a problem with the game itself -- d4s really pushed
the limits of these two chips to pull off that impressive intro. It
was more that I was hitting an extremely tiny window of time that
caused a deadlock.
This timing change only affects S-CPU <> S-SMP communications (eg
handshakes and such), and not timing inside each individual processor.
Recall that both processors in both regions (NTSC and PAL) have
slightly different timings, and the exact timings vary even on real
hardware, as the crystal clocks used are not perfect.
The NTSC S-SMP has been observed at ~32040hz on an oscilloscope by the
guy at alpha-ii.com, which is faster than the stock speed of ~32000hz.
But we still use stock speeds for the S-CPU because that's all we
have. Changing the S-CPU speed a bit would've fixed this as well.
So yeah, the fix is a bit of a kludge, but it's the best I can do when
the problem is in communication between the two chips.
Keep in mind that the S-SMP clock rates are cached in the config file.
You'll either need to delete it, or reset the values to the default in
the advanced panel. Otherwise the game will hang on first run.
Also, I tightened DMA transfer restrictions even more. A-bus accesses
to $4200-421f and $4016-4017 are now blocked. And I also block these
during HDMA line counter / indirect address fetches (as observed on
hardware.) Further, I was previously allowing invalid B->A transfers
to still write the the MMIO reg specified in A, but ignoring the B-bus
read. This seemed wrong: not being able to access the reg should mean
not being able to access it period, so I swapped that around.
Shouldn't affect any known games, but mentioning it just in case.
> Perfect timing matching isn't needed, the games are broken if they
> can't take a normal sized delay for this.
Mortal Kombat II breaks if you're exactly 6 cycles off from expected
timing (but works if you're more than six cycles off.) Jumbo Osaki was
failing by 20 cycles. Wild Guns fails if off by two cycles. A couple
other games were the same. There are roughly _21 million cycles_ in a
second.
Death Brade and some European racing game break if _uninitialized RAM_
doesn't return the values they like.
Uniracers is quite simply _beyond_ broken.
I wish I could get away with just saying the games themselves were
broken (and they are), but when it runs at least 99% of the time on
hardware, you can't use that as an excuse. Everyone will still call it
an emulation bug :(
> Err, not really. Fixed delay for all operations is as dumb as no
> delay for all operations.
I typically like the idea of emulating as much as we can ("building
blocks" and such), if that means guessing approximate delays, so much
the better. But for the DSP-1, adding any delays is even worse in my
opinion. Why?
First, the delay lengths will no doubt vary depending upon how complex
the transfer is. Second, emulating the delays would force us to
implement the DSP-1 as the dedicated processor that it is: thusly, its
overhead would soar from barely noticeable to nearly as intense as
SuperFX / SA-1 emulation. Third, it may be possible to read partially
computed results before the operations finish. We can't even figure
out the partial computations of mere _unsigned multiplication and
division_ in the S-CPU core, so how the hell would we ever plan to
figure out attitude / altitude calculations?
The only feasible way we're going to get this right is to dump the
program ROM and then emulate the instruction set. Even decapping the
DSP-1 has been no help for that, and even if by some miracle we got
the ROM, we'd have to figure out the instruction set and timing with
no documentation. And all of this to improve emulation of a couple of
lackluster action games. Good luck finding someone willing to do all
that for free, and just to end up getting ~90% of people bitching that
suddenly DSP-1 emulation is as demanding as SFX emulation, yet
provides no visible improvement over existing emulation. And it even
requires another DSP1program.rom file that they didn't need before!
Thus, it's really not worth the effort if our entire model of
emulating the chip is busted in such a manner that we couldn't improve
it more even if we wanted to anyway.
[No archive available]
|
|
|
byuu
|
0cf16ce784 |
Update to bsnes v033r04? release.
Posted a new WIP which can pass the test_hdmasync ROM I posted in the other thread. Please note that it's currently throwing off Jumbo Osaki exactly 50% of the time. I'll look into it over the weekend. But the change I've made is correct, so if I can't fix these, the games stay broken :/ One of the most unfortunate parts of emulation: when a game works because two things are bad, but no longer when only one thing is bad. [No archive available] |
|
|
byuu
|
ce38d577ef |
Update to bsnes v033r03? release.
New WIP posted. It adds my new findings on HDMA, which I've posted here: http://board.zsnes.com/phpBB2/viewtopic.php?t=11804 This effectively fixes Mecarobot Golf once and for all. Interestingly enough, it also eliminates the track line flickering in Super Mario Kart. Image What a boring screenshot ... I've tested for regressions with Battle Blaze, Battletoads, Battletoads & DD, Breath of Fire 2 German, Circuit USA, Der Langrisser, Energy Breaker, Earthworm Jim 2 (USA and EUR), F1 Grand- Prix, FF: Mystic Quest, Mortal Kombat I & II, Jumbo Ozaki no Hole in One, Secret of Mana and Street Racer. Basically, all the usual HDMA suspects. Looks good to me. Let me know if you guys find any new regressions, though. [No archive available] |
|
|
byuu
|
0a87b99370 |
Update to bsnes v033r02? release.
Alright, then. This was the new feature from the last WIP: Image Multitap support for Nach and tetsuo55 :) New WIP up as well. This one adds Pogo's request, there's a new config variable named input.analog_axis_resistance. The setting works both for the DirectInput/Windows and SDL/Linux drivers. It used to be 75% on Windows, 50% on Linux. Now it defaults to 50% on both platforms. If any of you guys have an analog stick and want to come up with a better default value, please feel free. I wasn't able to pull off Ryu's spinning kick thing very easily at 75%, for instance. > The WIPs are private. Most of the people with access got it two > years ago. I used to give out access to anyone who found a new emulator bug in a public release, but that's not working so well anymore ... Eventually I'd like to get a system set up where anyone can get access, yet avoid having the WIPs leak. I really don't want to bother emu news site readers with daily WIP updates that change ~3kb of code. [No archive available] |
|
|
byuu
|
82d5761705 |
Update to bsnes v033r01? release.
Alright, new WIP. Added a new feature so people will stop _harassing_ me about it :P Try and guess what it is. [No archive available] |
|
|
byuu
|
9133129209 |
Update to bsnes v033 release.
This release adds SPC7110 emulation, without the need for graphics packs!!, and a rewritten S-RTC (real-time clock) emulator. SPC7110 support means that Far East of Eden Zero, FEoEZ: Shounen Jump Edition, Momotarou Dentetsu Happy and Super Power League 4 are now all fully playable. I will warn you, the emulation is very slow in this version -- while most areas of each game will run at the same speed as other games, there are a few peak moments where speed will drop by up to ~50%. The reason for the slow-down is that I am currently uncertain how to determine the amount of data to decompress in advance, so I default to the maximum amount possible. The reason I am releasing now anyway, is because I beleive in the "release early, release often" paradigm. It will likely take me a few weeks to finish researching this chip, and I didn't want to keep the work I had private during that time. But rest assured, bsnes v034 should feature much faster SPC7110 emulation. neviksti, Andreas Naive and jolly_codger worked non-stop on the SPC7110 decompression algorithm for the past two weeks. caitsith2 provided valuable data to the effort. I only wish that I could've been of some use, but alas, I had no role in this. In the end, it was neviksti who managed to crack all three(!!) compression modes of this chip, which turned out to be a customized 8-bit QM-coder with a prediction model. You can read more about this here. I would also like to thank Dark Force and John Weidman (aka The Dumper) for their research notes on the SPC7110 register interface. For those who don't understand the hoopla about figuring out this compression algorithm when we already had graphics pack simulation, I should note that we have since found a few errors in these packs. Not to mention, you no longer need ~4-16MB packs for each game you wish to run. They work like any other game now. Better still, the chip can now be used to compress new graphics, eg for any future translation efforts on these titles. The real-time clocks in both Far East of Eden Zero and Dai Kaijuu Monogatari 2 will now save a ".rtc" file in your save folder, which contains the clock as set by the video game, as well as a timestamp from your computer when the time was last updated. It uses the difference between the saved timestamp and current time to update the time. This allows you to specify any time you like, whereas previously bsnes would just use your computer's current time, ignoring the time you set in-game. It also allows the "round clock by 30 seconds" option in both games to work. I avoided this before because this method makes supporting daylight savings time and such impractical, although I should note that the original hardware did not support DST, either. This method was required to pass the SPC7110 tests, and is overall much more faithful to how the original chips worked. Once again, I'd really like to personally thank neviksti for his tireless efforts. Eliminating graphics packs from SNES emulation was one of my primary reasons for getting involved in the SNES emulation scene. That neviksti managed to crack this algorithm means a lot to me. Thank you so much, neviksti. This release is dedicated to you, now go get some sleep Wink |
|
|
byuu
|
7d83cde40a |
Update to bsnes v032r01? release.
This worked great, thank you. libao is now tolerable on ALSA. Now I just need to add support for disabling "Audio::Synchronize" (by disabling sound output, since libao is a blocking API.) --- EDIT: posted a new WIP, with RedDwarf's ALSA and libao fixes. Both work very well for me, your mileage may vary. No Windows binary, as it would be exactly the same as v032a, anyway. This one's mainly for Linux users who can compile from source. [No archive available] |
|
|
byuu
|
bbc77a6cf2 |
Update to bsnes v032a release.
- Windows: file open filters are now working once again
- All ports: emulation speed setting is now properly restored at startup
|
|
|
byuu
|
ebb9367c68 |
Update to bsnes v032 release.
- Core: simplified CPU / SMP flag calculations
- Added ALSA audio output driver to Linux port [Nach]
- Improved font handling for Windows and Linux ports
- Greatly cleaned up the user interface
- Windows port now uses Unicode instead of ANSI
- Added localization support
- Config and locale files can now be placed inside bsnes executable directory for single-user mode, if desired
- Fixed crashing bug with HQ2x on Linux/amd64 port [RedDwarf, Nach]
- Hid "Power Cycle" option by default, as it is too similar to "Reset"
- Slighty tweaked program icon [FitzRoy]
- Minor code cleanups -- replaced union bitfields with templates, improved memory allocation, etc
|
|
|
byuu
|
96fe8f760d |
Update to bsnes v031r08? release.
Thank you everyone for the translations! I've also posted a new WIP, with an improved Japanese locale. No changes to the strings that anyone has to worry about with theirs. To strike a compromise, I've removed power cycle from the menu by default, and added a new config file option, "advanced.enable". Set to false initially, but if you set it to true and restart, power cycle will re-appear. I intend to use this option to hide the debugger functionality if and when that gets re-added, as well. Plus we can remove other questionably useful / confusing stuff this way. The key binding for it still shows up (removing it there would be tricky), but it's not bound to anything by default, either. Sound fair? Also, something I've been meaning to do for a while now ... unload/reset/power cycle are now disabled when a cartridge is not loaded. [No archive available] |
|
|
byuu
|
8abd1b2dfe |
Update to bsnes v031r07? release.
Okay, new WIP. Couple of changes. One, I was displaying the warning message about unsupported chips no matter what. Oops, fixed. Two, removed the "Select Folder" text. The dialog looks a bit empty now, but oh well. Three, added "Ok" to the warning message box strings. Four, added "Enabled" to the cheat editor strings. You'll notice that "Disabled" is not there -- it's shared by the speed regulation setting. I know, sharing strings sucks, but that's pretty much how the localization system works, sorry. You can use something simple like "On" / "Off" in place of "Enabled" / "Disabled", if necessary. Also updated the locale.cfg file for everyone: http://byuu.cinnamonpirate.com/temp/locale.cfg [No archive available] |
|
|
byuu
|
f6efcbe6fd |
Update to bsnes v031r06? release.
Okay, I've posted a new WIP, which has a completed locale.cfg file. Well, it's completed for v032, at least. All translations are going to have to be updated for every release, sadly. For those interested in translating it, I'm looking to only have native speakers perform translations. I don't care if things aren't a perfect literal translation, so long as the general idea gets across. But I don't want anyone using machine translation tools, either. They're very unprofessional, better to wait until someone fluent comes along. Yes, I know that's ironic given my translation to Japanese: hoping someone will re-do that one. The reference locale file is here: http://byuu.cinnamonpirate.com/temp/locale.cfg Format is obviously UTF-8. Yours will need to be in this format as well. Any local encodings will fail miserably. You can see most of the options in bsnes v031 to see where they come into play. I have them mostly sorted per window. Some windows share the same string. I doubt that's going to be a problem, but we'll see. If you have access to the WIPs, be sure to get the latest one to test with. If not, and you're willing to translate the UI, feel free to PM me and I'll happily send you a link to it. I've added a "Localization by:" field to the about screen. Please feel free to add your name there. Next up, I'm trying something a bit different for the config files, and I've updated readme.txt to reflect this: bsnes will now check in the same folder as the executable for bsnes.cfg and locale.cfg. If they're found, bsnes will use these files. If they are not found, it will use your user profile folder for storage. So, if you want bsnes to run in single-user mode, just make sure bsnes.cfg and/or locale.cfg exist. If not, you can create a blank file and bsnes will use that next time you run it. If you want multi-user mode, delete the files. If you want multiple profiles, use single-user mode and multiple copies of the executable. I'll be distributing future Windows binaries with blank bsnes.cfg and locale.cfg files, so that single-user mode is the default. Just delete them to switch to the old method if you prefer. Hopefully this pleases everyone. [No archive available] |
|
|
byuu
|
36859ea52c |
Update to bsnes v031r05? release.
Well, that was certainly a pain in the ass ... Image Had to port hiro to full-on Unicode / UTF-16. But the GUI API still takes UTF-8, it's all converted internally now, bidirectionally. Oh, and don't make fun of my Japanese :P --- As for the new WIP, I've included my example locale.cfg. No other lines will translate, so don't try yet. You need to put it in the .bsnes folder next to bsnes.cfg. And don't try it unless you have Japanese fonts, obviously. [No archive available] |
|
|
byuu
|
64589148d4 |
Update to bsnes v031r04? release.
New WIP. This one adds DPI-independent font sizing for both Windows and Linux. With that, I've reduced the font size back down to "Tahoma 8" on Windows, and "Sans 8" on Linux. Because of that, I was able to reduce textbox and button height from 30 to 25, and label, checkbox and radiobox height from 20 to 18. In other words, the UI looks like it did back with v019. There's only one tiny flaw with the Linux port, I'm unable to change the font face for the listbox column header. It's not actually a widget, so it ignores my gtk_container_foreach -> gtk_widget_modify_font() calls. Any help would be greatly appreciated. I've also added FitzRoy's new icon. It seems to only have 32-bit icons, and no 256-color icons ... I guess we'll see how that looks on Win2k soon enough. Lastly, statusbar toggle was broken in the last WIP, that's fixed now. [No archive available] |
|
|
byuu
|
89ae1101ee |
Update to bsnes v031r03? release.
Another WIP. This one changes the GUI toolkit to not invoke callbacks when the API is used to set the state of widgets. With that it was really easy to get the speedreg / frameskip checks to update when using the keyboard controls. What I really need for this WIP is testing to see if any UI elements are now broken as a result of the change. For example, try and get a checkbox to not represent the actual state of something. Eg a frameskip of 2 but the checkbox is on 0. Also check startup states and that sort of thing. The UI code really needs to be cleaned up at this point ... [No archive available] |
|
|
byuu
|
340d86845a |
Update to bsnes v031r02? release.
New WIP. Please be sure to test a few games with this one to look for
regressions.
I got tired of using bit packing for CPU / SMP register flags, because
they do not mask the upper bits properly.
In other words, (assume big endian) if you have struct { uint8_t n:1,
v:1, m:1, x:1, d:1, i:1, z:1, c:1; } p; and you set p.m = 7; it will
set p.v and p.n as well. It doesn't cast the type to bool.
So I rewrote the old template struct trick, but bound it with a
reference rather than relying upon union alignment. Looks something
like this:
template<int mask>
struct CPUFlag {
uint8 &data;
inline operator bool() const { return data & mask; }
inline CPUFlag& operator=(bool i) { data = (data & ~mask) | (-i
& mask); return *this; }
CPUFlag(uint8 &data_) : data(data_) {}
};
class CPURegFlags {
public:
uint8 data;
CPUFlag<0x80> n;
CPUFlag<0x40> v;
...
CPURegFlags() : data(0), n(data), v(data), m(data), x(data),
d(data), i(data), z(data), c(data) {}
};
Surprisingly, benchmarks show this method is ~2x faster, but flags
were never a bottleneck so it won't affect bsnes' speed.
Anyway, with this, I decided to get rid of the confusing and stupid
!!() stuff all throughout the CMP and SMP opfn.cpp files. It's no
longer needed since the template assignment takes only a boolean
argument. Anything not zero becomes one with that.
So code such as this:
uint8 sSMP::op_adc(uint8 x, uint8 y) {
int16 r = x + y + regs.p.c;
regs.p.n = !!(r & 0x80);
regs.p.v = !!(~(x ^ y) & (y ^ (uint8)r) & 0x80);
regs.p.h = !!((x ^ y ^ (uint8)r) & 0x10);
regs.p.z = ((uint8)r == 0);
regs.p.c = (r > 0xff);
return r;
}
Now looks like this:
uint8 sSMP::op_adc(uint8 x, uint8 y) {
int r = x + y + regs.p.c;
regs.p.n = r & 0x80;
regs.p.v = ~(x ^ y) & (x ^ r) & 0x80;
regs.p.h = (x ^ y ^ r) & 0x10;
regs.p.z = (uint8)r == 0;
regs.p.c = r > 0xff;
return r;
}
I also took the time to figure out how the hell the overflow stuff
worked. Pretty neat stuff.
Essentially, overflow is set when you add/subtract two positive or two
negative numbers, and the result ends up with a different sign. Hence,
the sign overflowed, so your negative number is now positive, or vice
versa.
A simple way to simulate it is:
int result = (int8_t)x + (int8_t)y;
bool overflow = (result < -128 || result > 127);
But there's no reason to perform signed math, since the result can't
be used for anything else, not even any other flags, as the opcode
math is always unsigned.
So to implement it with this:
int result = (uint8_t)x + (uint8_t)y;
We just verify that both signs in x and y are the same, and that their
sign is different from the result to set overflow, eg:
bool overflow = (x & 0x80) == (y & 0x80) && (x & 0x80) != (result &
0x80);
But that's kind of slow. We can test a single bit for equality and
merge the &0x80's by using a XOR table:
0^0=0, 0^1=1, 1^0=1, 1^1=0
The trick here is that if the two bits are equal, we get 0, if they
are not equal, we get one.
So if we want to see if x&0x80 == y&0x80, we can do:
!((x ^ y) & 0x80);
... or we can simply invert the XOR result so that 1 = equal, 0 =
different, eg ~(x ^ y) & 0x80;
The latter is nice because it keeps the bit positions in-tact. Whereas
the former reduces to 1 or 0, the latter remains 0x80 or 0x00. This is
good for chaining, as I'll demonstrate below.
Do the same for the second test and we get:
bool overflow = ~(x ^ y) & 0x80 && (x ^ result) & 0x80;
We complement the former because we want to verify they are the same,
we don't for the latter because we want to verify that they have
changed.
Now we can basically use one more trick to combine the two bit masks
here. We want to return 1 when overflow is set, so we can look for a
pattern that will only return one when both the first and second tests
pass.
An AND table works great here. 0&0=0, 0&1=0, 1&0=0, 1&1=1. Only if
both are true do we end up with 1.
So this means we can AND the two results, and then mask the only bit
we care about once to get the result, eg:
bool overflow = ~(x ^ y) & (x ^ result) & 0x80;
And there we go, that's where that bizarre math trick comes from. I
realized while doing this something that bugged me in the past.
I used to think that for some reason, the S-SMP add overflow test
required x^y & y^r, whereas S-CPU add overflow used x^y & x^r.
Probably because I read the algorithm from Snes9x's sources or
something.
But that was flawed -- since addition is commutative, it doesn't
matter whether the latter is x^result or y^result. Only in subtraction
does the order matter, where you must always use x^result to test the
initial value every time.
Subtraction switches up things a little. It sets overflow only when
the signs of x and y are _different_, and when x and the result are
also different, eg:
bool overflow = (x ^ y) & (x ^ result) & 0x80;
Fun stuff, huh?
So I was wanting this tested thoroughly, just in case there was a typo
or something when updating the opfn.cpp files.
---
That said, I also polished up the UI a bit. Moved disabled to the
bottom of the speed regulation list, and added key / joypad bindings
for "exit emulator", "speed regulation increase / decrease" and
"frameskip increase / decrease".
I know these key bindings do not update the menubar radiobox positions
yet. I'll get that taken care of shortly.
[No archive available]
|
|
|
byuu
|
b895f29bed |
Update to bsnes v031r01? release.
New WIP posted. Not much to this one. - added FitzRoy's updated program icon - removed safe_free / safe_delete / safe_release template functions - replaced nearly all malloc / free calls with new / delete[] And lastly ... long ago, I used "File / Edit / Help" to conform to standard UI design. I quickly replaced Edit with Settings, and later Help with Misc. Lately, the last one has been bugging me ... "File"? File what? Why is there a reset system option under file? So, it may be somewhat controversial, but I renamed File to System, and dropped the now superfluous " System" from Reset / Power Cycle. I'd honestly like to remove "Exit" from that menu as well, but I know I'd be pushing it then. What I want to do next is move "Disabled" in speed regulation to the bottom of the list, and add key bindings to increase / decrease speed regulation. I'd like the step after fastest to be disabled. It makes sense, as fastest can never be faster than disabled, but disabled can be faster than fastest. Other nice ideas would be: a cartridge info option under the system menu somewhere, frameskip +/- key bindings, an exit emulator key binding, a new GUI panel with options to warn on reset / unload / exit, and cleaning up of the event namespace for the UI. Specifically, start working on a more advanced status panel that can display five- second alerts that override the normal output. [No archive available] |
|
|
byuu
|
1ef279cb83 |
Update to bsnes v031 release.
New release posted. Perhaps the most important change was fixing a bug in the Windows port when the keyboard was used for input. For some reason, the IsDialogMessage() function I use for tab key support was causing the main window to emit the Windows error beep every time a key was pressed after a few minutes of use. I do not know why this is, so I have simply disabled the tab key support to prevent this from happening.
Other than that, lots of polishing went into this release. UPS soft-patching will work with the recently released Der Langrisser v1.02 translation, for those curious. You can also store the UPS patches in GZ/ZIP/JMA support, and bsnes will detect this and decompress the patches first. Use the same ".ups" file extension for this, as it detects via file header.
If you wish to try out the newly added OpenGL support: start bsnes, go to Settings->Configuration->Advanced and set system.video to "wgl" (or "glx" for Linux users), and then restart the emulator. Please bear in mind that ATI's OpenGL drivers are an industry-wide joke, so I'd only recommend trying this on an nVidia or Intel video card.
Changelog:
- Fixed bug and re-enabled HDMA bus sync delays
- Emulated newly discovered IRQ timing edge case
- Optimized offset-per-tile rendering
- Added state-machine implementation of S-DSP core, ~5% speedup
- Added SPC7110 detection, will now warn that this chip is unsupported
- Fixed very annoying Windows port OS beeping noise when using keyboard for input
- Linux port will now save most recent folder when no default ROM path is selected
- Added OpenGL rendering support to Windows port [krom]
- Fixed Direct3D pixel mode scaling bug [krom, sinamas, VG]
- Improved SNES controller graphic [FitzRoy]
- Added UPS (not IPS) soft-patching support; UPS patch must be made against unheadered ROM
- As always, cleaned up source code a bit
|
|
|
byuu
|
0241dd78b7 |
Update to bsnes v030r08? release.
New WIP posted, which adds the immediate-mode opcode IRQ delay findings from this past week. Doesn't have any visible effects on anything. I also went back to a switch table for the CPU / SMP opcodes instead of the jump table. Shaves ~100kb off the object files and compiles faster with no speed loss. I used the jump table before to simplify PGO, but since that's been broken for at least a year now anyway ... Fes, thanks for the temporary workaround. I'll try and get a new release out this weekend if possible. I'd like to have UPS soft- patching in before the next release, though, hence the delay. [No archive available] |
|
|
byuu
|
a13c3aece6 |
Update to bsnes v030r07? release.
New WIP. Direct3D driver: removed diffuse color vertex information, and made driver re-initialize whenever window size changes. Should fix ATI resize in pixel scale mode bug once and for all. Confirmation would be appreciated. Speed will still be bad on some cards that can't handle large textures, and I don't really want to implement StretchRect() profiling, so that's still an issue. Windows/hiro: disabled IsDialogMessage(). This will prevent the tab key from working in the configuration panel, but will also stop the main window from beeping every time you push a key -- the lesser of two evils. Blame Microsoft for this bullshit. IsDialogMessage() should empty the key buffer, but it doesn't when there are no tabbed controls on a window. I'll rig something up in the future for this. Linux/hiro: GTK+ file open / file save / folder select dialogs will now save the path if you selected a valid file, so that next time you will start in that folder. This didn't matter if you set hard-coded paths in bsnes, but it makes a positive difference if you did not. [No archive available] |
|
|
byuu
|
20977817ae |
Update to bsnes v030r06? release.
New WIP up. This one fixes HDMA bus sync timing. I verified this was correct per hardware with the HDMA test sync ROM. It was definitely wrong before. Secret of Mana, Street Racer and Jumbo Ozaki no Hole in One all work. Yes, they worked in the official v030 release, but that release had HDMA sync disabled and rounded. Mecarobot is improved greatly, but still flickers when the golf course is moving. If you're as desperate as I am to play this amazing masterpiece _right now_, you can always hex edit the ROM and change offset 0x1c6f from 0x40 to 0x80 :) I'm still investigating that issue more before I start running hardware tests. I want to rule out things that can't be the cause of the bug first. I've also added (hopefully) proper SPC7110 detection. If anyone wants to test all of them to make sure it works, great. It should give you a popup now saying that it's unsupported. Down to just needing ST-011 detection now. [No archive available] |
|
|
byuu
|
ba25c82939 |
Update to bsnes v030r05? release.
New WIP posted, which adds: - krom's Direct3D fix; point mode at multiples of 3x and higher without aspect ratio correction is no longer blurry - FitzRoy's updated SNES controller graphic - glX improvement for Linux, window will clear to black on startup for ATI cards now too, but it still doesn't redraw when the window is damaged because I can't trap the exposure events - tiny clarification to S-DSP emulator source (use echo_hist_pos enum instead of just "8") - started to add SPC7110 _detection_ for the sole purpose of advising that the chip isn't supported. Not finished yet. Also need to fix ST-011 detection while I'm at it (it's detected as ST-010 now; they share ROM type and mapper IDs), and all special chip games should be covered. - re-added the slightly incorrect HDMA sync timing. It helps (but doesn't fix) Mecarobot, it breaks the SoM intro again; but Street Racer and Jumbo Ozaki are still working right -- looks like other timing improvements since then were enough for those titles For those asking for WIP access, I'm really sorry but I have way too many testers now. It's extremely hard for me to even keep track anymore. I just don't have the bandwidth. If you absolutely need a specific WIP, I'll stick it on a file sharing site or something for you. Otherwise, my apologies for not sending you the link. I absolutely do appreciate the offers to help beta test, though. [No archive available] |
|
|
byuu
|
3babe932fd |
Update to bsnes v030r04? release.
One thing we can always do is add some platform-specific profiling code. Have bsnes try and determine what the fastest driver is upon first run. As if I don't have enough to do already, heh. New WIP, which converts the S-DSP ring buffers to an internal class object. Surprisingly, it actually does make the code a bit nicer to look at, although it's kind of unfortunate I can't hijack operator[]=, heh. I'd be forced to use modulus for that. Even more surprising, it's about ~2% faster than before. Even though it's technically even more complex now with three writes instead of two. Makes no sense at all, but I won't complain. Getting 122fps now on Zelda 3 load screen. --- ATI Radeon X300LS: Direct3D = 64fps OpenGL = 24(!!)fps ... as if we needed _another_ reason not to buy ATI products. What the hell was AMD thinking, buying them? Better yet, why do people buy ATI products? Laptops, I can understand. But for desktops?? Seriously. That performance is so terrible, you couldn't even play OpenGL games with that. We really need more OGL titles to rape ATI on benchmark tests, so that they'll get their heads out of their asses. [No archive available] |
|
|
byuu
|
6bdeaef0f4 |
Update to bsnes v030r03 release.
v030 wip3 posted. This one add's krom's ruby changes, meaning Windows OpenGL support. For consistency, I changed the Windows system.video setting to "wgl", and Linux OpenGL to "glx". Linux users should be sure to update that to avoid SDL video output. I get ~119fps with OpenGL, and ~120fps with Direct3D. I'd appreciate if everyone else would test OpenGL support. If it works everywhere that D3D works, and avoids that texture size slowdown issue, then we should make it the default driver. The only issue I see with the driver now is that vsync is enabled no matter what. You can turn it off in eg the nVidia control panel by overriding the setting. I also recommend enabling triple buffering. With that, video is perfectly smooth and audio is ~99.5% perfect. So, so close. A slight cpu.freq change and you can probably get it perfect. God, it's so nice having perfect video and audio. I really wish that worked across the board. It's absolute euphoria playing games like that. [No archive available] |
|
|
byuu
|
9e3827e2a2 |
Update to bsnes v030 release.
I didn't want to release a new version so soon, however there is a rather serious bug in bsnes v029 where the path information for the save RAM files is discarded when one has not selected a default save RAM / cheat path from the path settings tab in the configuration settings window. Because of this, it gets stored to the base directory. For Windows users, this is c:\, and for Linux users, this is / This bug forced my hand, so I'm releasing v030 to correct this issue. I also cleaned up the S-DSP emulation code to be more consistent with my programming style -- it gets bit-perfect matches to v029's wave output, so I don't foresee there being any problems. |
|
|
byuu
|
e499670ad9 |
Update to bsnes dsp release.
Okay, it's just blargg's. I hope he doesn't mind ...
I rewrote his S-DSP emulator in pure C++. Only took me seven hours,
not bad. anomie's took a few days.
Now, given, it's extremely similar of course. First, the algorithms
are going to be mostly the same regardless of who writes the code.
Second, I really didn't see a reason to waste too much time on this
reverse engineering a bunch of stuff myself, so I pretty much just
took the code and "rewrote" (read: copied) it in my unique style, and
changed a few things here and there. Code flow, variable names,
tables, exact algorithms, etc were blatant, direct copies.
Things I did change:
- counter rate 0 is now hardcoded to not ever hit zero
- counter read is now boolean instead of unsigned short
- a lot of multiplication was converted to shifts
- broke up the program into ~9 source files
- no more global functions anywhere, all in one class
- removed the hooks for things like external channel muting -- will
re-add if I ever add an option like that to bsnes
- modified VREG to not need the voice regs handle passed to it
- all voice functions take a reference instead of pointer to the voice
structs now
- packed 32-line timing table expanded to multi-line
- left everything in their own small chunk functions ... kind of torn
on whether I want to merge that with the main timing function. I like
the encapsulation, but it would remove the need to keep so many
struct-based state variables
- added a few more comments on parts that confused me at first
- removed assignment inside conditional stuff; even though I do that
myself on occasion in other code I write, heh
- yadda yadda, more minor stuff like that
Going to keep working at it -- wanted to get it working now, so that
finding regressions will be easier. I want to remove the double writes
for the ring buffer, make a decision on whether I want to rely on sign
extension, or use sclip<> for that, implement a compile-time option to
bypass libco (will save 2.048 million co_switch calls a second) since
the S-DSP's entire operation fits into a single switch table quite
easily, convert a lot of the mul / div stuff to shifts, convert those
clever split up branches in the envelope and BRR decoding routines to
switch / case tables, remove the shift tables from the BRR decoding,
and try and figure out what's going on with some of the code so that I
can try and document it :)
I'll see if I can contribute something back, too. Perhaps I can look
into what happens when you enable mute or something.
New WIP up which has the new core enabled by default. For those
without WIP access, I've posted the new source for reference. Comments
welcome.
byuu.org/files/bsnes_dsp.zip
... man, feels weird posting a new topic.
[No archive available]
|
|
|
byuu
|
805398e5a8 |
Update to bsnes v029 release.
A new version of bsnes has been released. It contains a few minor emulation fixes, as well as user interface improvements. Behind the scenes, the source has been cleaned up more in preparation for running the CPU and PPU (video processor) separately from each other (eg with no enslavement.) This is required for implementing a clock cycle based PPU renderer.
- Greatly improved invalid DMA transfer behavior, should be nearly perfect now
- Major code cleanup -- most importantly, almost all PPU timing-related settings moved back to PPU, from CPU
- Added option to auto-detect file type by inspecting file headers rather than file extensions
- Rewrote video filter system to move it out of the emulation core -- HQ2x and Scale2x will work even in hires and interlace modes now, 50% scanline filter added
- Re-added bsnes window icon
- Added new controller graphic when assigning joypad keys [FitzRoy]
- Redundant "Advanced" panel settings which can be configured via the GUI are no longer displayed
- Improved speed regulation settings
- XP and Vista themes will now apply to bsnes controls
- Added "Path Settings" window to allow easy selection of default file directories
- Tab key now mostly works throughout most of the GUI (needs improvement)
- Main window will no longer disappear when setting a video multipler which results in a window size larger than the current desktop resolution
- Added two new advanced options: one to control GUI window opacity, and one to adjust the statusbar text
|
|
|
byuu
|
7e6e3e3a69 |
Update to bsnes v028r16? release.
Lots of talking. As I've said many times before, I typically don't like working on fan translations. The programmers are almost always far less skilled than professional developers, and they almost always test on emulators rather than hardware. I may look into this when I'm feeling particularly bored, though I don't know how you could have possibly picked a worse game for me to be caught debugging at work. Well, maybe those "Adult Manga" PD ROMs ... EDIT: New WIP. This one adds IsDialogMessage() support. It isn't perfect, the test apps get the highlighted dots around the active controls, but bsnes isn't for some reason. Don't know why that is yet. And it seems once tab enters into a child window, you can't get back to the outer window. But otherwise, it's better than nothing. I even got the z-order thing down so tab works in the right direction. [No archive available] |
|
|
byuu
|
16ba1d1191 |
Update to bsnes v028r15? release.
Thanks, FitzRoy. The controller graphic looks really amazing. I have
two very minor changes to request if you don't mind.
First, I had to increase the size to 372x178 (Windows BMP format adds
alignment if width is not a multiple of 4 -- this makes it a real
bitch to convert the image to my UI wrapper pixel format), and shift
the actual image one pixel left to center the gradient fade.
Second, and more importantly, could you store the controller graphic
in 32-bit format with alpha? Rather than using a white or gray
background, if I could get the full alpha channel information, then I
can adjust the background color to anything I like in the future.
Depending on how it looks, maybe I can just let the controller blend
against the window background itself.
And thank you, King of Chaos, as well. It was extremely difficult to
choose one over the other. I wish I could use just both so as not to
offend anyone. But I kind of like FItzRoy's more. I was kind of going
for that pristine, "cleaner than real life" look. Still, I really
appreciate your help in making a controller graphic.
---
New WIP.
I've added FitzRoy's controller graphic to the input capture window.
It will only display when configuring joypad buttons, not when
configuring UI buttons.
I've also added the new UI settings panel. This lets you control
window translucency for all but the main bsnes window. I capped
opacity to 50% minimum, because I don't want to hear bug reports when
people slide it to 0% and can't find the config window anymore :P
Works on Windows and Linux. If you lack a compositor on Linux, it'll
just stay a solid color. If you have Compiz / Beryl and the blur
filter, use it with gaussian alpha blur. Then you can set opacity all
the way down to 50% and it will still look amazing. I want to post a
screenshot of it, but the image is ~3MB. Maybe later I'll post it to
one of those file hosting sites.
There's also a setting here to control what gets written to the
statusbar. I went back to just displaying the raw ROM title. So you
can use %t for that, %n for the filename, and %f for the frame rate.
Still working on this feature. Plan to keep the game name visible when
pausing, add some additional info that can be output here, etc. It may
be better to keep this setting in the advanced panel, as it's not the
most user friendly thing in the world. Up to you guys, I guess.
Need more settings here, though. Need to fill out that
window more.
[No archive available]
|
|
|
byuu
|
29c871ef62 |
Update to bsnes v028r14? release.
New WIP. Adds Win2k alpha adjust (against black background), some
minor code cleanups, LZSS compression / decompression for storing
graphics, and puts the program icon onto the about screen, which has
been shrunk down a bit again.
So, too late mudlord, the answer was LZSS :P
I wanted to just go with RLE for simplicity, but the compression
ratio sucked. LZSS is the same number of lines of code, yet is three
times more efficient with the icon. And something like a controller
with much more repetition will probably make an even bigger
difference. Meh, the code's easy enough. I wrote it for clarity over
speed, and decompression is always lightning fast with LZ anyway.
Good job decoding the base64 portion, though. Very useful
routine for a library.
As for the controller graphics, wow ... I'm really torn. I really
love how clean FitzRoy's version looks, yet at the same time King of
Chaos' version is so lifelike it's scary. I dislike the "flaws",
though. The scratches on the X, the dot on the bottom right, and the
off-center buttons ... since it's digital anyway, I'd prefer it to
appear perfect, if at all possible.
But it's a tough call. I'll have to hold a vote or
something :)
Thanks a million for helping with the controller graphic,
both of you!
[No archive available]
|
|
|
byuu
|
42f1d08c02 |
Update to bsnes v028r13? release.
New WIP.
Adds a base64 encoder, which zaps the ~21kb icon down to ~5kb. With
the extra space, I used the 48x48 icon instead. It should look a tiny
bit better, but it still obviously can't beat a non-resampled icon.
Also added Linux icon support. That turned out to be a royal pain, as
the gdk-pixbuf library documentation was separate from the GDK
documentation. Tried finding visuals, to make colormaps, to get GCs,
to create pixmaps to blit onto as drawables, to create pixbufs with,
to attach to the window. Turns out, gdk-pixbuf has a function to turn
raw data into a pixbuf.
> Could we have an option to disable this effect in advanced settings
> so that the mode can appear "crisp" as it does in other emulators?
This blurring is required for pseudo-hires to operate
properly, eg in Jurassic Park.
Nonetheless, if you guys really want the option to disable the
blurring, I can add it. Just keep in mind that we're opening up a can
of worms. People will then want an option to disable the sprite
drawing limit, to add hi-res mode7, etc etc. Harder to draw a line in
the sand when you aren't all or nothing.
> This is a problem? If it's a question of storing them all in an ico,
> why not simply say "Here's a nicer ico set seperately, DL if you
> want'.
I'm not going to put resources external to the executable, unless I
absolutely have to. Thus, I have to put all of these icons inside the
source code, and I have to modify the GUI API wrapper to handle this.
> I was thinking, you know, one of you could report it to them.
"Hi, uh, Microsoft? Yeah, your compiler is erroring out
when I compile my emulator with it and PGO enabled."
"Sure, as that's a $12,000 Team Suite Edition feature,
if I could just get your serial number, that'd be great."
"Oh, uh ... I think I left that at home. I'll call you
right back with it, okay?"
"Oh, no problem. If I can just get your full name, I'll
pull you up in our system ... ... hello? Sir?"
::dial tone::
And for the _official_ legal record, I only used the
free trial and express editions :)
> Yeah, one issue they can fix is maybe implement blargg's spc core;
> then again, I thought Snes9x was dead.
Not dead, but on severe life support. Same for SNEeSe and Super
Sleuth. anomie, TRAC and Overload have minimal presence anymore. A
damn shame. The SNES scene is in worse shape than most people realize
at the moment. NES emulators have had dot-based PPU renderers for
years now.
[No archive available]
|
|
|
byuu
|
521f4f6952 |
Update to bsnes v028r12? release.
New WIP.
vcounter / hclock / hcounter renamed to vcounter / hcounter / hdot. I
think it's more clear this way. Fixed up the v/hc stuff to v/h in
bppu_mmio.cpp to match.
Instead of building each driver for ruby independently, I grouped
them all together into one object file. I know everyone else hates
that, but too bad -- that's the way I program. No sense building ~10
object files when one will do just as well. I was able to cut out ~20
lines from the Makefile as a result of this.
I added CB_SETITEMHEIGHT magic to actually set combo box to requested
height. Neat. Of course, bsnes doesn't currently use any combo boxes
in the UI, but it'll be nice when it does, at least.
Lastly, I added something new to the Windows port (that
used to be there a long time ago), just for FitzRoy :P
I'll go over that in more detail tomorrow. For now,
consider it a surprise.
[No archive available]
|
|
|
byuu
|
92cfb1268a |
Update to bsnes v028r11? release.
New WIP up.
I was a little too busy to work on bsnes this weekend,
but I got some work done tonight.
First, I moved the field / interlace / overscan status
functions over to the PPU, where they belong.
This led me to kill a lot of extra CPU timing variables, such as
vblstart and vnmi_trigger_pos. The latter I had to kill because I can
no longer call sCPU::update_interrupts() when the PPU changes the
overscan setting. You may be wondering about interlace toggle -- well,
it can only take effect at the start of a new frame anyway, and the
timing for scanline 0 is the same regardless of interlace setting, so
it doesn't really need to call update_interrupts() anyway.
With this moved back to the PPU, I was able to clean up the PPU
functions a bit, too. Before, I had PPU::scanline_is_hires() and
CPU::interlace(), and then a function called PPU::get_scanline_info()
that would read the previous two functions and copy them into a
struct. What an odd construct, I'm sure it was more complex in the
past. Cruft, basically. I just killed that, renamed scanline_is_hires
to just hires, and now SNES::Video just queries ppu.hires() and
ppu.interlace() directly. Much nicer.
I didn't lose any speed here, either. I made up the difference by
force inlining the PPU states in the bPPU header file.
I ran all my IRQ and NMI tests again, I didn't see any regressions.
Testing of games that use interlace and overscan, as well as of IRQ-
sensitive games, would be appreciated.
While cleaning up the PPU, I had some code that would flush the PPU
buffer when disabling interlace. I removed that as it looked rather
ugly. Don't really have a clean way of handling that. Not like any
game out there toggles interlace every frame anyway.
I went through and killed a bunch of config file options that don't
actually do anything anymore, such as audio.frequency and
video.use_vram.
Lastly, I rewrote the advanced panel code finally. All options that
can be controlled through the UI have been removed. The list is ~80%
smaller now. I also improved a lot of the descriptions. I think it
looks a lot better now, at least. I went with a blacklist, rather than
whitelist. I figure, better to have extra options if I forget to
filter them out; than to have missing options if I forget to add them.
Before the next release, I'd like to add back default_height() stuff
to get the textboxes and buttons smaller on the Windows port. Maybe
revert that back to Tahoma 8. I should also add descriptions to the
last few advanced panel options missing them. Other than that -- just
regression testing, I suppose. I can't break up the PPU enslavement
any more without adversely affecting performance at this point.
Hmm, would also be nice to rename vcounter / hclock / hcounter to
vcounter / hcounter / hdot. Afraid of missing a reference somewhere
and screwing up the timing, heh.
I tried to get the icon working again on the Windows port. But using
LoadImage or CreateIconIndirect doesn't handle the alpha level of
bsnes' icon properly. It ends up as a 1-bit transparency that looks
terrible in the titlebar, as well as the taskbar. The only way I can
get it to look good is with LoadIcon and grabbing the icon from the
resource file. The reason I don't want to do this is because it's not
at all portable to GTK+. Sigh. Tested this on Win2k, by the way. Win2k
isn't supposed to support the alpha channel in icons at all, but it
sure the hell does on the taskbar.
I even tried GetIconInfo() on the icon returned from LoadIcon(), and
then CreateIconIndirect on that, and it crushes the translucency
again. So it isn't a problem with the format of hbmMask and hbmColor
in my ICONINFO struct.
[No archive available]
|
|
|
byuu
|
4d922ba17c |
Update to bsnes v028r10? release.
New WIP.
This one nukes the region, region_scanlines, prev_line_clocks and
prev_field_lines variables, and removes timeshift.cpp; replaced with
the new history ring buffer. It doesn't appear to affect speed at all,
which is fine by me. Next up, I want to move interlace and overscan
settings back to the PPU.
All of my NMI and IRQ test ROMs, even the absolutely insane clock-
perfect ones, still pass. So there shouldn't be any regressions. But
if you feel like testing any IRQ sensitive games, that's cool.
More visibly, I've bound the .cht path to the selection in the path
settings window. So all three paths actually work now. I tested it by
sorting all of my images by ROM, SRAM and Cheat ... have to say, the
folder looks a whole hell of a lot nicer now. I can see why this
feature is so popular.
> Mainly, there needs to be mechanisms to capture the current frames,
> like through render targets.
Well, I guess if you don't mind writing up a small
example I could work on porting the current code over.
[No archive available]
|