bsnes v0.036 released

Archived bsnes development news, feature requests and bug reports. Forum is now located at http://board.byuu.org/
Locked
DancemasterGlenn
Veteran
Posts: 637
Joined: Sat Apr 21, 2007 8:05 pm

Post by DancemasterGlenn »

Apparently we're "done arguing about it", but for the record,
FitzRoy wrote:basically, no one has ever complained about this in hundreds of other popular emulators and computer games, and bsnes with a userbase 1% the size suddenly has people finding it indispensable?
I don't know about other people, but I do ask for this feature in other emulators.

I dunno. The way I think about it is that if my controls are mapped to the keyboard, I don't want the emulator to regard keyboard as input (for obvious reasons). However, since when I'm not using my emulator I'm not using my gamepad, I see no reason to turn off this feature (if that makes sense). If bsnes was set up to always allow PAD controls to work (no idea how that would be detected), and simply stopped detecting keyboard input when not in focus, I know that I personally would no longer need both options (both being 1 and 2). Does anyone else feel this way? And if so, is it even something that can be implemented, given that different pads give different values?
I bring the trouble.
byuu

Post by byuu »

If bsnes was set up to always allow PAD controls to work (no idea how that would be detected), and simply stopped detecting keyboard input when not in focus, I know that I personally would no longer need both options (both being 1 and 2)
Though I don't at the moment, I can detect the difference between the keyboard and joypad.

It doesn't seem too useful, though. Since you always have to remap the joypad and keyboard to switch anyway, not much of an inconvenience to hit the radio box above while you're at it. And it'd be a hard option to describe tersely.

Back when I used to have the dual inputs per button thing in the past, it would've been a much more compelling feature. But that had to go due to the extreme complexity of supporting it (more than doubles the input parsing code size, which is already quite difficult to maintain.)
creaothceann
Seen it all
Posts: 2302
Joined: Mon Jan 03, 2005 5:04 pm
Location: Germany
Contact:

Post by creaothceann »

byuu wrote:Copy-paste from NESdev. Neat little blog, this was one of the programmers who worked on Uniracers. He mentioned that he had to get Nintendo R&D to approve their use of mid-frame OAM writes.

Someone should let him know that thanks to his efforts, true hack-free emulation of all commercial games will require a much more complex PPU renderer :P
Not complaining, quite the opposite. It gives justification to supporting things properly, just like d4s' BoF2 G + partial mul/div results.
Nice, he also worked on Lemmings...
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
DancemasterGlenn
Veteran
Posts: 637
Joined: Sat Apr 21, 2007 8:05 pm

Post by DancemasterGlenn »

byuu wrote:
If bsnes was set up to always allow PAD controls to work (no idea how that would be detected), and simply stopped detecting keyboard input when not in focus, I know that I personally would no longer need both options (both being 1 and 2)
Though I don't at the moment, I can detect the difference between the keyboard and joypad.

It doesn't seem too useful, though. Since you always have to remap the joypad and keyboard to switch anyway, not much of an inconvenience to hit the radio box above while you're at it. And it'd be a hard option to describe tersely.

Back when I used to have the dual inputs per button thing in the past, it would've been a much more compelling feature. But that had to go due to the extreme complexity of supporting it (more than doubles the input parsing code size, which is already quite difficult to maintain.)
*nod* Makes sense. I always configure my pad and then never touch my keyboard for controls again, is my reasoning. There probably are still a lot of people who switch back and forth, so I guess that could just be more confusing. Doesn't matter too much, I'm very happy with the current options.
I bring the trouble.
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

My mantra from now on is going to be "dig, dig, dig" on options that 1% of people use. Grab a shovel and dig, dig, dig, straight to the abyss of the advanced section. No way, no how can these things be sitting pretty atop 100% options.

Moving on, I feel "Satellaview BS-X" should be renamed to "Satellaview" as this is how the actual unit is labeled. Trust me, I have one. BS-X is what the cartridge is called.

