...unless you're using a non-RPM distro (i.e. Slackware) and don't like compiling from source.
Just extract the .RPM,download some dependencies and run bsnes

If you want to search for rpms themselves, you should look at http://download1.rpmfusion.org/nonfree/fedora.

If it's non-free, then I demand you start paying me $3 per download :P
Consider it an abuse of the English language toll charge :D </troll>

If it were up to me, we'd have freeasinbeer and freeasinspeech trees

i'd rather just have a beer tree
[/off-topic]

Re: UPS patches saying they worked when they did not. That was easy enough.



Wasn't checking the return value of apply_patch.

New WIP.

Updated centering code, it now just has per-platform centering code. So it should look great with no flickering / movement on Windows or Linux.

Fixed the patching status thing so it won't say it patched when it fails. But seems there's not enough safeties in nall::ups. A patch of nothing but "UPS1" has a 50% chance of crashing the emulator.

Most importantly, I finally got around to writing my pre-processor, which is intended to add macro support to both C++ and xkas. Calling it bpp, for byuu's pre-processor.

I started rewriting the S-CPU opcodes to use the new pre-processor. 40 of 256 opcodes finished. I'm also separating the 8-bit and 16-bit versions this time. Twice the code, but it's easier on the eyes.

Old:


New:




Yes, I know the above can be done with the C pre-processor. Two major reasons I avoided it:
1) I refuse to put \ after every line.
2) parameters are limited, eg MACRO(&=~, x += 2) would not work.

The important thing was making a more generic / flexible format. Will allow me to kill off src/tool, though I'll still include the new parser's source under src/lib/bpp.

May extend bpp in the future, who knows. @if/@else/@endif would be nice, as would nested macros and static programming functions.

Great! Maybe you can make it even more readable by removing those empty ()s somehow.

() distinguishes functions from variables.

Had trouble getting a pointer into a member function pointer table last night, so I was using:



Now:



Seems to be a bit faster, 124fps -> 127.5fps. Still below 129fps for v042 official. Won't be able to tell if the new method is faster (should be) until I convert all opcodes. Right now it has to see if the table entry is empty, and if so go back to the older switch table.

Mednafen pointed out what I forgot, we can shadow cases in a switch table to avoid code duplication, eg:



But honestly ... even if it's a lot more work to use functions instead of a giant switch table (need function headers and table initialization), and it adds to compile time + code size very very slightly, I think I prefer it that way. Looks nicer in the macros (wouldn't be able to group _b + _w types in the same macro with cases; switch table would be a lot uglier than my table setup code), and it avoids the need for an opcode offset index.

Could also work largely in my favor for more natural hypothetical SA-1 support by forming a base 5a22 class that they both inherit from. That would work with switch() too, but would take away a tiny bit of flexibility in the opcode dispatch model (eg have to call the base class' function that has switch table instead of implementing it directly in the derived class.)

Not quite.
A function is a variable.

() at the end means to call the function and return the result, while without it means to assign it the memory address of the variable.

var = blah; //Var equals the address of blah, running var() would be the same as running blah()
var = blah(); //Var equals result of running blah, blah is actually ran here

Obviously, 'var' is a function pointer in the first, while it's the type of the returned value in the second.

Indeed, And for fun, the type of the returned value can also be a function pointer.

I gave a quick answer, wasn't going for a technical exact explanation :P

Anyway, up to 194 of 256 opcodes converted to the new pre-processor. Very, very tiring work.

Erm... I think creaothceann was being sarcastic.

I mean, he made VSNES. I have trouble believing he has no idea what a function is.

Just can't help commenting on C-style languages from time to time. And probably getting on people's nerves by doing that...

Yeah, () indicates functions/calls... just seems like a nutty way to go about it.

Couple weird bugs in v0.42. Not really huge bugs, but thought you might like to know:

1. Close and re-open bsnes. Go to input configuration. Click on an assignment that has something assigned to it (as in, not "none"). Click Unassign. The line item increases slightly in height. Closing and re-opening bsnes resets it to the default line height.

2. bsnes no longer works with GlovePIE (which I use so I can play bsnes with a Wii Classic Controller). I assign the Classic Controller's buttons to keyboard buttons, then I try to assign that to bsnes buttons. It used to work, at least in v0.40. I also tested it in a text editor and it works fine there. EDIT: found the fix. Switch input driver back to DirectInput.

Finally, is there a way so that I can close the various bsnes dialog boxes using ESC? This is the typical behavior of almost every other Windows program I have ever used (ESC closes a dialog box).

EDIT: My Xbox 360 controller appears to work as expected. Didn't specifically test the shoulder triggers.

1. is a bug with Qt. Not much I can do about it.

2. GlovePIE apparently hooks DirectInput, but not RawInput. Something the author of the program needs to address.

3. none of my windows are true dialog windows, they're just popup windows. Alt+F4 / Ctrl+F4 should also work.

Except for the load window, which indeed works with Esc.

I don't know if this is the right place but... i'm using bsnes on a HP notebook and i just can't play without opening the menus everytime i assign any joypad button to certain keys, like, spacebar, H or S. Is there some way to stop these keys from opening the menu?

nobuo, I don't follow. Spacebar, h and s don't trigger the menubar. Alt does, however. Alt+any of those keys will cause the menu to appear. And unfortunately, I don't have a way around that right now. Qt will trigger the context menu even when it is hidden. So you'll have to avoid pressing alt while playing.

Actually, the bug nobuo describes is more severe than that (I've noticed it too) ---

Once Alt has been pressed to access the menubar (even just one time), the menu accelerator keys become functional even without pressing them together with Alt.

So, for example:
1. Alt+S, Enter (Load game...)
2. S, X (emulated buttons 'X', 'A' by default)
3. Oops, bsnes quits

Holy crap this actually happens.

Stop pressing alt.

New WIP. The entire S-CPU opcode core has been re-written to use my new pre-processor.

The downside is that it's actually slightly slower, by less than 1%. Guessing that having almost twice the opcode implementations ends up eating more valuable L1 cache, making it more painful than the two conditionals per function I had before. But damn if it isn't more readable now.

Before:


After:

( note: {lc} is short-hand to 'hide' last_cycle(); )

Really worn out now, so don't expect a new WIP for quite a long time I'm afraid. I'll worry about the S-SMP's core much later. Would appreciate thorough testing. Given I rewrote all 256 opcodes by hand, it's possible I made a mistake somewhere.



Wow ... that is quite alarming. Not sure why Qt is doing that. But since I don't have a way of fixing it yet ... for now:



:/

Ironically, nachch's problem wouldn't even be possible if the useless "exit" hadn't been covertly reinserted. The CIA calls this blowback.