N-Rage doesn´t work right with Project64 2.x about project64

[cxd4]

Are you sure you're using the exact same N-Rage plugin with both Project64 1.6/1.7 as with Project64 1.7.0.49+?
Older Project64 versions bundled N-Rage V1.82.
Lately Project64 forked some unstable stuff squall did starting in N-Rage 2.2. I would recommend testing with N-Rage 2.1 overhaul by rabiddeity instead:
http://sourceforge.net/projects/nragev20/files/Nrage%20v2/NRage%20DInput8%20V2.1/

How does that work?

[Predator82Germany]

Use 2.3c for all
I´ll test 2.1

Edit: The same with 2.1

[cxd4]

Okay, so just to make sure (I have to ask because I don't know how to test N-Rage using my mouse...I only use a keyboard.) you didn't have this issue with 1.7.0.49? It was introduced in 1.7.0.50 in, some alpha version?

If there is 1.7 history in the repo that might be something to browse around later on.

[Predator82Germany]

1.7.0.49 works like 1.6
Yes, the problem starts with 1.7.0.50

[Predator82Germany]

Something found?
May zilmar has the sources of all 1.7 on HDD?
I would search the differences & then we may find a fix

[cxd4]

Pages 14 and 15 of the current GitHub history for project64 show some SVN commits from before 2010.
https://github.com/project64/project64/commits/master?page=14
https://github.com/project64/project64/commits/master?page=15

Here is a list of changes to pj64 1.7.0.50:
http://www.pj64-emu.com/change-logs/app-project64.exe/1.7.0.50-ver-23/#zAnswerList_695

Here maybe VI Refresh Rate has something to do with it:
5ff8e00

If you lower/raise VI refresh rate does it modify your issues using the mouse to control?

[Predator82Germany]

How much should I change the value to may see a difference? x, x0 or x00?

[cxd4]

I would just try setting VI refresh to exactly 1000 and 3000 I guess.

[Predator82Germany]

Can I change the settings on the fly or better restart the emulator after value change?

[cxd4]

I've never done them on the fly. I think also if you do things like change RDB, load ROM, load saved state, it might replace a few changes to the RDB for things like 4/8 MB RDRAM size. I would just save settings then start ROM clean.

[Predator82Germany]

With 1000 or 3000 the game goes only faster or slower but the input stays broken

[cxd4]

I hate to set up the mouse for N-Rage, but I guess if you send me a saved state to make my job easier I'll try testing each of the commits in the beginning of this repository to isolate exactly where the issue began and what commit broke it. I guess there's no other way since most people don't like using their mouse, and you don't know how to compile PJ64 / don't want to (especially for 10s of commits).

[Predator82Germany]

You mean I should send you the N-Rage settings file?

[cxd4]

Actually that might be even better, so that I don't have to figure out how to set up the mouse.

I like to use N-Rage 2.1 rc3 btw, in case that changes anything. I can just backup my old settings file. And you said try to turn/steer in Luigi's Raceway?

[Predator82Germany]

It´s very easy to set :)

Here it is:
http://www.wc-predator.de/NRage.zip

Yes, example was Luigi´s Raceway
And you should be very sensitiv & move the mouse very slow to see/feel the issue

[cxd4]

It's hard to explain, but I think you're right. Somehow it just "feels" more insensitive, higher lag/input delay on 1.7.0.50 alpha 23, than on 1.7.0.49.

Only one issue with your issue: Your issue started after 1.7.0.49 on 1.7.0.50 something. Well 1.7.0.50 ver 23 EXE was posted to the downloads site on 2010-05-16, just over 3 years after 1.7.0.49 was posted, and I don't have any of the pre-alpha23 EXEs on my hard disk anymore (tossed them as I kept downloading the updated alphas). I guess there is no way to download older alpha versions, so I guess there is no way to test them to see exactly which alpha version your input issue created on.

The very first Git commits to this repository were on 2008.09.17, which is still a little bit after 1.7.0.49 was released, so I guess there is a possibility I might be able to isolate your issue based on multiple compilations of project64 EXE from the commit history, though I think that is going to take a long time.

In the meantime, here's one of the differences I've noticed: "RSP Audio Signal", "Delay DP Interrupt", "Delay SI Interrupt", and "32 bit Engine" ... those 4 settings were either added to 1.7.0.50, or changed from their global default values since 1.7.0.49. So why don't you try flipping all 4 of those in the current 2.1 build to see if that affects your issue? I tried to toggle them myself but it's hard to really get a "feel" for whether or not I've fixed the issue...I just know there is a difference.

Also here is the private change log for Project64 EXE 1.7.0.50 alpha 23 which was omitted from the site: http://forum.pj64-emu.com/showthread.php?t=1623

[project64]

when I was using svn before git I used the check in number as the build version
so
git-svn-id: https://localhost/svn/Project64/trunk@23 would be build/alpha 23

build 23
f148d1b

build 27
f9db523

[cxd4]

That explains a lot. I know nothing about SVN.
So then it really is possible to build/test a list of all the alpha versions since b49.

@Predator82Germany , I think toggling "Delay SI Interrupt" fixes this issue (at least definitely alters it). Is that so for you?

[Predator82Germany]

Doesn´t fix it
Edit: Have toggled everything in game settings & found no difference
Edit2: Any other idea?

[cxd4]

What doesn't fix it? I said multiple things. Be careful with the amount of detail here--20 detailed posts in an issue thread could be more organized than 40 semi-detailed posts. I mentioned SI interrupt, I mentioned that 1.7.0.49 predated changes to DP interrupt, 32-bit core, and "RSP audio signal". All 4 of those options, conceivably even another, could have an effect. Why not simply invert all of them from what they're currently set to if you're not sure where to begin? That's what I did.

I'm way too used to winning at this game with my keyboard. Couldn't really stand testing with the mouse really. All I remember was that I caused it to have a difference by changing RDB. I'd really like to rule out what I can from RDB before compiling 40 different EXEs and sending them to you to test all of them.

[Predator82Germany]

cxd4, you´ve seen my edits?

[Predator82Germany]

What´s next?

[cxd4]

Sending you a bunch of old builds to test I guess. :P

You seem more qualified to judge whether or not this issue is actually fixed than I am so I am not able to test it myself. I would have to install VC 6.0 so that older builds of Project64 will compile.

[Predator82Germany]

Good idea

[project64]

is this still an issue with the current build now with 2.2 ?

[Predator82Germany]

Test it later

Edit: Still an issue with 2.2

[Predator82Germany]

2.3.0.2 too

[Predator82Germany]

Difference: https://www.youtube.com/watch?v=YAKMOPk5Zzc

[cxd4]

Can't believe I'm saying this, but it looks like I'm going to have to act as a build-bot and get all the old, hardly compilable VC6 commit histories of this repositories to each alpha build in binary form for testing this.

[Predator82Germany]

Woohoo

[cxd4]

https://github.com/project64/project64/tree/f92a2c67bacb0c3d9adc2a62c8bb8e5afd931f9b

Trying to compile that in VC 6.0.
It builds some components successfully, fails on others.
https://gist.github.com/cxd4/a845ffd258480384bb92

It does build the RSP plugin and all of the common libs, but it fails with errors on the main Project64 core component while building the WTL headers from some loosely defined or undefined types.

[LegendOfDragoon]

Is this still an issue?

[theboy181]

Has any testing been done on this issue since 2.3 or 2.4 ? Can this issue be closed?