Next, let's talk about changing some of the other sections and making things look a little more uniform:

Drivers section
-----------------
1. Instead of listing the active settings in parenthesis below, put them after the selection box names as is done with the audio section.
2. Remove the note and create two 50% width buttons directly below the selection boxes called "Apply & Restart" and "Restore Defaults"

Audio section
---------------
1. Dump the advanced mode and sliders.
2. Create two rows of input boxes, two boxes at 50% width each. First row: Volume, Latency. Second row: Input Frequency, Output Frequency.
3. Create two 50% width buttons directly below the input boxes called "Apply" and "Restore Defaults"
4. Limit each input box to a valid range, so that if a user tries to input "0" for latency, it goes to 1 instead. (0 or negative values will crash the emulator and require a deletion of the cfg file.) Or if a user tries to put 1000 for volume, it goes to 100 instead. No popups necessary to keep people from hurting themselves.
5. Put that note in and bold it eventually.

Video section
---------------
1. Dump the sliders and do a row of input boxes here as well.
2. Decolumnize the checkboxes and delete invert colors
3. Two buttons again, "Apply" and "Restore Defaults"


Lastly, the current size of the config is simply too large and is creating vast amounts of empty space and really long buttons. Here is around where I think it can be reduced: 550x340.

Image
Last edited by FitzRoy on Tue Sep 30, 2008 2:05 am, edited 1 time in total.
DancemasterGlenn
Veteran
Posts: 637
Joined: Sat Apr 21, 2007 8:05 pm

Post by DancemasterGlenn »

FitzRoy wrote:My mantra from now on is going to be "dig, dig, dig" on options that 1% of people use. Grab a shovel and dig, dig, dig, straight to the abyss of the advanced section. No way, no how can these things be sitting pretty atop 100% options.
Congrats, you're not the person making the final decisions though. So keep on dig, dig, digging at people.
I bring the trouble.
byuu

Post by byuu »

Moving on, I feel "Satellaview BS-X" should be renamed to "Satellaview" as this is how the actual unit is labeled.
Alright.
1. Instead of listing the active settings in parenthesis below, put them after the selection box names as is done with the audio section.
Would look kind of weird.
2. Remove the note and create two 50% width buttons directly below the selection boxes called "Apply & Restart" and "Restore Defaults"
It would be difficult for me to close and then re-open the emulator through code. Not entirely sure how to do that everywhere, and I'd have to be careful with them both not touching the same files at the same time. Would also be kind of dangerous in my book. I don't think everyone would pay attention to "Restart", and then they'd end up losing their progress in a game.
1. Dump the advanced mode and sliders.
Volume really works well as a slider. Frequency works best as a drop-down box. Latency can go either way. And Frequency Adjust really should be a text box for maximum flexibility. A smörgåsbord of control types.
4. Limit each input box to a valid range, so that if a user tries to input "0" for latency, it goes to 1 instead. (0 or negative values will crash the emulator and require a deletion of the cfg file.)
Yeah, that's a good idea.
1. Dump the sliders and do a row of input boxes here as well.
That's much less user friendly. A lot harder to see the adjustments quickly and find the value that works best for you.
2. Decolumnize the checkboxes and delete invert colors
I like invert colors. It's trippy :P
Besides, entries are too short for one line each, even with a smaller window.
3. Two buttons again, "Apply" and "Restore Defaults"
I'll fight to the death for my gamma enhancements, but there also needs to be a quick default method for those who complain about their colors not being totally washed out.
Lastly, the current size of the config is simply too large and is creating vast amounts of empty space and really long buttons. Here is around where I think it can be reduced: 550x340.
It needs to look good on Linux, but I can look into resizing it down some, sure. Some of those buttons really are ridiculously big at the moment.
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

