Menu
What's new
By:
Filters

NRage Input Plugin V2.00 BETA (an overhaul)

p_025

p_025

Voted Least Likely to Succeed
The bug tracker says "No matches found." I dunno exactly wtf that means, but my guess is something is broken somewhere.

EDIT:
p_025 said:
2. I like to update my configuration as I go in the game, figuring out what works best. However, sometimes when I open the configuration dialog during the game and try to bind things to a mouse event (Axis, click, scroll wheel) it doesn't work at all. It's as though it doesn't detect the mouse's actions.
Click to expand...
Post 551.
 
Last edited:
squall_leonhart

squall_leonhart

The Great Gunblade Wielder
Thats normal, since there are no bugs in the tracker yet, it can't display any.

take a look at the links just above that though, you'll find what you need.

isn't working for Snowboard kids, it seems. Mempak is detected everytime, but the rumble pak isn't.
seems a longer delay between switches is needed
 
Last edited:
OP
R

rabiddeity

Plugin Hacker
One more thing: when you post bugs there, please include the OS you're running. There are many problems with DirectInput that seem to show up only under Win9x/ME for example. Unicode is another area where earlier versions of Windows are lacking. I might not be able to reproduce the bug (I no longer have a machine that is even capable of running Win98, nor do I have the desire to install it) but at least we can identify it.
 
mudlord

mudlord

Banned
I started work on the archive support. I seen what you did, it certainly made things easier when figuring out the best way to do it. Currently, I am loading from the archive first. If that fails, then it falls back to the normal GB/GBC loading routines.
 
N-Rage

N-Rage

New member
Im a bit disappointed - it`s been ages and you still dint release a new Version? :evil:
(I probably was way less pedantic with making sure everything worked back then.)

Im surprised theres still interest in that Plugin though, so I thought I try figuring out my old Password and congratulate you to keep up with my horrible undocumented mess of code.

And hoping to be of some use...
rabiddeity said:
Ha! It works! There's now a 1 second delay whenever switching paks, to give the emulated game time to figure out the pak has been switched.
Click to expand...
Im incapable of getting your sources, sourceforge SVN seems to be down ATM. Did you try out the last Version I released (1.83).
I remember fixing such problems by simply leaving the new pak unitialised (and thus not responding to read/writes). Paks are supposed to be initialised with RD_GETSTATUS Commands. Games will realise a Pak got changed if Read/Write fails and then call RD_GETSTATUS. Thats better than hoping they`ll figure everything out in an arbitrary timespan.
 
p_025

p_025

Voted Least Likely to Succeed
What about his back wow?
Anyway, the N-Rage plugin has always been the best, simply for mouse support. What rabiddeity has done is mostly fixing stability issues and things with gamepads, and has actually added very little. What he has added has been a nice improvement though.
It'd be great to have you on board too, N-Rage. I'm surprised both you and mudlord are showing interest, but it's a good thing.
 
squall_leonhart

squall_leonhart

The Great Gunblade Wielder
N-Rage said:
Im a bit disappointed - it`s been ages and you still dint release a new Version? :evil:
(I probably was way less pedantic with making sure everything worked back then.)

Im surprised theres still interest in that Plugin though, so I thought I try figuring out my old Password and congratulate you to keep up with my horrible undocumented mess of code.

And hoping to be of some use...
Im incapable of getting your sources, sourceforge SVN seems to be down ATM. Did you try out the last Version I released (1.83).
I remember fixing such problems by simply leaving the new pak unitialised (and thus not responding to read/writes). Paks are supposed to be initialised with RD_GETSTATUS Commands. Games will realise a Pak got changed if Read/Write fails and then call RD_GETSTATUS. Thats better than hoping they`ll figure everything out in an arbitrary timespan.
Click to expand...

Hi N-Rage, try this link to download a tarball of the trunk
http://nragev20.svn.sourceforge.net/viewvc/nragev20/trunk.tar.gz?view=tar
 
painkiller78

painkiller78

New member
:D It's great you are back.
Your plugin was the only one I have ever used to play N64 games on emu.
Excellent work, hope you can help now... my respect :D
 
N-Rage

N-Rage

New member
Upon looking at the sources, the new version dint modify how Paks are switched (at least I couldnt spot a difference). So the old version had the same problems I guess.

Hi to those who hi me, Im not really back I`m just doing drive-by-posting.
 
OP
R

rabiddeity

Plugin Hacker
@NRage

A lot of stuff has been changed in the sources since 1.83, much of it not that obvious. Get a Subversion client, point it at https://nragev20.svn.sourceforge.net/svnroot/nragev20/trunk and pull everything. I prefer TortoiseSVN but you can use whatever you want. I wouldn't trust any tarballs to be up to date, and I want to make sure we're all working on the same page.

RE the pak changes, it's handled in DoShortcut, not in Interface.cpp or PakIO.cpp. It "removes" the pak for a short time (handles closed, paktype set to PAK_NONE, set a thread called "DelayedShortcut" to sleep for a short time and then insert the new pak). When paks are changed it still invalidates the pak reads, RD_GETSTATUS is called by the game, and it gets reinitted. But now the paks can't get changed immediately, that seems to throw off a few games (nobody is that fast at switching out paks in real life.) I'm trying to keep things as clean as possible so as not to leak handles. If you're seeing things differently, you might be looking in the wrong place. I haven't really messed with PakIO because I don't know how the real pak is supposed to behave.
 
Last edited:
T

thegeek6

Random Guy
Stupid of me to ask on this forum thread, but the problem of the GB tower not working could be caused on the lack of timing accuracy most N64 Emulators have, right? (not talking bad.) Are PC's Getting fast enough to have a Timing-accurate N64 emulator?
 
Doomulation

Doomulation

?????????????????????????
I don't really think so. Timings in HLE is very tricky - I view them more as hacks.
Emulating the hardware as it really works is the business of LLE, which currently is pretty slow on today's computers (since most if it is single threaded).
Emulating very accurate timing would probably slow down by some other factor, as well (I'm comparing against SNES here, though this might not be 100% accurate).
 
OP
R

rabiddeity

Plugin Hacker
N64 is a bit harder to emulate than previous generation consoles. For true emulation you have to simulate every chip in the hardware. I won't go into the hardware here, but suffice it to say the N64 has several interdependent chips which have to be emulated. Modern HLE emulators take some shortcuts to get a reasonable speed, since the graphical system for example doesn't require perfect timing. Unfortunately this kills any possible attempt at emulation within emulation as in the GB tower. I doubt we'll see clock-perfect N64 emulation for a long time, if ever. There's just not very much incentive for it at this point.

edit: Doomulation makes the perfect case here. Compare the speed of BSNES versus the speed of ZSNES. The first is attempting to be a tick-perfect emulator. The second has tons of hacks to make it run at a reasonable speed. Only now is the hardware becoming capable of running BSNES at a reasonable speed.
 
Last edited:
p_025

p_025

Voted Least Likely to Succeed
I'm going to take a more optimistic view and say there are probably some hacks that could be coded into an emulator to make GB Tower work, but it wouldn't be easy. Well, that's an understatement. But I'm quite sure it would be possible.
 
You must log in or register to reply here.

Top