I apologize, bsnes v066 had a small error in the source that resulted in the PPU not synchronizing properly to the CPU. This bug was not exposed in the images I use to test releases. I have also updated the cheat code database, which is maintained by mightymo.
Major features in this release are: serial controller emulation, a brand new scheduler that supports multiple simultaneous coprocessors, and accuracy improvements.
The serial controller is something devised by blargg. With the proper voltage adjustments (5v-9v), it is possible to wire an SNES controller to a serial port, which can then be used for bidirectional communication between the SNES, and (usually, but not only) a PC. The support in bsnes was added so that such programs could be debugged and ran from within an emulator, and not just on real hardware.
The scheduler rewrite was meant to allow the combination of coprocessors. It was specifically meant to allow the serial controller thread to run alongside the SuperFX and SA-1 coprocessor threads, but it also allows fun things like MSU1 support in SuperFX and SA-1 games, and even creating dev cartridges that utilize both the SuperFX and SA-1 at the same time. The one thing not yet allowed is running multiple instances of the exact same coprocessor at the same time, as this is due to design constraints favoring code inlining.
There are two important accuracy updates. The first is that when PAL video mode is used without being in overscan mode, black bars are shown. Emulators have always shown this black bar at the bottom of the screen, but this is actually incorrect. resxto took pictures from his PAL TV that shows the image is in fact vertically centered in the screen. bsnes has been updated to reflect this.
Also interesting is that I have backported some code from the dot-based PPU renderer. In the game Uniracers, it writes to OAM during Hblank, and expects the write to go to a specific address. In previous releases, that address was hard-coded to go to the required memory location. But the way the hardware really works is that the write goes to the extended attribute address for the last sprite that the PPU fetched, as the PPU is still asserting the OAM address bus. Now, due to the precision limitations, I was not able to also port timing access during the active display period. However, this is sufficient to at least remove the last global hack from the older, speed-focused scanline renderer.
Fairly major changes here, I'd appreciate some testing if anyone's not
busy. Note that the save state version has been bumped, so consider
WIP saves unstable until v066 official.
Rewrote the entire scheduling system. Instead of having a global class
that all of the chips call into, each class now contains its own
thread, clock and frequency information. They also implement their own
syncing primitives, but with a tiny bit of standardization.
void step(unsigned clocks) -- add to/subtract from counter based on
master/slave select.
void synchronize_chip() -- make sure chip is caught up to our current
thread before continuing.
So we go from scheduler.sync_copcpu() to sa1.synchronize_cpu(); with
the sa1. being omitted inside the SA1 class itself.
The S-CPU implementation also adds an array<Processor*> coprocessors;
list, and iterates them all. This allows bsnes to have an infinite
number of additional coprocessors at the same time. But there is still
the limitation of only one of each type. So you can use the XML memory
mapping to make a cartridge that contains a SuperFX2 chip, an SA-1
chip, an MSU1 chip and that can be debugged via serial communications.
However, you can't make a cart that has two SA-1 chips. That
limitation probably could be overcome as well, but it's less
important. I mainly wanted to be able to use MSU1 and Serial on
special chip games.
I implemented the synchronization primitives in the chip base classes,
which means that for inlining purposes I had to make it all global, so
you'll have src/cpu/synchronization.hpp, etc now. This was to reduce
some redundancy of having the same exact code inside both bPPU and
sPPU, etc. I'll probably make a Coprocessor : Processor class to
automatically implement the step+synchronize_cpu functions for the
five coprocessors next.
The Scheduler class is actually still around, but it's very trivial
now. It simply saves the program thread and last active emulation
thread for the purpose of entering and exiting emulation. Because I
killed Scheduler::init(), which was responsible for destroying and re-
creating threads, I had to create the threads inside
ChipName::create(), which I call at power and reset. This means that
to load a save state, the system needs to be reset to destroy those
threads.
This caused some troubles with the SA-1, specifically in Kirby's
Dreamland 3, but no other games I tried. I had to move the SA-1 bus
initialization to the power-on event, and only reset when loading a
save state. It would appear that the SA-1 is leaking bus mapping state
information, presumably from the SA-1 MMIO registers that control some
of the mapping layout. If I add remapping of those sections into the
SA1::serialize() function, it should take care of that problem and I
can move sa1bus.init() back into SA1::reset().
All of this results in a 2-3% speed hit for normal games, and a 6-7%
speed hit for special chip games. The former should not have any speed
hit, so I will have to look into what's going on there. The latter we
have no choice on, to allow for more than one coprocessor, the
coprocessor synchronization needs to iterate a list, compared to a
single hard-coded check in the previous builds. If I can figure out
what is happening with the regular game speeds, it should drop the
special chip hit to 4%. Worst part is this hit is in addition to the
10-15% speed hit from v065 official where I wasn't syncing the special
chips up to the CPU except once per scanline and on MMIO accesses.
But that's progress. v065 is definitely going to be the preferred
build for playing SuperFX/SA-1 games for a long time to come.
Only posting because the link changed, it's the exact same as r03.
Only difference is some improvements to nall:
- string class gains lower(), upper(), transform(), *trim(_once)
- file::print now accepts variadic arguments like print
Examples:
strtr(item, "ABCDEF", "abcdef"); -> item.transform("ABCDEF",
"abcdef");
strlower(item); -> item.lower();
fp.print(string("Age: ", age, "\n")); -> fp.print("Age: ", age,
"\n");
Polishing work. My dlopen wrapper accepts an optional path argument
now, and the basename setting is universal instead of just for MSU1,
so serial-based games can load in a dynamic client library directly.
Still need to update snesserver to accept another argument for the
program library name to load.
Upped the serial polling frequency to 8x UART speed per blargg.
And a very tricky change, I updated nall/string to remove sprint(). At
first, I used:
string name = string() << path << basename << ".msu";
I then improved upon that with:
string name = sprint(path, basename, ".msu");
Tonight I went ahead and finished this by taking advantage of variadic
templates for the constructor itself. Very tricky because my
conversion functions created new strings to copy data into, which
would create an infinite loop; then of course I also had to leave the
copy constructor behind even after this. So the end result is the
following:
string name(path, basename, ".msu");
Oh, and I found a typo in MSU1, it wasn't using the proper extension
when loading a save state for the data file.
Be warned, this is going to get complicated.
To start out with, serial.tar.bz2 is a simple SNES program that is
right now being used for integrity testing. The important part is
here:
serial_read:
lda #$01
-; bit $4017; bne -
-; bit $4017; beq -
nop #24
pha; lda $4017; eor #$01; ror; pla; ror; nop #18
pha; lda $4017; eor #$01; ror; pla; ror; nop #18
pha; lda $4017; eor #$01; ror; pla; ror; nop #18
pha; lda $4017; eor #$01; ror; pla; ror; nop #18
pha; lda $4017; eor #$01; ror; pla; ror; nop #18
pha; lda $4017; eor #$01; ror; pla; ror; nop #18
pha; lda $4017; eor #$01; ror; pla; ror; nop #18
pha; lda $4017; eor #$01; ror; pla; ror; rts
serial_write:
pha #6; pla #6; wdm #$00; stz $4016; sec
pha #6; pla #6; wdm #$00; sta $4016; ror
pha #6; pla #6; wdm #$00; sta $4016; ror
pha #6; pla #6; wdm #$00; sta $4016; ror
pha #6; pla #6; wdm #$00; sta $4016; ror
pha #6; pla #6; wdm #$00; sta $4016; ror
pha #6; pla #6; wdm #$00; sta $4016; ror
pha #6; pla #6; wdm #$00; sta $4016; ror
pha #6; pla #6; wdm #$00; sta $4016; ror
pha #6; pla #6; wdm #$00; sta $4016; rts
Fairly ugly, but it works.
Next, I needed a way to be able to execute the client in such a way
that it would work with both bsnes and real hardware, with no
recompilation or changes needed. The nice way would be some form of
inter-process communication, but well, I don't really do that. And
it's probably extremely platform-dependent.
So I used what was available to me already, a cross-platform dlopen
wrapper for dynamic library support. The client application is written
and compiled into a shared library that exports a single function,
snesserial_main, which runs as if it is its own program and never
returns. It takes three parameters, the time tick(), read() and
write() function pointers. It can call them to do its work. This
process is put in a folder called snesserial for now. It's the
accompanying program to serial.sfc.
Now I have both bsnes (v065.02 above) and snesserver, they both act
the same way. They load in snesserial, and give it those three
functions and call its main entry point. The difference is that the
read/write functions in bsnes simulate a serial strobe to the
emulator, and the read/write functions in snesserver actually read and
write to the TTY device you specify as the program argument, eg for me
I use: ./snesserver /dev/ttyUSB0
Mmm, USB<>SNES for the win.
There's a limitation in my dlopen wrapper, it adds the libN.so or
N.dll stuff automatically, making it difficult to also specify a path.
That means that for now you have to put libsnesserial.so into
/usr/local/lib. Obviously you don't want to be limited to just one
program. The plan is to have it load the library that matches the game
name:
zelda.sfc + zelda.so/zelda.dll/zelda.dylib (yeah, no libzelda.so.)
Now, the bsnes+serial emulation works on any platform. However,
snesserver only works on Linux. You can blame that one on Microsoft.
They make you require special kernel drivers to be able to access the
serial port. I'm not going through the trouble. OS X can probably use
it if it makes the appropriate /dev/tty device, but I'm not going to
test it.
Activating the module can only be done with a custom XML file, as
before. Still need to work on integration with the controller port
options, as it's not really a special chip.
Lastly, the timing is "pretty good", but not perfect. It accepted a
374 cycle-per-bit loop for serial writes from the SNES to the PC, but
snesserver did not. I had to adjust to 364 cycle-per-bit loop for it
to work on both.
This is really bad, because the goal here is to use the PC as the
testbed to make sure it'll work on the real thing. On the plus side,
you only have to get it working one time, and stick with the
serial_read/serial_write functions like at the top of this post. But I
do need to address this. I'm not entirely sure how to more accurately
simulate a serial port at this point though.
Oh, and I am thinking I need to expand the read/write functions to
process more than one byte at a time. That should greatly speed up
transfer time on the real thing. I also need to add some slowdown so
the emulator more closely matches hardware speeds.
In order to fully decode the 16MB address maps, I am going to need to
use blargg's stop-and-swap, which will require a serial-communications
program. To develop this program, and others in the future, as well as
for testing automation, it would be very beneficial to have a way to
debug these programs through bsnes.
So what I'm working on now is emulating a serial port inside bsnes.
The basic premise is to start with a custom XML map that specifies its
presence:
<?xml version="1.0" encoding="UTF-8"?>
<cartridge region="NTSC">
<rom>
<map mode="linear" address="00-7f:8000-ffff"/>
<map mode="linear" address="80-ff:8000-ffff"/>
</rom>
<ram size="2000">
<map mode="linear" address="70-7f:0000-7fff"/>
</ram>
<serial baud="57600">
</serial>
</cartridge>
I am essentially treating the serial communication as a special chip.
One could argue this belongs as an option under controllers, and one
would be right. But as I can't have two coprocessor threads at the
same time, this is how it is for right now. Eventually it'll probably
be under controller port 2, and only enabled in the debugger builds.
So, this pseudo-coprocessor ... it's basically emulating the PC-side
communications program.
Meaning I still need to externalize this somehow so that any program
can be run.
The below program writes 0x96 six times, and then reads in data six
times. Well, technically forever, but the SNES ROM only writes six
times at the end.
void Serial::enter() {
scheduler.clock.cop_freq = cartridge.serial_baud_rate() * 2;
latch = 0;
add_clocks(512);
for(unsigned i = 0; i < 6; i++) {
latch = 1; add_clocks(2);
latch = 1; add_clocks(2);
latch = 0; add_clocks(2);
latch = 0; add_clocks(2);
latch = 1; add_clocks(2);
latch = 0; add_clocks(2);
latch = 1; add_clocks(2);
latch = 1; add_clocks(2);
latch = 0; add_clocks(2);
latch = 0; add_clocks(2);
}
while(true) {
while(cpu.joylatch() == 0) add_clocks(1);
while(cpu.joylatch() == 1) add_clocks(1);
add_clocks(1);
uint8 data = 0;
for(unsigned i = 0; i < 8; i++) {
add_clocks(2);
data = (data << 1) | cpu.joylatch();
}
print("Read ", strhex<2>(data), "\n");
}
}
The SNES code looks like this:
//21,477,272hz cpu / 57,600hz serial = ~372.87 clocks/tick
org $8000
xce; rep #$10
ldx #$01ff; txs
jsr serial_read; sta $700000
jsr serial_read; sta $700001
jsr serial_read; sta $700002
jsr serial_read; sta $700003
jsr serial_read; sta $700004
jsr serial_read; sta $700005
nop #46
jsr serial_write
jsr serial_write
jsr serial_write
jsr serial_write
jsr serial_write
jsr serial_write
//hang
-; bra -
serial_read:
-; lda $4017; and #$01; bne -
-; lda $4017; and #$01; beq -
nop #23; lda $00; nop #10
lda $4017; and #$01; asl $00; ora $00; sta $00; lda $00; nop #13
lda $4017; and #$01; asl $00; ora $00; sta $00; lda $00; nop #13
lda $4017; and #$01; asl $00; ora $00; sta $00; lda $00; nop #13
lda $4017; and #$01; asl $00; ora $00; sta $00; lda $00; nop #13
lda $4017; and #$01; asl $00; ora $00; sta $00; lda $00; nop #13
lda $4017; and #$01; asl $00; ora $00; sta $00; lda $00; nop #13
lda $4017; and #$01; asl $00; ora $00; sta $00; lda $00; nop #13
lda $4017; and #$01; asl $00; ora $00; sta $00; lda $00; nop #13
rts
serial_write:
lda #$01; sta $4016; nop #23
lda #$00; sta $4016; nop #23
lda #$01; sta $4016; nop #23
lda #$00; sta $4016; nop #23
lda #$00; sta $4016; nop #23
lda #$01; sta $4016; nop #23
lda #$00; sta $4016; nop #23
lda #$01; sta $4016; nop #23
lda #$01; sta $4016; nop #23
lda #$00; sta $4016; nop #23
lda #$01; sta $4016; nop #23
rts
That reads six times, and then writes six times.
I haven't made the test do an infinite PC->SNES transfer, but I have
for SNES->PC. No errors after millions of bytes, even if I stride the
CPU timing.
As this is just an example, it's pretty lousy with actual timing, but
I guess that's a good thing as it still works quite well. More
tolerance = less potential for errors.
**Now, this part is important.**
While debugging this, I noticed that my serial coprocessor was only
running when Vcounter=n,Hcounter=0. In other words, nothing was making
the CPU synchronize back to the coprocessor, except the once-per-
scanline synchronization that was there in case of CPU stalls.
That's ... really bad. MSU1 worked only because it buffers a few
hundred samples for audio mixing. I don't really know why this didn't
cause an issue for SuperFX, SA-1 or Super Game Boy games; but in
theory they were at most 682x less precise than they should have been
in terms of CPU->coprocessor synchronization.
Making it sync after every add_clocks() call results in a 10% speed
hit to SuperFX, SA-1 and Super Game Boy emulation, unfortunately.
I don't notice any quality improvements in emulation, but in theory
the lack of this syncing before effectively eliminated the benefits of
the SuperFX and SA-1 being cycle based.
I'm going to have to look into this more to understand if I was
intentionally not doing this sync before, or if I really did forget
it. I'm thinking it was an oversight right now. The SuperFX and SA-1
don't really talk back and forth a whole hell of a lot, so once a
scanline probably wouldn't be that noticeable.
But holy hell ... now that I'm thinking about it, I wonder if this was
the cause of all that craziness in trying to sync up the Super Game
Boy's VRAM transfers. Yeah, definitely need to look into this more ...
It's been a while, so here is a new release of bsnes.
Unfortunately I don't have a full changelog this time. Most of the work went into stabilizing libsnes (which is used by the experimental .NET, Cocoa and Python UIs; as well as by Richard Bannister's OS X port).
The Windows binary package now comes with all three variants included: bsnes.exe, the standard version that casual users should run; bsnes-debugger.exe, for SNES programmers and ROM hackers only; and bsnes-accurate.exe, which should not be used by anybody, ever.
In all seriousness, bsnes-accurate.exe is bsnes with the dot-based S-PPU renderer. It's twice as slow as the normal build, and you won't really notice any differences except in Air Strike Patrol. It's there for the curious and for any SNES programmers who want to try making some really awesome video demos.
Changelog:
* OS X port builds once again; now requires gcc44 from Macports
* libsnes API finalized
* fixed a bug with S-CPU debugger breakpoints
* various source cleanup
Wow, that's probably a record for the longest time between two WIPs.
My priority has obviously shifted to language learning, but as time
goes on things should balance out better.
Okay, changes:
- linear_vector, pointer_vector and array are greatly improved: added
insert and remove (can insert or remove more than one item at a time
for O(n) performance); renamed add to append; improved array::find to
use optional<unsigned> instead of -1 trick ala the new strpos function
- fixed string to floating-point conversion for international systems
that use "," for fractions
- libsnes::snes_get_memory_(size|data) will return 0 if you try and
access: BS-X data without a BS-X cartridge loaded, same for ST, same
for SGB; this is in case someone tries to write a generic function
that writes all memory that is valid instead of special casing based
on the cartridge type they loaded
- libsnes::snes_load_cartridge_* returns a boolean result to indicate
success; always returns true for now, but it's meant to eventually
catch when libgambatte fails to load a GB cartridge -- bsnes itself
will never fail to load an SNES/BSX/ST cartridge
- Linux monospace font changed from "Monospace" to "Liberation Mono",
because the former is not monospaced when your desktop environment is
set to Japanese, etc.
- some other misc. cleanups
[No archive available]
- swaps the video_refresh output from BGR555 to RGB555, for the sake
of direct copying for certain APIs. Not going to do RGB565 because the
G5 bit doesn't exist, and faking it is lame.
[Meanwhile, in bsnesui 2010-04-24...]
bsnes.python:
- adds more icons and stuff.
bsnes.net:
- new port, targets C#, binds every function in libsnes
- targets .NET 3.5 ... I honestly would have went with 4.0 for the
nicer IntPtr addition alone, but the SP3 requirement may put off a lot
of people
- video output that doesn't scale (or clean up when dropping to a
smaller size)
- Port1 joypad input support via keyboard only
bsnes.cocoa:
- stuck in a time/space wormhole until Apple gets their heads out of
their asses and updates GCC
Probably the coolest thing about Python and .NET is that anyone can
now compile these GUIs and modify them just by having the run-times
installed. I really like the way MS is distributing the complete
development chain along with the run-time.
Fixes S-CPU debugger breakpoint issue.
libsnes always returns 0 for "no memory present" now, never -1U.
[Meanwhile, in bsnes-python 2010-04-20...]
Won't error if there's no joypad present.
Swaps menu and status bars with a toolbar.
Adds keyboard support - you can use both a keyboard and joypad for
input now.
Won't crash if RAM doesn't exist yet.
Won't crash if game uses no RAM.
Nothing interesting, just added bsnes-qt.py to ui_python. No input
handling, but OpenGL-based video resizing and libao audio. Doesn't use
numpy, found a workaround for that. It's obvious that we need
video/audio/input handled by an external library for this to work, so
I'm thinking now about a rewrite of ruby to a C-like interface.
Adds bool snes_get_region(void) to libsnes (permanent).
Adds snes_blit_colortable and snes_blit to libsnes (temporary).
Adds src/ui_python with a basic Python GUI, and abstraction between
the libsnes wrapper and PyGTK (so it can be reused for PyQt, etc.)
The GUI has:
- menubar
- video output (2x scale, supports NTSC/PAL, hires, overscan and
interlace correctly)
- audio output (libao through ALSA)
- input (very lousy key press events, they toggle off and on if you
hold a key down ...)
I'm getting full-speed, so that's good.
Not sure where I want to take all of this stuff yet, but it's kind of
neat for now I suppose. It would be kinda fun to go really out there
with completely new GUI design styles that aren't just your standard
menubar+video. Things like a toolbar, mouse gestures, really deep
platform integration, AVI-based recording, frame analysis shit, game-
specific GUI shit (perhaps map touch-screen input + gyroscope on top
of a simulated gamepad; or perhaps read the contents of RAM and
provide statistical information on the sides of the video output
screen?), I dunno ... whatever. It's there, it's possible, but it's
certainly not good enough to replace the official C++ Qt port, and I
don't really have the time or patience to make it that good myself.
A thank you to everyone who helped test the RC to ensure stability. I've uploaded the official v064 release to Google Code.
The most important change in this release is the cycle-based PPU renderer; but due to performance reasons the scanline-based renderer remains the default in the Windows binary. If you want to try out the cycle-based renderer, you will need to compile from source for now.
Another major change is the introduction of libsnes, which allows one to build bsnes as a shared library that can be used from other programming languages. It is intended both to create a regression testing framework, and to provide API stability for the various projects that use the bsnes core. While I can't guarantee the API to libsnes won't change, I will properly revision it and do everything I can to avoid changing it if possible.
- libsnes updated ... should be the official syntax now, I don't
expect any more changes
- added kode54's patch for HQ2x
- NOT going to add the libjma Windows Unicode fix, I want something
more elegant than hijacking all of std::ifstream, so that can wait for
now
- fixed status.irq_lock for Power Rangers
- went back to blargg's 1.024MHz S-DSP for the fast build
- updated mightymo's cheat pack to the latest version
I'm posting a release candidate for v064, for which I am looking for beta testers. If you would like to help out, please give it a try and report any bugs or regressions on the forum. If all goes well, this will be posted as v064 official shortly.
Note that you will need the Qt run-times from bsnes v063 official to use this. Also, this build does not use the new cycle-based PPU. Official builds are going to continue using the scanline-based renderer. This build should be about 10% faster than v063 was, which should lower the system requirements further.
Well I really don't want to think about a caching system right now, so
I skipped that.
- added sPPU::Background::get_tile(), which computes its own copies of
mask_xy, screen_xy, tile_size, etc; allows BG3 offset-per-tile to
compute tile correctly
- fixed two V=(start of Vblank) checks that lacked overscan tests
- removed fade stuff from video output, going to rely exclusively on
filters for that stuff now
- modified state. to t. for brevity
- cached regs.overscan for overscan() function
- PPUDebugger uses interlace_enable() and overscan_enable() to avoid
conflicts with the base classes; forgot to move PPUcounter to
PPUCounter
- added controller selection capability to libsnes; still needs cheat
code and save state support
Should fix that Adventure Island thing, confirmation would be
appreciated.
I tried some quick hacks and was able to get mode7 caching (NHL '94)
and OAM caching (Winter Gold) working without breaking anything, but
it's too scanline-PPU for my tastes. There's really no reason to half-
ass this just to get games playable, so I'll wait and do it the right
way later on.
Only worked on this for about an hour today ... I must be burned out.
Think I'll try messing around with Python or something, since Ruby is
a dead-end for using libsnes.
Writing to SETINI will update video mode priorities for EXTBG mode.
Merged pixel output { main, sub { valid, priority } } into just
priority. A priority of zero is considered invalid now.
Merged pixel output { main, sub { palette_index, palette_number } }
into just palette with the tiledata bits for direct color mode at
d8-d10.
This cuts a lot of copying and extra comparisons out of the final
screen rendering pass, though it doesn't really help speed.
Output is always 512x448 now. Having trouble deciding on how to do
video for that, but I'll post more on that later.
Really need to figure out how offset-per-tile fetches in regards to
lores v hires and SC size, tile size and wrapping.
For now, I simplified it to constants; whereas the scanline-renderer
uses the BG3 settings.
I also made it not perform OPT lookup on BG3 and BG4 anymore. Skips a
pointless trickery of setting the OPT valid bit to zero for BG3,BG4
and is faster.
Forgot an overscan check in sprite drawing, should draw sprites
properly to V=225-239 now.
Made the mode7 variable names more consistent.
With this release, the final last-generation holdout, the scanline-based PPU renderer, has been replaced with a true, accurate, cycle-level PPU that renders one dot at a time. Finally, this fulfills the greatest milestone remaining in the SNES emulation scene. With every processor emulated at the lowest possible level, SNES emulation finally rivals the accuracy levels that NES emulators have offered for years.
Now, please do understand that this release is not a beta, nor is it even an alpha. It is simply a preview of things to come, and as such you can consider it a pre-alpha. There are many caveats at this time.
First, it is very slow. More than twice as slow as v063 official. There have been absolutely no optimizations whatsoever to the new dot-based renderer. I do expect to be able to speed this up significantly in future releases.
Second, this may lock up on Windows Vista and later for unknown reasons. I haven't had a chance to look into it; so stick with Windows XP or Linux for now.
Third, save states are not supported yet. If you try and use them anyway, bad things will happen.
Fourth, and most importantly, this isn't 100% bit-perfect by any stretch of the imagination. Off the top of my head, memory is accessed far too often, the OAM and CGRAM address lines are not controlled by the S-PPU during active display, none of the various glitches are supported, and the OAM renderer does not pre-cache the next scanline's sprites, it happens on the same line for now.
I will obviously be doing my best to improve the accuracy of the aforementioned things. But even with those missing, this is still leaps and bounds above a pure scanline-based renderer. It essentially provides 682 times the parallelism. It is enough to finally properly emulate the shadow effect in Air Strike Patrol, and it finally eliminates the "PPU Hclock render position" hack once and for all.
Lastly, you'll need the DLLs from v063 official. I didn't bother to include them this time.
Enjoy!
So that's about 24 solid hours worth of programming in two days. Holy
fuck am I exhausted. Don't expect the last bits any time soon.
Missing features:
- Mode 7 renderer
- OAM previous-line caching
- offset-per-tile mode
- some edge cases in color add/sub
- hires
- interlace
- overscan
- S-PPU control over VRAM, OAM, CGRAM during active display
Speed hit is about as bad as I had feared. 172fps with scanline
rendering to 80fps with dot rendering. I'm guessing that with
optimizations I can make it to ~100-110fps.
No binary, this is just a point release.
I have basic lores BG1-4 rendering with mosaic added. No offset-per-
tile, no windowing, no color math (requires windowing), no sprites, no
hires, no interlace, no mode7.
It's enough to see how powerful the concept is already, though.
- Battle Blaze intro looks just fine (can't beat a battle because I
can't see my sprites or save states yet)
- Dai Kaijuu Monogatari II stat bar looks fine (no duplicated line)
- Super Metroid looks fine (no extra status bar line)
- Air Strike Patrol shows the translucent shadow for your plane (but
the left-hand scrolling is glitchy ... not sure what's up yet)
Speed is ... yeah, it's bad. About 50-60% speed. But it can get
better, I'm being really lazy and completely recomputing everything
for each pixel. A very large number of these operations can be cached.
I'm going to wait until the renderer matches the quality of the
scanline-renderer before optimizing; and I'm not going to push too far
on optimizing this (eg I probably won't bring back the tiledata
planar->packed conversion cache.)
I'm designing this similar to MooglyGuy's N64 renderer, putting each
component in its own class. So far I'm really liking the concept.
src/lib is no more, merged libco, nall and ruby into src/.
libsnes has been improved, builds in when you "make library" now.
XML memory map generation happens from a nall template header, so both
libsnes (used by ui_sdl) and ui_qt can run again without snesreader.
ui_sdl improved, can run any game via command-line, but doesn't load
or save RAM yet.
And most importantly, much work has gone into sPPU, the new cycle-
based PPU renderer. It has enough support to be compatible with all
games ($2134-213f are mostly complete, just missing range/time over
flags and VRAM/OAM/CGRAM blocking.) It only renders the back color, as
if you had all BG and OAM layers disabled.
At this point, if you run Air Strike Patrol, thanks to its gradient
fade highlighting, you can see the plane's shadow, just as on real
hardware now. It also runs test_hello and test_noise, which I will
upload shortly.
Extremely substantial code structure changes this time. Probably the
most in four years.
All of the SNES core now resides in src/snes, and the contents of
system have been unrolled into this directory as well. This folder
gets its own Makefile now, and some special build commands, "make
library" and "make install-library". This creates static and dynamic
link libraries of the core, completely devoid of Qt, ruby, the GUI,
etc.
There's a new module as well, src/snes/libsnes. This is a C interface
that will let you initialize and control the bsnes core without the
need for anything more than a 1KB header file.
To test this, I've created a UI fork, ui_sdl. Very very simple, 2KB,
nothing there at all really, it just boots up Zelda 3 and runs it
directly with keyboard input support and video only. The important
point here is that the ui_sdl project does not reference the core, or
ruby, or Qt, or anything else, and is fully C++98 (though it could
also be C89 if desired.)
Now I'm being a bit lazy and using the compiled objects directly, but
it'd be just as easy to replace them with a library include directive,
or even dynamically link against the shared library and use an
entirely different language.
It's not actually my goal to make a C++ SDL port, what I really want
to do is make a port using Ruby only. May not be so easy, we'll have
to see how one accesses shared libraries in it.
The main src/Makefile was also simplified for the sake of supporting
non-Qt code. All of the Qt and ruby references were moved into the
src/ui_qt/Makefile.
I fixed up aDSP to compile again, but you still have to manually
comment out sDSP and comment in aDSP. Doing so will net you a 6-12%
speedup at the cost of some accuracy.
Lastly, I added a workaround for the Battletech 3050 splash screen.
It would be a really good idea to test all of the HDMA-sensitive games
with this WIP, if anyone's up for it.
Rewrote most of sCPU::DMA. It now implements a parallel two-stage
pipeline to more closely model the hardware. Even if it turns out to
be wrong, simply making dma_write() immediate would revert it to the
old behavior. Fixed a bug where HDMA init and run were always syncing
to the DMA counter, even when a DMA was already in progress. Will
speed up the S-CPU in a very, very small number of games, namely
College Football '97. Most games avoid this because it can crash
CPUr1. New DMA variables means new save state version, sorry.
I did not add the MDR override code, because it's too fucking insane.
Speedy Gonzales still works.
Removed the status bar size grip entirely. There's really no point in
it being there in windowed mode since you can already grip the sides
of the window anyway. Added space to each side of the status text so
that it doesn't nail the very edge of the monitor.
Added checks in XML mapping to not map in special chip sections when
you try and load BIOSes directly, which will stop the SGB and BS-X
BIOSes from crashing the emulator. Load it the right way and it'll
work fine, as always.
Fixed the loader window to display screenshots properly when you have
HTML entities in the filename, eg &, < and >.
I've had enough of idiots incapable of finding fullscreen settings.
The menubar is enabled in fullscreen mode by default. A new option in
settings->configuration->video will let you hide it as with v063
official. I don't want to hear about how I shouldn't allow any
settings to be configured differently in fullscreen mode, or how it
should be in a GUI panel, or whatever. I will ignore you if you bring
it up.
I've also added the strpos / qstrpos function->class code, as
mentioned in the programming section.
Time for another (hopefully) stable release. The changelog has all updates since the last stable release.
Most notably, this release features substantial accuracy improvements all around. Almost all of them represent brand new findings never before seen in any SNES emulator.
Changelog:
- fixed off-by-one buffer size issue in S-PPU RTO calculations [PiCiJi]
- added XML parser
- added XML-based memory mapping system
- moved header-based memory mapping code into snesreader library
- added some linker flags for Fedora [belegdol]
- added cheat code database; with codes for over 1,500 games [mightymo]
- fixed a bug where S-CPU IRQs were being tested one cycle early on direct page indexed read opcodes
- added global cheat system enable/disable checkbox to cheat code editor
- fixed bug in overflow calculation of S-CPU ADC and SBC opcodes in BCD mode [blargg]
- emulated the S-CPU ALU MUL and DIV hardware delays with partial result calculation steps [blargg]
- controller port read now returns real-time results of B button when strobe latch is raised
- major improvements to emulation of the S-SMP TEST register [blargg, byuu]
- fixed DSP2 memory map [Overload]
- "Apply Patch" checkbox will now scan UPS patch folder if one is set in the paths section
- fixed S-CPU TSC negative flag calculation in emulation mode [address]
- added "make uninstall" command to Makefile for Linux users
- S-CPU (H)DMA now updates the S-CPU MDR; fixes a freeze in Speedy Gonzales - Stage 6-1
- very substantial code cleanups and optimizations as a result of moving from C++98 to C++0x
Added make uninstall, and fixed up nall::function to also bind lambdas
that don't yet exist in GCC 4.4.
Spent most of tonight rewriting the standalone UPS patcher.
Mostly minor stuff again.
Fixes:
array, linear_vector and pointer_vector need to set source.pool = 0
before calling reset() to avoid destroying the object we're trying to
move.
All of nall::string is inside namespace nall now. No idea what I was
trying to do before with the half-global approach.
nall::function gains a reset() function, more obvious than func =
(void*)0;
The movie file loader wasn't binding the right action when changing
files and clicking load, can't believe nobody noticed that one.
This WIP has bsnes.exe, snesreader.dll, and src/. If you need anything
else, get it from past releases, please.
I fixed TSC negative flag calculation in emulation mode. Will pass
this test now:
http://blargg.parodius.com/snes-tests/snes_test_tsc.zip
_Way_ too obscure to affect anything, but definitely good to get it
right.
Also rewrote nall/function.hpp to use C++0x variadic templates. New
version is ~85 lines instead of ~190, 40% smaller, doesn't require
recursively including itself, doesn't require the C preprocessor,
evaluates to ensure the member function pointer is big enough to hold
what you're assigning statically (at compile time) instead of
dynamically (at run time), and supports infinite arguments instead of
zero to eight now.
This is source code only, no binaries. Sorry, worn out after spending
four hours straight writing crazy ass Julian<>Gregorian date
functions. Holy fucking hell that is crazy shit. Tell me, how many
days have passed since 01-01-4731 BC on the Julian calendar?
Okay, this really was just about taking advantage of vectors inside of
vectors. I've updated the XML parser to use vectors of actual objects
instead of pointers. This makes cleanup free, and turns countless ->'s
into .'s -- much nicer to look at. I may take advantage of overloaded
operators for something now, not sure yet.
You'll need snesreader's DLL from my last WIP post to use the above.
This initializes mode, region and ram_size again in Cartridge::load()
to stop the phantom SRAM files from being generated.
This fixes DSP-2 mapping to match Overload's findings (which requires
an unposted snesreader, so Dungeon Master won't run for you guys yet.)
This removes nall/traits.hpp and uses std::tr1::type_traits instead.
It also drops move, forward and identity in favor of those from
std::tr1::utility*.
This fixes linear_vector and pointer_vector to not crash when using
vectors of vectors and copying them.
This fixed linear_vector, pointer_vector and array to initialize all
internal variables for all constructors.
This fixes the file browser to look for patches in your patch
directory, so the "Apply Patch" box should work correctly now.
* I have no objection to using functions from the C++ standard library
when they don't suck.
To run this, you'll need the DLLs from v062r04's public beta, and the
updated snesreader.dll in the same folder as the WIP. No profiling.
This fixes UPS patching, and it also modifies snesreader to generate
the XML map separately, so that the map can be generated post-
patching.
The new enum classes weren't attaching properly to the config file, so
the input settings, expansion port and region settings are saved
again.
It also converts the S-SMP timers back to unsigned integers instead of
using floating point, no accuracy improvement but much more in line
with hardware.
Lastly, it makes the div register shift left 16 places and pre-shifts
on divide, which is just for aesthetics.
And I'll wait on your tests, FitzRoy. I really hope that Big Run
Jaleco Rally is correct, because I don't have the first idea how to
debug that one. Speedy I can probably handle.
I suppose I should start calling these nightlies, heh. blargg went ahead and verified every last possible edge case with regards to the S-CPU MUL / DIV registers. It uncovered a few errors in my implementation, which have since been corrected. The design used now should be a direct reflection of the hardware implementation: no actual multiplication, no actual division, and no variable-length bit-shifting.
We also spent about eight hours straight hammering away at the S-SMP test register. We have a partial understanding of TEST.d3 and TEST.d0, and a complete understanding of the other six bits. All of this has been implemented as well.
Lastly, snesreader gets a tiny update to fix Test Drive II, which broke due to a slight regression when porting the mapping code to XML.
blargg and I sat around for a good 8+ hours today hacking away at the
S-SMP Pandora's Box: the TEST register. What better way to spend Pi
Day, right?
We came up with the following tests:
http://byuusan.kuro-hitsuji.net/blargg_2010-03-14.zip
First, controller_strobebehavior.smc improves emulation of $4016. When
the joypad strobe latch = 1, reading $4016 returns the current value
of the B button. As in, you can keep reading it over and over. It
won't increment the shift register, and it will keep telling you the
actual current state of the button. This is very much like the NES
behavior. One more TODO in the S-CPU code taken care of.
Next, all kinds of S-SMP TEST register improvements. Turns out d7-d6
alone controls the actual S-SMP clock rate. 0 = 100%, 1 = 50%, 2 = 0%
(locks the S-SMP forever), 3 = 10%. Wild stuff, you can actually
permanently slow the S-SMP relative to the S-CPU.
d6-d5 is a timer tick control, but it actually uses d7-d4 overlaid.
The algorithm is fucking nuts, and is really my only contribution to
today's work. The rest was all blargg's research.
We had d2 wrong, it's not MMIO disable, it's RAM disable. As in,
disable read and write. Returns 0x5a on regular SNES, 0xff on mini-
SNES. 0x5a is not the S-SMP MDR. IPLROM is still readable when RAM is
disabled. d1 was correct, just RAM write disable. Can still write to
$f8 and $f9, of course. But it won't go through to RAM.
d3 and d0, we are still a little unsure on. The T0-T2 timers seem to
have a low and high phase, and if you strobe them you can force ticks
of stage 2 to happen, and you can disable them in such a manner than
stage 2 never ticks at all.
blargg is still uncovering all sorts of crazy things in $xB mode, so
emulation of these two bits is not perfect.
But overall we are leaps and bounds further now toward complete
emulation. I'd say we went from 10% to 80% with today's work. But
we'll have to see how deep the rabbit hole goes on d3+d0 first.
Current register map:
case 0xf0: { //TEST
if(regs.p.p) break; //writes only valid when P flag is clear
status.clock_speed = (data >> 6) & 3; //100%, 50%, 0%, 10%
status.timer_speed = (data >> 4) & 3; //100%, ...
status.timers_enabled = data & 0x08;
status.ram_disabled = data & 0x04;
status.ram_writable = data & 0x02;
status.timers_disabled = data & 0x01;
unsigned base = 1 + (1 << status.clock_speed);
unsigned step = base + (15 >> (3 - status.timer_speed));
status.timer_step = 1.0 / (3.0 / step);
t0.sync_stage1();
t1.sync_stage1();
t2.sync_stage1();
} break;
Fairly confident that no emulator prior to this WIP could pass any of
blargg's tests, so this is all brand new information. Fun stuff :)
Major accuracy improvements have happened over the past few days. They easily warrant a new beta release.
First, it turns out that every emulator to date; not only for the SNES, but for the Apple II GS as well, incorrectly computed ADC (add) and SBC (subtract) flags in BCD (binary-coded decimal) mode. At least fifteen years of emulating the 65816 processor, at least five known investigations into their behavior, and we all still had it wrong.
So I wrote some tests that dumped every possible combination of adc and sbc with every possible input and every possible flag, and recorded both the accumulator result and status flag register. From here, blargg figured out the underlying trick: the CPU was computing overflow before the top-nibble's BCD correction pass. With the routines rewritten, bsnes perfectly matches real hardware now.
Next, some background. The whole reason I got into SNES emulation was because I was tired of writing code that ran perfectly fine on emulators, but failed miserably on real hardware. The number one problem was emulators allowing video RAM to be written while the screen was being rendered. This single bug has broken dozens of fan translations and ROM hacks. Some have been updated to work around this bug, and many others are left in a permanently broken state (such as the translations of Dragon Quest I & II and Sailor Moon: Another Story, to name just two.) After asking emulator authors to fix this since 1997, I finally had enough in 2004 and started on bsnes. For this particular bug, I'm very happy to report that all but one SNES emulator now properly blocks these invalid accesses. Although sadly one still offers a configuration setting for backwards compatibility with these translations. What an ironic shame ... emulating an emulator. And in the process, sapping the motivation to ever go back and fix these
titles to ever run on real hardware. But I digress ...
The second biggest problem that causes software created under emulation to break on real hardware has, without a doubt, been the hardware delays as the S-CPU computes MUL (multiplication) and DIV (division) results. To date, whenever you used this hardware functionality, emulators have immmediately furnished the correct results. But on real hardware, multiplication requires eight CPU cycles, and division requires sixteen. Each step computes one bit of the source operand and updates the results. Reading the output registers early thus provides the partially computed results.
This is obscure. It isn't well known, and many people writing software for the SNES probably aren't even aware of this limitation. Because of the partial computation results, outright delaying the computation would break many commercial software titles. But by not emulating the delay at all, we were causing a great disservice to anyone wishing to use an emulator for development purposes.
Now, once again, thanks to blargg's algorithm help, he has determined the underlying multiplication and division algorithms. Combined with my expertise of SNES analysis and hardware testing, I was able to determine when and how the ALU (arithmetic logic unit) stepped through each work cycle. Our work combined, bsnes now also perfectly emulates the hardware MUL and DIV delays.
Again, this isn't going to fix commercial software titles. They would have realized that they were reading back invalid MUL and DIV values, and fixed their code. This is for all of the software developed using emulators. This is an extension of my commitment to create a hardware emulator, and not a video game emulator.
We also verified that the S-PPU multiplication interface does indeed return instant results with no delay. So emulation of that interface was already correct.
I'm only labelling this release a beta because it hasn't been tested. But I'm fairly confident that it is stable, and I seriously recommend upgrading from v060 or prior releases. This is easily one of the last major pieces missing from emulation.
The last notable elements are: S-CPU auto joypad poll timing, S-CPUr1 HDMA crash detection, S-CPU<>S-SMP port ORing, S-SMP timer glitching, S-DSP mute pulse, and full cycle-level emulation of the S-PPU. With all of the aforementioned items, I will consider a v1.0 release of bsnes ;)
Lastly, I'll post this screenshot just for fun. When d4s translated Breath of Fire II to German, he added some code that relies on the incorrect emulation of the DIV register to detect emulators. With this emulated properly, you now see the following screen:
./sshots/bs_349.png
Sorry to spoil that, but the secret's already out, as the MESS team reported on it publicly already.
I intend to add pseudo-randomness support shortly, which should eliminate one of the last vectors possible to distinguish bsnes from real hardware :)
A million thanks to blargg for making this release possible.
This is probably the biggest accuracy fix in several years.
Thanks to the efforts of blargg and myself, bsnes is now the very
first emulator to properly emulate ALU multiplication delays. It's
100% bit-perfect.
Note that we don't yet know the underlying division algorithm. So in
this WIP, I just make it wait eight ticks before storing the results.
It _may_ cause some issues, but I wanted to get rid of the
status.alu_lock and config.alu_mul/div_delay garbage in advance.
I'm absolutely enthralled, I never thought I'd actually see this
emulated properly.
Complete rewrite of adc + sbc opcodes, should fix:
- adc BCD overflow flag
- sbc BCD overflow flag
- sbc BCD invalid input value
Testing is appreciated, I believe Sim Earth is probably the most
likely to observe any difference.
Found the cause of the issue breaking SuperFX games after loading SA-1 games. Seems the XML mapping tree wasn't being cleared. It's also not a good idea to use bsnes/ as the folder name when the Makefile generates a binary by the same name in the same directory, so back to src/ for the main emulator it is.
With those fixes, this release should be fully stable; but again my intentions are to keep v060 as the stable release for a while.
Nonetheless, you can grab the new beta at Google Code. It should be the last update for at least a few weeks.
Please keep in mind that bsnes v060 remains the current stable release. v061 has been released as a work-in-progress build. As such, it is only available at Google Code.
I am releasing this WIP to allow the public to test out and comment on the new XML mapping system, as well as the integration of mightymo's cheat code database into the cheat editor. I would greatly appreciate feedback on these two on the forums.
There are some important issues with this release. The biggest is the move to C++0x. This requires GCC 4.4.0 or newer to compile, thus it is not currently possible to build this on OS X using Xcode. Nor would it be possible on certain BSDs or older distros. If you have an older compiler, please stick with v060, or use a binary release where available.
Another issue is that TDM/GCC 4.4.1 for Windows crashes with an internal compiler error when attempting to generate a profile for the DSP-1 module. This is a bug in the compiler, and not in the code itself. The workaround is to simply omit profile-guided optimization for this one object.
Lastly, there's also a known bug in the memory mapping. If you load an SA-1 game, SuperFX games will not load properly afterward unless you restart the emulator. I'm looking into the cause now, but it didn't seem serious enough to hold up a WIP release.
So, yes. If you want a good gaming experience that's been fully tested and stable, please stick with v060. If you want to see some bleeding edge features, I'd appreciate feedback on v061. Thanks for reading this.
Changelog:
- added mightymo's cheat code database, access via "Find Cheat Codes" button on cheat editor window
- added an option to temporarily disable all cheat codes quickly
- debugger now properly uses S-SMP IPLROM when needed for disassembling and tracing
- indexed indirect read opcodes in the S-CPU were testing for IRQs one cycle too early [someone42]
- fix an off-by-one array iteration in S-PPU OAM rendering [PiCiJi]
- added some implicit linked libraries to linker flags for Fedora [belegdol]
- moved from C++98 to C++0x, resulting in substantial code cleanups and simplifications
- C++0x: implemented foreach() concept for linear container iteration
- C++0x: implemented concept system using SFINAE and type traits
- C++0x: utilized auto keyword to increase source readability
- C++0x: moved to strongly-typed enumerators
- C++0x: rewrote va_list-based code to use type-safe variadic templates
- C++0x: replaced noncopyable class with deleted default copy functions
- C++0x: replaced custom static_assert template class with built-in version
- C++0x: utilized rvalue references to implement move semantics into string, array, vector and serialization classes
- C++0x: utilized std::initializer_list for { ... } initialization support to lstring, array and vector classes
Added concept support, vastly improved foreach to handle break
properly and only compute the size once (based off concepts), extended
it to work QList, and updated cheateditor.cpp to use foreach
everywhere now.
Added an "Enable Cheat Engine" checkbox to the bottom left of the
cheat editor window with a tooltip to help explain it more. It
essentially simulates the switch on the Game Genie. A way to quickly
toggle all codes on and off, without having to check/uncheck each one
individually. Useful for the codes that lock up games between levels
and such. It's bound to the existing keyboard shortcut that did this,
and they both update the check state and system status properly.
Hopefully the GUI option will make more people aware of this
functionality.
Updated array, linear_vector, pointer_vector and lstring to support
std::initializer_list constructors. This allows:
lstring list = { "apple", "strawberry", 3.4, -27, true,
QString("why?") };
array<int> = { 3, 4, 9, 2 };
std::initializer_list is a pain in the pass, it lacks a subscript
operator, an at() function and a get() function. Forced to use
constant iterators to read out the contents.
[No archive available]
Fuck, adding #include <iostream> grows the Windows binary by 300KB
pre-UPX, and 100KB post-UPX. And I'm only using std::cout to avoid the
very last call to printf(). I may just say fuck it and stick with
stdio.h instead.
Nothing really big in this one.
Added "Select All" + "Clear All" buttons to the cheat finder
Added move semantics to dictionary, array, linear_vector and
pointer_vector
Killed class noncopyable and replaced it with proper class(const
class&) = delete; (inheriting noncopyable makes some classes non-POD)
Added type-safe variadic sprint() and print() functions, which are
designed to replace sprintf() and printf(), which I only use for bug-
testing anyway
Couple other small things like that
[No archive available]
This release parses the 1.3MB cheats.xml file about 960x faster than
the last release, no exaggeration at all there. The tiny 5-10ms lag to
search now is probably more due to Qt than anything else. It also
won't eat up an extra 40MB of RAM, instead only using about 100KB now.
So yeah, please give it a try and let me know what you think of the
new cheat lookup system.
Aside from that, I fixed a tiny S-CPU typo bug where the IRQs were
being tested one cycle too early in op dp,x and op dp,y opcodes.
I also redid a bit of nall in C++0x. Most importantly, I've added move
semantics to nall::string, which should cut out ~20% of the memory
allocations bsnes needed before. I really wanted to write a variadic
template string::printf replacement, but I couldn't come up with a
syntax I liked, and I didn't want to write a sprintf clone because
that takes forever and is ugly. So I just said fuck it, removed
string::printf (and with it the very last vestige of va_list in all of
my code, good riddance), and updated the str* functions to take
template arguments to specify padding length and character. Both
optional, another fun C++0x only thing - default function template
arguments.
Before: string foo = string::printf("%.4x", variable); -- went
through raw sprintf(), va_list, and had a limited 4k buffer
After: string foo = strhex<4>(variable); -- manually built by hand, no
buffer issues
nall/utility.hpp got my own copies of std::move and std::forward. I
have no problem using the std:: ones, but the <move> header seems to
be missing, and I already have my own traits library, so that was easy
enough for now. Added a move-semantic swap as well. Using nall::sort
on an array of nall::string objects should be almost as fast as
sorting integers now.
The cheat code editor .. whenever you import into a new slot, or clear
that slot, it will uncheck the box now as well.
[No archive available]
This version embeds mightymo's cheats.xml inside the bsnes executable.
It's about 1.3MB, but thankfully Qt compresses it heavily first, so
the binary only grows by 100kb. BZip2 doesn't fare as well,
surprisingly, and grows the source archive by 200kb. I think it's
worth it.
The cheat code editor window gets a new button, "Find Cheat Codes ..."
If you click it, it will match the SHA256 of the currently loaded game
to an entry in the database. No matches? It apologizes for letting you
down. But if it finds some, and there's a good chance it will with
~1500 entries, it gives you a list of them. Check the codes you want
and they are imported into the available slots. The way it works is
the first checked code goes to the first empty slot, the second
checked code to the second empty slot, and if there aren't any slots
left available (very unlikely), it won't import them.
It's incredible, actual innovation in the SNES scene.
- no more web searching for codes
- no more applying codes for the wrong revision, or the wrong country,
or whatever
- no more flat out broken codes
- no more having to name the codes yourself
- cheat grouping avoids the need to add and toggle multiple slots to
get a single effect
Anyone who likes this, please send a thank you PM to mightymo77 and
tukuyomi. They deserve all the credit for the amazing database that
makes this possible.
Now then: **major caveat, for the love of god read this first!** My
XML parser is ... brutal on this file. It has to allocate memory for
each attribute and each element. And ... it rapes the ever loving SHIT
out of malloc(). Oh my god. On my E8400, it takes a good 30 seconds to
parse the 1.3MB database on Linux. And on Windows, holy god, it has a
horrendous version of malloc. It takes at least 3-5 minutes.
Seriously, go make yourself a cup of coffee if you are running
Windows.
I only have to parse the file one time per program run, and I only
parse it when you click the find cheat codes button for the first
time. But yes, it is painful. Very, very painful.
[No archive available]
Feeling amazing tonight. The low of fighting a bad cold for the past
week, blocked nose, bloody lips and wrist pain combined can't hold me
down.
Two years of searching and I finally found the Midnight Panic EP, and
it's amazing. And from this WIP forward, bsnes now uses C++0x instead
of C++03. I feel like I've been given this new amazing language, and
there's all these wonderful new possibilities for cleaning up and
simplifying code.
foreach is the most amazing concept. The only reason I've made it this
long without it is because I never got to use it. You will pry this
one from my cold, dead hands. Already applied it to the cartridge and
memory classes. It's insane.
Before:
for(unsigned i = 0; i < memory::wram.size(); i++) memory::wram[i]
= config.cpu.wram_init_value;
for(unsigned i = 0; i < cartridge.mapping.size(); i++) {
Cartridge::Mapping &m = cartridge.mapping[i];
After:
foreach(n, memory::wram) n = config.cpu.wram_init_value;
foreach(m, cartridge.mapping) {
Before:
for(unsigned i = 0; i < 32; i++) {
char value[4];
sprintf(value, "%.2x", shahash[i]);
strcat(hash, value);
}
After:
foreach(n, shahash) hash << string::printf("%.2x", n);
And that's just the first thing! So many things I can do now. Can't
wait to come up with uses for all the new features to simplify code
even more.
- auto type inheritance
- variadic templates to nuke the last vestiges of va_list and its
associated horrors
- strongly typed enums (no more enum Mode { ModeOfRedundancyMode }
shit. enum class Mode : unsigned { Normal, BSX };
- _real_ static assertions with actual error messages instead of 40
pages of template errors
- default templates parameters to template functions (but still no
function partial template specialization, grrr)
- property class can be implemented natively without having to trick
GCC into using template friend classes
- rvalue references will allow my string class and such to implement
move semantics, no more useless copying
- uniform list initializers, lstring foo = { "a", "b", "c", ... };
And that's just what's there now, it's only half-way done. The
completed support will be even more awesome:
- lambda functions
- nullptr
- class variable initialization in the header instead of needing
constructors
- native functors to replace nall::function with
- string literals in UTF-8
- native multi-threading support
- and so much more
[No archive available]
Forgot the -lXext thing, saw it when posting. It'll be in r06.
Updated the XML parser, will reject a lot more invalid stuff, and
it'll parse comments, <? and CDATA stuff. I haven't seen PCDATA
mentioned anywhere in the spec, so fuck that for now.
Went back to using offset= for SPC7110 data ROM. Thinking about it
more, using offset= allows you to put the data ROM anywhere in the
file, even before the program ROM. size= forces it to go at the end no
matter what. Now, ideally, you want to define both, but offset= should
be more important.
[No archive available]
I wrote a dedicated XML parser for nall::string, and updated
SNES::cartridge to use that instead of the ad-hoc implementation. It's
still not W3C-quality with 100% standards-adherence, but it's at least
an order of magnitude better now.
The parser supports infinitely nested elements and attributes via
pointers to child nodes, supports both single-tag <eg /> and tag-with
content <eg>content</eg>, and properly handles and validates the
<?xml?> header.
It doesn't fully ignore comments yet, but you should be okay anyway.
Whitespace culling, especially inside tags, still needs a bit of work.
It will properly reject the entire document if there are unopened /
unclosed tags now.
All in all though, it's very small. Only 3KB for the whole parser.
Usage example:
void Cartridge::parse_xml_cartridge(const char *data) {
xml_element *document = xml_parse(data);
if(document == 0) return;
for(unsigned i = 0; i < document->element.size(); i++) {
xml_element *head = document->element[i];
if(head->name == "cartridge") {
for(unsigned n = 0; n < head->attribute.size(); n++) {
xml_attribute *attr = head->attribute[n];
if(attr->name == "region") {
if(attr->content == "NTSC") region = NTSC;
else if(attr->content == "PAL") region = PAL;
} else if(attr->name == "ram") {
ram_size = strhex(attr->content);
}
}
for(unsigned n = 0; n < head->element.size(); n++) {
xml_element *node = head->element[n];
if(node->name == "map") {
parse_xml_map_tag(node);
}
}
break;
}
}
delete document;
}
Also updated DSP-3 and DSP-4 to separate ::DR and ::SR, SPC7110 uses
size= for program ROM size calculation now (makes more sense than
using offset=), added PCB info to BS-X, Sufami Turbo and Game Boy
cartridges to give additional meta-data (SGB emulation will properly
size RAM / RTC files again), and updated snesreader with these
changes.
And for better or worse, I made the vector classes copyable. Not
actually used by anything at the moment. I wanted to do:
struct xml_element {
vector<xml_element> element;
};
But obviously that causes an infinite recursion when the vector's copy
constructor is called, hence why I had to use pointers.
[No archive available]
Okay, this should get 100% compatibility back up again. All special
chips map via XML, and I also support BS-X, ST and SGB games again.
Only regression is that SGB currently forces on SRAM size to 128KB for
each loaded game. I need to move that into snesreader, and hook it
into the cartridge interface. Too much work to do it tonight, but in
time ...
Given the extensiveness of this, heavy testing appreciated. Let me
know if you spot any broken titles please.
[No archive available]
This one is not for the faint of heart.
All header detection code has been removed from the official bsnes
binary. It can now only load games with a valid XML memory mapping
file. If you have /path/to/zelda.sfc, then you also need
/path/to/zelda.xml that describes how to load the cartridge.
The 'ext' archive above contains a new version of snesreader, as well
as its DLL. snesreader now contains header detection, as well as XML
mapping generation. If you have snesreader, and no XML file,
snesreader will create one for you. It won't store it on your hard
disk, it'll only be in memory. An XML on the hard disk always
overrides the snesreader's auto-generated XML file.
So far, only normal ROMs, S-RTC, S-DD1 and SPC7110 games are up and
running. Everything else is broken, I'll have to fix them one by one
by extending the id= attributes in the XML parser.
Here's some example XML files:
<?xml version="1.0" encoding="UTF-8"?>
<cartridge ram="2000">
<title>The Legend of Zelda - A Link to the Past</title>
<pcb>SHVC-1A3M-30</pcb>
<map mode="Linear" address="00-7f:8000-ffff" id="ROM"/>
<map mode="Linear" address="70-7f:0000-7fff" id="RAM"/>
<map mode="Linear" address="80-ff:8000-ffff" id="ROM"/>
<map mode="Linear" address="f0-ff:0000-7fff" id="RAM"/>
</cartridge>
<?xml version="1.0" encoding="UTF-8"?>
<cartridge region="NTSC" ram="2000">
<map mode="Direct" address="00-3f:4800-483f" id="SPC7110::MMIO"/>
<map mode="Direct" address="80-bf:4800-483f" id="SPC7110::MMIO"/>
<map mode="Direct" address="00-3f:4840-4842" id="SPC7110::RTC"/>
<map mode="Direct" address="80-bf:4840-4842" id="SPC7110::RTC"/>
<map mode="Linear" address="00:6000-7fff" id="SPC7110::RAM"/>
<map mode="Linear" address="30:6000-7fff" id="SPC7110::RAM"/>
<map mode="Shadow" address="00-0f:8000-ffff" id="ROM"/>
<map mode="Shadow" address="80-8f:8000-ffff" id="ROM"/>
<map mode="Direct" address="50:0000-ffff" id="SPC7110::DCU"/>
<map mode="Linear" address="c0-cf:0000-ffff" id="ROM"/>
<map mode="Direct" address="d0-ff:0000-ffff" id="SPC7110::MCU"/>
</cartridge>
[No archive available]
This WIP fixes the S-PPU overflow issue mentioned by PiCiJi. It won't
cause any difference in terms of accuracy, for reasons I explained
earlier the effect was transparent, but it's good to do things the
right way.
It also adds a new ExSPC7110 memory mapping mode that allows for a 2MB
program ROM. This is an absolute necessity for the Far East of Eden
Zero translation.
[No archive available]
This is a long-term stable release. A full changelog will be available at the forum link below later in the day. Also, please note that I have merged all of the various distributions into two packages. The Windows binary package now contains both the profile-optimized (fast) build, and the debugger build. The source code package now contains sources for bsnes, snesreader, snesfilter and supergameboy.
Changelog:
- added Direct3D HLSL pixel shader support [mudlord]
- fixed a signal issue that caused loading games to take 1-2 seconds longer in v059
- 21fx API revised to its final form, S-MSU (public documentation pending)
- worked around QTBUG-7188 to fix multi-file 7-zip file listbox to update when scrolling
- added scale max - normal, wide, and wide zoom modes to fullscreen mode
- added overscan cropping tool (needed for wide zoom mode; useful for developers simulating games on a real TV)
- added "go up one folder" button to file load dialog
- added group (un)assignment to the input settings window
- now honors input.allowInvalidInput setting; defaults to false [Jonas Quinn]
- cheat code editor grays out empty slots
- cheat code editor adds "clear selected" button to quickly erase multiple cheat codes
- to load folders as game images, folders must end in .sfc, .bs, .st, .gb now
- debugger: added S-CPU (H)DMA registers; S-SMP registers; S-DSP registers to properties list
- snesfilter: HQ2x filter is now multi-threaded (scales infinitely: the more cores you have, the less overhead required)
- pixelshaders: added screen curvature shader to simulate curved CRT tubes
- source: lots of code cleanup, as always
Fun WIP, lots of work put into this one.
First, I added .st, .bs, .gb, .sgb, .gbc folder-based loading. Works
the same as .sfc folders. So far, only .st shows additional preview
info (just the ROM size for now), but the base code is in place to
specialize .bs / .st / .(s)gb(c) cartridges next.
Next, I added overscan configuration settings to the video settings
window. The reason for this is twofold:
1. testing your translation / hack without a real TV, you can set
overscan to 6% in all directions to ensure all the text is onscreen
2. for the smart video scale mode, noted below
Now, when in fullscreen mode, you get three additional scale settings:
Scale Max - Normal (keeps aspect ratio, maxes out height)
Scale Max - Fill (fills as much as the screen as possible, no
cropping)
Scale Max - Smart (splits the crop and aspect ratio distortion, 50/50
on each; try it, it looks fairly decent in most titles)
No scale max - zoom, because that's just too much cropping; almost
nothing plays well with it
Note that cropping doesn't work so great right now for games that mix
lores and hires (Secret of Mana 2 textboxes, for instance.) I'm
working on it, but it's going to be very tough. All filters take solid
screen sizes quite well, which surprised me.
Also, scale max - smart is for widescreen monitors. It makes zero
sense to use it in portrait mode. I'll add some sort of special case,
just in case anyone crazy tries it, in a future build.
Lastly, I killed the separation of video.cpp and pixelshader.cpp, it's
all inside video.cpp now; and I cleaned up the object names in
video.cpp.
Scale Max - Smart + Curvature pixel shader + NTSC filter - R/F +
Scanlines - 70% is an incredible sight to behold. So much processing,
yet still easy to get 60fps with perfectly synchronized video and
audio. Add that with the Xbox 360 gamepad, throw in a nice S-MSU CD-
quality soundtrack, and it's nirvana.
Please try out the Scale Max - Smart mode if you are using a
widescreen monitor and let me know what you think.
[No archive available]
This is an experimental release, as such it is posted only to Google Code.
Changelog:
- 21fx API moved to pre-finalized form as S-MSU1; more about this on the forum
- OpenGL driver now uses GL_CLAMP_TO_BORDER instead of GL_CLAMP_TO_EDGE to support screen curvature shader
- rewrote file open dialog; code is greatly simplified, interface is improved
- all cheat code columns are now enquoted, and empty codes at the bottom of the file are omitted (format is compatible with previous releases still)
- debugger: added missing DMA variables to S-CPU properties viewer
- snesfilter: added OpenMP (multi-threading) support to HQ2x filter
- lots of other miscellaneous code cleanup work
Funny, much more effective changes but in a lot less time. The file
dialog is just a major pain in the ass, I guess. Had to sit and think
for at least two hours just to handle the differences between activate
(double-click an item) and accept (click accept button.) Eg if it's a
folder, double-clicking needs to go into the folder, but the accept
button needs to use that folder. But files act differently, load has
the open-folder thing that overrides the default entering of folders,
and saving doesn't have any such concept at all. Fun fun fun, but done
now.
libqb (QbWindow, QbCheckAction, QbRadioAction) is dead; DiskBrowser is
dead; HexEditor is dead. They've all been merged into nall/qt now.
nall/Makefile-qt goes to the more logical nall/qt/Makefile. The last
thing to do is export style sheet defaults into nall/qt to get the
spacing of the new file dialog under control.
Improved the save dialog, instead of putting the entire path in the
box, it only puts the non-directory part, and pulls the directory from
the file system mode's root path. I decided not to allow .. and /
commands inside the save text box. I just strip all that out. Go to
the damn folder you want to save in, sheesh. And before anyone
complains about that, note that bsnes doesn't even use the save dialog
mode :P
Still have to hook up the new folder button to an actual dialog,
haven't bothered yet. Since there's plenty of room with the extended
width, I'm just going to leave them both visible.
nall/qt/hex-editor is pretty much a direct port, no changes. But I
intend to make the height programmable, and fork that into a stand-
alone, super light-weight hex editor to replace bless (so that I can
remove Mono.) Same for check-action and radio-action, direct ports.
nall/qt/window is a bit different, binds the geometry outside the
constructor. This fixes some issues where certain windows weren't
saving their geometry properly, like the debugger properties window.
And I think there's some other advantage to it not needing a
complicated constructor, but I don't recall what at the moment.
Modified GL_CLAMP_TO_EDGE to GL_CLAMP_TO_BORDER, so everyone can try
out the curvature pixel shader now. Added it to my pixelshaders pack,
but I haven't uploaded a new pack yet, so get it from the other thread
for now.
I mainly need testing on the new file dialog stuff. Please let me know
if something strange is broken, other than the new folder button.
Eight hours of non-stop work, for the sole purpose of trying to
separate the file browser underlying mechanics from the bsnes-specific
stuff.
So far, it's going quite well. 95% of the functionality is there with
only 25% of the code size. Forked the underlying stuff to
nall/qt/file-dialog.moc.hpp, which is now designed to support
open+save+folder selection natively. Save mode adds a text box to
enter your own file name, and folder mode hides the filter drop-down
and all files automatically. The top bar now spans 100% of the width.
I like it more this way. I also killed the tree view in favor of a
list view, for the sole reason that I really can't stand how when you
go up a folder and the deeper tree is still open. Since the
QFileSystemModel is asynchronous, I can't close the tree nodes when
navigating up.
The simplifications were needed because it was getting damned-near
impossible to edit that mess of a file (diskbrowser.cpp.) Compare to
filebrowser.cpp, much cleaner. Now I should be able to add open-folder
concept for BS-X, ST and SGB games much easier. And of course, I
should be able to offer the base QFileDialog as an option, too.
After that, I'll probably export the hex editor to a generic class,
and then export the Qb stuff (window geometry save/restore, stock
check / radio menu buttons.)
Also, I just wiped out Windows XP and put Windows 7 back, just to fix
the video tearing issue relating to DWM and ... it works perfectly
fine. Zero tearing, zero skipping, zero audio popping. All I did was
start bsnes v059.04, set audio sync to the usual 31960, and it was
just fine. What the hell are people complaining about, exactly?
For the emulator, I added some missing S-CPU variables to the
properties viewer: all eight DMA channel registers, and $420b/DMA
enable + $420c/HDMA enable. Should probably add the S-SMP timers in
the future.
Updated nall/Makefile-qt to take $(qtlibs) as input, eg qtlibs =
"QtCore QtGui QtOpenGL" and it does the rest to generate $(qtlib) and
$(qtinc) for you. Killed nall/Makefile::ifhas, as it was rather
stupid.
I tried to bind the CPU/SMP/PPU/DSP modules inside of SNES::System,
but it turned out to be a major pain in the ass. I'll have to plan
that a lot more before trying to do that. The ultimate goal would be
having the entire emulator inside class SNES, so that you can
instantiate multiple copies or whatever.
I also updated snesfilter with a nice treat. Inspired by DOLLS'
phosphor code, I added OpenMP support to the HQ2x filter. I have a
dual core E8400 @ 3GHz. With no filtering, I get 177fps. With HQ2x, I
get 123fps. With HQ2x+OpenMP, I get 143fps. Pegs both CPUs to 100%,
heh. And other open applications will interfere with speed, eg
Audacious drops it to 138fps.
Not bad overall though. It should scale even higher on quad cores. And
before anyone asks, no I can't add it to the NTSC filter. I'd have to
talk to blargg about that, and it's already faster than HQ2x anyway.
This is really more a test for things like
HQ3x/HQ4x/Phosphor3x/Phosphor5x in the future. Also, it only works on
Linux at the moment. Need libgomp and libpthread, which I don't have
on Windows.
ZSNES took the approach of putting the filter in another thread while
the next frame is emulated; whereas bsnes forks off new threads when
rendering is hit. I believe the latter is a better approach: it avoids
a 16-20ms latency penalty, it's much simpler, and it can scale up to
240 cores (instead of being limited to two.)
So yeah, I easily have the fastest, smallest, most definitive version
of HQ2x possible right now; so long as you have a quad core :)
[No archive available]
Changelog:
- added folder-up button to the file loading window
- hid new-folder button except on path selection window
- removed "Assign Modifiers as Keys" button; replaced with input.modifierEnable in the configuration file
- fixed a Qt signal issue that was causing ROM loading to take an extra second or two longer than necessary
- scale 5x setting will now maintain an exact multiple in both width and height for both NTSC and PAL modes
- re-added group assignment and unassignment to the input settings window
- re-wrote mouse capture code to be more intuitive, now uses buttons to set assignment
- re-added input.allowInvalidInput check to stop up+down and left+right key combinations by default [Jonas Quinn]
- split "Tools Dialog" menu option into separate items for each tool (Cheat Editor, Cheat Finder, State Manager)
- added S-SMP and S-DSP property information readouts to the debugger
**Known issues:**
- button menus do not show up with Windows Vista/7 theme
- snesreader's multi-file archive dialog box doesn't redraw itself on
Windows when you choose different games
Windows Qt is buggy as always. Nothing we can do but keep waiting. I'm
also going to hold off on including pixel shaders until Direct3D PS
support is in. It's just going to annoy the 98% of users who can't use
them if I include them now. Yes, Windows OpenGL support is that bad.
Anyway, from v058 wip10, the following changes were made:
- cheat code editor grays out the slot#s when they are empty. I can't
put "Empty" in the text boxes for various reasons.
- added "Clear Selected" button and multi-selection support to cheat
editor. This is meant to quickly erase all slots.
- settings and tools windows start at 600x360 when bsnes.cfg is not
found / empty
- fixed the emulationSpeed section to start with input. instead of
config.
- open-folder concept requires the folders to end in .sfc to work now,
once again doesn't care what the ROM inside is named
(this is meant to mimic OS X .app folders)
- 21fx API extended to map to $2200, $2201 for now; mostly as a test
for A-bus access (21fx->VRAM DMA, etc)
(old $21fx registers remain for now)
I intend to release this on Saturday as-is even if a few small bugs
are reported. But if there's something major we can make another RC
build.
We've tested the latest release on at least a dozen computers now, all seems to be in order for a release.
Changelog:
- added 21fx support (more on this later)
- added movie recording and playback support
- added rewind support (enable under Settings->Configuration->Advanced, use backspace key to rewind)
- added speedup (fast forward) and slowdown key bindings
- audio no longer stutters on Windows when moving or resizing the main window
- co-processors can now specify their own clock rates instead of sharing the S-CPU clock rate
- Super Game Boy 2 now runs at the correct hardware speed, and not 2.4% faster like the Super Game Boy 1 does
- added Vsync support to the Windows OpenGL driver (Intel graphics drivers do not support this option, because their engineers are lazy)
- OpenGL driver no longer re-initializes when changing video synchronization, helps pixel shaders
- refactored user interface compilation; now split into several object files, auto-generated MOC files placed under src/obj/
- worked around a bug in the PulseAudio sound server that was causing the ALSA output driver to lock up [BearOso]
- rewrote and simplified the save state manager, it is no longer a part of the core
- S-DD1 and SPC7110 can now access up to 256MB via their MMCs
- re-added background and OAM layer toggling under the tools dialog
- added config file options to adjust emulation speed levels (config.system.speed*)
- added snesreader, snesfilter and supergameboy support to the OS X port
- added a really neat pixel shader that can perform point scaling to non-even multiples, eg it looks great even with aspect correction [Fes]
- upgraded to Qt 4.6.0 official
Debugger changelog:
- added memory export and import to the memory editor
- added bus usage analyzer: logs opcodes, memory reads, memory writes and M/X states to usage.bin file
- added disassembler that can trace both forward and backward from the current execution address
- extended read/write breakpoints to the S-SMP
- re-added trace masking option
Errata: there is one known bug in Qt 4.6.0 that affects the Windows port: menus attached to buttons show up as invisible on Windows Vista and above. I only use this on the file load dialog options button, and only to toggle the information pane on and off. Given that this is less severe than the bugs in the beta versions, I've upgraded anyway. I'll submit a bug report to the Qt team for this shortly. Also, my sincerest thanks to Bradley Hughes from the Qt development team for quickly fixing this show-stopper bug that greatly affected performance in bsnes v056.
I'm really sorry about this, but a major issue snuck into v056. It was caused by a bug in the newly released Qt 4.6.0 RC1. Whenever one moved the mouse cursor over the main window in the Windows port, the frame rate was immediately cut in half, which effectively ruined Mouse, Super Scope and Justifier support. As for how this could happen, well ... I'm ... really at a loss for words about this.
This release does not change the source code at all except to increment the version number, and it is built against Qt 4.6.0 beta 1 instead of 4.6.0 release candidate 1 as v055 was.
I will file an official bug complaint and post a link to it here during next week. Again, my apologies for any inconvenience. I incorrectly assumed it would be safe to update to RC1, and didn't spot the bug in time.
This release adds a lot of new user interface features, and polishes Super Game Boy support.
Note that many pixel shaders need to be coded specifically for bsnes, eg ones designed for Pete's OpenGL2 plugin will not work. I will maintain a pixelshaders archive on the bsnes download page with a collection of working shaders. Right now, there are three: HDR TV, Scale2x and HQ2x; written by guest(r) and Pete, and ported by myself.
Changelog:
- lowered Game Boy audio volume so that it matches SNES audio volume
- fixed Super Game Boy multi-player support
- fixed Super Game Boy swapped player bug
- compressed Game Boy cartridges can now be loaded
- added save state support for Super Game Boy games
- blocked illegal Super Game Boy packets, fixes Zelda DX, Akumajou Dracula, etc palette issues
- main window once again shrinks on size changes
- joypads can now control the file loading window (support is very rudimentary)
- cleaned up video and audio sliders, increased audio input frequency range for 59hz monitors
- rewrote all of the input capture system from scratch
- added dozens of additional GUI hotkey bindings to resize the main window, control synchronization, control speed, etc
- it is now possible to map keyboard modifiers (shift, control, alt, super) to any input or hotkey; eg alt+enter = fullscreen
- merged all input capture windows into the main settings panel
- added turbo button support; hold down turbo buttons to send a 30hz input pulse
- added asciiPad controller emulation; contains off/turbo/auto fire toggles and slow-motion mode
- asciiPad support allows for quick switching between keyboard and gamepad input
- merged scanline filter into the user interface (under Video Settings) to allow it to work on all filters; including the NTSC filter
- killed off an evil QString <> string intermediary class called utf8; string class can convert to and from QString directly now
- added fast BS-X, Sufami Turbo and Game Boy cartridge loading: use the filter list under "Load Cartridge" to bypass the BIOS selection screen
- added pixel shader support to the OpenGL driver on Windows and Linux; note that it only really works well on Linux at the moment
- added proper Vsync support to the OpenGL driver on Windows and Linux using GL extensions; again this really only works well on Linux
- added unique path memory for shaders, folders, cartridges, BS-X, Sufami Turbo and Game Boy images
- upgraded to Qt 4.6.0 release candidate 1; fixes an issue with the first checkbox in lists not updating when clicked
Happy Halloween, this release adds full Super Game Boy support ... but is it a trick, or a treat? ;) ::cough::, lameness aside ...
The Game Boy emulation core is courtesy of gambatte, and excellent, accuracy-focused, open source, and lightning fast Game Boy Color emulator. Now I know what you're thinking, using a Game Boy Color emulator with the Super Game Boy? The truth is, gambatte was just such an amazingly perfect fit that nothing else compared. I fully believe that even as a CGB emulator, gambatte will do a better job than any pure DMG emulator could.
The emulation of the ICD2 chip (aka the Super Game Boy) was fully reverse engineered by myself. Eventually I'll get an updated document put up explaining how it works.
The next question might be, "why emulate the Super Game Boy when existing Game Boy emulators do?"; well, they can only simulate part of the SGB. Features such as custom SNES sound effects, hand-drawn borders, multi-tap support and custom SNES code execution can only be accomplished by a true SNES emulator. Space Invaders is perhaps the most impressive demonstration, as it contains an entire SNES game embedded inside the Game Boy cartridge.
bsnes' SGB emulation supports virtually every command, full sound mixing from both the SNES and Game Boy sides, both BIOS revisions, etc. The only thing that is not fully functional yet is the multi-player support, but it should be in due time. Save state support is also planned for a later date.
Changelog:
- added Super Game Boy emulation (thanks to gambatte for the Game Boy core)
- extended hybrid scanline/cycle PPU renderer to support Mode7 register caching; fixes scanline flickering on NHL '94 title screen
- all windows (other than the main window) can be closed with the escape key now
- file dialog path selection now accepts typed paths; can be used to access hidden directories and network shares
- file dialog's game information panel can now be disabled
- fixed a crashing issue when the file dialog was given an invalid path
- fixed screenshot capture save location
- added screenshot capture option to tools menu
- state manager now auto-closes when loading a state; it can be reopened quickly with F3
- fixed GZip archive loading
- fixed NTSC off-by-one filter bug on hires screens
- extended Scale2x, LQ2x and HQ2x to properly filter hires screens
- added Pixellate2x filter
After a half-dozen hours of installing and compiling various combinations of MinGW and Qt, I've finally found a combination that once again allows for profile-guided optimizations: MinGW GCC 4.3.3 and Qt 4.6.0-beta 1. Though Qt 4.4 still has broken PGO, the latest Qt beta no longer has the process freeze issue upon termination.
This release is essentially the same as v053, but it's now at least as fast as v052 was, and ~10% faster than v053, which lacked profiling.
I did add in two quick changes, however: first, when starting in fullscreen mode, the video output size was being incorrectly set to the windowed size; second, by requiring save states to match the CRC32 of games, it made debugging with them impossible, so I've turned off the CRC32 matching.
This release greatly polishes the user interface, adds a new cheat code search utility, adds the snesfilter library, and adds Qt-based GUI support to both snesfilter and snesreader. snesfilter gains 2xSaI, Super 2xSaI and Super Eagle support, plus full configuration for both the NTSC and scanline filters; and snesreader gains support support for multi-file ROM archives (eg GoodMerge sets.)
Statically linking Qt to bsnes, snesfilter and snesreader would be too prohibitive size-wise (~10MB or so.) I have to link dynamically so that all three can share the same Qt runtime, which gets all of bsnes and its modules to ~1MB (including the debugger build); and Qt itself to about ~2.5MB.
However, there is some bad news. There's a serious bug in MinGW 4.4+, where it is not generating profile-guided input files (*.gcno files.) There is also a serious bug in Qt 4.5.2/Windows when using dynamic linking: the library is hanging indefinitely, forcing me to manually terminate the process upon exit. This prevents the creation of profile-guided output files (*.gcda files.) It would be tough enough to work around one, but facing both of these issues at once is too much.
I'm afraid I have no choice but to disable profile-guided optimizations until these issues can be addressed. I did not know about these bugs until trying to build the official v053 release, so it's too late to revert to an all-in-one binary now. And I'm simply not willing to stop releasing new builds because of bugs in third-party software. As soon as I can work around this, I'll post a new optimized binary. In the mean time, despite the fact that this release is actually more optimized, please understand that the Windows binary will run approximately ~10% slower than previous releases. I recommend keeping v052 for now if you need the performance. Linux and OS X users are unaffected.
Changelog:
- save RAM is initialized to 0xff again to work around Ken Griffey Jr Baseball issue
- libco adds assembly-optimized targets for Win64 and PPC-ELF [the latter courtesy of Kernigh]
- libco/x86 and libco/amd64 use pre-assembled blocks now, obviates need for custom compilation flags
- added a new cheat code search utility to the tools menu
- separated filters from main bsnes binary to libsnesfilter / snesfilter.dll
- added 2xSaI, Super 2xSaI and Super Eagle filters [kode54]
- added full configuration settings for NTSC and scanline filters (12+ new options)
- further optimized HQ2x filter [blargg]
- added Vsync support to the Mac OS X OpenGL driver
- added folder creation button to custom file load dialog
- fixed a few oddities with loading of "game folders" (see older news for an explanation on what this is)
- updated to blargg's file_extractor v1.0.0
- added full support for multi-file archives (eg GoodMerge sets)
- split multi-cart loading again (BS-X, Sufami Turbo, etc) as required for multi-file support
- cleaned up handling of file placement detection for save files (.srm, .cht, etc)
- file load dialog now remembers your previous folder path across runs even without a custom games folder assigned
- windows now save their exact positioning and size across runs, they no longer forcibly center
- menus now have radio button and check box icons where appropriate
- debugger's hex editor now has a working scrollbar widget
- added resize splitter to settings and tools windows
- worked around Qt style sheet bug where subclassed widgets were not properly applying style properties
This is a maintenance release, which fixes a few important bugs. It also adds some graphical icons to soften the user interface. Note that if you have set any custom paths with v051, you'll need to set them again for the fix to work. As always, my apologies for releasing two versions so close together. I felt the bugs were important enough to warrant it.
Changelog:
- fixed loading of files and folders containing non-ANSI characters (Chinese, Japanese, etc)
- fixed a slight lag on startup due to the new file browser
- fixed path selection setting, screenshots will now be saved to the correct directory
- hid memory editor scrollbar since it does not work yet
- disabled window positioning on Linux due to bugs in the Compiz compositor
- added icons from the Tango icon library to the menus and panels
Starting with this release, I wish to take bsnes in a new direction. It has always excelled in accuracy, as the only SNES emulator to offer a full 100% compatibility rate with all known commercial software. But over the years, it has also gained an impressive array of features and enhancements not found anywhere else. It is also the only actively developed SNES emulator with rapid, periodic releases. Its only achilles heel is the steep system requirements, which is quickly being overcome by aggressive new optimizations and steadily-increasing hardware speeds.
In an effort to make bsnes even more accessible to everyone, starting with this release, bsnes is now fully open source software, licensed under the terms of the GNU General Public License. I would like to work toward positioning bsnes as a truly general use emulator, and would welcome any help with this.
Specifically, I am looking for an interested Debian maintainer to package bsnes for Linux users; as well as for anyone interested in helping to optimize and improve bsnes as a whole. It also seems that many still do not know about bsnes, I'd appreciate advice and help on spreading the word. Please leave a message on my forum if you are interested.
I would also welcome and support any forks that target specific areas: a speed-oriented version, a tool-assisted speedrun version, netplay bindings, and so on. As part of this targeting, I've also released a custom debugger-enabled version, which trades a bit of speed in turn for best-in-class debugging capabilities.
Please check back here over the following few days, I'll be writing up documentation explaining all of the various unique features of bsnes, as well as detailed compilation instructions for programmers.
Changelog:
- corrected a small bug in HDMA processing; fixes College Football '97 flickering
- corrected ROMBR and PBR SuperFX register masking; fixes Voxel demo [MooglyGuy]
- DSP-4 driver AI bug fixed [Jonas Quinn]
- added save state support to the S-DD1, S-RTC, DSP-1, DSP-2 and ST-0010 co-processors
- fixed a freeze issue when the S-SMP encounters STOP and SLEEP opcodes
- Cx4 save states no longer need floating-point values, and are thus fully portable now
- added new custom file loading dialog; allows non-modal usage, screenshot previews and ROM info summary, among many other benefits
- added support for IPS soft-patching
- added blargg's File_Extractor library
- added support for archives compressed using 7-zip, RAR and BZip2; which is in addition to existing support for Gzip, ZIP and JMA
- state manager now properly updates the timestamp column on saves [FitzRoy]
- added OpenGL renderer to OS X port
- fixed system beep issue with keyboard input on OS X port
- fixed menubar visibility issue on OS X port
- fixed a Display handle leak on Linux port [snzzbk]
- X-video driver now releases SHM memory properly upon exit [emon]
- fixed Direct3D rendering issue that was blurring video on some cards [Fes]
- enhanced window positioning code for all platforms
- debugger is now GUI-driven instead of via command-line
- memory hex editor is now fully usable
- added PPU video RAM viewer to debugger
- added S-CPU and S-SMP tracing capabilities to debugger
- Qt version upgraded to 4.5.2, and compiled with optimizations enabled; runs faster but makes the binary slightly larger
- too many code cleanups to list
I always regret having to post new releases so quickly, but a semi-major bug crept into v049. I'd rather fix it now, before I start making major changes that will need testing again. The problem was that the S-PPU was not being synchronized as often as it should have been, resulting in titles such as F-Zero and Super Mario Kart showing flickering lines here and there. This release fixes that.
This release also adds savestate support for Mega Man X2 and Mega Man X3, which utilize the Cx4 coprocessor; and it fixes a bug where input was still accepted even when the main window was minimized.
This is a maintenance release, but it offers a lot of bug-fixes and speed-ups, so it should be well worth the update. The debugger is not finished yet, so use it at your own risk. It is disabled in the binary release because breakpoint testing impacts performance. Once it is ready, I will release a separate binary with the debugger enabled.
Changelog:
- Optimized S-PPU emulation, provides a ~10-15% speedup in normal games
- Cleaned up cheat editor user interface
- Added save state and export data path selections
- Added workaround for a strange issue that caused PAL games to run at 60 fps sometimes
- Fixed sprite caching issue; fixes SD F-1 Grand Prix
- Fixed PPUcounter reset issue; fixes Bishoujo Janshi Suchie-Pai [Jonas Quinn]
- Fixed scaling on scanline, Scale2x, LQ2x and HQ2x filters on hires and interlace screens
- Fixed sizeof(bool) serialization issue for PowerPC architecture [Richard Bannister]
- Fixed cheat code sort ordering
- Fixed a bug with centering in fullscreen mode
- Fixed an audio pitch bug when changing frequency
- Fixed a volume adjust bug when frequency was exactly 32000hz
- Fixed X-video RGB rendering bugs [thanks to tukuyomi for testing]
- Fixed a file open dialog issue on Linux when using QGtkStyle [jensbw]
- Fixed a memory corruption issue involving QApplication::main() [giovannibajo]
- Added a preliminary debugger (disabled in binary releases due to associated speed hit)
- Added S-CPU and S-SMP stepping and tracing support
- Added read/write/execute breakpoint support
- Added memory editor (currently it can only view memory)
- Added screenshot capture support [kode54]
- Save state archives are now ~60% smaller than before
- Various code cleanup work, as usual (note: the debugger code is messy, as it is in-progress)
The biggest feature of this new release is the addition of save state support. Note that this is only currently supported for normal games, and the SPC7110 and OBC-1 co-processors. Other special chips, such as the SuperFX and SA-1, cannot currently save and load state files. I will be adding support for other co-processors little by little in future releases.
Changelog:
- Added save state support
- Added SPC7110 and OBC1 save state support
- Added new tools group, with new cheat code and save state managers
- Lots of new UI shortcuts: quick save state, quick load state, show state manager, etc
- Escape key will now close both the settings and tools group windows
- Added major speed-ups to both SuperFX and SA-1 emulation; both now run ~15-25% faster than v047
- Added new video filter, LQ2x; it's as fast as Scale2x while being almost as smooth as HQ2x
- Re-wrote HQ2x algorithm; code size was reduced to less than 10% of its original size with virtually no speed loss
- Corrected SuperFX2 cache access timing; fixes Stunt Race FX menus and slowdown in other titles
- Relaxed palette write limitations for PGA Tour Golf [Jonas Quinn]
- Fixed a slight timing issue that was breaking 'An Americal Tail - Feivel Goes West'
- Turned off auto-save of SRAM as it was causing slowdowns when writing to flash memory; can be re-enabled via bsnes.cfg -> system.autoSaveMemory = true
- Added bsnes.cfg -> system.autoHideMenus, defaults to false; when true, menu and status bars will be hidden upon entering fullscreen mode
- Added skeletons for ST011 and ST018 support. Both Quick-move titles get in-game now
- Re-wrote S-CPU and S-SMP processor cores to use templates, removed custom pre-processor
- Split PPUcounter into a base class inherited by both PPU and CPU; allows both cores to run out-of-order
- Split inline header functions to separate files, allows headers to be included in any order now
The most notable feature for this release is the addition of SuperFX support. This enables an additional eight commercial games, and two unreleased betas, to run with full support. Most notably of these would be Super Mario World 2: Yoshi's Island and Starfox. Though timing is not quite perfect just yet, there should be no known issues with any titles at the time of this release. That means there should only be two official, commercially-released titles that are not compatible with bsnes at this time: Quick-move Shogi Match with Nidan Rank-holder Morita 1 and 2 (using the ST011 and ST018 co-processors, respectively.)
SuperFX support was the work of many people. GIGO was a great help by providing the source code to his SuperFX emulator (for reference; the implementation in bsnes is my own design), _Demo_ was very helpful in getting Starfox to work properly, and Jonas Quinn provided roughly a half-dozen very important bug fixes that affected nearly every SuperFX game. Without them, this release would not be possible. So please do thank them if you appreciate SuperFX support in bsnes.
Please note that SuperFX emulation is very demanding. I hate to have to repeat this, but once again: bsnes is a reference emulator. It exists to better understand the SNES hardware. It is written in such a manner as to be friendly to other developers (both emulator authors and game programmers), and the findings are meant to help improve other emulators. As far as I know, bsnes is the first emulator to fully support all SuperFX caching mechanisms (instruction cache, both pixel caches, ROM and RAM buffering caches, ...); as well as many other obscure features, such as full support for ROM / RAM access toggling between the SNES and SuperFX CPUs, and multiplier overhead timing. By emulating these, I was able to discover what additional components are needed to emulate Dirt Racer and Power Slide, two titles that no emulator has yet been able to run (they aren't very good games, you weren't missing much.) It should be possible to backport these fixes to faster emulators now.
That said, with a Core 2 Duo E8400 @ 3GHz, on average I get ~100fps in Super Mario World 2, ~95fps in Starfox and ~85fps in Doom. Compare this to ~165fps in Zelda 3, a game that does not use the SuperFX chip. My binary releases also target 32-bit x86 architecture. For those capable of building 64-bit binaries, especially Linux users, that should provide an additional ~10% speedup. Be sure to profile the application if you build it yourself.
Lastly on the SuperFX front, note that Starfox 2 is fully playable, but that most images floating around have corrupted headers. I do not attempt to repair bad headers, so these images will not work. Please either use NSRT on the Japanese version, or use Gideon Zhi's English fan translation patch, if you are having trouble running this title.
With that out the way, a few other improvements have been made to this release: xinput1_3.dll is no longer required for the Windows port (though you will need it if you want to use an Xbox 360 controller), the video drivers in ruby now allocate the smallest texture size possible for blitting video, and the code has been updated with preliminary compilation support for Mac OS X. Note that I will not be releasing binaries for this: it is primarily meant for developers and for porting my other libraries to the platform. Richard Bannister maintains a much better OS X port with full EE support and a native Apple GUI that follows their interface guidelines much better than a Qt port ever could. He has also synced the Mac port with this release. You can find a link to that in the bsnes download section.
Unfortunately, I was not able to include any actual Super Game Boy support in this release. I was however able to back-port all other changes since v045, as well as add a lot of new stuff. Though there are few visible changes from the last release, internally much has changed. I'm releasing this mostly as a point release whilst everything should be stable.
I've decided to support the Super Game Boy via external DLL (or SO for Linux users.) There are many reasons for this. Most notably is that the largest special chip in bsnes right now weighs in at ~30kb of code. Emulating an entire Game Boy, not including the SGB enhancements, would require an additional ~800kb of code, or nearly half the size of the entire SNES emulation core. Add to that potential issues with licensing, conflicts with the build process / namespace, a significant increase to build time, and a lack of flexibility over which Game Boy emulator to use, and it's pretty clear that this is something best left external. At least until we have a fully trimmed, fully working SGB emulator available.
The way this will work is bsnes will look for SuperGameBoy.(dll,so), and if present, it will call out to pre-defined functions. Users will need the SGB BIOS loaded, at which point they can select a Game Boy cartridge, and bsnes will use the DLL for actual emulation. Sadly I don't have a working DLL ready for this release, and even if I did, there's no sound bridge yet for the Game Boy audio.
Other than that, much of the core has been updated in an attempt to make the core more library-like. It still has a few major limitations: it requires libco (which is not portable) and nall (which is quite large), and only one instance can be instantiated as all of the base objects are pre-defined and inter-linked. Not that I can imagine any practical use for multiple simultaneous SNES emulators anyway ...
Changelog:
- Save RAM is now automatically saved once per minute
- Added delay to Super Scope / Justifier latching to fix X-Zone
- Fixed an edge case in CPU<>PPU counter history
- S-CPU can now run up to one full scanline ahead of S-PPU before syncing
- Added interface for Super Game Boy support (no emulation yet)
- Fixed a bug with path selection not adding trailing slash
- All S-SMP opcodes re-written to use new pre-processor
- Entire core encapsulated into SNES namespace
- Core accepts files via memory only; zlib and libjma moved outside of core
- Major Makefile restructuring: it's now possible to build with just "make" alone
- Linux: libxtst / inputproto is no longer required for compilation
- Lots of additional code cleanup
This is a maintenance release to fix a crashing bug in S-DD1 games (Star Ocean, Street Fighter Alpha 2), and a video issue in games using the WAI instruction.
As always, my apologies for any inconvenience. SA-1 support required modification of a large amount of delicate code in the emulation core, and our limited testing team was not able to catch these in time before release.
This release adds full SA-1 support, with no known issues. All 26 games have been tested by myself and others, and a few have been beaten from start to finish. The latter include Super Mario RPG, Kirby's Dreamland 3, Kirby Super Star and Jikkyou Oshaberi Parodius.
Please understand that the SA-1 is essentially four times faster than the SNES' main CPU, so system requirements will be very high for these games. For example, on an E8400 @ 3.0GHz, I average ~160fps in ordinary games. But for SA-1 emulation, this drops to ~90fps, with the worst case being ~80fps.
The following features are emulated:
- 5a22 CPU core (bus-cycle accurate)
- Memory access timing
- SA-1 -> S-CPU interrupts (IRQ + CHDMA IRQ)
- S-CPU -> SA-1 interrupts (IRQ + Timer IRQ + DMA IRQ + NMI)
- SIV / SNV interrupt vector selection
- Timer unit (linear and H/V)
- Super MMC unit (ROM + BW-RAM)
- BS-X flash cart slot mapping
- Normal DMA
- Character-conversion 1 DMA (2bpp + 4bpp + 8bpp)
- Character-conversion 2 DMA (2bpp + 4bpp + 8bpp)
- BW-RAM virtual bitmap mode (2bpp + 4bpp)
- Arithmetic unit (multiplication + division + cumulative sum)
- Variable-length bit processing (fixed and auto increment)
While the following features are not currently emulated, mostly due to lack of information:
- SA-1 bus conflict delays
- Write protection (BW-RAM + I-RAM)
- SA-1 CPU priority for DMA transfers
- DMA access timing
New WIP. Wasted two and a half hours trying to figure out why re-
implementing IRQs at home was failing in Parodius. Finally just
reverted to wip05 and started again, changing one line at a time.
Turns out I inverted the reset release flag by mistake for the SA-1
CPU. Fun.
Adds S-CPU -> SA-1 IRQs, DMA IRQs and NMIs + SA-1 -> S-CPU IRQs +
CH1DMA IRQs. Also slightly improves variable bit-length reading and
removes DPRIO mode for now until I can test it properly.
Parodius, SRW: Gaiden and Kirby: SS should all be fully playable now.
Mario RPG is damn close, but it freezes immediately after you exit the
level up bonus screen. I don't have any idea what it wants. The
graphics on the bonus screen don't show up either, as I don't support
char conversion modes 1 or 2 yet (it uses mode 1.)
How annoying ... first the graphics on the logo are bad. Add the ALU,
good. Now the title screen background is black. Fix the ALU MA
register reset, good. Now it freezes after the first intro scene. Add
SA-1 -> S-CPU IRQs. Now it freezes half-way through the intro. Fix
S-CPU /IRQ line holding from the SA-1. Now it freezes at the start of
the level up bonus screen. Add CHDMA IRQs. Now it freezes immediately
after the level up bonus screen.
I have no idea what the hell SIV / SNV are for. I'm guessing the SA-1
controller detects which processor activates SA-1 IRQs and uses that
vector address ...? It obviously can't over-ride the S-CPU's vector
addresses.
Documentation is shit. It doesn't specify what vectors DMA / CHDMA
use, or what to do without specific general DMA / CHDMA IRQ enable
flags in the control registers, and on and on.
[No archive available]
New WIP. Copy-paste:
> Working on SA-1, still a long way to go. Fixed a bug where I was
> clearing MA after multiplication / cumulative sum when I wasn't
> supposed to. Fixes Kirby 3 Pop Star scene.
> Added normal DMA, along with full support for DPRIO (allowing DMA to
> run alongside the SA-1 CPU) and blocking of invalid transfer types /
> modes. This fixes sprites in Marvelous.
> Also added BW-RAM bitmap mirroring to $[60-6f]:[0000-ffff], proper
> mapping for the bitmap mode to the $[00-3f|80-bf]:[6000-7fff]
> regions, variable-length bit read data port, and I now at least
> cache the register settings for IRQs (though I still do nothing with
> them.)
> I added support for BW-RAM and I-RAM write protection, but when it's
> enabled, most games will no longer load. So I'm forced to leave that
> off for now. Maybe the protection didn't actually work on the real
> hardware? Hmm ...
> No idea what the bitmap registers $2240-$224f are for, and I don't
> see how it's supposed to be possible to trigger IRQs as needed by
> Super Mario RPG and Parodius. But at least three of five games
> should now be fully playable with no issues. Speed remains the same
> as yesterday. No hit for the SA-1 CPU+DMA simultaneous transfer mode
> support.
Image Image
> I want pictures of SRW Gaiden!
Can always try it and see what happens ... after I get some sleep :D
[No archive available]
I mentioned I wouldn't be posting a new WIP for a while so that I
could work on something in secret. That way in case it didn't work
out, nobody would be bummed out. Imagine my surprise when it only took
me two days to get this far ...
Image Image
Image Image
Image Image
(I removed the title-bar text for the sake of the screenshot
aesthetic. Check the WIP yourself if you don't believe it.)
Kirby's Dream Land 3 and Dragon Ball Z: Hyper Dimension are fully
playable. Note that most games aren't playable, and most of the chip's
added features are missing.
Speed took a ~3-5% hit for non-SA1 games due to all the new co-
processor thread synchronization primitives that you can't really hide
from inlined, super-intensive sections of the scheduler code.
As of now, and this will change, SA-1 games run about ~60% slower than
normal games. Meaning you'll really want at least an E4500, but
preferrably an E8400; and no filters.
The most impressive part is that I emulate this at the bus/clock
level. Meaning if both the S-CPU and SA-1 access RAM at the same time,
they'll see the changes and stay perfectly in sync. I even emulated
the bus conflict resolution of the SA-1 memory controller. So in terms
of accuracy, this is akin to the cycle-level S-PPU. It's the
"theoretical worst case" for the most processor-intensive, lowest-
possible emulation achievable.
I believe it was _Demo_ who speculated that it'd take at least a 10GHz
processor to achieve this. Then again, it's been so long I could be
attributing the quote to the wrong person. Don't even remember the
exact words anymore. Anyone recall?
This gives us insight into the kind of performance we can expect from
the cycle-PPU (also runs at 10.74MHz) and SuperFX. For SA-1+cycle
S-PPU, it would appear that there is no processor on the market that
can maintain full speed with that combo yet, heh. By the time I get
around to S-PPU, there most likely will be though.
Lastly, don't bug me about SuperFX support because of this. This SA-1
support is a simple subclass of the core S-CPU that already existed in
cycle-perfect, bug-free form; plus a memory mapper and ALU. Lots more
to go, and even then, this is easily multiple times less work than the
SuperFX is going to be.
[No archive available]
New WIP. The entire S-CPU opcode core has been re-written to use my
new pre-processor.
The downside is that it's actually slightly slower, by less than 1%.
Guessing that having almost twice the opcode implementations ends up
eating more valuable L1 cache, making it more painful than the two
conditionals per function I had before. But damn if it isn't more
readable now.
Before:
ror_addrx(0x7e, ror) {
1:aa.l = op_readpc();
2:aa.h = op_readpc();
3:op_io();
4:rd.l = op_readdbr(aa.w + regs.x.w);
5:if(!regs.p.m) rd.h = op_readdbr(aa.w + regs.x.w + 1);
6:op_io();
if(regs.p.m) { op_$1_b(); }
else { op_$1_w();
7:op_writedbr(aa.w + regs.x.w + 1, rd.h); }
8:last_cycle();
op_writedbr(aa.w + regs.x.w, rd.l);
}
After:
@macro op_adjust_addrx(name)
void {class}::op_{name}_addrx_b() {
aa.l = op_readpc();
aa.h = op_readpc();
op_io();
rd.l = op_readdbr(aa.w + regs.x.w);
op_io();
op_{name}_b();
{lc}op_writedbr(aa.w + regs.x.w, rd.l);
}
void {class}::op_{name}_addrx_w() {
aa.l = op_readpc();
aa.h = op_readpc();
op_io();
rd.l = op_readdbr(aa.w + regs.x.w + 0);
rd.h = op_readdbr(aa.w + regs.x.w + 1);
op_io();
op_{name}_w();
op_writedbr(aa.w + regs.x.w + 1, rd.h);
{lc}op_writedbr(aa.w + regs.x.w + 0, rd.l);
}
@endmacro
( note: {lc} is short-hand to 'hide' last_cycle(); )
Really worn out now, so don't expect a new WIP for quite a long time
I'm afraid. I'll worry about the S-SMP's core much later. Would
appreciate thorough testing. Given I rewrote all 256 opcodes by hand,
it's possible I made a mistake somewhere.
> Once Alt has been pressed to access the menubar (even just one
> time), the menu accelerator keys become functional even without
> pressing them together with Alt.
Wow ... that is quite alarming. Not sure why Qt is doing that. But
since I don't have a way of fixing it yet ... for now:
> Stop pressing alt.
:/
[No archive available]
New WIP.
Updated centering code, it now just has per-platform centering code.
So it should look great with no flickering / movement on Windows or
Linux.
Fixed the patching status thing so it won't say it patched when it
fails. But seems there's not enough safeties in nall::ups. A patch of
nothing but "UPS1" has a 50% chance of crashing the emulator.
Most importantly, I finally got around to writing my pre-processor,
which is intended to add macro support to both C++ and xkas. Calling
it bpp, for **b**yuu's **p**re-**p**rocessor.
I started rewriting the S-CPU opcodes to use the new pre-processor. 40
of 256 opcodes finished. I'm also separating the 8-bit and 16-bit
versions this time. Twice the code, but it's easier on the eyes.
Old:
ldy_addrx(0xbc, ldy, regs.p.x),
ora_addrx(0x1d, ora, regs.p.m),
sbc_addrx(0xfd, sbc, regs.p.m) {
1:aa.l = op_readpc();
2:aa.h = op_readpc();
3:op_io_cond4(aa.w, aa.w + regs.x.w);
4:if($2) last_cycle();
rd.l = op_readdbr(aa.w + regs.x.w);
if($2) { op_$1_b(); end; }
5:last_cycle();
rd.h = op_readdbr(aa.w + regs.x.w + 1);
op_$1_w();
}
New:
@macro op_read_addrx(name)
void {class}::op_{name}_addrx_b() {
aa.l = op_readpc();
aa.h = op_readpc();
op_io_cond4(aa.w, aa.w + regs.x.w);
last_cycle();
rd.l = op_readdbr(aa.w + regs.x.w);
op_{name}_b();
}
void {class}::op_{name}_addrx_w() {
aa.l = op_readpc();
aa.h = op_readpc();
op_io_cond4(aa.w, aa.w + regs.x.w);
rd.l = op_readdbr(aa.w + regs.x.w + 0);
last_cycle();
rd.h = op_readdbr(aa.w + regs.x.w + 1);
op_{name}_w();
}
@endmacro
@global class sCPU
@include "opcode_read.bpp"
@op_read_addry(ldx)
@op_read_addry(ora)
@op_read_addry(sbc)
Yes, I know the above can be done with the C pre-processor. Two major
reasons I avoided it:
1) I refuse to put \ after every line.
2) parameters are limited, eg MACRO(&=~, x += 2) would not work.
The important thing was making a more generic / flexible format. Will
allow me to kill off src/tool, though I'll still include the new
parser's source under src/lib/bpp.
May extend bpp in the future, who knows. @if/@else/@endif would be
nice, as would nested macros and static programming functions.
[No archive available]
A new release quite a bit faster than I was expecting, but a lot has changed. Most importantly is a new Windows input driver, "RawInput". The downside is that this makes bsnes require at least Windows XP, as Windows 2000 and earlier lack RawInput support. The upside is that input from multiple keyboards and mice can be distinguished from each other — very useful for dual-Justifier support in Lethal Enforcers. Users of previous versions of bsnes will need to manually select the new driver via Settings->Configuration->Advanced->Input driver, and will need to re-map all assigned input keys, including the default user interface hotkeys. Or alternatively, delete the configuration file under %APPDATA%\.bsnes or ~/.bsnes.
Also new is an XInput driver, which avoids the DirectInput driver limitation of being unable to distinguish the two shoulder trigger buttons. This makes bsnes require DirectX 9.0c or later for the necessary drivers. Note that Windows Vista SP0 does not ship with these, so if you haven't installed it yet, you'll need to do so. This driver is part of the "RawInput" driver mentioned above.
This part is important: if you receive an error regarding xinput1_3.dll, you need to download and install the DirectX 9.0c run-time.
For those on Windows 2000, or without DirectX 9.0c, it is still possible to compile and run bsnes with the older DirectInput driver only; but I won't be providing a binary myself for this — at least not at this time.
More bad news for some: hiro, my Win32 / GTK+ API wrapper, has been discontinued and removed from the source tree for this release. Qt 4.5.0+ is now required for the user interface. Very sorry to the Linux distros that do not have packages for QT 4.5 yet. You'll need to continue with v041 for now.
Okay then, if everyone possible could test this _quickly_, I can post
a new release tonight. Especially the input mapping, and especially
there for gamepads / controllers.
http://byuu.org/files/bsnes_test.zip
No source, Windows only binary.
If you get an error about xinput1_3.dll, install the DirectX 9.0c
redistributable.
Changes from last WIP:
- I was able to reproduce FitzRoy's issue, and fix it. Really, really
crappy gamepads that send large phantom movements when the user isn't
even touching the axes may trigger the calibration window early; not
much I can do about that. None of my controllers do this at least.
- I updated the mouse button capture window. It now uses a framed
label (kind of like a groupbox but with text in the center), and you
have to release a mouse button inside the box for it to map.
- Screensaver / monitor power saving disabled on both Windows and
Linux.
- More improvements to window centering.
> Btw, are you on SP1 like me?
No, I'm using Windows 7 beta 1.
[No archive available]
New WIP.
Rewrote a large portion of the RawInput driver, cleaning it up
substantially. Each API is now its own separate class, and pInputRaw
(the ruby private implementation class) pulls data from each separate
driver.
For keyboards, I've added the fixes for print screen and
pause/num_lock.
For joypads, I added XInput controller detection through RawInput's
RIDI_DEVICENAME, instead of that crazy ass COM + wbem shit from MSDN.
I also added a proper XInput driver, so now the left and right axes
can be mapped independently, and you can use both at the same time.
All in all, quite expensive and a lot of work, but it's the little
bits of polish that really make an application shine.
Do note that MinGW still doesn't ship with libxinput.a -- it's only
been out for four years now, after all. You'll need to take XInput.lib
from the DX9 SDK x86\lib folder, copy it to MinGW\lib, and rename it
to libxinput.a. I'm surprised that works, but it does. I tried to use
LoadLibrary("xinput1_3.dll") + GetProcAddress("XInputGetState"), but
the app kept crashing in bsnes when optimizations were enabled. gdb
showed it to crash in msvcrt!memcpy() from inside dinput8.dll. No idea
what the hell was going on there.
Non-XInput controllers will fall back on using DirectInput, of course.
Fixed the joypad indexing, so multiple joypads should work again. Got
the window centering hopefully right on WinXP so that windows opening
for the first time won't 'flicker' anymore. Added the mklib(gdi32)
entry, so you can compile with -mconsole again.
Re-did the mouse capture stuff. 'Assign Mouse Button' + 'Assign Mouse
Axis' are now buttons instead of menu buttons.
For button assignment, you are given a window with a large disabled
button named '(capture box)'. The instructions say to put whatever
mouse you want over this button and click the mouse button that you
want to assign. It'll assign upon release. Right now, assignment won't
work for 1-2 seconds to prevent instant assignment when you click.
I'll make a button mask in the future to avoid that delay. Also, it
only verifies you clicked a mouse button while the capture window was
active. I'll need to look into Qt's methods for mapping cursor clicks
to control regions onscreen. Good news is it's now much easier to
assign extended buttons like up+down ... you don't have to know what
button #s they are anymore.
For axis assignment, mapping based on mouse motion is too dangerous.
So you get a window with two buttons: 'X-axis' and 'Y-axis'. I can add
Z-axis if anyone wants (for the scroll wheel), but it seems kind of
useless. The instructions say to click the axis button you want, with
the mouse you want the axis assigned to.
Now I know the instructions will probably just confuse people with
only one mouse (~99% of users), so if everyone really thinks it'd be
better to leave multi-mouse users in the dark about how the capture
system works, I can take out the verbose notes.
Hoping your controller will work now, FitzRoy. Otherwise I have no
idea what's wrong. Be sure you manually set the driver to RawInput,
too. Will most likely require a config file with "version = 42",
otherwise reset to defaults, for the next release.
[No archive available]
New WIP. This version adds RawInput support.
I strongly recommend just deleting the old config file, because all
the old bindings won't work. You may also need to select the driver
manually from the advanced tab (it should be the default if no config
file is found.)
I now allow up to sixteen keyboards, sixteen mice and sixteen joypads
to be uniquely identified and independently mappable. So if anyone
wants to setup a 6-man-per tag-team game of N-warp Daisakusen, now you
can. And $50 for the first person to take a picture of said event for
me ;)
While ZSNES beat me to mouse support with ManyMouse, I win with
"ManyKeyboard" :P
And if anyone wants to get me one of those SNES barcode battler games
+ hardware, I'll try and emulate a generic USB HID barcode scanner.
Let's see ... currently the mouse assignment from the UI won't work.
You'll need to edit bsnes.cfg. The format is:
mouseNN.x, mouseNN.y, mouseNN.z, mouseNN.buttonXX
NN = 0 - 16, XX = 0 - 4
Need to plan how I want to design a mouse capture window, so that will
be a while still.
Also didn't get around to the screensaver disable code just yet. Took
me seven hours straight and I just barely finished the RawInput driver
in time.
Testing would be greatly appreciated.
[No archive available]
Meh, window is appearing on XP when placed at -1,-1. Changed that to
2560,1600 to stop that initial flicker before the windows appear
centered. Also from the WIP I made it use showNormal() so it'll show
windows even if they were previously minimized.
> Some people prefer baby seal meat.
I'm still not following your point. I've already added it. It took me
a few days but it's done. Everything that worked before is exactly the
same, but you now have the _option_ of doing more. Binary size is the
same, source code grew by ~2k (mostly due to extreme commenting.)
Not necessary, no; but I wanted it. Now we have it, and it's one more
bit of polish (along with infinite cheat codes, infinite length
descriptions in UTF-8, cheat code grouping and sorting, UPS support,
single or multi user modes, resizable config windows, flexible theming
and backdrop images, ...) that no other SNES emulator has yet :D
And tons of stuff I'm missing: savestates, rewind, SuperFX, SA-1,
speed, macros / key combos, movies, netplay, ...
-----
This works well enough for Windows:
class Application : public QApplication {
public:
#ifdef _WIN32
bool winEventFilter(MSG *msg, long *result) {
if(msg->message == WM_SYSCOMMAND) {
if(msg->wParam == SC_SCREENSAVE || msg->wParam ==
SC_MONITORPOWER) {
printf("blocked sleep\n");
*result = 0;
return true;
}
}
return false;
}
#endif
Application(int argc, char **argv) : QApplication(argc, argv) {}
};
Add XTestFakeKeyEvent sans XSync (to avoid X-Video stuttering issues
per BearOso) and screensaver disable should be taken care of -- at
least until someone works on the OS X port.
[No archive available]
Okay, new WIP. That's the best I can possibly do.
For all six axes, I now ignore input until the state changes for the
first time. If it goes from 0 to > 24576 in a single poll, it
considers the axis to be a button. Otherwise it treats it as a stick.
Positive on a stick means down or right, so it's less likely users
will hit this first (up, left are more common for assignment as
they're first in the control lists.)
To minimize the damage of a bad map, I now map each axis to their own
value without regard for axis vs analog button indexing. Eg you will
have { axis00, axis01, analogbutton02, analogbutton03, axis04, axis05
} instead of { axis00, axis01, analogbutton00, analogbutton01, axis02,
axis03 }. That way if you do screw up the mapping and restart, the
indexes won't change on you. I don't do that on Linux to allow as many
axes + analog buttons as possible, and because it's not needed.
I had to choose what to bias, so I went with axes as they seem more
important overall. Eg -32768 to +24575 = stick; +24576 to +32767 =
button. That means it's easier to map a button as an axis than vice
versa.
It's unfortunately still quite easy to map these incorrectly, eg if
you slam down on a button or smack a stick as hard as you can down or
to the right.
But it was basically ... have a chance of mapping inputs wrong, or
don't let them be mappable at all. The former seems better in that
case.
If _anyone_ has a proper solution for this problem, I'd greatly
appreciate it. In fact, let's put a bounty on it. I'll pitch in $20
for the solution (a way to get the true state of axes without
requiring the user to press a button first.)
I also used EnumObjects over all absolute axes to map them to -32768
to +32767. That should help with the Xbox 360 controller that defaults
to half that range or whatever (fuck you, XInput.)
Testing would be appreciated. Both for the Windows and Linux ports,
though I can't foresee there being any problems with the Linux one.
---
SDL on Win32 does the same thing ... not surprising since it just uses
DirectInput anyway.
#include <SDL/SDL.h>
SDL_Joystick *gamepad;
int __stdcall WinMain(HINSTANCE, HINSTANCE, LPSTR, int) {
SDL_InitSubSystem(SDL_INIT_JOYSTICK);
SDL_JoystickEventState(SDL_IGNORE);
gamepad = SDL_JoystickOpen(0);
while(true) {
SDL_JoystickUpdate();
unsigned axes = SDL_JoystickNumAxes(gamepad);
for(unsigned n = 0; n < axes; n++) {
printf("%d = %6d; ", n, SDL_JoystickGetAxis(gamepad, n));
}
printf("\n");
}
return 0;
}
[No archive available]
New WIP.
This adds support for hats and analog buttons, and fixes the centering
code so that it never ends up minimized on Linux at startup. Just went
back to putting the window offscreen before centering, as thanks to
the delay in propagating window messages in Xorg, you don't even
notice the flicker on Linux.
You can now have up to 8 hats, 16 axes, 16 analog buttons and 96
digital buttons. Just to future proof things. If your controller has
more than that ... then I demand you send it to me before I'll support
it.
SDL input for Linux should work fully: hats allow four unique inputs,
axes two and analog buttons one. It calibrates to tell the difference
when you start the emulator.
DirectInput doesn't work so well. The DIJOYSTATE2 struct has a ton of
analog inputs, but only lX/lY map to the first stick, and lRx/lRy to
the analog buttons. But I can't even detect those properly because for
some bastardized reason, polling them at startup returns 0, 0. It
isn't until the user presses at least one button that the controller
'snaps out of it' and returns the proper +32767,+32767 for the two
buttons.
On the bright side, DI treats POV hats like POV hats. It allows up to
four, so that's what you get. You'll have to deal with that or the
first analog stick for Windows.
Unless there's a DirectInput expert here, not sure I can fix this. The
other inputs are not in DIJOYSTATE2 at all. Yet somehow the control
panel applet can sense them.
Mapping is fully inclusive, for joypad buttons and UI shortcuts, you
can use keyboard buttons, mouse buttons, joypad buttons, joypad axes,
joypad hats, joypad analog buttons. For mouse / super scope axes, you
can use mouse axes and joypad axes. Buttons aren't bi-directional and
lack the precision to support the mouse / SS / Justifier to any usable
degree, and analog buttons are uni-directional.
> Have you thought about rendering plugins for sound, input, video?
Would rather not. Cross-platform dynamic library support is terrible.
> Hmm must be "spin the black circle" as far as I can tell.
Yeah, here. I posted about it here a while back. Probably should've
mentioned the name.
> Yeah. That cheating nonsense discourages me from really playing any
> online games with top scores like that. It sucks all the fun out of
> it.
It's usually okay when it's painfully obvious. I cleared every level
at least a dozen times, and took advantage of every collision quirk
there was to get time there. For there to be a > 30 second leap
between #4 and #5 (and #1-4 all from the same person), it's pretty
obvious that he was cheating in some way.
I consider the best time to be 03:58, and 04:06 (edit: 4:01:97 now) is
close enough to make me happy :D
[No archive available]
New WIP.
I've added the centering code. Had to hide and show the window to
prevent the Windows 'restore-from-taskbar' animation. That's causing
Xorg events to not propagate quickly enough so sometimes the windows
start minimized. I'll keep working on it.
I've also killed joypad<>::up, down, left, right; and added
joypad<>::hat<0-3>.
So far, I've adapted the Qt UI to map analog axes. You'll see now when
you map one that you get ::lo or ::hi to indicate the state direction
at the time of assignment. I have not done this for hats, so only the
'up' direction will map currently.
I only know how to read the first two axes (first stick) on Windows,
so it won't see any others yet.
For the mapping, I made it both range-sensitive (requires at least 75%
force to map, 50% force to trigger) and distance-sensitive (prevents
auto-assignment for those annoying analog sticks that flicker within a
few points in any direction; also protects against those sixaxis
buttons that are idle at +32767) -- the distance is at 512, and slow
movement causes ~1,000+ movement based on ~20ms sampling, should be
enough.
To prevent rapid assignment of the same analog axis when using the
"Assign All ..." button, and because it makes no sense to allow it,
I've added a check to make sure that each key assignment is unique to
all previous ones. This doesn't apply to individual assignment in case
you really do want one key to map to two inputs. It was that or add a
~200ms delay between each assignment.
The only thing my emulator doesn't handle completely are those six-
axis buttons. Mostly because I have no way of telling what they are. I
can't tell if a user is holding a stick south-east, or if it's a
button not pressed. You can map them anyway, but it won't work as you
expect a button to.
Lastly, I'm not sure how to support mouse pass-through just yet. Right
now I block mouse input when the mouse isn't exclusively acquired. If
I don't, then clicking to acquire the mouse will send a 'fire' command
to the emulator. But if I do, then you can't use a mouse as a joypad.
[No archive available]
New WIP.
I _may_ have found the SDL POV hat issue. I was masking a result, but
the array wasn't boolean. It may work better now.
I've also dropped the analog -> D-pad mapping in both drivers. It just
doesn't work ... some controls treat the D-pad as a mirror of the main
analog axis, some treat it as a POV-hat, some treat it as its own
'analog' axis (that only returns -32767, 0 or 32767).
What this means is that for now, no mapping of analog sticks will work
correctly. I'm going to have to adapt the mapping system to
accommodate these.
I also added an 'Assign All ...' button to the input capture window.
Note that it is grayed out on 'User interface' items. Although I
could, it makes no sense to quickly assign all of those (as most you
won't want mapped to anything at all.)
I'm thinking about re-ordering the list from:
Up, Down, Left, Right, A, B, X, Y, L, R, Select, Start
to:
Up, Down, Left, Right, Y, X, B, A, L, R, Select, Start
Reason being that it's more natural with the layout of the real
controller. Agree or disagree?
Oh, and I fixed the NTSC merge settings thing. Takes effect
immediately too.
[No archive available]
I apologize for posting a new version so quickly. This is mostly a maintenance release: joypad analog axes can once again be mapped to the mouse / super scope axis controls, the input capture window has been rewritten to be much more compact, and I've omitted all unneeded features of Qt 4.5 to reduce the final binary size as much as possible (from ~3.33MB to ~2.3MB.) The source archive is also ~20% smaller.
Barring any unforseen problems, this will likely be the last official release for a while.
Also, I finally have dedicated hosting for byuu.org. I ask that you please update any bookmarks to point here, rather than to byuu.cinnamonpirate.com from this point on, as we'd like to free up the cinnamonpirate sub-domain slot.
Too much to really name. The biggest news is that the entire user interface has been re-written from scratch. It is now far more polished and professional. To name one example; the cheat code editor now has checkboxes in the list to quickly toggle codes on an off, there is now a global hotkey to toggle all cheat codes, and each cheat code can contain multiple individual Game Genie or Pro Action Replay codes, allowing easy grouping of multi-part codes.
You'll also notice new artwork: a logo created by Derrick Sobodash (note that the logo contest from below is still active — if someone can design a better logo, it can appear in v041), and a new photo-realistic SNES controller graphic by FirebrandX.
I was finally able to utilize MinGW's profile-guided optimizations, which means this release is approximately ~12% faster than v039.
And emulation itself was even improved(!), such as with Jonas Quinn's fix for a sprite overflow bug.
There were many other changes as well: Linux users will be happy to see RGB overlay support for the X-Video driver, many will benefit from greatly enhanced warning messages and tooltips throughout the GUI, Windows users will now be able to access the menu without freezing emulation, etc etc.
New WIP.
Softened the panel titles a lot, they take less space but still stand
out well enough.
Should I add a checkbox+global hotkey to toggle the cheat code system
itself on and off? Ala the flip switch that's on the real Game Genie.
Not sure if it's as important anymore now that it's easy to group
multiple cheat codes together and toggle them with just one checkbox.
If so, I need a caption for the checkbox widget, eg "Enable cheat code
system", but something more descriptive.
Rewrote a couple chunks of the nall::string library. I had a lot of
problems with casting due to things like this:
int strdec(const char*);
string strdec(int);
string::operator int();
string::operator const char*();
string::operator=(int);
string::operator=(const char*);
string::operator<<(int);
string::operator<<(const char*);
string::string(int);
string::string(const char*);
It couldn't implicitly determine if string() << 0 should refer 0 as
const char* or int. So I started by dropping the string->integer
implicit conversions, no need for those, use the strTransform(string)
functions instead. More verbose of the format you want anyway (eg
signed or unsigned integer).
Next, rather than try and implement signed+unsigned+signed
short+unsigned short+signed char etc etc for string::operator= +
string::operator<<, I instead wrote them to use templates. Worked
around the limitation that classes can't use explicit template
specialization by using global thunk functions. operator<<, operator=
and lstring::operator<< all share one set of template specialization
functions to perform conversion of any supported type to a string for
assignment or appending. Pass an unsupported type and it will throw a
"template function undefined" error and fail to compile. No run-time
surprises.
I was careful to implement the copy constructor and copy operator= to
stop the compiler from generating its own functions that copy around
the raw pointer (which would lead to memory leaks + double memory
frees.) So it should be 100% leak proof.
I also split strdec(int) into strsigned(signed) and
strunsigned(unsigned); and updated all the other stuff that used the
lib for that (eg nall::config et al), so you can now perform
unsigned->string conversions on UINT_MAX without getting back -1.
Only thing I'm debating now is if I want to trade C compatibility for
speed and store the string lengths inside the string class for O(1)
length + append functions, compared to their O(n) now. Multiple
chained appends raise that to O(n^2), but with ~20 appends at most per
string, it's hardly a bottleneck right now.
I'm hesitant to do this, because if I do, I'll have to remove char*
operator()() to give a raw handle to the string pointer. I use that
for quick libc const char*->string& wrapper functions, and it's also
nice for other functions to use. And char& operator[](size_t) would
take a hell of a speed hit for having to check for '\0' writes to
adjust the length internally.
_Not_ going to allow storing '\0' directly ala std::string, and make
string::c_str() require memory allocation. Fuck that. Use an
appropriate binary container if you want '\0' inside a block of
memory. The whole idea of nall::string is to maintain 100%
compatibility with C89 strings and their functions.
[No archive available]
New WIP.
I added FirebrandX's controller image (let me know if you don't have
the WIP link and want to check it out, FB.)
I also added Derrick's SVG logo for now. The contest thing isn't over
yet, and I like DMM's the best so far (sans the aliasing issues.) But
the auto-resizing to exactly what I want is too nice to pass up. I
think I'm going to require SVG for the final submission at this point.
Side note: Qt supports SVG for auto-scaling, but I use a PNG anyway as
not all Qt libs are going to have SVG support built-in. I still want
SVG for website / print purposes.
For belegdol, I added SDL hat support. It only works with the first
hat, as I figured those four-controller-as-one-device cheapass drivers
might not work well if every single players' hat manipulates the same
controller. You'll have to let me know how it works, since SDL doesn't
detect my joypad's hats.
I'd also like it if someone could test the X-Video RGB support. Anyone
with an RGB overlay surface can do so just by selecting the Xv driver.
[No archive available]
New WIP. This one's available here:
http://byuu.cinnamonpirate.com/temp/bsn ... ip.tar.bz2
http://byuu.cinnamonpirate.com/temp/qtdlls.zip
Please don't distribute to other news sites.
You will need to extract the Qt run-time DLLs into the same folder as
the bsnes executable. And you'll likely need WinRAR or 7-zip to
extract the WIP archive.
Please report any issues you can find that weren't present in v039.
I'd like for v040's release to be as bug-free as possible.
Changes from wip19:
The new 'current directory' caching mechanism was caching _after_ save
RAM load, so it wasn't loading save files correctly on first run.
Fixed.
I wasn't setting the internal renderer to match the requested video
mode, so PAL mode wasn't showing the extra scanlines. Fixed.
Had to add a 50ms (very conservative) delay when toggling fullscreen
mode to give Xorg enough time to complete the request. Before it was
trying to query the window size too soon and not fully expanding
fullscreen video to fit the screen. Because of this added delay, I
made it clear the video output when toggling modes. Can't help the
slight line redrawing issue in Qt. Not a bug in my code there.
After reading FitzRoy's comments and thinking more about it myself,
I've decided against the 'intelligent' fullscreen auto-menu hide.
Sorry. It'll still remember whether you were in fullscreen mode on the
last run, but the menubar is always visible by default now. It doesn't
change your menu visibility when you toggle fullscreen anymore.
I also added back the aspect adjust settings to the config file. This
time I combined them to floating point values. So instead of the old:
video.ntsc_aspect_x = 54
video.ntsc_aspect_y = 47
You now have:
video.ntscAspectRatio = 1.14893617
It's an advanced feature not in the GUI, so I expect you to know how
to compensate for the 256x224 vs your native monitor's resolution if
you screw with that setting. Maybe someone can make a web script to
calculate it ala those Xorg modeline generators or something.
Lastly, I removed the group boxes. Took advantage of every row having
three options but one, and added a spacer to get everything aligned.
Advanced panel looks a lot better now.
[No archive available]
New WIP.
- added hardware settings group to advanced panel. Lets you control
hardware region and base unit.
- added descriptive tooltips to video and audio settings.
- revised documentation to list filetypes, mention BS-X issues and
generalize unsupported special chip notes
- improved handling of paths: core now keeps track of cartridge path
rather than relying on the current working directory; export data path
now works the same as SRAM / cheats / etc when not selected
- fixed XvRGB15/16 blue color channel glitch; testing would be much
appreciated
- I now set the drivers to "None" when they fail to initialize and
give a warning. Before the app would just crash on cart load if this
failed
- added more options to the config file: allow invalid input, analog
axis resistance, and for the first time ever -- CPU, PPU1 and PPU2
version configuration
Really not happy with the overall look and feel of the advanced panel.
I don't think the group boxes are working there. Also, the filetype
descriptions are very terse, but I like them that way. Don't really
care if someone doesn't know what 'non-volatile' means, that's why god
made Google. Complain and I'll make the complex terms hyperlinks to
Wikipedia :P
I'll look into the fullscreen menubar thing again in a few days or
something.
> The Cpu and DMA approach is the same like in bsnes. The exception
> are the stp and wai opcodes.
Heheh, I bet someone looking at STP without being aware of how the
cothreads work would gasp in horror :D
> You are right it's really hard to jump back from doing a nested hdma
> transfer within a dma. But with my approach such an action is not
> needed.
Yeah, I know it's possible with enslavement to only make the simpler
processor a state machine. In our case, the S-SMP. That's how SNEeSe
does it. I just really hate the idea of enslavement.
I can certainly see why others get so upset with me on this, but
having each module cleanly separated is, to me, more important than
savestates. That it's somewhat faster here is just an added bonus. I'm
sure you can appreciate my S-SMP op_*.b files over those state
machines for maintenance, too ;)
As for your work on rewriting all the S-SMP opcodes, I wish you
would've mentioned this to me earlier ... the cycle labels in those .b
files are used to create the exact same switch(cycle) {} code you
wrote automatically, you just have to use a different generator. Given
I dropped that generator back at ~v017, it should be easy to update /
rewrite. The downside is that they don't directly support the bus hold
delays.
Still overall, really really impressive stuff. Kudos on making
something so cool :D
[No archive available]
New WIP.
Added fix for OAM Yflip overflow bug pointed out by Jonas Quinn.
Re-added QGroupBox controls as per discussion with jensbw, the frame
issue should be fixed with Qt 4.5.
Config file now omits " #" marker when there is no item description.
Main window resizes itself a bit better before showing itself on Linux
for the first time. Not a problem at all on Windows.
Using _wgetcwd instead of getcwd for Windows UTF-8 support.
Finished Cartridge class revisions: load_foo returns boolean success,
unload() doesn't need one so that was removed, dropped redundant
bsx_cart_loaded() as you can tell via mode() == ModeBsx. Still need
bsx_flash_loaded() for register mapping purposes.
Fixed hiro port to compile again.
I also rewrote much of the Xv driver. It now properly finds modes via
XvListImageFormats(), and I added support for more modes. It used to
be YUY2 only, now it supports RGB32, RGB24, RGB16, RGB15, YUY2 and
UYVY (chooses the driver mode in that order.)
Unfortunately I was only able to test YUY2 and UYVY with my driver, so
no idea if the RGB modes even work or not. I know RGB16/RGB15 will
have problems, forgot to mask the blue channel before uploading: for
line 344 and 359, (p >> 3) needs to be ((p >> 3) & 0x1f).
To test each mode, the optimal ones would have to be manually disabled
since there's no external way to select the preferred driver. And the
RGB32 copy is sub-optimal, I'll probably allow direct rendering to its
surface in a future revision.
[No archive available]
New WIP. Posted only for the sake of testing for regressions.
The only real change was adding nall::property as discussed earlier,
and completely revamping the Cartridge class with it. Results:
http://byuu.cinnamonpirate.com/temp/cartridge.hpp
Compared to the old version, it's night and day. All stuff that can be
hidden has been, end-user can't screw with important internal-settings
while emulation is active, as many functions as possible were made
const, ditched char* stuff to replace with string, removed a few
useless structs, simplified the public interface, replaced a memory
duplication in the cart loader that removes the header with a
memmove() instead, blah blah blah.
If I screwed any of this up, it may break the following:
- special chip detection
- RAM / PSRAM / RTC data saving
- UPS patching
- cheat code loading
- relative path stuff
- etc
[No archive available]
New WIP. Sorry about the delay in adding your .desktop file, belegdol.
I appreciate you sending it to me.
- worked around a cursor bug in Qt/Xlib: if you started the app and
your mouse cursor was on top of where the window appeared, it gave you
the "resize window" grip cursor, and it would stay like that. The
resize function now ensures you always get the normal cursor.
- worked around a bug in Qt/QGtkStyle: if you pass a default path of
"", it throws all kinds of errors at you on the terminal window, I
implemented a current working directory system for both folder path
selection and file selection (when no default game path is selected.)
It starts in your program startup directory (via getcwd()), and will
update whenever you choose a valid file or folder without canceling
the window.
- icon is now stored in $(prefix)/share/pixmaps instead of
$(prefix)/share/icons
- added belegdol's bsnes.desktop. If I can figure out how to get the
one from Derrick, his has stuff that makes it auto-suggest bsnes for
.SFC files and such. I'll probably add his extensions to it later.
This file installs to $(prefix)/share/applications, and bsnes shows up
under 'games' now.
- updated src/cart a bit, merged some 5x ~800 byte files to a general
cart_loader.cpp file, renamed the functions to be clearer:
cartridge.load_cart_bsc() -> cartridge.load_bsx_slotted();
cartridge.unload_cart_st() -> cartridge.unload_sufami_turbo();
- resized HTML viewer, was too small before, but I think it's too wide
now, meh.
- readme was renamed to documentation. I don't care that it's not
verbose enough to warrant the name right now. I intend to expand upon
it in the future and have it be the general sort of "help"
functionality, hence the name change.
- both the documentation and license are now stored inside src/data as
HTML files. These are embedded with Qt's resource compiler into the
final binary. Easier to edit, and the HTML files can stand on their
own.
- I've partially revamped the documentation. It's somewhat of a
compromise between my ideas and FitzRoy's. I may expand on it a bit,
but I like how it is now, so don't expect many more changes there
please.
- Revamped the license stuff a good deal, removed a lot of cruft.
Grant of Rights section remains the same, so no legal changes.
> bsnes could detect the computer's time zone, and switch to purple if
> necessary.
The US SNES is an eyesore. Both the console and especially the
controller. Fuck it, if they want to see that they can look it up on
Google Images :P
[No archive available]
Okay, new WIP. To my knowledge, the Qt port now matches or exceeds the
feature-set / quality of the hiro port in every regard, sans things
I've intentionally removed.
- added back all the UI shortcut keys
- started using Qt's resource compiler, rcc, to embed files into the
binary on all platforms; not as efficient as my base56+LZSS method,
but much more standardized and avoids string length limits in Visual
C++
- Linux port now sets the program icon from bsnes.png @ 48x48 (any
larger and the filtering makes it look bad)
- Windows port uses embedded 16x16, 32x32, 48x48 or 256x256 icon as
before
- all windows now rise to the top when they are shown
- replaced about screen -- it's just a placeholder for now so that
it's not modal. Want to put the logo on there, with the rest of the
info and a webpage link below
- removed 'Ok' button from document viewer window
- killed icon48.h and controller.h, ~100kb worth of source. Right now,
hiro port shows black boxes in their place. I'll do something nice
with it later; but I don't want to grow the source that big for the
non-standard target
- added .zip, .gz and .jma to filter, based on compilation flags
Thinking about killing src/data, putting the necessary stuff in each
platform folder. Just a slight issue with windres taking a relative
path to the working directory, so it won't allow easy renaming of the
ui folder names if I do that. Can work around it with 'cd' command in
the Makefile, I suppose.
Would be nice to take advantage of rcc a bit more: it's very easy to
use 16x16 / 32x32 icons inside the UI for eg menu and config panel
list icons. Just going to be tough to make nice icons for them.
Stuff removed from hiro:
- controller graphic:
I love this graphic and want to have it in the official binary, but it
looks really odd when it's only there for one controller type ...
should we keep it anyway? If so, I'll embed it with rcc.
- trace logging hotkeys:
Want to replace these with a real debugger that will have buttons for
them. That will be a long-term goal, of course. May add shortcut keys
for the debugger functions too at that time.
- frameskipping:
Probably the biggest one, I didn't want to re-add this as the new PPU
will make it pointless anyway. If we do add this back for the fast
PPU, I'll probably keep the option hidden from the UI side.
> SFT was the acronym used for the catalog codes. For example, Poi Poi
> Ninja World had SFT-0103 on the cartridge. So there is some historic
> precedent for it at least. BSX, not so sure, but I figured
> everything else was three letters.
Sounds good, but I'd like to check with Nach first. He seems to be on
extended leave at the moment.
> Exhaust Heat 2 still bug out
Wasn't aware ST-0010 had any problems. Not sure if it's bit-perfect or
not anymore, but it definitely has no DSP timing.
[No archive available]
Okay, another new WIP.
Drag-and-drop is in, and it works in Windows and Linux. Tested with
Thunar under Xfce, but it should be fine with any freedesktop.org-
compatible app/WM.
Worked around the Qt bug ... either
qtreewidget->currentItem()->isSelected() returns the true current item
and the Xlib port has a bug, or it returns the previous and the
Windows port has a bug. I'm using
qtreewidget->selectedItems().count()==1 in its place. Works on Windows
and Linux, so the cheat editor should be fine now.
Forgot to add assign / unassign key disable in the last WIP, so I took
care of that this time.
Added back the readme and license viewers. Used QTextBrowser, which
lets me use HTML formatting plus anchor hyperlinks. Not terribly
useful with such small documents, but meh. We can grow "readme" into
"documentation" in the future. Maybe even add a section listbox on the
left ala CHM files. Throw in a custom CSS stylesheet to make it
prettier. Whatever, not worried about it right now, but we'll get it
ironed out before v040 official.
Got too tired (Red Bull having no effect either), forgot to add the
.zip,.gz,.jma file extensions; and didn't check if cheat codes are
saving on Linux. Also need to work on getting window show commands to
put the windows in the foreground. If they're already visible, they
aren't raising to the top / gaining focus.
Still need to add a bunch of GUI hotkey bindings back, and I think
that'll do it for the rewrite. From there it's all adding stuff the
hiro port lacked.
[No archive available]
Finally, a new WIP.
I redid the spacing / margins on all windows, it should match the old
bsnes/hiro port better now.
Removed all instances of QGroupBox, to work around the problem with
QGtkStyle ignoring the frame entirely, as well as getting around the
ridiculously large margin-top in it that you can't remove. Using
horizontal spacers in its place. Quite a bit more annoying to code
for, but it looks better than even the working frame, at least in my
opinion.
Modified the config panel listbox trigger to use currentRowChanged()
instead of itemSelectionChanged(). This fixes an annoying glitch where
if you clicked down on an item and dragged the mouse, it'd be off-by-
one in the list.
The code editor and cheat code panel both disable buttons when actions
aren't allowed, ala bsnes/hiro. There seems to be a bug in
QTreeWidget::itemSelectionChanged() on Linux, the returned
QTreeWidgetItem::isSelected() value is inverted. Too tired to work
around that tonight.
Improved automatic window resize for the input config and ROM add-on
cart loader windows. They should fully shrink as much as possible now,
rather than leaving blank space.
Dropped the Segoe Print font for titles, as it only looks good on
Vista+.
Removed the sort stuff from the cheat core class and hiro UI, since
the Qt UI can sort by header clicks.
Scale Nx items are checked again according to config file setting.
Stuff left to do:
- work around Qt/Linux bug on edit/delete enable on cheat code panel
- cheat codes don't seem to be saving to disk
- need to re-add screensaver disable code
FitzRoy, it's hard to show you the Qt rendering issues on GNOME, if
you're not familiar with how it should look ...
http://byuu.cinnamonpirate.com/temp/clearlooks.pnghttp://byuu.cinnamonpirate.com/temp/qgtkstyle.png
Clearlooks is the KDE default style. Looks good, but doesn't match
GTK+ apps.
QGtkStyle is the Qt wrapper that tries to use your GTK+ theme. Biggest
annoyance would be the buttons. There's this red box in the middle
that shows up when a button has focus. With the real GTK+, the entire
button turns red (no border) when you click it, but with just focus
alone it shouldn't have any color. The fonts are also much uglier,
like it has really poor anti-aliasing and slightly wrong sizes.
[No archive available]
New WIP adds a ton of refinement.
I feel it's exceeded the old UI in quality already, so I added the
platform-functions (realpath, userpath, ...), so now it'll look for
the multi-user config file, falling back on single-user. If you use an
old config, most settings from v039 will be lost, but some will be
pulled in. It now looks for bsnes.cfg and style.qss (for theming.)
Slight issue with relative paths and realpath() on Linux. New
initargs() function adds back support for non-ANSI paths.
Path window shows <startup path (/path/used)> rather than just
<startup path>.
All buttons trigger on release (mouse up / off) rather than press
(mouse down).
Revamped the centering code. All windows respect the reserved screen
areas (taskbar, dock, etc) and center perfectly. They only center on
the first show, after that they will remember where you placed them.
Completely rewrote the windowed / fullscreen handling code. It works
properly even on Linux now. Scale max is great, perfect fit to the
edges of your screen sans reserved areas. If menu+status toggle are
bound to the same key, it'll only refresh the window once to reflect
the new state now.
Going back to the forced size thing. I need to re-add the menu checks.
You can't shrink the window smaller than your current settings, and if
you make it bigger, you get black borders (since I can't disable the
resize reliably on all platforms.) Makes more sense this way anyway,
the menu options should reflect what you see, not what the startup
state is.
It remembers the fullscreen setting automatically now. I took it a bit
further, though. If you have no ROM loaded, it will show the
menu+status in fullscreen to alert you there's no cart and give you a
chance to select one. I also re-added command-line loading, and if you
successfully load a game there, it will turn off the menu+status for
you. There was a slight delay there. You see, loading a game calls
snes.init() which needs the interface (video, etc drivers) setup.
Those drivers rely on the UI being created. So we have to make the UI,
setting the menubar visibility, before we can verify that we're going
to load a game.
_Yes, I can work around this!_ Add a first-run boolean and validate
the command-line path is valid, or separate cart load from SNES init
so I can load, setup GUI then start, etc etc. It's just annoying, not
sure if it's worth the effort to hide the menubar 2ms sooner.
ROM slot loader and cheat path windows now both disable buttons when
no cart is loaded. Major work in progress, lots of stuff left to do
here. When you pick a file with the ROM loader, it doesn't steal focus
to the main window anymore. When you pick a path, it clears the audio
buffer to prevent audio looping. Not sure if I want to hook move /
resize events, since Linux doesn't block as much as Windows. Maybe
I'll #ifdef it.
Qt 4.4 has a bug with GTK+ file open, if you give it a blank path it
spits out lots of errors. It needs a fully-qualified path. Going to
make my old-style "remember last selected path" thing that I used in
hiro/gtk to fix it later.
[No archive available]
New WIP re-adds the multi-part ROM loader. For some reason that took
way too long, all I got finished.
A bit different this time, one window for all three modes (bs-x
slotted, bs-x and sufami turbo.) It auto adjusts based on what you
want. Much more compact now that I can put the labels on the same line
as the controls.
It otherwise works the same. In the future, I'll be adding a Date/Time
control when loading pure BS-X carts. Makes no sense adding it to the
UI before the core supports it.
> [X] Pause emulation when main window does not have focus
> [X] Ignore input when main window does not have focus
For the hundredth time, that creates four states instead of three.
What's the difference between pause on + ignore on and pause on +
ignore off?
I'll most likely use a QScrollArea to put a scrollbar on the right if
we end up with too many advanced options for one page.
[No archive available]
New WIP.
I guess we've tested the container resize enough, at least for
Windows. Set fullscreen container color to pure black.
To avoid the accidental mouse assignments from v039 and earlier, I
went with UI buttons to assign mouse axes / buttons. Keyboard and
joypads assign the same as before. The extra 1-3 buttons are for six-
button mice like my MX518.
Also re-added mouse capture: load a game, and have a mouse/scope set
as an input device, click in the window and it captures. Press escape
to release. I blocked mouse buttons without capture now, too. That was
allowing a fire shot to go through in previous versions without it
when you first gained focus.
Fixed up hiro/GTK+ to compile again. Should give GNOME/Xfce/Qt4.4
distro packagers some reprieve for a while. Not going to be improving
it anymore, though.
Qt/Linux now uses pkg-config, rather than hard-coded paths. No such
luck for Windows users. There's a Win port of pkg-config, but not many
will have it so the path to Qt will remain hard-coded.
Ditched a few more global nall::string functions (count, find,
(q)replace, (q)split) and moved them inside classes. Fixed the
resultant compile errors in bsnes, hiro and xkas.
The rest of the nall::string functions are also useful on char*
arrays, eg strtr, strlcpy, trim, etc; so it doesn't make a lot of
sense to put them inside the string class.
Not entirely impressed with how the code looks mixing class functions
and global functions, but meh. At least it will reduce mistakes in
trying to pass char*s to string-only functions like replace.
[No archive available]
New WIP. Adds menubar/statusbar toggle, defaults fullscreen to max
scale with no menu/status (you can change the scale and it will
remember your settings in the future), and I re-added all the audio
panel options.
That leaves a few more GUI shortcut key assignments, mouse support +
binding, BS-X / ST ROM loaders, readme/license windows, and a few new
controls to replace the old Firefox-style advanced screen with
something more user-friendly. After that, the rewrite should be
complete.
Trying to move my string lib to a more OO-approach: removed overloaded
strcpy,strcat in favor of =,<< or .assign,.append. Will be trying to
remove more global functions (replace(foo -> foo.replace(, etc) in the
future. Taking it slow so I don't break xkas too badly.
I also want to shave as much excess functionality as I can from it.
Its main purpose is to be a streamable, implicit-castable alternative
to std::string with a few built-in special functions unique to my
needs (eg qsplit,qreplace.)
[No archive available]
New WIP, looking for feedback on these changes.
First, I switched from a standard QWidget to a more semantically-
correct QMainWindow. Not much difference, except it adds an automatic
menubar and statusbar, no need to make my own. One advantage was free
status hint support without having to catch the event. So I took that
and redesigned the status system.
First, the game name on the status bar ate up too much space for
nothing. I moved it to the titlebar: bsnes v0.nnn - Game Title (U)
Second, I merged the FPS counter with the system state and put it on
the right-hand side of the status bar. It shows "No cartridge loaded",
"Power off", "Paused" and the framerate. This is persistent and always
visible. FPS doesn't show ideal FPS next to it anymore. That just
wastes space.
Third, the new left-hand stuff. It uses the native QStatusBar support
for timed messages. I use that to pump power state changes ("System
was reset.", "Loaded Star Ocean (J), and applied UPS patch.", etc.)
They go away after ~3 seconds. Unsupported special chip warnings now
pop up a modal dialog box instead of showing in the status bar.
Fourth, we can now set special menu group / item descriptions that
appear when the items are hovered. For instance, mouse over
settings->video mode->ntsc and it explains that the setting affects
the perceived video output size, rather than the core emulator mode.
The descriptions there now suck, but it shows off the concept. We'll
leave them off for all the obvious items.
With all of that, I was able to kill off the "Status" class, ~4kb of
nasty code that polled the time constantly and maintained an internal
string queue for statusbar messages.
Also new to this WIP ... it's apparently not trivial to set a fixed
window size with Qt on Xlib. My MinimizeWindowHint that worked on
Windows was making the window top-most on Xfce, and breaking
fullscreen mode.
So, I tried again to write code that could properly switch between
windowed and fullscreen mode. For some reason, this always causes tons
of problems. Window managers like to take their sweet ass time
updating internal states, so rapid geometry changes often fail,
leaving the window in odd positions and sizes.
It took quite a while, but I have it working, hopefully, 100% on
Windows. I even account for the desk area (ignoring the taskbar and
such) and the window decorations. Centering should be truly perfect,
and scale max should be a pixel-perfect fit to all available screen
size, while maintaining the ratio.
Linux support is still kind of flaky, though. Long shot, but any
knowledgeable help here would be appreciated.
void Utility::updateFullscreenState() {
if(config.video.isFullscreen == false) {
config.video.context = &config.video.windowed;
winMain->window->showNormal();
application.processEvents();
} else {
config.video.context = &config.video.fullscreen;
winMain->window->showFullScreen();
application.processEvents();
}
//refresh options that are unique to each video context
for(unsigned i = 0; i < 2; i++) resizeMainWindow(); //call
twice as Xlib drops window messages sometimes
updateHardwareFilter();
updateSoftwareFilter();
}
//if max exceeds x: x is set to max, and y is scaled down to keep
proportion to x
void Utility::constrainSize(unsigned &x, unsigned &y, unsigned
max) {
if(x > max) {
double scalar = (double)max / (double)x;
y = (unsigned)((double)y * (double)scalar);
x = max;
}
}
//0 = use config file value, 1+ = override with new multiplier
void Utility::resizeMainWindow(unsigned multiplier /* = 0 */) {
if(multiplier != 0) config.video.context->multiplier =
multiplier;
else multiplier = config.video.context->multiplier;
unsigned width = 256 * config.video.context->multiplier;
unsigned height = (config.video.context->region == 0 ? 224 :
239) * config.video.context->multiplier;
if(config.video.context->correctAspectRatio) {
if(config.video.context->region == 0) {
width = (double)width * 54.0 / 47.0 + 0.5; //NTSC adjust
} else {
width = (double)width * 32.0 / 23.0 + 0.5; //PAL adjust
}
}
QDesktopWidget *desktop = QApplication::desktop();
if(config.video.isFullscreen == false) {
//get effective desktop work area region (ignore Windows
taskbar, OS X doc, etc.)
QRect deskRect = desktop->availableGeometry();
unsigned deskWidth = (deskRect.right() - deskRect.left() +
1);
unsigned deskHeight = (deskRect.bottom() - deskRect.top() +
1);
//place window offscreen so resize events do not cause
flickering
winMain->window->move(desktop->width(), desktop->height());
application.processEvents();
//shrink window as much as possible to compute frame + menubar
+ statusbar size
winMain->canvas->setFixedSize(0, 0);
winMain->canvasContainer->resize(0, 0);
application.processEvents();
winMain->window->resize(0, 0);
application.processEvents();
QRect frameRect = winMain->window->frameGeometry();
//constrain window so that it will fit inside desktop work
area
constrainSize(height, width, deskHeight - (frameRect.bottom()
- frameRect.top() + 1));
constrainSize(width, height, deskWidth - (frameRect.right() -
frameRect.left() + 1));
//resize canvas to desired size
winMain->canvas->setFixedSize(width, height);
application.processEvents();
//shrink window so that it contains all of canvas, but is no
larger
winMain->window->resize(width, height);
//allow canvas to be resized along with window by user
winMain->canvas->setMinimumSize(256,
config.video.context->region == 0 ? 224 : 239);
winMain->canvas->setMaximumSize(desktop->width(),
desktop->height());
winMain->canvas->setSizePolicy(QSizePolicy::Expanding,
QSizePolicy::Expanding);
application.processEvents();
//force window size change to take effect
winMain->window->resize(width, height);
application.processEvents();
//center window onscreen:
//take desktop work area and window frame decorations into
account
QRect windowRect = winMain->window->frameGeometry();
unsigned windowWidth = (windowRect.right() -
windowRect.left() + 1);
unsigned windowHeight = (windowRect.bottom() -
windowRect.top() + 1);
winMain->window->move(
deskRect.left() + (deskWidth - windowWidth ) / 2,
deskRect.top () + (deskHeight - windowHeight) / 2
);
} else {
constrainSize(height, width,
winMain->canvasContainer->size().height());
constrainSize(width, height,
winMain->canvasContainer->size().width());
winMain->canvas->setFixedSize(width, height);
}
}
If anyone wanted to get stupid, a style for QWidget.backdrop {
background: url(border.png); } when designed for a specific resolution
+ scaling mode would allow Super Gameboy-style borders :P
Let's see ... properly subclassed the generic input binding pools for
clarity, and added user interface key binding support again. So far
only for exit emu + toggle fullscreen, but the rest should be easy
now.
I can't reduce the space for the QFrameWidgets. Only setMargin works,
but it reduces margins on all sides where only the top is bad. I may
have to revert it back to a section label + horizontal separator
between each area. Probably a good idea, QGtkStyle doesn't support
QFrameWidget's decoration anyway. Looks terrible on GNOME.
Finally, fixed ui_hiro for Windows. Still need to fix up the Linux
target. They share the same Makefile, so additional targets should be
easy, eg a pure SDL port or whatever.
> Darn. Oh well, guess I could keep whatever I concoct to myself.
Or tell me what you want to do, as I probably won't mind :P
[No archive available]
Man, I don't have time to read all that ... >_>;
New WIP. Lots of UI refinements.
- re-added power on / power off / reset to main menu (expansion port /
region won't be coming back here)
- re-added status message system
- figured out a way to hide the child indicators in list boxes, as
well as enable sorting while starting with default ordering (so
headers are now clickable to sort, you can even rearrange them)
- merged driver settings and input focus policy into advanced panel
- old advanced panel list is dead, driver panel is dead
- replaced scale 5x with scale max; minor help to 1920x1200+
resolutions
- re-added smart scaling + window size clamping
- Linux port should build out-of-the-box, but there's definitely some
issues in regards to window sizing (even Qt has trouble with this)
- new $(ui)/Makefile system -- as if I weren't abusing GNU make enough
before, new automoc rules are madness -- fear:
# automatically generate .moc files from .hpp files whenever:
# - they don't exist
# - .hpp file was modified after .moc file
%.moc: $<; $(moc) $(patsubst %.moc,%.hpp,$@) -o $@
$(foreach object,$(moc_objects),$(eval $(object): $(patsubst
%.moc,%.hpp,$(object))))
ui_build: $(moc_objects);
ui_clean:; -$(foreach object,$(moc_objects),@$(call
delete,$(object)))
- lots of other crap
http://byuu.cinnamonpirate.com/images/b ... 090126.png
Now to update the locales for v039 finally ...
[No archive available]
Well that wore me out ... the UI went from 45kb to 109kb in one night,
with no copy/pasting.
New WIP:
- re-added the InputManager + InputDevicePool classes. The latter is
very complicated, but impressive
- re-added Input Configuration Editor
- re-added Cheat Code Editor
- re-designed individual cheat code editor
- re-added Path Editor
- stopped subclassing QWidget w/Q_OBJECT to work around Qt stylesheet
bug
- re-added controller port selections
Sorting by column header clicking is screwy. It has to be manually
enabled, and the second you do that it re-orders everything. This is
really bad when you want the default order, eg "up, down, left ..." or
your default cheat ordering; so I had to leave it off. Would be too
tacky to add a numeral ID column to work around that.
Seems Qt also has a ridiculously complex tree view (MVC-based), but
thankfully they added a simplified version that works well enough,
QTreeWidget. Only problem is I can't seem to make it hide the child
expander space at the very left-most side. This creates an annoying
little gap. Anyone know how to hide those with Qt?
Even got checkboxes inside the list to toggle cheat codes.
Documentation could've been clearer there.
Speaking of which, I was able to use child nodes on the cheat code
list to show each individual cheat code, but it just didn't look right
to me. There was a ton of blank space on the sides. I can actually
fill in multi-line descriptions as well here, but it still looks
really tacky in my opinion.
Thought about using add code + append code + delete code and putting
the textboxes back, but that just seems tacky and error prone, too.
I'm not adding individual descriptions for each code sub-part.
Only way I can think to make it work that way would be to replace the
multi-code method with a grouping affinity (eg group codes 1+3 into a
set), but then we're getting really complex, with a minimum of 5-6
buttons on the window and 3 text boxes. I think the learning curve
would be too high to be worth it.
So, I used the old method, but instead of a textbox to paste in codes,
I went with a slightly less error prone method of a textbox for the
description and a listbox for each code part. Threw in add / delete /
delete all for the code list. Takes a bit longer if you're trying to
copy/paste codes off the web, but the increased intuitiveness and
consistency is worth it in my opinion.
New cheat code editor (description typo due to extreme fatigue)
There's a lot of rough edges and few safety checks, so if you try to
break things you probably can.
Overall, really having fun with the Qt API. It can be awkward at
times, but it's definitely the most straight-forward API I've seen so
far.
[No archive available]
2009-01-25 08:16:00 +00:00
1286 changed files with 174371 additions and 54484 deletions
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.