byuu wrote: Would look kind of weird.
So... why do you put them there in one section and not the other?
It would be difficult for me to close and then re-open the emulator through code. Not entirely sure how to do that everywhere, and I'd have to be careful with them both not touching the same files at the same time. Would also be kind of dangerous in my book. I don't think everyone would pay attention to "Restart", and then they'd end up losing their progress in a game.
It would have been nice to have apply behavior the same in every section. And I pity the fool that tries to change their API in the middle of a game.
Volume really works well as a slider. Frequency works best as a drop-down box. Latency can go either way. And Frequency Adjust really should be a text box for maximum flexibility. A smörgåsbord of control types.
Whatever you do, don't mix and match sliders with boxes, it's ugly. I don't really like sliders anymore, they're not really applicable for options with few or 200+ choices and they take up assloads of space.

Here's a thought, in standard mode, use dropdowns with sane intervals like:

25/50/75/100 for volume
25/50/75/100 for latency
31800/31850/31900/31950/32000 for input frequency
32000/44100/48000/96000/192000 for output frequency

Then have advanced mode change them all to input boxes when enabled.
That's much less user friendly. A lot harder to see the adjustments quickly and find the value that works best for you.
The slight quickness sliders would offer here means nothing. I've actually toyed with the Brightness and Contrast sliders before, and nothing away from default did anything but bad. They're next to useless, but a section with gamma only would admittedly look kind of stupid. Even gamma is pretty much a 75 or 100 game.
Besides, entries are too short for one line each, even with a smaller window.
Floating columns look strange is all.
I'll fight to the death for my gamma enhancements, but there also needs to be a quick default method for those who complain about their colors not being totally washed out.
I'm not arguing to change the default, well maybe to 75.
mudlord
has wat u liek
Posts: 559
Joined: Tue Sep 11, 2007 2:54 pm
Location: Banland.

Post by mudlord »

I like invert colors. It's trippy :P
I find it with shaders its even more trippy....even when you make the background render surface undulate in time....*hint hint*

Seriously, I would love to see the NTSC filter in shader form. It certainly can be done.
byuu

Post by byuu »

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.
creaothceann
Seen it all
Posts: 2302
Joined: Mon Jan 03, 2005 5:04 pm
Location: Germany
Contact:

Post by creaothceann »

byuu wrote:no idea how to bind the mouse to the bsnes window region
ClipCursor does that on Windows...
Last edited by creaothceann on Sat Oct 04, 2008 9:37 am, edited 1 time in total.
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
byuu

Post by byuu »

Thanks, ClipCursor is almost what I need ...

I definitely need the capturing ability of it, as even SetCapture() allows clicks to leak through to applications behind it. But the problem with it is that once the mouse hits the corners, it stops sending mouse move events.

Essentially, for SNES mouse support, I need to capture raw "moved N pixels in X, Y direction", and not "mouse is currently at X, Y pixel."

I tried a cheap mockup by detecting movement, and immediately forcing the cursor back to the center of the window. But A) I don't think this will feel very good, especially for fast movements and/or small window sizes; and B) I really don't think it'll be very portable.

Anyone have ideas on how I can get Windows to give me relative movements in each direction since the last mouse poll?

Code: Select all

#include <windows.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

HWND hwnd;

LRESULT CALLBACK wndproc(HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam) {
  if(msg == WM_DESTROY || msg == WM_RBUTTONUP) {
    ClipCursor(0);
    ShowCursor(TRUE);
    PostQuitMessage(0);
  }

  if(msg == WM_LBUTTONUP) {
  //SetCapture(hwnd);
    RECT rc;
    GetClientRect(hwnd, &rc);

    int cx = (rc.right - rc.left) / 2;
    int cy = (rc.bottom - rc.top) / 2;

    POINT p = { 0, 0 };
    ClientToScreen(hwnd, &p);

    cx += p.x;
    cy += p.y;
    SetCursorPos(cx, cy);

    OffsetRect(&rc, p.x, p.y);
    ClipCursor(&rc);

    ShowCursor(FALSE);
  }

  if(msg == WM_MOUSEMOVE) {
    POINT p = { 0, 0 }, hp = { 0, 0 };
    GetCursorPos(&p);
    ClientToScreen(hwnd, &hp);
    p.x -= hp.x;
    p.y -= hp.y;

    RECT rc;
    GetClientRect(hwnd, &rc);

    int cx = (rc.right - rc.left) / 2;
    int cy = (rc.bottom - rc.top) / 2;

    int rx = p.x - cx;
    int ry = p.y - cy;
    if(rx || ry) printf("x = %4d, y = %4d\n", rx, ry);

    cx += hp.x;
    cy += hp.y;
    SetCursorPos(cx, cy);
  }

  return DefWindowProc(hwnd, msg, wparam, lparam);
}

