mirror of https://github.com/bsnes-emu/bsnes.git
235 Commits
| Author | SHA1 | Message | Date |
|---|---|---|---|
byuu
|
7b0e484c18 |
Update to bsnes v047 release.
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. |
|
|
byuu
|
f8e425ff49 |
Update to bsnes v046a release.
[No changelog available] |
|
|
byuu
|
2a6a66f478 |
Update to bsnes v046 release.
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
|
|
|
byuu
|
3c42e6caa0 |
Update to bsnes v045r09 release.
[No changelog available] |
|
|
byuu
|
5f96547beb |
Update to bsnes v045 release.
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. |
|
|
byuu
|
44b5f1bf27 |
Update to bsnes v044 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
|
|
|
byuu
|
b0a8de0208 |
Update to bsnes v043 release.
[No changelog available] |
|
|
byuu
|
11e0a2ac18 |
Update to bsnes v042r05? release.
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] |
|
|
byuu
|
3a6eb56cef |
Update to bsnes v042r04? release.
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] |
|
|
byuu
|
4c92d11d80 |
Update to bsnes v042r03? release.
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] |
|
|
byuu
|
f3d1d10d3e |
Update to bsnes v042r02? release.
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]
|
|
|
byuu
|
90aa780d57 |
Update to bsnes v042r01? release.
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]
|
|
|
byuu
|
b5b21a4ec2 |
Update to bsnes v042 release.
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. |
|
|
byuu
|
2b587de04b |
Update to bsnes v041r08? release.
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]
|
|
|
byuu
|
1e133eeb5e |
Update to bsnes v041r07? release.
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]
|
|
|
byuu
|
9de4b1dea2 |
Update to bsnes v041r06? release.
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] |
|
|
byuu
|
2b84d1ef37 |
Update to bsnes v041r05? release.
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]
|
|
|
byuu
|
e2a44195cd |
Update to bsnes v041r04? release.
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]
|
|
|
byuu
|
9ac912d100 |
Update to bsnes v041r03? release.
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] |
|
|
byuu
|
d15092dada |
Update to bsnes v041r02? release.
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] |
|
|
byuu
|
91270e504a |
Update to bsnes v041r01? release.
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] |
|
|
byuu
|
f976998222 |
Update to bsnes v041 release.
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. |
|
|
byuu
|
def86470f4 |
Update to bsnes v040 release.
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. |
|
|
byuu
|
3e7578761a |
Update to bsnes v039r22? release.
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]
|
|
|
byuu
|
45feae8f75 |
Update to bsnes v039r21? release.
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] |
|
|
byuu
|
4d10c36870 |
Update to bsnes v039r20? release.
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] |
|
|
byuu
|
cca8164005 |
Update to bsnes v039r19? release.
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]
|
|
|
byuu
|
0f83e39d5c |
Update to bsnes v039r18? release.
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] |
|
|
byuu
|
ebbcc998d0 |
Update to bsnes v039r17? release.
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] |
|
|
byuu
|
78da6946c6 |
Update to bsnes v039r16? release.
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] |
|
|
byuu
|
4d31452bca |
Update to bsnes v039r15? release.
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] |
|
|
byuu
|
eb1eca4a6d |
Update to bsnes v039r14? release.
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] |
|
|
byuu
|
07c9df31a6 |
Update to bsnes v039r11? release.
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.png http://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] |
|
|
byuu
|
c64232a479 |
Update to bsnes v039r10? release.
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] |
|
|
byuu
|
85b08fd24b |
Update to bsnes v039r09? release.
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] |
|
|
byuu
|
3b3214d1be |
Update to bsnes v039r08? release.
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] |
|
|
byuu
|
b5a38d2a07 |
Update to bsnes v039r07? release.
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] |
|
|
byuu
|
94004f86ec |
Update to bsnes v039r06? release.
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]
|
|
|
byuu
|
148bbddb1a |
Update to bsnes v039r05? release.
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]
|
|
|
byuu
|
e5b2e87ff8 |
Update to bsnes v039r04? release.
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] |
|
|
byuu
|
67318297dd |
Update to bsnes v039 release.
Changelog:
- Recovered ~10% speed loss from last release via S-CPU IRQ timing optimizations
- Implemented O(1) binary-heap priority queue for event scheduling
- Fixed a bug where BS-X slotted carts were never mapping SRAM
- Fixed a bug where invalid controller input was always being allowed
- Fixed all compilation warnings with GCC 4.3 and Visual C++ 9.0
- Added advanced options to control S-CPU ALU hardware delays
- S-RTC and SPC7110 timers updated to handle time_t overflow (Y2k38) gracefully
- Cheat codes can now have multiple codes per entry, and multiple lines per description
- Rewrote config file parser; removed config/ class from emulator core
- Windows: added 256x256 image to program icon set
- Linux: fixed Xorg keysym mapping, key names should show correctly in all cases now
- UI: updated video panel, added fullscreen-on-startup and NTSC merge fields options
- UI: simplified audio panel
- UI: boolean options on advanced panel can be toggled via double-click
- Lots of code cleanup, especially for S-CPU IRQ handling and nall template library
|
|
|
byuu
|
1a6de37454 |
Update to bsnes v038r13? release.
<edit: removed outdated WIP> **Delta queue support** First up, I've added a binary min-heap delta queue. I converted all events except IRQ/NMI test and hold. If we can convert these to use the delta queue, there should be a speedup of 30-40% or so -- pretty much the biggest low-hanging fruit there is. And the thing that has plagued me for 12-18 months in the past before the major speed hit v0.018 when I gave up and went with testing IRQ/NMI on every single clock tick. But it won't be easy: the delta queue works by adding an event when you know its going to trigger. But we cannot _know_ if an IRQ or NMI interrupt will trigger until we're at the current time. One can literally disable or change these 2 clocks before they occur, which would leave a bad trigger event in our queue. IRQ/NMI hold also needs to be scheduled exactly four clocks after IRQ/NMI trigger. Unless we queue these at least ~16 clocks in advance of the trigger, then we may not be able to trip them exactly when needed. Since the test/hold are in the same inner loop, before or after the delta queue time update, we can't just enqueue the hold and not the test. So, in the WIP I've included my insanely rigorous test ROMs for IRQ, NMI and HDMA timing, and I'm asking for help. If anyone could please help in merging sCPU::add_clocks() IRQ testing into the delta queue, I'd be greatly in their debt. Relevant code is at src/cpu/scpu/timing/[timing.cpp, irq.cpp] and src/cpu/scpu/deltaqueue.cpp. I'll be working on it as well, of course. Note: removing events not at the top of the heap is not supported. _If_ this is needed, it would probably be best to do an O(n) search for the event, and overwrite the event code with 0 (meaning ignored) than to try and pull out the event and renormalize the heap. IRQ/NMI hold edge cases are very rare, so O(n) time shouldn't hurt speed. **ALU delay** Since there's no speed hit anymore, I added back hardware ALU (mul / div) delays. While we still don't emulate the proper partial calculation results, we should at least return 0 when reading too soon. The exact delay varies based upon the calculation, however. We ran into problems with Taz-Mania in the past. So for this WIP only, I've added settings to the advanced panel: "temp.alu_mul_delay" + "temp.alu_div_delay" The value has to be a _multiple of 2_ (2, 4, ... 32, 34, ...), and the goal is to find the _highest_ possible value that will not cause any bugs in games. What I'm asking is for people to just set the value to something and test a few games. If you spot a bug that's not in v038, try lowering the value until it goes away. Then post the values here. We'll keep lowering the current number until we find the best setting for future releases. Let's start with really high values that will definitely cause bugs: ALU mul delay = 104 ALU div delay = 208 For example, pick any game ... say Zelda 3. Note how the triforces won't render now. Lower the value until it works, post what numbers you needed here plus the game name. Then everyone will use those values and test other games. Rinse and repeat. _Important note:_ you have to reset the game after changing these values in the GUI for them to take effect. **Fullscreen on startup** I've added "video.start_in_fullscreen_mode". Because there's no way to exit other than a keyboard shortcut, I've unhid the "Exit" option for now. We can discuss the UI design stuff in the main v038 talk thread, just stick to mentioning if you hit any bugs with it for this thread. Thanks to all in advance for any help here! [No archive available] |
|
|
byuu
|
de47a2c7de |
Update to bsnes v038r12? release.
New WIP adds nothing new, but fixes Visual C++ compilation issues. Stopped windows.h from defining min/max again, disabled (bool)intmax_t stupidity, added a default: so VC doesn't assume a function has a blank return path, omitted -static on libco, and reverted to always using windres over rc. Express Edition lacks rc, and you already need GNU make anyway, so why bother supporting rc, too? > Can you tell me what I should include? It looks like the taskbar is only 32x32 ... yet the result looks really weird. Almost like the .ico file only has a 1-bit transparency mask or something :/ Image As you can see, all the other icons look much sharper. > I always wondered why the entire line of an entry doesn't highlight. I have no idea ... don't see any other listview styles I can use that'd highlight the whole thing :/ [No archive available] |
|
|
byuu
|
25ad9701ab |
Update to bsnes v038r11? release.
New WIP. - invalid input is blocked again when input.allow_invalid_input == false - vertical scrollbar only appears when needed in multi-line textboxes - cheat editor properly encodes / decodes quotes and line breaks - advanced panel now allows double clicking boolean items to toggle their state - cleaned up all of the nall template library - nall::array was missing copy constructor, causing swap/sort to fail - moved start in fullscreen to advanced panel for now - renamed most of the options FitzRoy asked for > Invalid input is always allowed in bsnes. The config file option > doesn't change that. Thank you very much, that was a huge oversight. > In the latest WIP I've notice Pro Action Replay codes aren't working > anymore. For example, try these codes for Super Mario World (U); Those work fine for me ... maybe try the next WIP? > Here's a couple of boolean advanced options I'd like to see: > misc.minimize_to_system_tray > misc.run_at_system_startup System tray control is probably something the GUI library needs anyway, but its value is completely lost for Windows 7 -- the taskbar works similar to the system tray + quick launch. In fact, by default tray items are hidden and require you to go through a menu to get to them. Run at startup would be tricky. I could only get that working on Windows, and it's really something the user should do externally. Drag it to the startup folder, put it in the registry, use MS config, whatever. Also seems very niche, no? You'd still have to load a game for it to be useful. > maybe the two file ones as well, not sure what use those have One is for OS X users. Some of them don't understand file extensions. The other is for ROM hackers. It'd be needed to multi-chain UPS patches in the future, as well. > I'd also like a minor change in the system menu: flip the power > settings with the controller settings. Why? Seems arbitrary, and I like the current ordering. We can even make up some crazy stuff to support the current ordering: 1) Looking at an SNES from top to bottom, you have the cart slot, then power / reset, then controllers. 2) Group options that affect carts, then group options that affect input. > Let me know when you're ready to talk about the readme overhaul. Will probably release v039 next weekend. Can work on the readme for v040, I guess. [No archive available] |
|
|
byuu
|
9a5a3b8246 |
Update to bsnes v038r10? release.
Probably a mapping issue. Wish we could've spotted it less than 21
versions ago, would've been easier to find the regression. Ah well, at
least we found it now.
New WIP completes the multi-part cheat codes. I changed the file
format, and it may change again, so backup your old .cht files first.
Went with the unified textbox thing to allow infinite number of codes
per cheat item, though the textbox itself will stop parsing after
1,024 bytes at the moment. Really ... you're doing something wrong if
you need more than ~120 parts for one cheat code entry.
It will parse and treat spaces, +&|,;{tab} and {linefeed} as
separators for codes. You will lose the space formatting after you
okay the code and go back to edit it again.
Also one glitch if you toggle cheat status, it won't clip the extra
cheat parts as it should. Will fix it later, ran out of time. Don't
try multi-line descriptions or commas for separators just yet. Need to
iron proof that so it won't corrupt the file format.
Any testing of this new feature would be greatly appreciated.
Design questions:
- should we change the order of desc/code/enablestate on either the
main cheat window or the cheat sub-editing window? If so, why? Be
verbose, use examples.
- should we change the .cht file format? Again, please clarify what
the advantage would be.
- should we change the text labels for the sub cheat editor to
something more clear?
- should the default separator be changed from " + " to something
else? Maybe linefeed?
[No archive available]
|
|
|
byuu
|
daac76858b |
Update to bsnes v038r09? release.
Damn, absolutely loving this Aftershock I just picked up. Scary stuff -- 80 proof and it tastes like a malt beverage. New WIP, added the cheat code editor UI changes. The cheat code class in the back-end still doesn't actually support multiple codes just yet, but it will. Image Need to decide how many codes we should allow. A real Game Genie didn't allow more than five, so I think we should go with either four or six. Also not shown, when a code you're editing is incomplete / bad, there's a grayed out text label that appears on the right to tell you that the code is invalid. It also disables the ok button during this time. I wouldn't try entering a multi-line description just yet. I don't parse that at all. Worst case, it'll corrupt your cheat file. My plan is to only show the first text line in the listbox, but allow extra lines for more verbose comments. I'm being lazy and disabling the add/edit/delete buttons from the main window when the sub editor window is open. Prevents abuses like deleting the code you're editing, then trying to update it. [No archive available] |
|
|
byuu
|
c63df7e009 |
Update to bsnes v038r08? release.
Another WIP, but nothing visible to end users. Still get it if you
don't have 07 for the nice speedup.
Mostly source-cleaning stuff.
- removed 'uint' type, replaced all instances with the proper unsigned
int.
- removed as many headers as I could from the global interface.hpp
file, including only in the cores that need each of them. Should help
compile time. Though I still have a lot of global header includes due
to needing ultra-hot sections of code inlined.
- added include protection bumpers to the CPU+SMP opcode core
generated files
- added const-correctness to a few more classes.
- updated S-RTC and SPC7110 time to handle time_t overflow: it's now
Y2K38 proof even on 32-bit signed time_t systems, and the file format
remains unchanged. But it adds one limitation that you'll lose your
time if you wait ~34 years before loading your last save game. I think
that's reasonable for now. Once 64-bit time_t systems are ubiquitous,
we should be able to trivially expand that without breaking old saves.
Relevant code (I tested with int16_t, uint16_t, int32_t, uint32_t,
int64_t and uint64_t):
time_t diff
= (current_time >= rtc_time)
? (current_time - rtc_time)
: (std::numeric_limits<time_t>::max() - rtc_time + current_time
+ 1); //compensate for overflow
if(diff > std::numeric_limits<time_t>::max() / 2) diff = 0;
//compensate for underflow
Avoided the obvious (y-x)&<time_t>::max() just in case there's some
crazy platform where the value != (some power of 2)-1. Modulus
(max()+1) won't work there either, as it'll overflow if
sizeof(unsigned) == sizeof(time_t). The +1 might throw it off by a
second on one's complement system, but I don't really care :P
Anyone with GCC 4.3 want to try something for me? Try modifying
src/lib/nall/platform.hpp and change #define alwaysinline
__attribute__((always_inline)) to:
#define alwaysinline __attribute__((always_inline))
__attribute__((hot))
... and let me know the FPS difference you get in some arbitrary game,
please :D
It's supposed to be like manual-PGO.
[No archive available]
|
|
|
byuu
|
3908890072 |
Update to bsnes v038r05? release.
New WIP, this one's fairly big as nightlies go.
First, moved the priority queue to a generic implementation so I can
re-use it elsewhere in the future. Took a ~1% speed hit or so by using
functors for the callback and using the signed math trick to avoid the
need for a normalize() function. Sadly it gets up to 3% slower if the
priorityqueue class code isn't placed right next to the CPU core.
Second, while I failed miserably at using the queues for IRQ / NMI
testing, I did come up with a neat compromise. NMI is only tested once
per scanline, IRQs only have PPU dot precision (every 4 clocks), the
hold time for both is four clock cycles, and scanlines for both NTSC
and PAL, even on the short colorburst scanline, are always evenly
divisible by four.
... so testing every 2 clock cycles was kind of pointless, as it'd
always be false. Since the delays between the PPU counter and CPU
trigger for NMI is 2, and IRQ is 10, they even align again with an
offset of 2.
... hence, I can call poll_interrupts() half as often by using
if(ppu.hcounter() & 2). I reverse that for the Super Scope / Justifier
dot testing and cut their overhead in half as well.
That gives us a nice ~10-15% speedup. Nowhere near the idealistic
~30-40% for range tested IRQs, because that only actually tests once
per scanline (~1364 cycles). This just cuts ~682 tests down to ~341
tests. Still, it's pretty close to half as good while still being
super clean and easy. It greatly diminishes the value of a range-based
IRQ tester, as that will only offer a ~15-20% speedup now at best.
Getting PGO working again is the new lowest-hanging fruit.
I also eked out a tiny bit more speed by adding some previous missed
"else" statements in the irq_valid testing part.
With the newfound speed, I gave a tiny bit up (1-2%) to simplify and
improve some old edge cases. It's known that IRQs won't trigger on the
very last dot of each field. It's due to the way the V and H counters
are misaligned, that we can't easily emulate.
So before I had a bunch of cruft to support that, update_interrupts()
was called at the start of each scanline, which would call irq_valid()
to run a bunch of tests to make sure the latch positions would
actually work on hardware. Writes to $4207-420a would also call the
update_interrupts() proc.
I killed all that, and now compute the HTIME position inline in
poll_interrupts(), and perform the last dot check there. Since testing
is ten clocks behind anyway, then we need only check to see if VTIME >
0 and ppu.vcounter(-6 clocks) == 0 to know that it was set for the
last dot on any given field.
This gives us two nice perks for free: one, no more need to hard-code
scanlines/frame inside the CPU core; and two, the old version was
missing an edge case in interlace mode where odd fields would allow an
IRQ on the last dot, which was simply because my old irq_valid() test
didn't have a third condition for that.
All that said, I'm getting ~157.5fps instead of ~137.5fps now in Zelda
3.
Third, I removed grayscale/sepia/invert from the video settings panel,
and stuck them in advanced. Used the new space to add checkboxes for
NTSC merge fields and the start in fullscreen thing.
Reference:
//called once every four clock cycles;
//as NMI steps by scanlines (divisible by 4) and IRQ by PPU
4-cycle dots.
//
//ppu.(vh)counter(n) returns the value of said counters n-clocks
before current time;
//it is used to emulate hardware communication delay between
opcode and interrupt units.
alwaysinline void sCPU::poll_interrupts() {
//NMI hold
if(status.nmi_hold) {
status.nmi_hold = false;
if(status.nmi_enabled) status.nmi_transition = true;
}
//NMI test
bool nmi_valid = (ppu.vcounter(2) >= (!ppu.overscan() ? 225 :
240));
if(!status.nmi_valid && nmi_valid) {
//0->1 edge sensitive transition
status.nmi_line = true;
status.nmi_hold = true; //hold /NMI for four cycles
} else if(status.nmi_valid && !nmi_valid) {
//1->0 edge sensitive transition
status.nmi_line = false;
}
status.nmi_valid = nmi_valid;
//IRQ hold
status.irq_hold = false;
if(status.irq_line) {
if(status.virq_enabled || status.hirq_enabled)
status.irq_transition = true;
}
//IRQ test (unrolling the duplicate Nirq_enabled tests causes
speed hit)
bool irq_valid = (status.virq_enabled || status.hirq_enabled);
if(irq_valid) {
if((status.virq_enabled && ppu.vcounter(10) !=
(status.virq_pos))
|| (status.hirq_enabled && ppu.hcounter(10) !=
(status.hirq_pos + 1) * 4)
|| (status.virq_pos && ppu.vcounter(6) == 0) //IRQs cannot
trigger on last dot of field
) irq_valid = false;
}
if(!status.irq_valid && irq_valid) {
//0->1 edge sensitive transition
status.irq_line = true;
status.irq_hold = true; //hold /IRQ for four cycles
}
status.irq_valid = irq_valid;
}
[No archive available]
|
|
|
byuu
|
155b4fbfcd |
Update to bsnes v038r04? release.
New private WIP. Nothing worth downloading it over, really. - fixed first scanline DRAM refresh event (passes irq.smc and nmi.smc again) - fixed PPUcounter to initialize before CPU; not that it affected anything as-is, but it's nice for future proofing to do it right - optimized priority queue thing to move instead of swap; didn't affect overall emu speed sadly (still infinitesimally faster than the last official release), but I still like the model for timing events that will occur no matter what - made the ALU delays more permanent advanced config options; 32 and 48 were still screwing with taz-mania ... not even a whole opcode on the mul -- that game literally reads the regs immediately. We can't get things any better than we already have until we emulate the formula; so I set them both to 2 clock cycles for now, they're at least there for hobbyist devs, who can set them fairly high to guarantee their code would work on hardware - removed a bit of cruft > * RSA-1024 is busted Really? What are its factors, then? Please tell me in private so I can claim the $100,000 bounty when it's offered again :D (they've only broken a 200-decimal digit one with the equivalent of 75 PC work-years, RSA-1024 has 309 and the problem is exponential, not linear.) [No archive available] |
|
|
byuu
|
02ca0f1e69 |
Update to bsnes v038r05 release.
[No changelog available] |
