mirror of https://github.com/bsnes-emu/bsnes.git
195 Commits
| Author | SHA1 | Message | Date |
|---|---|---|---|
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] |
|
|
byuu
|
6cacb2517a |
Update to bsnes v038r03? release.
I haven't posted the new WIP, just updating on the status of it. First, I noticed that Xorg changed the keycodes, at least for Kubuntu 8.10. belegdol, the other person at RPM fusion was mentioning that he was getting weird key mappings like page_down for left, etc -- this would be why. Didn't realize they were variable like that. I went back and made a lookup table to convert the official keysyms to keycodes, so this issue should now be fixed. Anyone packaging bsnes is free to update to the latest WIPs to fix this if they like. Second, I added "adjust" to brightness/contrast/gamma, and they all start at 0% centered, go to -95% and +95%. Still not sure what to name "Frequency adjust", so I left that alone for now. Third, I updated the ~400 or so %0.nx sprintf statements to %.x, so that GCC 4.2+ will shut the hell up. Lastly, I can't come up with a good double->string conversion routine (causes subtle rounding errors with the obvious approach), so I wrapped strdouble() around snprintf. bsnes doesn't even use it yet, but at least it can now ... > How would dropdowns be better than what ZSNES is currently using? The WIP link on Rapidshare is dead ... what are they using? If it doesn't involve tab panels, then I can do that. > Wouldn't these just be hardware filters like NTSC that simulate the > lossy characteristics of certain type of analog output? These are settings _for_ the NTSC filter to affect its quality. They don't affect any other filters. > There's no fundamental difference between a coprocessor and central > processor in the scheme of emulation. That the coprocessor happened > to be located on what we would physically categorize as the > "cartridge" is immaterial. There's quite a large distinction between something inside the SNES and outside. I understand where you're coming from, but we shouldn't pretend as though the SNES contains all these chips, either. Sheesh, I don't even know what we're discussing here anymore :P > You'd be crazy to externalize all your code just to allow people to > create imaginary 10ft boards with 2ghz GPUs. What I wouldn't give for just one person to make such a board ... :D > The only invaluable option in that entire section is overload's > gamma curve, everything else about the image can be destroyed in my > video driver or monitor settings. Haven't we covered this in the past? SNES games were played with gamma, etc settings calibrated to NTSC / PAL televisions. Monitors are calibrated very differently. I doubt anyone wants to go into their driver control panels to adjust these settings every time they start and close the emulator. And cheaper drivers (especially on Linux) may not have these options at all. Not saying we have to go crazy here ... I'm happy to leave out hue/saturation settings. > I am aware that any changes made to WIP releases are posted here on > this forum, but maybe it's an idea to start including those as well > on the WIP download page? I _could_ ... but it's easier to type things up here later on at my convenience :/ [No archive available] |
|
|
byuu
|
9a8203b3c3 |
Update to bsnes v038r02? release.
New WIP. - defaults are now centered for video settings panel sliders, modified default gamma to 100 with gamma curve enabled. - removed all the preset buttons, it looks terrible with just one. - fixes 99% of the useless bullshit warnings with GCC 4.3, still didn't change all the "%0.2x->%.2x" strings in the disassemblers though. - fixed up the double->nall::string conversion, but it still has some rounding issues, so I can't use it yet. About ready to just implement that as a wrapper around sprintf. > Byuu i would like to request support for the following audio > renderers. Sure, you can post them here when you're done and I'll include them in the source. If they don't cause missing driver errors on a clean install of Win2k SP4 or newer (this is why Win/OpenAL is disabled), then I'll enable them in the default binary as well. [No archive available] |
|
|
byuu
|
9c7ac24ff7 |
Update to bsnes v038r01? release.
New WIP. Audio panel was revised, it's now the same both in regular
and advanced mode.
Volume, Frequency and Latency all appear on one row and are all combo
boxes with sane defaults. Advanced mode gives them additional options.
Frequency adjust remains a slider. Given that 1 tick can mean the
difference between frame stuttering once a minute and once an hour, I
think it's worth keeping the precision.
Code-wise, I merged the ppucounter object into the PPU class (through
inheritance). This results in the following code simplification:
Before:
ppucounter.vcounter() //S-CPU time
ppucounter.ppuvcounter() //S-PPU time
After:
ppu.vcounter() //S-CPU time
ivcounter() //S-PPU time (called inside its own class, no need
for ppu. prefix)
i just stands for "internal". It was that or slow things down with a
co_active() check inside the counter read calls.
Man, it feels weird editing C++ code after all of that CSS magic. I
find myself wanting to write a pattern-matching rule ...
uint16 PPUcounter::vcounter() {
return cpu_vcounter();
}
uint16 PPUcounter::vcounter() [class="PPU"] {
return ppu_vcounter();
}
> I probably would have stuck it in a carefully-styled <SPAN> rather
> than an attribute, but I notice your approach is sanctioned by HTML5
> (or at least it would be if you called it "data-date" instead of
> "date").
<h3><span>2008-12-20</span>Title</h3>
<blockquote><p>All that is necessary for the triumph of evil is
that good men do nothing<span>Edmund Burke</span></p></blockquote>
Could work ... looks weird, though. Adding a class type to the spans
to state what they are makes it even more bloated, but perhaps worth
it ... hmm.
HTML5 approach looks cool, too. data- prefix isn't too bad. A good
indicator that it's not a real tag.
EDIT: oops, looks like I forgot that IE6 can't handle the text-align
attribute properly, either. Eh, I'll fix it tomorrow. Tired now.
[No archive available]
|
|
|
byuu
|
c13ae98863 |
Update to bsnes v038 release.
- eliminated S-DD1 DMA enslavement to the S-CPU; this allows the S-DD1 to behave more like the real chip, and it also simplifies the S-CPU DMA module
- eliminated S-PPU enslavement to the S-CPU; all processor cores now run independently of each other
- added cycle-level S-PPU timing for OAM address reset and OBSEL; fixes scanline glitches in Mega Lo Mania and Winter Olympics
- removed ppu.hack.* settings; as they are no longer needed due to above changes
- corrected VRAM tiledata cache bug; fixes Super Buster Bros v1.0 reset glitch
- added memory export and trace logging key bindings to user interface
- removed WAV logging (to trim the emulation core)
- embedded readme and license texts inside executable
- simplified S-CPU, S-SMP flag register handling
- source code cleanup for S-CPU timing module
- GUI-Linux: added style improvements to the listbox and combo box controls
- GUI-Linux: finally added filetype filter support to the file open dialog
- GUI-all: shrunk configuration panel [FitzRoy]
- GUI-all: modified paths panel descriptions for clarity [FitzRoy]
|
|
|
byuu
|
e370a35d7d |
Update to bsnes v037r07? release.
New WIP. The biggest news is that I've implemented what I was discussing earlier, and it worked perfectly. The S-PPU enslavement to the S-CPU is no more. As of this point, all four processor cores, and all three of their shared relationships, run completely independently of one another. This required moving the inline timing code from the absolute most timing-sensitive section of the emulator, to an entirely new external class. It also required logging more state data, adding ~100k/second more context switches, etc. It was unavoidable that the new approach would be slower, but I was able to greatly mitigate the speed loss. Right now, it stands at a ~6-8% speed loss from the previous release. But there is good news: 1) aside from SuperFX / SA-1 support, which will require additional processing inside the emulator core, no other changes should slow down the emulator again. It can only get faster from here. Most importantly, a range-based IRQ tester would offer a major speedup. 2) this approach will allow both a scanline-based and cycle-based S-PPU core to work with only one S-CPU core. No need to subclass and duplicate the timing code + scheduler as I was planning to before. 3) with this change, I was finally able to convert the scanline-based S-PPU renderer to a hybrid that I've talked about with FitzRoy in the past: this allowed me to finally cache OBSEL writes at (roughly) the appropriate position, while still rendering the screen at a different point. I render the screen at H=512, and cache OBSEL at H=1152. May not be hardware accurate, but it allows Adv. of Dr. Franken + Winter Olympics + Mega Lo Mania to all work as expected, all at the same time. It wasn't 100% exactly how I wanted to do things ... but I'm really happy about this de-coupling. I've always been a purist when it comes to implementing processor cores independently of one another, and it's always bothered me greatly the way the CPU controlled the PPU and its counters. With the above changes, I've eliminated the four ppu.hack config settings. I don't see much of a need for them. I've also embedded the readme and license text files. FitzRoy, I haven't had a chance to revise the readme as you were suggesting yet. Not ignoring you there, it's just low on my priority list right now. Lastly, I took FitzRoy's advice, and removed the WAV logger entirely. I'm also going to leave the screenshot capture out. At least for now ... the UI is starting to get a bit too bloated for my tastes. This is also the first uploaded WIP with the new debugging key- bindings (tracing and memory export.) I don't expect anyone here to have much use for them. Anyway, testing would be appreciated. It's very likely that the OBSEL cache position needs to be tweaked further. I recall LotR or something also had issues with caching in the past ... but I couldn't find the game at ::ahem:: the used game shop ... to test it. I think there were other games that had different behavior based on the old obsel_cache setting, too. Would be good to make sure they all work as expected. EDIT: Ah, "JRR Tolkein's LotR", bah. Yeah, no sprite flickering with the new WIP. Also, speed hit only seems to affect Core 2's. No frame drop on my Athlon. Probably something to do with locality of reference or somesuch. Modern processors are too damned complicated :P So then, assuming nobody spots any bugs ... how about a new release tomorrow? [No archive available] |
|
|
byuu
|
a721c7e91b |
Update to bsnes v037r06? release.
What about calling the "Default" button on the paths window "Auto" instead? And no, label text does not wrap. That's why I have the forced line breaks. New WIP: - fixes the tiledata cache glitch for Super Buster Bros V1.0; possibly others - adds updated nall templates: copy constructor vector class with amortized constant growth being the most notable change. Resisted the CC approach before because it's slower; but the amortized growth avoids most of the overhead, and I'd rather do things through the CC than possibly change the internal object memory base address transparently (invalidating self-pointers and such.) - adds snes.hide_light_cursors or something similar for Panzer88 Panzer88, I'd appreciate input on the last one. My fear is that because the system is 100% relative, if you move your Wii remote too far to the side, it will appear to "throw off" the alignment after the cursor sticks to one end. Only way around that would be to use absolute positioning. It'd be really difficult to support both relative and absolute systems at the same time, due to the way the drivers work. Absolute cannot work with the mouse by its very design, and it'd be sketchy with different window sizes and such for the light guns. And even if no game uses it -- it _is_ possible to use a mouse on port 1, and a scope on port 2. [No archive available] |
|
|
byuu
|
14bd3077e5 |
Update to bsnes v037r02? release.
New WIP. If anyone on Linux uses this one, be careful. I'm not entirely sure, but I think my style changes may be affecting the entire theme and not just bsnes. I looked at example code of other popular apps that do the same thing, though. I'm not sure if it's just my imagination. Audacious' file open dialog seems narrower, but every app still has the menu-style combo-boxes ... so I don't know. But if it is changing it -- I don't know how to revert it. Not like it's a major change, anyway. F-3582, cool thanks. You have the WIP URL, right? henke37, it can't do point filtering when upscaling the image (eg the image always gets blurry.) [No archive available] |
|
|
byuu
|
7236499e2f |
Update to bsnes v037r01? release.
New WIP. For Linux users, this adds a PulseAudio driver, using <pulse/simple.h>. Debian / Ubuntu users will need to add libpulse-dev, or remove "audio.pulseaudio" from the ruby= line in the Makefile to compile now. I wasn't able to test the driver at all -- I get "Connection refused" when I call pa_simple_new(). It appears that despite having Xubuntu 8.04, it doesn't come with PulseAudio installed. Guess they lied about it on their website or something ... I could install the packages, but hearing horror stories from others -- I'd rather not. If anyone can test for me, that'd be great. Check the console for error messages. Next, I finally got around to re-doing the S-DD1 driver to eliminate the need to hook DMA transfers inside the S-CPU core to recognize decompression events. That violated my strict feelings regarding separation of cores and avoiding enslavement, even when it adds significant overhead. I'm now going with a radically different approach, that's hopefully much more like the real hardware. It explains the way $4800 / $4801 behave, as well as why fixed transfers are required, but it may not be faithful. What I do is have the S-DD1 chip spy on $43x2-$43x6, and cache the values internally. Then, whenever you read from $c0-ff:0000-ffff, it will test if $4800 & $4801 != 0. If that's the case, we look at the address requested, if it matches one of the active S-DD1 channels (eg $4800 & $4801 & (1 << channel#) != 0), then we hijack the read with decompressed data. In my implementation, I decompress the entire block on the first read, then stream from the buffer. On real hardware, it most likely starts streaming on $4801.dN enable, but that's not too feasible for a few reasons for me. Most notably the S-DD1 lib requires a size parameter. It doesn't really matter, since we know the size from $43x5,6; so it doesn't suffer the same problems the SPC7110 did. Anyway, once all the data is transferred, it will clear the channel bit from $4801. There may be some hardware differences here -- can you perform two transfers at the same time? What happens if HDMA terminates the DMA channel? These things never happen in Star Ocean or SFA2, so they'll have to be tested manually. If no channels are active or there are no address fetch matches, it invokes the MMC to return raw ROM data. All of that gives a ~1.5% speedup both to regular games and S-DD1 games. The former because DMA transfers don't have to test for the S-DD1 during every transfer; the latter because I'm using a quick lookup table (slower per fetch) in place of re-mapping the whole banks on writes to the MMC (very slow per write.) The latter was much cleaner and simpler, but I need the former to hook the decompression stuff natively. Windows binary is included, I'd appreciate if anyone could play some Star Ocean / SFA2 and look for regressions from v037a. > I'm just so used to seeing everyone having a "Close" button in their > configuration dialogs I figured bsnes would have one. It just now > that I looked around that I realised that only some of the > configuration "panels" actually have buttons. Ah, I see what you mean. Sorry. I can add one if you want, I suppose. [No archive available] |
|
|
byuu
|
9b03874f32 |
Update to bsnes v037a release.
[No changelog available] |
|
|
byuu
|
a9bff19b5b |
Update to bsnes v037 release.
This release adds support for the SNES mouse, Super Scope and Justifier peripherals. It also simplifies cartridge loading and refines the user interface. Lastly, GZ and ZIP archives can now contain non-ANSI characters (Chinese, Japanese, Russian, ...) This support existed in the last release for all uncompressed files. Together, this means only JMA support on Windows lacks support for loading non-ANSI filenames. This is due to the library itself (really, it's more Windows' fault), and licensing issues prevent me from patching libjma as I did with zlib (bsnes is not GPL compatible.) I'm planning to work with Nach to fix this in a future release.
About the cartridge loading changes ... the emulator now determines what kind of cartridge is being loaded (eg normal, BS-X BIOS, Sufami Turbo cart, etc) by looking inside the file itself. If it detects a cart type that requires more than one ROM image to load, it will present you with the appropriate specialized load menu automatically. Aside from being more intuitive, this method also allows loading of BS-X and Sufami Turbo games from the command-line or via file association.
Changelog:
- added mouse support to DirectInput and SDL input drivers
- up to 96 buttons per controller; 8 buttons per mouse (5 per mouse on Linux) can be mapped now
- added SNES mouse support (does not support speed setting yet)
- added Super Scope support
- added Justifier support (supports both Justifiers)
- input management system almost completely rewritten to support new controllers
- "Load Special" menu removed, all cart loading merged to "Load Cartridge ..." option
- replaced "Power Cycle" and "Unload Cartridge" with "Power" -> "On" / "Off"
- when video exceeds screen size and is scaled down, aspect ratio is now maintained [Ver Greeneyes]
- zlib modified to support non-ANSI characters
- cheat code count was limited to 1,024 codes before; it now supports unlimited codes per game
- added sort by description setting for cheat code list
- polished listbox control interaction (disable buttons when nothing selected, etc)
- cleaned up OBC-1 chip emulation (code is functionally identical to v036)
- added option to toggle fullscreen mode to settings menu
- added advanced mode options to toggle base unit (none, Satellaview) and system region (Auto-detect, NTSC, PAL)
|
|
|
byuu
|
20be19f876 |
Update to bsnes v036r15? release.
Got the EP / Region stuff hidden in standard UI mode, and added the text label to the audio panel. Didn't post the WIP, not much point in testing that. I think I'll just take it slow, wait another week or so, make sure no bugs pop up; rather than rush a release this weekend. > If there is a problem with it, please let me know as I just spent a > while thinking about it Yeah, I wasn't sure about the math. That's why I put the height scale first. I think your code should be fine, too. If someone can definitively show them to be the same, we can use that just because it's smaller, which is nice. > By the way, is it just me or has the NTSC filter's intentional > glitchyness gotten erratic and unpleasant? It's like it randomly > gets a seizure I believe I turned off the NTSC filter's merge fields setting, now that we have vsync. It needs to have its own panel just for that filter, I'm just really lazy and don't want to add the hooks to libfilter to allow modifying NTSC filter settings :/ The merge fields thing looks good when not running at perfect 60hz, but it's less faithful. I figured more people would be using that filter with the idea of faithfulness, and thus vsync, enabled. > Oh, I wasn't bugging you about those again, they're years away from > feasible. Just stemming off the inevitable. I do wish it was quick and easy to add those, like with the other chips. So far the Cx4 has been the worst (thanks to Andreas Naive and neviksti's awesome S-DD1, SPC7110 and DSP-1 libraries, and Overload's DSP page for the rest.) And I even had at least half of the Cx4 done by Nach. > I'll just focus on the next two versions before I ask you if you're > interested in contributing to something on the game management end > of things. I hear game-specific settings are in high-demand. But that's a difficult thing to get working right. But yeah, thanks; we'll cover that in a future release. > 1. I noticed that you may have forgotten to remove video sync from > the advanced section after it was added as a functional menu option. Kay, we'll add that to the list. > 2. What happens when someone uses multiple mice? You currently don't > list the mapping as mouse00, just mouse. Will this ever pose a > problem? Both DirectInput and Xlib only support one mouse. If you plug in two, they both return input to the same device. You'd need something like ManyMouse to support multiple mice. I didn't bother as I didn't want to add another library dependency, and really -- how many people really have multiple mice on one PC? It's definitely a really neat feature in ZSNES, and the library itself is definitely awesome. But I think the analog joystick mapping should cover people who really want to use dual justifiers / mice for bsnes. If not, we can always add it in a future release. The guy's license is really permissive (zlib), which is awesome. EDIT: this _may_ pose some problems, too ... > On Windows, ManyMouse requires Windows XP or later to function, > since it > relies on APIs that are new to XP...it uses LoadLibrary() on > User32.dll and > GetProcAddress() to get all the Windows entry points it uses, so on > pre-XP > systems, it will run, but fail to find any mice in ManyMouse_Init(). > ... > Please note that using DirectInput at the same time > as ManyMouse can cause problems; ManyMouse does not use DirectInput, > due > to DI8's limitations, but its parallel use seems to prevent > ManyMouse from > getting mouse input anyhow. > ... > (XInput code isn't finished yet, but in the future this note will be > true.) Mmm ... those are what I use now. But I think ZSNES uses DirectInput, too; so who knows. [No archive available] |
|
|
byuu
|
f748a34e49 |
Update to bsnes v036r14? release.
New WIP. Couple of changes here. Ran into that damn char *argv[] crushing Unicode on Windows thing again with the MOTHER 3 patcher. Before I had to #ifdef the main() entry point and add all kinds of magic to rebuild the command-line string as UTF-8. So I moved all of that inside of hiro. Linux users can now use GTK+ command-line arguments as a result, too. And ui/main.cpp loses a bunch of platform-specific wrappers. Moved realpath(), userpath() and mkdir() wrappers inside hiro; as they all need UTF-8 <> UTF-16 stuff anyway. That cuts bbase.h to ~1.5kb. Very close to killing it off now. And probably most importantly, added VG's scaling changes. But I redid the code to support the same effect in windowed mode. I also made sure it works on portrait monitors, too (eg width is too big; scale height instead). That was a messy section before. Please test it out and let me know if it doesn't work as you guys were wanting. I want to get a new release out shortly. Release-stoppers right now are: - axis sensitivity sucks; mouse maps too fast, joypad axes don't map at all on Windows. - need to swap mouse.button01 with mouse.button02 so Linux and Windows use the same IDs; then I need to set defaults for the mouse / SS / Justifiers. - need to hide expansion port / region in simple UI mode. - still need to add that skew help message to the audio settings panel. If I'm missing anything serious in the above, eg you know of some critical bug or something, please let me know now. I'm going to put off the video panel discussion and ROM PCB mapping stuff until the next release or so. Too much to cover, and they'd take too long at this point. > That saddens me a little, not because I don't think you'd do a great > job, but because there are far more people rom hacking than there > are writing emulators or improving emulation. And what have we been improving for the last two years? :/ It's been 95% GUI polishing and minor bug fixes. The only major change I can think of off-hand was the HDMA timing improvements. I'm really starting to doubt that it's possible to simultaneously allow both the scanline and cycle-based PPUs. I try and come up with something every other week, and nothing I think of will avoid a major speed hit to the scanline renderer. And I really don't personally care about the SuperFX / SA-1. Yes, I know a lot of you do, and I'll hopefully get around to adding them. But if I'm going to start a months-long RE task, it's going to be the PPU first, sorry. And I'm at a major impasse there. [No archive available] |
|
|
byuu
|
0af5703c47 |
Update to bsnes v036r13? release.
New WIP finally adds non-ANSI filename support for GZ and ZIP archives. That plus the existing support for uncompressed filenames means it works with everything now but JMA archives. Compression support was enabled with this WIP for testing. I used Nach's suggestion with gzdOpen() for GZ, but I had to modify ioapi.c for ZIP support, as there was no unzOpen() that took a file descriptor. No big deal, it was only a four-line change and it works great. I noticed that the Windows hiro port wasn't sending the -1 position for when no items in a listbox were selected. That turned out to an absolutely major pain in the ass to support, thanks to the way Windows works. Say you switch from item #3 to no item, it will send "item 3 lost focus", but nothing for the fact that no item has focus. Easy enough, but then if you switch from item #3 to item #4, it sends "item 3 lost focus", followed by "item 4 gained focus." Since you can't tell after the first message if a second message will occur, you don't know whether or not to send a "no items selected" message; and if you try and wait and there is no message, you won't get a chance to send it again. Took a lot of evil state tricks, but I got it working. That'll make the input config, cheat editor and advanced panel buttons gray out when nothing in the list is selected. Please let me know if you spot any oddities with that. That ate up nearly all of my time ... with only an hour left, I fixed the input mapping once a cart was loaded; but I didn't have time to fix the Windows joypad axis mapping bug, which should be the only bug left at this point. > Your website got foobared somehow, I can't navigate to places. I knew what it was before even looking, based on your description. Derrick's host turned off PHP register globals. Apparently we can't have nice things because a few dumb fucks can't remember to initialize variables. Whatever, it's fixed now. [No archive available] |
|
|
byuu
|
f73d0908c4 |
Update to bsnes v036r12? release.
New WIP, doesn't do much. The core no longer scales axis values at all; and the platform input manager scales joypad axes only by 4096. Mice are unscaled here. Meaning you can use joypads and mice together at the same time now. Also updated the input config panel to add all the new input devices. Assignment is still sketchy. My idea is to separate axis movement from button movement, and allow fast mouse movements (+/- 20 in a given direction) or strong joypad axis movements (~50% tolerance+) to assign axis stuff. For buttons, they'd work as before, but you can also click a mouse button with the mouse over the input capture window. Disabled Xlib mouse acceleration during capture mode. I don't notice a difference, but I may as well leave it in case it matters somewhere. Sadly, it looks like buttons 4/5 are never set via XQueryPointer(), and you can only get buttons 6-9 with event callbacks. Since the input wrapper doesn't own the window (in actuality, GTK+ does), I can't safely bind the XEvents to capture those. So left, middle, right click only on Linux. After that's done, we should start polishing for the next release. > gtk_tree_selection_get_selected() returns items from the underlying > unsorted list rather than indexes into the sorted list. Really? That's interesting. Not sure I like that. If I call listbox.set_selection(0), I would expect it to select the first entry, not the eleventh. It does sound very convenient 99.9% of the time, though; I agree. > (imagine porting to Mac OS X's Cocoa GUI which tries to do even more > work for you...) Oh geez, let me guess. You can drag a listbox item out of one app, and drop it into another, and the other app can now invoke your callback functions for activate / change with it? :P > Since the X11 protocol only really supports three buttons, two > button mice generally have buttons 0 and 2, and button 1 is emulated > by clicking both 0 and 2 together (this is controlled by the > Emulate3Buttons option in xorg.conf). Excellent, very good to know, thank you. You sir, are a treasure trove of knowledge! :D So, should I go the Windows way for the majority; or the Xlib way since it's a bit cleaner? At least, when you consider most mice have three buttons these days. [No archive available] |
|
|
byuu
|
18389cb8f7 |
Update to bsnes v036r11? release.
Another WIP.
A few changes here; I added on_change notifications to both Windows
and Linux textboxes. I use that to only enable the "Add Code" button
on the cheat code screen when a valid GG/PAR code is entered. A bit
nicer than just not doing anything when you click "Add Code". Also
disabled toggle / delete code when one is not selected. Minor touches.
Added on_input mouse capture to the canvas widget for Linux. Needed
for the input.acquire() mouse capture hook.
Tried to use SDL_WM_GrabInput and SDL_GetRelativeMouseState ...
doesn't work at all. Unless SDL creates the window itself, it doesn't
give you any mouse info. SDL_WINDOWID hack doesn't work here either,
same issue with the keyboard input and why I had to use raw Xlib
there.
So, I use XGrabPointer + XQueryPointer + XWarpPointer and some magic
to make my own invisible cursor. Major pain in the ass. It works okay,
but it feels a bit too jumpy ... I'm going to try screwing around with
the acceleration controls to see if I can smooth it out a bit.
And hooray, more fucking cross-platform headache:
Windows: button 1 = right, 2 = middle
Linux: button 1 = middle, 2 = right
I had to completely disable the scale for this build to get the mouse
to work well on Linux, so no joypad axes for this one. I'd be
interested to see how the mouse performs for FitzRoy; where the last
one was too slow, this should be 5x faster. Surprisingly still
playable for me, but a bit too fast for my tastes.
The scalar of 1 feels great for Windows with the cheapo 400dpi mouse
here, too. I think this is a reasonable default.
-----
Detecting listbox column header clicks was easy enough on Windows:
if(((LPNMHDR)lparam)->code == LVN_COLUMNCLICK) {
printf("%d\n", ((LPNMLISTVIEW)lparam)->iSubItem);
}
And of course, there's no obvious way to do the same with GTK+:
http://www.gtk.org/api/2.6/gtk/GtkTreeView.html
http://www.gtk.org/api/2.6/gtk/GtkTreeViewColumn.html
http://www.gtk.org/api/2.6/gtk/TreeWidget.html
I have a couple of hangups about a column sort click, anyway.
1) there's no logical reason to sort by code (they're technically
gibberish, especially encoded Game Genie codes), status (you want the
list to change around when you toggle the status? yuck), or by reverse
description (scroll to the bottom and read up, same thing.)
2) it won't save the setting across runs; each time you load a new
game, you'll have to re-click to sort the list.
3) there'd be no way to stop sorting completely.
But again, we can make this a hidden option like deep filetype
detection if it's too obscure.
[No archive available]
|
|
|
byuu
|
448a8336b1 |
Update to bsnes v036r10? release.
Sorry, was a bit under the weather lately. Anyway, new WIP, very little changed. Updated nall::sort from insertion sort to merge sort* [O(n log n)], and then used that to add a "Keep cheat code list sorted by description" checkbox to the cheat code editor. I'll admit this probably isn't very useful, I really just wanted an excuse to implement a proper sorting algorithm and get rid of the embarassing O(n^2) sorting code I had in my template library. It's actually the first time in 11 years of programming that I've ever used a sort function in an application, believe it or not. I'll make it an advanced mode option if it really bothers people (eg as feature bloat.) It was only ~12 extra lines of code. (* not using quick sort as I need a stable sort for my purposes (eg two descriptions that are the same, but with different codes -- it shouldn't bounce around every time the list changes or you toggle the sort option), and it's nice avoiding the worst-case O(n^2) issue with quick sort.) Updated the mouse acquired check to work, but only on mouse input. Not that it matters much since I still don't have a method for distinguishing between mouse and joypad movement deltas. Eg this build only works with joypads, not mice. Moved the endian stuff from bsnes/src/lib/bbase.h to nall/endian.hpp. I've been trying to eliminate bbase.h for quite a while now. Getting pretty close, just some Windows POSIX wrappers and typedefs left. Hid a bunch of the new config file options from the advanced panel. The idea, of course, is to hide anything that can already be controlled from the GUI anyway. Sigh, no way I can make an October 14th release this year. Way too much stuff is broken. Dullaron, no, that's not the problem at all. See the input driver thread for more info. FitzRoy, wow, 1800dpi. Yeah, my mouse can do that, too; but I leave it at 1000dpi. That's odd, the work mouse is only 400dpi and its slower there than my 1000dpi. I'd have expected 1800dpi to be way too fast for you. I'm at a loss, maybe I'll take a look at how other emulators handle mouse movement ... [No archive available] |
|
|
byuu
|
233e645772 |
Update to bsnes v036r09? release.
I fixed up the SDL and X input drivers to work with the new model, so the Linux port builds again. For the sake of testing, this WIP disables the "mouse acquired" requirement, and raises the divider on motion to 5000 from 5. In other words, this release will work with gamepad thumb sticks, but not with mice. Having a _lot_ of trouble coming up with a way to get both working cleanly. But yeah, you can at least see how it works now. You want to set the X axes to "joypad00.axis00", and Y axes to "joypad00.axis01". Use the config file, input assignment is still screwed. > I can't get bsnes to recognize thumbstick 2. DIJOYSTATE2 has lX and lY, but that's it. I guess making that an array would be too easy. I'll have to dig through and hope one of the 20 other oddly named variables (lHX, lRX, lRLX, etc) refer to the other analog stick. You think that's stupid ... the scroll wheel increments in ticks of 120 per one physical tick of the mouse. Always 120, it's a fixed constant. Using DIPROP_GRANULARITY to get it from the mouse tells you the driver doesn't support that operation, but there's a Windows #define called WHEEL_DELTA for it. Seriously, what's the point of an arbitrary, fixed-value multipler for something, anyway? > An idea that I had that would get these things working for everyone > and every platform, would be to create 4 mappable directions that > could be assigned to a dpad If we could come up with some way to map both analog bi-directional inputs and single push button controls together, then yes we could do something like that. I think it would be too difficult to play like that, but whatever. The flexibility would be nice at any rate. [No archive available] |
|
|
byuu
|
f0627239bb |
Update to bsnes v036r08? release.
New WIP. Not really worth grabbing if you have a previous one, progress is very slow but steady here. First, I kept the just-in-time cycle-accurate Super Scope / Justifier latching support; but optimized things to reduce the overhead even more. It's now ~0.5% speed hit with no light gun, and ~1.2-1.5% with. Next, I rewrote ruby::input and the DirectInput driver to scan at O(1) instead of O(n). With that, I increased the max # of joypad buttons per controller to 128 (the # doesn't affect speed anymore -- 128 is just a hard limit with DirectInput), and gained a ~2% speedup over the old method. Renamed the mouse axes again, to just "mouse.x" and "mouse.y", sorry. Added a blocker for mouse.button00, but as the new input system merges key_down/key_up/axis into one single-pass scan, it's now mapping mouse motions, and if not that, lousy analog joypads that return sporadic values. Hey, it's a WIP release for a reason, right? Getting there, my idea is to have the input driver return information about what "type" of input each symcode is, and then pass masks from the input configuration mapping to control which types of input are considered valid for each of the different types of controls. Not sure if I want to allow the Mouse/SS/Justifier axes to be mapped by swinging the mouse fast in a given direction (the threshold now is any movement at all, I'd make mapping it require +100/-100 in any direction so you have to move it fast to map it), or use a dropdown box for that. Oh, and I added the glow shadow I was talking about earlier to the light gun cursors. If you do decide to try out the WIP, let me know what you think of that. The Linux port is pretty much 100% busted at this point. I have to port all of the SDL / X input drivers over to the new system. Ah, and if anyone's bored and has a five button mouse, try mapping top thumb to left, bottom thumb to right, left click to B, right click to Y, and middle click to start; and then play Super Mario All Stars - Mario 1. 100% control via mouse alone = good times :D I made it to 4-2 on my first life. > The speed at which the mouse moves is so slow The scale is based on my gaming optical mouse (it was the only 5-button mouse I could find without a tilt wheel; fuck those things), so the DPI scaling I use is pretty high. I'm having trouble getting it to move at the speed of your regular mouse universally, because I don't know what the speed of the mouse is to interpret the mouse movement results. [No archive available] |
|
|
byuu
|
ae67f268a8 |
Update to bsnes v036r07? release.
New WIP. This adds all the aforementioned fixes. I got the speed hit to ~1% with no light gun, and ~7% with. All three light gun modes allow you to go offscreen by 16 pixels in either direction, and Super Scope's offscreen flag is now supported. Mouse still needs the speed bits supported. I also modified the cursor just a bit by adding dots to each side of the circle. Makes it look a lot better. Not sure if I should add a shadow around the cursor or not. It really helps on red screens, but it seems kind of obtrusive to the view everywhere else. Oh, and the cursor works as expected in hires and/or interlace modes now. Also, x_axis, y_axis, button_NN is now mouse.x_axis, mouse.y_axis, mouse.buttonNN. joypadNN.button_NN and joypadNN.axis_NN are now joypadNN.buttonNN and joypadNN.axisNN. So be sure to update the config file again. Hopefully for the last time. I have not added the new input changes just yet, so the mouse button 0 still auto-assigns in the GUI. Use the spacebar or enter to bring up the assignment window for now. That also means that joypad analog axes won't work well for mouse simulation still. Other than what I mentioned above, please let me know if you spot any bugs this time around. Especially regarding the shots not going where you expect them to. I didn't test Yoshi's Safari myself, but it should be fine now. [No archive available] |
|
|
byuu
|
b2331ddb85 |
Update to bsnes v036r06? release.
New WIP. About 12 hours of non-stop programming ... I've added full mouse support to nall::input, hiro and ruby::DirectInput. With that, I added some really hacked-together support for the mouse, super scope and justifiers. Yes, all there -- now _please_ stop bugging me about this already. Caveats: - Mouse support doesn't honor the speed setting. - Super Scope doesn't currently let you go offscreen, which I should allow by at least a few pixels to allow the offscreen flag to be set for any games that might need it. - Dual Justifier mode is fucked. I don't understand where PIO is supposed to be raised, and I used a hack to get the "shoot offscreen to reload" thing to work for the single Justifier mode for now. The dual one tends to desync when you go offscreen and stuff, not very pleasant. - I'm not going to support SS / Justifiers in port 1. Since they can't latch counters anyway, and no games make use of them, I don't see much point in cluttering the menu more and confusing new people. Both multitap and mouse have games that can use port 1, so they stay. - There's no input config panel to map buttons. You have to edit the config file directly. - The mouse delta absolutely sucks. It's just a simple div 5, so moving the mouse really slowly won't even register, and moving it fast has only a linear curve. This one's going to be a real pain in the ass to get right on everyone's system, as the ranges DirectInput gives for mice tends to vary based on resolution, software and hardware mouse speed settings. - Joystick delta range is -32768 to +32767, so div 5 means it'll be pretty much unplayable with the joystick. - Input capture window binds mouse clicks now. This needs to be expanded quite a lot to support selective axis and mouse assignment. - The software-rendered cursor doesn't work right in hires / interlace modes. - To get the PIO latching behavior 100% correct without a dead spot during DRAM refresh, I'd have to test the cursor coordinates every single clock cycle. That would be way too damn slow, so I used a huge hack instead. I just test once per scanline and fake the latch counters to the cursor position. This is really shitty, and some timing-sensitive code that was looking for this could easily detect the emulator because of this, but it's either a ~10-20% speed hit, or no speed hit at all and hacky SS / Justifier support. Since it seems to work with all the games anyway, I'll go with the latter for now. - No Linux support for any of this stuff yet, sorry. If you want to try it, the config file keysyms are: "x_axis" - mouse x axis "y_axis" - ... "button_00" - "button_07" - mouse buttons; hope you have the side buttons on your mouse for the Super Scope, otherwise have fun using a keyboard + mouse at the same time. "joypad00.axis_00" - "joypad00.axis_03" - joypad axes (only 0,1 work with DirectInput; 0-3 for SDL.) Yes, I'll rename the mouse ones to "mouse.foo" in the future. Aside from all that, not really looking for bug reports at the moment. Way too preliminary for that. Oh, and you have to click inside the video output to acquire the mouse. You'll know as the mouse cursor goes away. You can release the mouse by pressing escape on the keyboard. If the mouse is acquired, escape overrides any GUI key assignment to that button. You can also toggle fullscreen mode and the mouse will stay acquired. You can't acquire the mouse unless you have a mouse/SS/justifier attached to a controller port, and a game loaded. [No archive available] |
|
|
byuu
|
2a2f50a8bc |
Update to bsnes v036r05? release.
New WIP. I was really hesitant to even do this much, but ... biggest feature: Image Lots of caveats here. The biggest one being that it isn't controlled via the mouse, as I don't have any mouse driver code written; and I really have no idea how to bind the mouse to the bsnes window region, nor do I really want to do that. I also can't map it to standard on/off keys, as there's no delta response to them. It would be uncontrollable like that. Instead, I've mapped it to the analog axis sticks on gamepads. The further you press the gamepad axis stick, the faster the mouse moves in said direction. Mouse left+right can be mapped to keyboard or gamepad buttons. I know, I know, not everyone has analog gamepads. Sorry, this is the best I can do for now. Does it work well? Honestly ... not so much. I can clear the first stage of the fly swatter game in Mario Paint, but that's about it. The only real advantage is you don't need ManyMouse to emulate two mice at the same time. It also works pretty good in the text games, like Tokimeki Memorial. Also, the documentation out there for the mouse absolutely _sucks_. I have no idea how the speed bits are supposed to work, so they aren't emulated at all. Thus, the mouse speed settings in games do nothing. It also fails the SNES mouse electronics test. But it is usable. Anyway, how to use it ... run the new WIP, then edit the config file. You have to manually set it up as there's no GUI for configuring it yet. Look for "input.mouse(1, 2).(x, y, l, r)". Here, you want to set x, y to axes, eg "joypad00.axis_00", and l, r to buttons, eg "joypad00.button_00". This only maps four axes for now, so limit the axis range from 0-3. Buttons can be 0-15. **Please do not bug me to improve this!** This was just a functional demonstration. It's going to be many months before proper mouse support is added, it may never even be added, who knows ... I have a _ton_ of complicated problems that must be overcome before I can get real mouse support in there. If you want to actually help with the programming side of things, then we can certainly talk about that. Also, **please do not bug me to add the Super Scope / Justifier next!** I can't even do it with the gamepad trick, because these two are supposed to trip interrupts at exact points, which is really difficult for me to do at this time. The SS would also require a software cursor to be drawn on-screen, another technical challenge. [No archive available] |
|
|
byuu
|
30b19613d5 |
Update to bsnes v036r04? release.
New WIP. Quite a bit of neat stuff this time. First, BS-X and ST BIOS detection is in. Attempting to load them will bring up the multi-cart loader window with the BIOS fields filled in. So now it doesn't matter what image the user tries to load, it'll just work. Next, added the expansion menu per FitzRoy. You can choose between "None" and "Satellaview BS-X". I also added a new menu there, for region selection. There's "Auto-detect" (base off the cart type), "NTSC" and "PAL". Admittedly not very useful, but I figure since we aren't automatically selecting the expansion unit, we should make it possible to manually specify the SNES type. Looks like some games work in either region, eg the SNES Test Program - Electronics Test. That kind of surprised me. I was thinking it might be best to hide expansion port + region when advanced mode is disabled, since it's something I imagine 99% of users will never need to touch. Also, it's set up so that you can only change the settings when the power is off, or no cart is loaded. This is very much intentional! It's impossible to change the SNES console without a mod-switch while it's on, and it'd be really stupid to try hot-swapping the BS-X base unit while it's running. You can still expand the menu to see what is currently selected, unlike power. I figured there wasn't much point in seeing the power-on state with no cart loaded. It's obviously off in that case. Speaking of which, updated hiro to support MenuGroup::disable() properly on Windows. Fixed the minor cosmetic Y start offset on the drivers panel. And I cleaned up the cart loading a bit more. Still need to do a bit more work on that, but it's looking pretty good so far. [No archive available] |
|
|
byuu
|
98fc865130 |
Update to bsnes v036r03? release.
New WIP. This one adds BS-X flash cart detection (please let me know if you get any false-positives or false-negatives), the redesigned System menu suggested by FitzRoy sans it still saying "Load Cartridge ..." (still open to suggestions at this point, of course), Power on/off in place of power cycle, henke37's fix for hiding the "Read Only" checkbox on WinXP file dialog boxes, and henke37's suggestion to add ellipses to form buttons that open new windows. Thanks to everyone for their help with this. Please note that Windows isn't disabling the "Power >" group as it should. I'll work on that tomorrow, got tired of screwing with it. It's ignoring MF_GRAYED and MF_DISABLED on group items for some reason. It works fine on Linux, and nothing bad will happen if you swap power states with no cart inserted. I won't release a new version until it's fixed properly, or until I find out I can't fix it properly (hopefully the former), of course. I'm also open to suggestions for improving the layout of the advanced mode audio panel. Note that it needs to be text boxes to enter values. Spinboxes aren't going to work there. [No archive available] |
|
|
byuu
|
f6a04682f5 |
Update to bsnes v036r02? release.
Finally got belegdol's Polish locale up. Thank you again for that! New WIP. The main thing is that all of the "Load N Cartridge ..." options have been merged into one. Here's how it works: - Load a normal cart, and the game starts right away. - Load a BS-X slotted cart, and you get a window with the slotted cart set to base, and the slot section empty. You can use Same Game + SG- FEoEZ or whatever to test. - Load a Sufami Turbo cart, and you get a window with the BIOS set to whatever was used last (blank for the first time), the ST cart assigned to slot A, and slot B blank. The ST won't actually play any games with a cart only in slot B ... but it does display a unique error message if you try. You can always clear slot A and then assign again to slot B if you want. Another benefit is this works with command-line loading, too. Before, it was impossible to load BS-X / ST games from the console / bsnes executable association. There is a bit of a lag in startup, as always, so that's a bit noticeable. Right now, I'm missing the algorithm for BS-X flash cart detection ... Nach, I don't suppose you'd mind posting that for me, please? Further, in the future I'd like to also detect the BS-X and ST BIOS files, and assign those and show windows with all slots empty. FitzRoy, if you want to mess around with the System menu layout again, that's cool. Just keep in mind that "Power Cycle" is still there in advanced mode. It looks tacky with load+unload+reset+powercycle with no separator. Unload cart does appear to have limited use, so if necessary, we can consider removing that, I suppose :/ [No archive available] |
|
|
byuu
|
87b91f0ace |
Update to bsnes v036r01? release.
Posted a new WIP. The biggest change was that I rewrote nearly all of the cheat code system, so heavy testing on that would be appreciated. Someone was mentioning over at Snes9X that it was limited to 300 cheats or something, so someone bumped it to 3,000. Not to be outdone (v036 is limited to 1,024), I vectorized the cheat table, meaning you can have infinite cheats now (limited only to available memory.) Actually cleans up the code quite a bit, too. Removed all the ugly strlcpy() stuff, the limitations on description text length, etc. Looks like I had a bug with deleting codes, too. I wasn't copying the actual cheat codes. That would corrupt the descriptions on every code after the one you deleted, I think. Strange nobody caught that. I also cleaned up the OBC-1 code, and added a "Fullscreen" checkbox after "Correct Aspect Ratio". Sorry for the delay with that, FitzRoy. Hopefully the checkbox is good enough for now, as I can't change the text to "Switch to ..." just yet. [No archive available] |
|
|
byuu
|
0114e10ede |
Update to bsnes v036 release.
This release fixes a somewhat serious bug introduced in v035, and also vastly improves Windows support for non-ANSI filenames. The bug was triggered when HDMA would occur during DMA. If the DMA were long enough, subsequent HDMA transfers would be blocked. This caused graphical glitches in Star Ocean, Super Mario Kart, and possible more games. If you noticed any regressions from v034 to v035, this was almost certainly the cause. Once again, we're operating under the assumption that there are no known bugs currently, so please let us know here if you find any. I've also rewritten the file handling for the emulator. On Windows, attempting to load a file with non-ANSI characters (eg Russian, Japanese, etc) would cause these characters to be removed. This meant that no version of bsnes thus far could load these files. This problem was exacerbated when I ported the user interface to Unicode (UTF-16), this caused even config and locale file loading to crash the emulator. The root of the problem is that Windows only accepts non-ANSI strings in UTF-16 format, whereas bsnes' UI wrapper converts strings to UTF-8 interally. When passing these file names to the standard file functions (fopen(), std::ifstream, etc), file loading would fail. To fix this, I replaced all file access functions with a new version that would convert the UTF-8 filenames back to UTF-16, and use appropriate access functions (_wfopen(), _wmkdir(), etc.) ... but there is still one limitation to this: ZIP and GZ support use zlib, and JMA support uses libjma. Neither of these libraries convert UTF-8 strings to UTF-16 before attempting to open files. Due to licensing issues, as well as technical issues, I am unable to correct this at this time. What this means is that loading ZIP, GZ and JMA files; on Windows only; and with Unicode characters in the file name only; will cause the image load to fail. Loading uncompressed images (SMC, SFC, etc) will work with or without Unicode on all platforms. I tried to be as thorough as possible with this fix: command-line arguments (via CommandLineToArvW + GetCommandLineW), user path (via SHGetFolderPathW), real path (via _wfullpath),folder creation (via _wmkdir) and file access/existence checks (via _wfopen) were updated in all cases. I also updated file loading for ROMs (SMC, SFC, etc), save RAM (SRM), real-time clock save (RTC), cheat files (CHT), UPS patches (UPS) and both configuration files (bsnes.cfg and locale.cfg.) Configuration file loading should work even if your username contains non-ANSI characters, and it should also detect config files put in the same folder as the bsnes executable, even if the path to the executable contains non-ANSI characters. Still, if you spot any bugs, aside from the ZIP/GZ/JMA loading issue, please let me know via e-mail at setsunakun0; at hotmail. Lastly, I'd like to apologize for the poor support for non-ANSI filenames in the past. Using an English version of Windows didn't expose the problems to me. I'll be more thorough in the future with this. |
|
|
byuu
|
8c591ce44a |
Update to bsnes v035 release.
Changelog:
- Added video synchronization support at long last [blargg, byuu].
- Added audio panel to control volume, latency, frequency and SNES input frequency settings.
- Added driver panel to select APIs to use for video, audio and input.
- Added crash handler for driver initialization.
- Xv and SDL video drivers now work with compositing enabled on Linux/Xorg.
- Improved ALSA audio driver for Linux.
- Now using a fixed output frequency, along with a 4-tap hermite resampler.
- Improved header detection; fixes Batman: Revenge of The Joker and a few fan translations.
- Frameskip will now randomly choose a frame in each set to display; helps with animations.
- Locales now support meta-data, which allows for unique translations of the same English input.
|
|
|
byuu
|
e2cc164f70 |
Update to bsnes v034r06 release.
This will probably be the last public WIP, so get it now if you want
it.
http://byuu.cinnamonpirate.com/temp/bsnes_v034_wip06.zip
I used the same "create a child window inside the output window" trick
for Xv that I used for OpenGL, so Xv will now work even with a
compositor enabled.
I also added Video::Synchronize support to OpenGL for Windows. My card
seems to force it on regardless of my driver settings, but maybe
you'll have better luck. That driver had the same issue with
allocating 16MB of memory instead of 4MB (that was due to copy and
pasting of code), so that's fixed too.
This version lowers the CPU<>SMP drifting by an order of magnitude.
You shouldn't notice the speed hit. I can't really get any lower
latency with that, though.
I also restricted the latency range to 25 - 175, with the default
being in the center, 100ms. Quite conservative, given the average we
see is 70-80ms. But you won't notice the difference, and this way we
ensure no popping even in exceptional circumstances by default. 25ms
is doable without video sync and with OSS4+cooked mode, but I
seriously doubt any Windows user will get lower without something
crazy going on with the sound card drivers.
Lastly, I've replaced the 2-tap linear resampler with a 4-tap hermite
resampler. You won't be able to tell the difference, but it's quite
pronounced if you use a waveform analyzer on much higher output
frequencies:
Linear:
Image
Hermite:
Image
Hermite is essentially better than cubic (for which cubic spline is an
optimized version of), as it is better at not going too far away from
the points, so you get a bit less clamping in the extreme cases. But
the difference isn't audible to humans anyway. It's still clearly
inferior to band-limited interpolation, as it will still have
noticeable aliasing of things like square waves and such, but it's
orders of magnitude less complex to implement.
Keep in mind that nobody could tell the difference even with linear
interpolation from the last few WIPs.
----------
Aside from that, I'm pretty much ready to release a new version. If
anyone has any show stoppers, _now_ is the time to say something.
Otherwise I'll probably post something tomorrow or Friday.
|
|
|
byuu
|
d09e54149b |
Update to bsnes v034r05 release.
http://byuu.org/temp/bsnes_v034_wip05.zip OpenGL/Linux now destroys the window and colormap it creates, and it also avoids allocating 16MB of memory when only 4MB are actually needed. Forgot to remove the * sizeof(uint32_t) from the buffer allocation after changing it from malloc to new. I use 4MB because the internal buffer size is 1024x1024@32bpp. I make it larger than needed to support both present and future filter requirements (eg HQ4x would need 1024x960 minimum.) The X-Video driver will now look for XV_SYNC_TO_VBLANK and add the video synchronize option when it exists. Unfortunately, that doesn't stop the binary nvidia driver from ignoring the setting anyway, but it should be nice for those using the nv driver or somesuch, especially as it lacks OpenGL support. For whatever reason, I was able to get my latency in DirectSound down to 70ms. Not sure if it's related to these changes or not, but I won't complain. I also needed to set 32150hz / -50 for the input frequency adjustment. Probably just differences between the monitor timings on Windows and Linux. That said, let's get some averages. With the new WIP, be sure to reset all of your audio and driver settings. It may even default to no driver at all if you were using a custom one before. From there, please post the video driver, audio driver, latency and SNES input adjustment values that work best for you. > BTW, were you able to look into that status bar bug? Thanks for pointing that out. The status bar properly restored its state, but the menu bar did not. Rather than save the menubar state (I wanted to avoid that for people who accidentally hide the menubar and then close the app, and don't remember how to re-enable it), I just made it not save the status bar state at all. Apologies to those who hate the status bar, you'll have to turn it off more frequently now. Direct your pitchforks at FirebrandX :P [No archive available] |
|
|
byuu
|
8e4f1be189 |
Update to bsnes v034r04 release.
14 hours of straight programming brings you this:
http://byuu.cinnamonpirate.com/temp/bsnes_v034_wip04.zip
Windows binary and source included, binary does not have ZIP+JMA
support enabled, as it's a WIP release.
Yes, vsync works both on Windows and Linux. In fact, it actually seems
to work better on Linux, in that it requires lower audio latencies and
has no troubles at full 5x scale on my 1920x1200 monitor.
Overview of new features:
Most importantly, I've added a new menu group to the settings menu
group, "Synchronize", containing "Synchronize Video" and "Synchronize
Audio" checkboxes. You can have neither, one or both checked. Up to
you. That made the "Uncapped" speed setting redundant, so that was
removed.
Next, there's a new audio configuration panel with lots of new
goodies.
Volume lets you scale audio from 10% to 200%. Note that going over
100% will obviously cause aliasing. It's a much better idea to turn up
your speakers first. But who knows, it could come in handy. On one
machine with OSS4, I couldn't adjust volume in Audacious, and it
always bothered me that it was so much louder than bsnes, so I saw no
reason to cap the volume to 100% here.
Latency lets you control the number of milliseconds between adding
data to the sound buffer and it being played. Note that this is _not_
the absolute latency. Any sound servers and resamplers will obviously
add to this. It increments in steps of 5ms, because I don't want
people wasting their time trying to get it absolutely perfect. 5ms is
a small enough increment that no human being will notice. I also have
to re-create all the buffers and/or device itself when that changes,
so I want to keep it from changing too frequently. Not that there's a
memory / resource leak, but just in case.
PC output frequency let's you control the master frequency for the
sound card output. You can set this to 22050hz (not a good idea, loses
precision, there as a last resort), 32000hz (for purists), 44100hz
(for most cards), 48000hz (for higher end cards -- set as default
because it's a nicer multiple of 32000 than 44100 is) and, yes,
96000hz. And I'm sure all the audiophiles will remark how much better
it sounds, right?
Believe it or not, there's actually some value to higher frequencies
for the vsync. Higher rates lower the rounding errors with
interpolation and such, so you can use lower SNES input rates. And
speaking of which ...
SNES input frequency is what the base SNES input is skewed to. The
basic idea is that you want to get the value as low as possible
without sound crackling. The lower it is, the less video frames
duplicated, the less jerkiness of the video. The higher it is, the
less likely an audio breakup is.
Once again, Linux seems to come out on top here. Because of it's non-
ring buffer approach to audio, both ALSA and OpenAL can insert blank
samples in a way that DirectSound simply cannot. Whatever it does to
BS underflows, it works really well, because you can barely even
notice it.
The default is a tad on the dangerous side. If anything, you may need
to increase it.
Get the right values for everything, and you can easily play games and
never notice any video tearing or audio crackling whatsoever.
Lastly, I removed the "Show Statusbar" option from the misc menu, per
FitzRoy.
Oh, also note that with Linux (both for OpenGL and Xv) and Win/OpenGL,
you have to toggle the vsync enable in your video driver's control
panel. Pain in the ass, that. Linux/SDL and Win/GDI do not vsync. No,
I'm not even going to bother trying to add that to them.
My settings:
Hardware:
nVidia 8800 GTS 320, Intel HDA audio, 24" LG @ 1920x1200x24bpp@60hz
Windows:
Direct3D, DirectSound, Latency = 120ms, PC freq = 48000hz, SNES freq =
32050hz; 4x scale always works, 5x scale misses vblank every few
seconds
Linux:
OpenGL, ALSA, Latency = 60ms, PC freq = 48000hz, SNES freq = 32050hz;
4x and 5x scale always works
I'd be interested in hearing what works best for you guys. I'm
especially interested in how PAL works on a monitor running at 50hz. I
don't have any that can handle that resolution, nor 100hz. I don't
expect scrolling to look great at 100/120hz, as I have no special
handling for it.
> Even if it is wondows-only, you may want to add the option of using
> a short sleep in the advanced options panel.
No, I really can't :P
I tried just to see what would happen, calling Sleep(1) a single time
is enough to jump over the entire vblank period. In the worst case
scenario, you get stuck in a loop, never hitting vblank, and the
framerate drops to 1fps. Trust me, you don't want a sleep in there.
Now, I know you're thinking, "why not let the video card do the sync
for you?" -- well, one, some drivers still eat up all the CPU time in
their loops, and two, by polling the vblank status repeatedly, I
actually get better results with 5x scale in D3D on my system. And I
don't have to destroy the video device to toggle the video sync
enable.
[No archive available]
|
|
|
byuu
|
f529a84fd1 |
Update to bsnes v034r03v release.
For Windows / Direct3D / DirectSound _only_.
http://byuu.cinnamonpirate.com/temp/bsnes_v034_wip03v.zip
Leave it at 100% speed, play NTSC games, leave frameskip off. I don't
care if any of that is broken or not right now.
There are two special variables this time: system.vsync_magic and
system.latency_magic.
The former is the skew for the resampler, you create that many samples
per 32000 samples of output. The latter is the latency in samples. It
will tell you how much total latency you'll end up getting when you
start the emulator.
Note that the system requirements are much greater with the CPU<>SMP
desync trick disabled. It's something like 10-20% slower. So leave off
the filters, please.
If vsync_magic is too low / high, it will tell you on the terminal by
printing an underflow warning. If latency_magic is too low, you'll
hear crackling.
The bad news: no matter what values I plug in, I still get crackling.
I can get it to be pretty rare, but I'm completely unable to get
smooth audio. Maybe you'll have better luck, who knows.
For me at least, the vsync_magic value that sounds best keeps varying
every few minutes between 32100 and 32250. The latency is through the
fucking roof. I've got it over 120ms and it's still not enough to
prevent occasional audio crackling. It's already much too high to be
practical for a release.
Note that without vsync, it only needed to be 60ms, and that was a
conservative number. We could get it down to 20-40ms with the right
hardware.
[No archive available]
|
|
|
byuu
|
567d415290 |
Update to bsnes v034r03 release.
New WIP, with _major_ changes to internal header detection.
This should get everything working, if we're lucky. It does get
Batman: RotJ working for the first time, as well as all the fan
translations.
I'm releasing it publicly, as I need all the help I can get with this
one. Windows binary with ZIP+JMA support included along with source
for the penguins.
byuu.org/temp/bsnes_v034_wip03.zip
Do note that I left the console enabled in the binary. It's not a
release-grade version, anyway. But the main reason was to print the
scoring information. If any games fail, I'd like that information
posted. Might be good to note really close passes, as well, so we can
keep an eye on them for future changes. Right now, I'm only aware of
SFA2 that gets really really close.
Basically, it prints the address it tests for a header at, the score
it ended up getting, and the reset vector's first opcode. If the
values are equal, it defaults to LoROM, then HiROM, then ExHiROM. If
the reset vector is invalid, or the ROM is too small to contain a
header at a certain offset, you won't see any output for that line!
That means a lot of times, you'll only see one line output, and
sometimes you'll see two or three. No worries, just assume missing
means total fail. It only prints output for "possible" header
locations.
If you do test, you don't have to play in-game or anything. The second
you see any visible output whatsoever, that's good enough.
Many thanks to everyone who tests in advance :D
----------
Hunter and tukuyomi, thank you for the kind words and localizations :)
I really hate that table on the download page, and I need to go
through and get names out of all of the locales, but I'd like to get
an "Author:" field in that table on the download page. Sorry it's not
there just yet.
----------
Fes, thanks for the feedback.
> Apparently it has a limit of 65535 bytes for string literals.
I don't have a workaround for that. For whatever reason, ISO didn't
add an "incbin"-style command, and I need a platform-agnostic way of
encoding binary data.
Not for v035, but maybe a while after that, I'll use a more advanced
compressor to get the controller below 64kb of string data. Maybe I
can rig my order-0 arithmetic coder onto the end of LZSS for a quick
and dirty size cut. The reason I don't use 0xnn, 0xnn, is because that
takes 5 bytes of source to encode one byte of input, whereas base-64
strings only take ~1.25 bytes. I didn't want those files to slow down
compilation much.
> # Next, in dictionary.hpp, the first for loop uses 'i' as its
> counter, then declares 'i' again inside the loop body for additional
> work.
Oops, sorry. Didn't get a warning on GCC, so I overlooked it. This is
now fixed.
> # Cartridge::get_base_filename and Cartridge::apply_patch both claim
> to return a value, but don't seem to do so.
First should return the filename, it's just a convenience thing to
allow chaining commands. The second should return result of patching.
I've fixed both now, thanks.
> # spc_dsp.h, nal/file.hpp, and ups.hpp all attempted to include
> stdint.h, which isn't part of vc++. Are those files perhaps meant to
> include nall/stdint.h instead of the standard one?
Microsoft really pisses me off by intentionally ignoring stdint.h.
nall/stdint.hpp was meant as a workaround, so that I didn't have to
special case Visual C++. The idea was to not require you to get one of
those third-party add-ons.
So yes, two of those were a mistake on my part, I used stdint.h on
them before I created my own stdint wrapper. I've corrected both.
As for spc_dsp.h, that shouldn't be compiled. That is for blargg's
reference, unmodified S-DSP emulator. The ones modified to work in
bsnes do not require it. And in fact, only src/dsp/sdsp will compile
at the moment due to memory map changes.
> # pEditbox::get_text seems to declare a dynamically sized stack
> array, which CL balked at.
Hahah, yeah, that would be C99 syntax. Very nice, that.
Looks like I was allocating length*2 wchars, too. I don't know why I
was doing that ... I don't think Microsoft's system even supports the
extended Unicode symbols that need more than 16-bits, and even if so,
they aren't likely to appear in the emulator.
Dropped that back to length+1, and made it use new[]/delete[],
instead. That's one horribly inefficient routine by the way, but
whatever, it works for now.
The rest I can't do much about, sorry. Hopefully it'll make it easier
for you to compile in the future. Sorry for letting the port slip, I
just don't have the patience to load VS2k5 again. Software takes like
three hours to install >_< and creates slower code than GCC4 anyway.
If they'd fix their damn PGO support, I'd be all over it again,
though.
|
|
|
byuu
|
435a194ccd |
Update to bsnes v034r02 release.
New WIP. First, the internal ROM header detected was enhanced. Nach was right, so I went ahead and did it the right way ... it'll score all three regions individually now, and then use some heuristics for those annoying games that duplicate the header entirely in multiple places. The hardest games to detect, that I recall, are Double Dragon and Street Fighter Alpha 2, which seem okay. In fact, all ~50 of the games I have seem to be working fine. Please let me know if any games fail to start as of this WIP. Second, finished updating all of src/memory to convert uint -> unsigned. Yeah, I like the former more, but the latter is a built-in type. Did the same to hiro, and converted Event to event_t, looks nicer in code. Part of namespace libhiro, so no worries about other things named event_t. Third, added the frameskip cycling code. It just randomly chooses which of the set of frames to display (random() % (frameskip + 1)). Seems to work as expected, you can see Link blink when hit even with FS=1, but obviously it stutters a bit more. Fourth, I finally added RedDwarf and Nach's latest ALSA code. ALSA will now with at 75% speed and with speed uncapped. It has the same overhead as OpenAL. So, unfortunately, due to OpenAL's issues with completely destroying echo / reverb for some reason, I'm going to have to recommend Linux users set system.audio to "alsa" from now on :/ FreeBSD users should rely on "libao". I'd like to release an update this weekend to address the ToP issue, as well as a missing string in the translate[] hooks and to distribute the new ALSA updates. I'm worried about the header detection changes breaking some other games, though. So if you guys wouldn't mind throwing a bunch of random games at it, I'd appreciate it. It _should_ be fine, though. In theory, the LoROM / HiROM detection is identical to the last release still, but I did restructure it, so you never know ... Oh, and I updated the website with new locales from Hatsuyuki, Itol, khiav and wushu. Thanks, guys! [No archive available] |
|
|
byuu
|
df9de289b9 |
Update to bsnes v034r01 release.
New WIP (yes, already.) Nothing that affects emulation, just a bunch of core changes I didn't want to make last-minute before the release. All of the APURAM / VRAM / OAM / CGRAM memory blocks have been moved to the Memory class, and I've added operator[] bindings and such so that I don't have to add .read(), .write() around everything. Required several dozen individual changes, and I was afraid of introducing a new bug. Everything looks good so far, anyway. I also missed the translate[] call around "Paused", so it's not possible to localize that in the new version. Oops. > edit and thanks to Jonas Quinn for the $4810 register/Super Power > League 4 fix. Definitely, I wasn't going to release a new version this week because of that bug. Speaking of which, I just tried SPL4 on the Windows port. Holy hell, that completely changed my opinion of OpenAL. Seriously, those on Linux ... compare that game with OpenAL and ALSA. With DirectSound / ALSA, the game actually has echo / reverb. It's _completely_ missing with OpenAL. The woman announcer sounds like she's speaking over a megaphone, but OpenAL makes her sound like she's two feet away from you. Wild stuff. And SDL video is going crazy on me now, it seems to be setting each pixel's alpha value to some sort of inverse of chroma. Eg you can see the background through the emulator window, and it's completely transparent on full white / black screens. Really trippy looking. Definitely be sure to set system.video to "glx" or "xv" if you use the Linux port. [No archive available] |
|
|
byuu
|
dd83559786 |
Update to bsnes v034 release.
For this release: SPC7110 emulation speed has been greatly optimized, massive improvements to HDMA timing have been implemented, Multitap support was added, and the user interface was polished a bit more.
Changelog:
- SPC7110 decompression code updated to latest version by neviksti and converted to a state machine; SPC7110 overhead is now identical to S-DD1 overhead (eg ~5% speed hit over standard games)
- Fixed a major bug in SPC7110 data port emulation that was crashing Super Power League 4 [Jonas Quinn]
- HDMA trigger point corrected to H=1104, bus sync timing corrected
- All illegal DMA A-bus accesses should now be properly blocked
- DMA state machine rewritten, greatly simplified
- Major corrections to HDMA run timing; fixes flickering bugs in Mecarobot Golf and Super Mario Kart
- Emulator now defaults to 2/1/3 SNES (CPU/PPU1/PPU2 revision numbers)
- Multitap emulation added, can be attached to either or both controller ports; user interface updated to reflect this
- Status messages (cartridge loaded / unloaded, UPS patch applied, etc) now appear in status bar
- Added advanced configuration option, "input.analog_axis_resistance", to control gamepad analog stick sensitivity
Also, the SPC7110 emulator download link below was removed: if you are looking for this, please download the bsnes v034 source code, which has the most up-to-date version in the src/chip/spc7110 folder.
|
|
|
byuu
|
100ef3a271 |
Update to bsnes v033r09? release.
New WIP, probably not worth downloading. For the sake of completeness, I finished optimizing the SPC7110 code. I've converted the pixel buffer rotation from swaps to moves, which should double the speed of the slowest part. I've also added reverse morton lookup tables (2x8-bit and 4x-8-bit deinterleaving), which are 8-10x faster than doing it using pure bit logic, I removed the redundant comparisons from the pixel context lookup (though a compiler would've done the same anyway), and lastly I've cut the mode2 context table in half, since the refcon add bit was only set on context 1 anyway. I could've replaced the other half with 5-6 if/else statements, but I didn't see much of a point in that since it'd only make the code harder to understand. That results in a 1-2fps speedup, at best. Really, the code is simply not a bottleneck. It's pointless to optimize anymore, as any changes from this point on will just make it harder to understand what's happening. I only added the morton tables because it does seem to aid readability. Also added translate[] wraps around all the new status messages, and moved the two checkbox options on the paths window to the advanced options list. No sense cluttering up the UI with near-useless settings. > It's hard going back to "Are you sure you'd like to exit?", no > multiplier eyeball stretching, etc. Heh, yeah. I never understood the floating point multiplier setups in some emulators. I guess it's useful if you want your video output size to be π x _e_. I thought about the "Are you sure?" thing, it'd be nice if you accidentally close the emulator, so you don't lose your save. But I quickly realized that despite using emulators for ten years, I've never _once_ actually done that. The only point where it might be appropriate is if I add mouse / SS support, since you may want to have the cursor near the top right of the window with the menubar off in windowed mode (though you're just asking for trouble at that point, honestly.) To be fair though, you helped design at least half the bsnes GUI, so obviously you should like it :P > I should offer a bounty at this point to anyone who can find another > bug that isn't PPU based. Super Power League 4 seems to die after an inning or two with a S-SMP crash. I still need to try screwing with the CPU/SMP scalars and try substituting with anomie's DSP core to see if it still dies. If neither of those affect it, it could very well be due to a timing issue with not emulating the delays of the SPC7110 chip or something. If someone wants to rule out the DSP core, they could try playing a SPC dump from the game in one of the plugins that use blargg's core. I doubt it's that, personally. The usual rules about special chips apply, but you can list it as a bug if you like. I probably will with a note. Maybe I can figure it out before release. Probably not, but who knows. Sigh, it's always the god damn baseball and golf games, isn't it? I'd probably half-ass the game too, if it were my job to work on one. > Two minor things that have probably been forgotten in all this > excitement that could make the next release: libui is still not > changed to "hiro" in the license, both online and text based. And > mudlord wanted to be added to the contributors for his OpenGL stuff. Ah, thanks. Updated the license file. Decided against listing all the libraries there for now, as they're getting quite numerous. As for credits, mudlord is already listed in the source file, and the contributors list is for people who have submitted code to the core of the emulator. It's not a good system, I admit. That obviously excludes you and tetsuo55, despite the fact that your testing has been one of the most helpful things I've received. It's not that I mind listing people, but I don't want that window to become cluttered with 100+ names of everyone up to and including people pointing out spelling mistakes in WIPs. That would make the window really onerous to look at. I really don't want to come off as rude here, I'm really truly grateful to everyone who has helped out even a little, and I'm happy to thank them all in some perpetual fashion (eg website thank yous tend to disappear as the news falls off the page.) That's the second time someone's brought that list up. I was afraid that adding such a list would just end up causing problems. Maybe I should just remove the contributors list on the about screen, and put everyone in the readme.txt file, so that everyone who ever contributed anything is listed? [No archive available] |
|
|
byuu
|
bccc5b5a12 |
Update to bsnes v033r08? release.
I wish I could post the new WIP, I really need it tested. But it looks like vstech.net (cinnamonpirate.com's host) got sucked into a black hole, literally. You can't even nslookup it. So ... sorry. What I did today was: - remove an unnecessary ternary condition in HDMA CPUsync (no visible effect on emulation or speed.) - move controller ports from settings to system. - rewrite SPC7110 decompression engine from scratch. The last one obviously the most important. I took neviksti's most recent decompressor code, made the essential variables static, added a bool init parameter you can use to start a new decompression sequence, and built up a dual-indexed (read+write cursor) ring buffer to stream byte sequences. I set the buffer to >= 32 bytes at a time. I also simplified a few parts, like the swap sequence for pixel ordering; and I took out the end of each function that computes length, since that's no longer needed (nor is bot.) The result is you can stream an infinite number of bytes safely from decompression, and nothing will ever go out of bounds of the data ROM. Speed results on Core 2 Duo E6600 @ stock 2.4GHz: FEoEZ cart riding sequence - 91fps (was 40fps) MDH title screen - 111fps (was 29fps) SPL4 title screen with players running across screen - 118fps (was 35fps) For comparison, Star Ocean in-game gets ~95fps. I didn't think we would need that many optimizations to get SPC7110 support running at full speed (how complex could a low-cost IC from 1995 be?), good to see I was right. As soon as vstech comes back (hopefully tomorrow), I'll post the PD / BSDL source, and get it sent over to GIGO. Hopefully he can add it to SNESGT. Speaking of which ... neviksti: In your updated DecompMode0.c file, you declare NUM_CONTEXTS as 15, but it should be 30. I'm guessing it runs fine in isolation (memory initializes to zero and all that), but when mode 2 ran and set contexts up to 32; only clearing 15 was resulting in corrupted graphics all over. No big deal, just mentioning it. > I don't really understand your (or byuu's) point. If the game does > indeed works on 99.9% of units...on what do you base yourself to say > their programming suck or that the game is "broken"? I mean, it > works, it works right? This is the problem I have with the black-and-white "bug" label ... it implies a game is broken to a casual observer, or there is at least noticeable corruption on at least one screen. In truth, bsnes has a few visible bugs. Street Racer will flicker one frame on the title screen, but only one time, and only once every ~4-8 runs. Adventures of Dr Franken and Winter Olympics show one black scanline because the games update OBSEL at very unusual points mid- frame. And there are countless "anti-bugs", eg Battle Blaze on the fighter select screen is supposed to show some garble up at the top due to mid-scanline PPU writes. Because bsnes renders an entire scanline at once, you don't see this. Lots and lots of games will have 1-16 pixels on one scanline at the left (usually not even visible on TVs) that flicker due to writing PPU regs past the end of hblank. BoF2 German detects emulators by reading the division register early. Since no emulator supports that, you don't see the anti-piracy splash screen. All of those could be considered bugs to varying degrees. I suppose what would be nice is a bug severity ranking system. "Severe" if it's game ruining, "Moderate" if it's more than one scanline / frame that glitches graphics or something, and "Minor" for the stuff 95% of people probably won't even notice. Or something like that. My point is that it doesn't make a lot of sense to work on the minor stuff. Most of that will probably go away with a cycle-based PPU anyway, and the rest will probably continually appear and disappear with infinitesimal timing changes. [No archive available] |
|
|
byuu
|
acee547da9 |
Update to bsnes v033r07? release.
And another one. I've re-written the DMA state machine. I decided to keep it in one FSM instead of two separate ones, because they honestly share so much. But I rewrote it to be a lot cleaner, and to handle some really exceptional edge cases. Due to the design, I was even able to make the HDMA during DMA edge case "transparent", eg the same codepath is used for normal HDMA and for HDMA during DMA :D New WIP passes the last four tests in test_hdmatiming.smc. The ROM posted doesn't validate the last four yet, so you have to compare the SRAM file to the source logged values if you care to. That should be everything with DMA and HDMA timing now, thankfully. Really happy with that codepath for the very first time. Such an improvement from the "don't even worry about HDMA syncing" code I had a few versions ago. I also reduced the DRAM refresh rotation from 7-lines of code testing against the NTSC color burst case to 1-line, using the DMA counter (dram_refresh_pos = 530 + 8 - dma_counter()) Lastly, I added a flush command to the status bar. Any important messages will now flush all buffered ones to display the new one. Eg load 10 games back-to-back and it'll say the name of the new game immediately, instead of scrolling through the other 9. It will still buffer lesser important ones, like unsupported chip and UPS patch applied messages. I also removed config / locale path display, because it annoyed me. Nearing a release. I want to state machine neviksti's SPC7110 decompression code, and I should be ready on my end. FitzRoy, I'll give you the final word. If you want controller port selection moved to "System", I'll do so. Any show stoppers should be mentioned now. I can't fix the "crash with Unicode characters in the executable path" issue just yet, so that'll have to wait. [No archive available] |
|
|
byuu
|
b1b146fd7d |
Update to bsnes v033r06? release.
New WIP. Adds some more HDMA timing improvements, DMA bus hold simulation, and hopefully proper detection for ST011, which should mean that every unsupported game will now notify you of that fact. Also, I finally got around to writing that status bar message queue system I mentioned a long time ago. Should make Deathlike happy. It'll tell you whenever any UI event occurs (load, unload, reset, power cycle, UPS patch applied, unsupported chip detected, config file / locale file load, etc.) Obviously if you turn off the status bar, you won't see them. Not a problem for me personally: if you want to see status messages, leave it on. With that, I removed the annoyingly bland message window, and muted the terminal message printing, putting it all inside the statusbar instead. I also got rid of some now-unused config variables, misc.status_text (it was kind of overkill to let that be customizable) and cpu.hdma_enable (it's always enabled now.) Opinions on the new status bar system welcome. I've also set the SNES to report itself as 2/1/3, rather than 1/1/1. Since I don't emulate things like the HDMA conflict crash, I figured I may as well set it to the CPU revision that doesn't have it. > Probably the best it's ever been, but Street Racer's track does > still flicker on "Head to Head" mode. With the above changes, I was able to eliminate the flicker in-game in all modes, as well as get rid of it ~80+% of the time on the title screen. Only once every ~5 restarts will you see it for _maybe_ one frame. That's really the best I can do, I'm afraid. It's so subtle I doubt anyone will even notice it now. Like Winter Olympics and Adventures of Dr Franken, I'm not going to consider it an active bug (yes, how convenient), but I'll watch the game closely with future timing changes. Hopefully it'll go away entirely with more refinements in the future. [No archive available] |
|
|
byuu
|
53e913e225 |
Update to bsnes v033r05? release.
New WIP.
After some more hardware testing, it seems my theory from before was
correct. See the HDMA thread for more info if you care.
With those changes plus a few others, I'm now able to get everything
in my "known troublesome" games list to work properly and with no
flickering:
- Breath of Fire 2 (G)
- Earthworm Jim 2 (U+E)
- Energy Breaker
- Jumbo Osaki no Hole in One
- Mecarobot Golf
- Secret of Mana
- Street Racer
- Super Mario Kart
I still can't get Street Racer to flicker, maybe you guys can?
Hopefully not, such a hard-to-trigger bug will be even harder to
debug.
Image
(ignore the framerate, from a pause/resume screen capture.)
And fucking _hell_ that game is hard.
Note that to get BoF2 (G) to work, I had to modify S-SMP cycle timing
from 32040hz*768 to 32041hz*768. It seems the game is very sensitive
to S-CPU <> S-SMP timing, and the improved HDMA timing was just
unlucky enough to just _barely_ miss the handshake. This was further
compounded by there being no input before the point in question to
vary timing.
It's not really a problem with the game itself -- d4s really pushed
the limits of these two chips to pull off that impressive intro. It
was more that I was hitting an extremely tiny window of time that
caused a deadlock.
This timing change only affects S-CPU <> S-SMP communications (eg
handshakes and such), and not timing inside each individual processor.
Recall that both processors in both regions (NTSC and PAL) have
slightly different timings, and the exact timings vary even on real
hardware, as the crystal clocks used are not perfect.
The NTSC S-SMP has been observed at ~32040hz on an oscilloscope by the
guy at alpha-ii.com, which is faster than the stock speed of ~32000hz.
But we still use stock speeds for the S-CPU because that's all we
have. Changing the S-CPU speed a bit would've fixed this as well.
So yeah, the fix is a bit of a kludge, but it's the best I can do when
the problem is in communication between the two chips.
Keep in mind that the S-SMP clock rates are cached in the config file.
You'll either need to delete it, or reset the values to the default in
the advanced panel. Otherwise the game will hang on first run.
Also, I tightened DMA transfer restrictions even more. A-bus accesses
to $4200-421f and $4016-4017 are now blocked. And I also block these
during HDMA line counter / indirect address fetches (as observed on
hardware.) Further, I was previously allowing invalid B->A transfers
to still write the the MMIO reg specified in A, but ignoring the B-bus
read. This seemed wrong: not being able to access the reg should mean
not being able to access it period, so I swapped that around.
Shouldn't affect any known games, but mentioning it just in case.
> Perfect timing matching isn't needed, the games are broken if they
> can't take a normal sized delay for this.
Mortal Kombat II breaks if you're exactly 6 cycles off from expected
timing (but works if you're more than six cycles off.) Jumbo Osaki was
failing by 20 cycles. Wild Guns fails if off by two cycles. A couple
other games were the same. There are roughly _21 million cycles_ in a
second.
Death Brade and some European racing game break if _uninitialized RAM_
doesn't return the values they like.
Uniracers is quite simply _beyond_ broken.
I wish I could get away with just saying the games themselves were
broken (and they are), but when it runs at least 99% of the time on
hardware, you can't use that as an excuse. Everyone will still call it
an emulation bug :(
> Err, not really. Fixed delay for all operations is as dumb as no
> delay for all operations.
I typically like the idea of emulating as much as we can ("building
blocks" and such), if that means guessing approximate delays, so much
the better. But for the DSP-1, adding any delays is even worse in my
opinion. Why?
First, the delay lengths will no doubt vary depending upon how complex
the transfer is. Second, emulating the delays would force us to
implement the DSP-1 as the dedicated processor that it is: thusly, its
overhead would soar from barely noticeable to nearly as intense as
SuperFX / SA-1 emulation. Third, it may be possible to read partially
computed results before the operations finish. We can't even figure
out the partial computations of mere _unsigned multiplication and
division_ in the S-CPU core, so how the hell would we ever plan to
figure out attitude / altitude calculations?
The only feasible way we're going to get this right is to dump the
program ROM and then emulate the instruction set. Even decapping the
DSP-1 has been no help for that, and even if by some miracle we got
the ROM, we'd have to figure out the instruction set and timing with
no documentation. And all of this to improve emulation of a couple of
lackluster action games. Good luck finding someone willing to do all
that for free, and just to end up getting ~90% of people bitching that
suddenly DSP-1 emulation is as demanding as SFX emulation, yet
provides no visible improvement over existing emulation. And it even
requires another DSP1program.rom file that they didn't need before!
Thus, it's really not worth the effort if our entire model of
emulating the chip is busted in such a manner that we couldn't improve
it more even if we wanted to anyway.
[No archive available]
|