int main() {
  WNDCLASS wc;
  wc.cbClsExtra = 0;
  wc.cbWndExtra = 0;
  wc.hbrBackground = (HBRUSH)(COLOR_WINDOW);
  wc.hCursor = LoadCursor(0, IDC_ARROW);
  wc.hIcon = LoadIcon(0, IDI_APPLICATION);
  wc.hInstance = GetModuleHandle(0);
  wc.lpfnWndProc = wndproc;
  wc.lpszClassName = "mousetest";
  wc.lpszMenuName = 0;
  wc.style = CS_HREDRAW | CS_VREDRAW;
  RegisterClass(&wc);

  hwnd = CreateWindow("mousetest", "mouse test", WS_OVERLAPPEDWINDOW | WS_VISIBLE,
    64, 64, 320, 240,
    0, 0, GetModuleHandle(0), 0);

  MSG msg;
  while(GetMessage(&msg, 0, 0, 0)) {
    TranslateMessage(&msg);
    DispatchMessage(&msg);
  }

  return 0;
}
For those who can't read the above:
How I want this to work is that by default with no mice selected on either control port, the mouse acts completely normal. But whenever you enable a mouse, it changes just a bit. By default, the mouse does nothing until you click inside the video output region (not the black borders in fullscreen). At that point, it locks the mouse and hides the cursor. You just move the mouse around and it moves the emulated mouse on the screen.

Left and right click work as expected. To release the mouse, you need to press escape.

I don't intend to support ManyMouse, at least not at this time, so I'm basically only going to allow the mouse to be on one controller port at a time. I'll disable the other option whenever one is selected, and if you try and edit the config file to assign both, I'll revert the second to "No controller" on startup. The SNES test program needs a mouse in port 2, Mario Paint needs it in port 1, so it has to be an option in both menus. For the SS / Justifier, I'll leave those as port 2 only for the time being.

Also, for Super Scope and Justifier ...

The basic idea is that they latch the counters when the laser inside them hits the beam cannon of the TV. In other words, the latch counters end up pointing to the X/Y coords of where the laser is pointing.

The problem for emulation is that it's really hackish to "fake" latch these counters, eg setting them to X=128, Y=128; when you're really at X=20, Y=10. My idea was to poll the cursor position once per frame, and then at the edge of each opcode cycle, if SS/Justifier is enabled, see if we've gone past the scope coords, and if so, latch the counters then. Maybe force the counters back, but that could probably be detected by game code.

The most precise way would be to latch the counters at the exact right moment, but that would be way too slow. I could also do it once per cycle, for a max variance of two pixels between where the laser is pointing and when the counters latch. Given that these aren't exactly sniper-class rifle scopes here, I don't think it really needs to be 100% perfect, and the games' built-in calibration features would easily compensate anyway. That should probably be good enough ...

I really wish we had better info here ... I don't even know if it's possible for the scope to trip the latch counters twice per frame or not (eg by moving the scope downward faster than the CRT beam cannon -- not an easy feat, but probably possible.)
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

Would you learn anything from having the hardware to play with? The mice are pretty common on ebay, I think.
byuu

Post by byuu »

It certainly wouldn't hurt to have all of these controllers (mouse, SS, Justifier), but I should be able to match existing emulation of things. I probably would need the mouse to get the exact delta curve, but the delta response of real mice already would prevent emulating that perfectly anyway.

