This represents a major code restructuring. The dot-based and
scanline-based renderers are now split into two separate core
libraries, asnes and bsnes.
For now at least, these are -internal- names. I'm not entirely decided
on how I'm going to handle releasing these two separate builds.
Regardless, the folders need names.
asnes has had all of the processor subfolders collapsed back into
their parent folders. In other words, ppu's functions were moved into
ppu/sppu, and then ppu was deleted, and then ppu/sppu became the new
ppu. Repeat this for the cpu, smp and dsp and there you go.
asnes/dsp also removed the DSP_STATE_MACHINE option. This was done for
the sake of consistency with the rest of the core.
asnes' debugger mode is currently extremely broken, but I will be
fixing it in time.
And for now, bsnes has kept the processor abstraction layer. I may
keep it around, not sure yet. It doesn't hurt speed or anything, so
I'm not too worried about making a decision right away.
I may throw snesfilter, snesreader and supergameboy into this folder,
just to have everything in one place. The alternate GUI forks are
definitely going in there as dotnet, cocoa and python.
Compiled output goes to the out/ folder now, to prevent conflicts with
a file and folder named bsnes, for instance.
This will be the final release with the current source structure.
This WIP contains a bugfix so that the last scanline does not fetch
OAM items. This fixes flickering in Ninja Warriors and Lord of the
Rings.
This build simplifies the tile cache significantly, and it now builds
the cache and fetches the VRAM data during Hblank, the VRAM reads are
modeled after real hardware.
This fixes Mega lo Mania without regressing Winter Gold or Adventures
of Dr. Franken.
I also fixed a pseudo-hires back color glitch in Super Buster Bros.
This substantially improves the S-PPU dot-renderer's sprite
processing. Instead of happening immediately at the start of the
scanline, each pixel is rendered one at a time. It eliminates the
SpriteList caching, sprite width/height caching, oam_palette caching
and oam_priority caching.
I'll explain it in more detail in the public thread in a bit.
Most noticeable is that Winter Olympics is now perfect, with no known
regressions on any of the sprite-sensitive games.
This adds the SA-1 compiler bug workaround for GCC 4.5.0, and updates
the load special libsnes functions to also generate XML mapping data
if given empty strings.
I built the binary above with GCC 4.5.0, so let me know if any new
problems appear. What I've noticed is that when not profiled, 4.5.0 is
about 3-5% faster, but when profiled, they are equivalent in speed.
Lastly, I did some more work on the .NET/C# and Snow Leopard/Cocoa
ports. They can both load all special types of ROMs, including Super
Game Boy.
For .NET, you need to be on a 64-bit version of Windows, have .NET 3.5
installed, and have SlimDX installed (I used February 2010, but
anything later should be fine.)
For Snow Leopard, you may want to build and install libsupergameboy,
but you don't have to. Just don't try loading SGB games without it.
Yes, the .NET one is pure 64-bit. I built snes.dll and
supergameboy.dll using MinGW64-GCC 4.5.0. Since the core library
doesn't use Qt, it builds fine in 64-bit mode.
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]
byuu