The controllers I really need are things like the Voiser-kun, Pachinko controller, etc. I doubt I can do anything neviksti couldn't with the Tribal Tap. The ones you may as well not even bother with, but I wouldn't mind playing around with, are the Lasabirdie, etc.

Just don't send me the Exertainment bike. I don't have room for it :P
henke37
Lurker
Posts: 152
Joined: Tue Apr 10, 2007 4:30 pm
Location: Sweden
Contact:

Post by henke37 »

You heard him, start buying him toys, I mean, provide him with the hardware needed to implement proper emulation. Better ask him if he got a battery charger or not, I heard that the Super Scope drains batteries pretty quick.
byuu

Post by byuu »

Oh wow, DirectInput's mouse support is a dream.

Code: Select all

LPDIRECTINPUT8 di;
LPDIRECTINPUTDEVICE8 dimouse;

  DirectInput8Create(GetModuleHandle(0), 0x0800, IID_IDirectInput8, (void**)&di, 0);
  di->CreateDevice(GUID_SysMouse, &dimouse, NULL);
  dimouse->SetDataFormat(&c_dfDIMouse2);
  dimouse->SetCooperativeLevel(hwnd, DISCL_EXCLUSIVE | DISCL_FOREGROUND);

      DIMOUSESTATE2 state;
      memset(&state, 0, sizeof(DIMOUSESTATE2));
      if(dimouse->GetDeviceState(sizeof(DIMOUSESTATE2), (void*)&state) != DI_OK) {
        printf("Acquire()\n");
        dimouse->Acquire();
      } else {
        printf("x = %d, y = %d, middleclick = %d\n", state.lX, state.lY, state.rgbButtons[2] & 0x80);
      }
... and that's it! The mouse hides itself, and you get pure relative coordinates for mouse movement, no capping on the corners, no binding the mouse to the window, no bullshit. Supports up to eight mouse buttons, too.

I can also omit DISCL_EXCLUSIVE and still poll the information.

It really is a treat being able to use DirectX.

And who wants to bet that doing the same on Linux will be 100x more painful? Anybody?
Dullaron
Lurker
Posts: 199
Joined: Mon Mar 10, 2008 11:36 pm

Post by Dullaron »

Linux will be harder? Ubuntu people always trying to change things. :roll:
Window Vista Home Premium 32-bit / Intel Core 2 Quad Q6600 2.40Ghz / 3.00 GB RAM / Nvidia GeForce 8500 GT
Gil_Hamilton
Buzzkill Gil
Posts: 4294
Joined: Wed Jan 12, 2005 7:14 pm

Post by Gil_Hamilton »

Dullaron wrote:Linux will be harder? Ubuntu people always trying to change things. :roll:
It's not just the Ubuntu people.
AamirM
Regen Developer
Regen Developer
Posts: 533
Joined: Sun Feb 17, 2008 8:01 am
Contact:

Post by AamirM »

Hi,
.. and that's it! The mouse hides itself, and you get pure relative coordinates for mouse movement, no capping on the corners, no binding the mouse to the window, no bullshit. Supports up to eight mouse buttons, too.
When I added Sega Menacer support to Regen I was having problems releasing the mouse for other windows. The mouse would be released but cursor wouldn't show up again. IIRC, the docs said you had to call dimouse->Unacquire (which I was using) but that wouldn't work. In the end, I just destroyed the dimouse object when releasing and created it when capturing which would work and was just really three more lines of code.

When I told this problem to bunch of MS guys, they told me to use Win32 APIs instead and that DX wasn't really for keyboard or mouse. Strange.

stay safe,

AamirM
adventure_of_link
Locksmith of Hyrule
Posts: 3634
Joined: Sun Aug 08, 2004 7:49 am
Location: 255.255.255.255
Contact:

Post by adventure_of_link »

henke37 wrote:Better ask him if he got a battery charger or not, I heard that the Super Scope drains batteries pretty quick.
wiring the super scope to where it uses an AC adaptor is fine too
<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
NSRT here.
byuu

Post by byuu »

Okay, can anyone post pictures of or explain the button layouts of the Super Scope and Justifier?

From what I can tell, there's "Fire", "Cursor", "Pause" and "Turbo" buttons. Fire is obvious enough, as is pause and turbo, but what the hell does the cursor button do? Too many buttons to map to ordinary mice, fuck. Will have to allow keyboard mapping for some of those.

Justifier seems to have "Trigger" and "Start". Guessing start is just a glorified pause button?

And emulating this thing ... man, it will not be easy. Getting it right I'd dare say would not be feasible. It apparently doesn't detect red pixels, blue pixels less than 75% bright or green pixels less than 50% bright. Emulating that would be ... quite the challenge. Not so much that it's hard to fetch the pixel (it would be annoying factoring in things like hires and interlace modes), but that I try very hard to keep things separate: the controller input code has no easy way to fetch PPU output data.

Further, it seems the SS only latches when the fire button is held down. Since I use polling rather than events, we'd have to BS that as well by detecting the fire state at the start of each frame, rather than in real time.

And I think it'd be best not to emulate offscreen mode. Would be too easy to go way off the screen and not be able to find the screen again. That's going to screw with my "relative only" cursor tracking design. SNES::Input will have to keep state information.

And then there's the issue of drawing the cursor on-screen. Again, with the separation of input from video, it won't be fun.

I doubt anyone will notice this stuff, at least.
In the end, I just destroyed the dimouse object when releasing and created it when capturing which would work and was just really three more lines of code.
Thanks for the info, I'll be sure to do this. How did you handle exclusive mouse access under Xorg for your Linux port, by the way?
AamirM
Regen Developer
Regen Developer
Posts: 533
Joined: Sun Feb 17, 2008 8:01 am
Contact:

Post by AamirM »

Hi,

My released Linux port does not have mouse support yet but my latest build has it and I am using SDL for it which pretty easy. On capture I call SDL_WM_GrabInput which hides the mouse and confines the mouse to your window and then use SDL_GetRelativeMouseState for input updating. Thats just it. I haven't looked at other ways to do this since it works pretty well for what I want.

stay safe,

AamirM
powerspike
Regular
Posts: 236
Joined: Mon Nov 21, 2005 3:43 am

Post by powerspike »

Cursor at least in battle clash would select an item in your inventory then you'd press fire to use it. It's on the back of the front grip of the super scope, if that makes any sense.

Final edit: Wikipedia works too http://en.wikipedia.org/wiki/Super_Scope . If that doesn't help I made a lame picture.

Image
Last edited by powerspike on Fri Oct 03, 2008 8:16 pm, edited 3 times in total.
grinvader
ZSNES Shake Shake Prinny
Posts: 5632
Joined: Wed Jul 28, 2004 4:15 pm
Location: PAL50, dood !

Post by grinvader »

You probably got that covered, but just in case...
byuu wrote:Essentially, for SNES mouse support, I need to capture raw "moved N pixels in X, Y direction", and not "mouse is currently at X, Y pixel."
You know that's essentially the same thing given a couple more variables ?

The ugly way:

Code: Select all

vartype p_var, c_var, var;

c_var = get_current_var();
var = c_var - p_var;
p_var = c_var;
The less ugly way is using structs to do the same thing for any amount of vars.
You will probably find a nifty c++ thingie to do that in another less ugly way too.
皆黙って俺について来い!!

Code: Select all

<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
wertigon
Rookie
Posts: 46
Joined: Sat Aug 07, 2004 7:20 pm

Post by wertigon »

I'm pretty sure the Q3 sources have the answer, but I'm on a 56k connection right now. Give me an hour to download the Q3 packages and dig through the input wrapper, then I should have something for xorg natively. :3
Locked