Go Back   Project64 Forums > General Discussion > Open Discussion

Reply
 
Thread Tools Display Modes
  #1  
Old 3rd August 2013, 03:30 PM
shunyuan's Avatar
shunyuan shunyuan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Apr 2013
Posts: 491
Default N-Rage Input 2.3c lite (No XInput, double rumble strength)

------------------------------
N-Rage Input 2.3c lite version:
------------------------------
* remove XInput driver (to remove the initialization delay if you don't have a 360 controller)
* double rumble strength
* fix crash at (New memPak/Browse) button


------------------------------
file descriptions:
------------------------------
NRage_Input_2.3c.dll : N-Rage Input 2.3c
src : source code

------------------------------
download:
------------------------------
N-Rage Input 2.3c lite (fix1)
__________________
---------------------
CPU: Intel U7300 1.3 GHz
GPU: Mobile Intel 4 Series (on board)
AUDIO: Realtek HD Audio (on board)
RAM: 4 GB
OS: Windows 7 - 32 bit

Last edited by shunyuan; 24th August 2013 at 07:53 AM.
Reply With Quote
  #2  
Old 10th August 2013, 12:05 PM
squall_leonhart's Avatar
squall_leonhart squall_leonhart is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Mar 2007
Location: Sydney, Australia
Posts: 2,918
Default

so instead of taking the time to fix the initialisation delay you just Byuu the whole thing.
__________________

CPU:Intel Xeon x5690 @ 4.2Ghz, Mainboard:Asus Rampage III Extreme, Memory:48GB Corsair Vengeance LP 1600
Video:EVGA Geforce GTX 1080 Founders Edition, NVidia Geforce GTX 1060 Founders Edition
Monitor:ROG PG279Q, BenQ BL2211, Sound:Creative XFI Titanium Fatal1ty Pro
SDD:Crucial MX300 275, Crucial MX300 525, Crucial MX300 1000
HDD:500GB Spinpoint F3, 1TB WD Black, 2TB WD Red, 1TB WD Black
Case:NZXT Phantom 820, PSU:Seasonic X-850, OS:Windows 7 SP1
Reply With Quote
  #3  
Old 10th August 2013, 01:00 PM
shunyuan's Avatar
shunyuan shunyuan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Apr 2013
Posts: 491
Default

I don't have a 360 controller.

You can fix the XInput initialization delay for the official build.
__________________
---------------------
CPU: Intel U7300 1.3 GHz
GPU: Mobile Intel 4 Series (on board)
AUDIO: Realtek HD Audio (on board)
RAM: 4 GB
OS: Windows 7 - 32 bit

Last edited by shunyuan; 10th August 2013 at 01:26 PM.
Reply With Quote
  #4  
Old 10th August 2013, 01:19 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

I can't use XInput anyway. I would get better support with RawInput than I would with XInput.
But, I don't think I wanna code anything DirectX, regardless.

Also, if you wanted to remove XInput, ideally all you had to do was fork the 2.1 RC3 version, then merge in squall's imported fix to the crashing that he applied in 2.2/3 something, and it would essentially be the same thing.


Btw, looks like Shunyuan statically linked in the MSVCR*** library so that we no longer have to worry about messing around with random DLL files.
Of course, this makes the plugin DLL size go up.
It is possible to remove all CRT functions and replace them with something lower-level and the plugin size will go back down.

Either way, zilmar if you happen to read this, unless you're a total MS geek, I really hope you don't plan on maintaining the XInput plugin, because that requires DirectX ten thousand and an Xbox controller.
Something smaller like this code base would resemble Jabo's DirectInput a lot better.
Reply With Quote
  #5  
Old 11th August 2013, 09:20 AM
squall_leonhart's Avatar
squall_leonhart squall_leonhart is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Mar 2007
Location: Sydney, Australia
Posts: 2,918
Default

Quote:
It is possible to remove all CRT functions and replace them with something lower-level and the plugin size will go back down.
Not if you want it to keep working. Microsoft breaks winapi all the time.
__________________

CPU:Intel Xeon x5690 @ 4.2Ghz, Mainboard:Asus Rampage III Extreme, Memory:48GB Corsair Vengeance LP 1600
Video:EVGA Geforce GTX 1080 Founders Edition, NVidia Geforce GTX 1060 Founders Edition
Monitor:ROG PG279Q, BenQ BL2211, Sound:Creative XFI Titanium Fatal1ty Pro
SDD:Crucial MX300 275, Crucial MX300 525, Crucial MX300 1000
HDD:500GB Spinpoint F3, 1TB WD Black, 2TB WD Red, 1TB WD Black
Case:NZXT Phantom 820, PSU:Seasonic X-850, OS:Windows 7 SP1
Reply With Quote
  #6  
Old 11th August 2013, 10:33 AM
shunyuan's Avatar
shunyuan shunyuan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Apr 2013
Posts: 491
Default

Quote:
Originally Posted by FatCat View Post
It is possible to remove all CRT functions and replace them with something lower-level and the plugin size will go back down.
What's the point that you suggest others not to use CRT functions but you still use fopen in your plugin?

Quote:
Originally Posted by FatCat View Post
Either way, zilmar if you happen to read this, unless you're a total MS geek, I really hope you don't plan on maintaining the XInput plugin, because that requires DirectX ten thousand and an Xbox controller.
Something smaller like this code base would resemble Jabo's DirectInput a lot better.
I am wondering if you have surveyed the RawInput API, it is a very low level API to access device driver, you need Windows Driver SDK to compile RawInput API. If you want to support gamepad and force feedback, DirectInput is the better choice.
__________________
---------------------
CPU: Intel U7300 1.3 GHz
GPU: Mobile Intel 4 Series (on board)
AUDIO: Realtek HD Audio (on board)
RAM: 4 GB
OS: Windows 7 - 32 bit

Last edited by shunyuan; 23rd August 2013 at 11:58 AM.
Reply With Quote
  #7  
Old 14th August 2013, 03:52 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Quote:
Originally Posted by shunyuan View Post
What's the point that you suggest others not to use CRT functions but you still use fopen in your plugin?
A misinterpretation on your part.
Saying that not using CRT functions is one solution, is not the same thing as suggesting all others to not use them or to never use them.

You've got some nerve, accusing me of such hypocrisy.

I don't use fopen anywhere, in any plugins.

You are probably referring to the CRT install I managed to implement to the latest commit of my RSP plugin so that I would stop forcing everyone to install a bunch of split DLLs. That hasn't even been released yet, so it is not valid to say that I "still" use fopen in it. I only JUST added it before my wireless adapter crapped out on me, on this stupid shitty Internet network.

Quote:
Originally Posted by shunyuan View Post
I am wondering if you have surveyed the RawInput API, it is a very low level API to access device driver, you need Windows Driver SDK to compile RawInput API. If you want to support gamepad and force feedback, DirectInput is the better choice.
Actually I never talked about RawInput here.
I was only asking squall about it as a possibility because I read about it before, and he said it wouldn't support most devices, and I believed him, so I was no longer interested in doing DirectX anything for input.

DirectInput, XInput, RawInput, ... I don't care.
You seem to think I was defending at least one of the three.

Unless squall was IMing you misinterpretive allegations about me supporting RawInput and putting words into my mouth.
Reply With Quote
  #8  
Old 14th August 2013, 04:14 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Now for calmer version of my reply, where I don't feel as mad.

Reasons why you shouldn't use CRT functions:
  • Standard C library methods are usually in-lined to syscalls and hardware interrupts on most operating systems, but not on Microsoft Windows. Instead, on Windows, this is converted to a C "run-time", where you are forced to use procedure calls in their modern compilers.
  • The Microsoft Windows CRT is ever-changing. It's generally backwards-compatible, but Microsoft sometimes likes to complain when you don't use their versions of the CRT methods or the Win32 internal methods. In some cases, this is more compatible, and avoids making the user install MSVCR???? dlls where ???? could totally be anything.
Reasons why you should use CRT functions:
  • To avoid dependency hell through USER32, ADVAPI32, or SHELL32. You can use CRT functions like fopen() like in the latest commit I did to $rsp before my Internet died, or system(), to avoid problems with entry points in intermediary updates to the standard WINAPI DLLs.
  • When building an EXE, and not an entry-point-free resource DLL, a CRT dependency table is unconditionally generated by Visual Studio. So your EXE is going to use CRT functions sooner or later anyway if it's not a DLL, so why not use even more CRT functions to take advantage of this already inevitable dependency?
  • Portability, duh.
  • More lower-level than the bloated, "secure" versions by Microsoft, thus more likely to optimize to function-free, call-less direct hardware interrupts or syscalls when compiled on other operating systems (so smaller and faster code).
So just because I say, you can avoid using CRT functions in a DLL plugin all the time, does not mean you assume that I am one-sidedly suggest that everyone except me becomes adverse to using the CRT at all in their problems. Thx, bye
Reply With Quote
  #9  
Old 14th August 2013, 06:37 AM
snoman909 snoman909 is offline
Junior Member
 
Join Date: Aug 2013
Posts: 10
Thumbs up

Quote:
Originally Posted by FatCat View Post
Now for calmer version of my reply, where I don't feel as mad.

Reasons why you shouldn't use CRT functions:
  • Standard C library methods are usually in-lined to syscalls and hardware interrupts on most operating systems, but not on Microsoft Windows. Instead, on Windows, this is converted to a C "run-time", where you are forced to use procedure calls in their modern compilers.
  • The Microsoft Windows CRT is ever-changing. It's generally backwards-compatible, but Microsoft sometimes likes to complain when you don't use their versions of the CRT methods or the Win32 internal methods. In some cases, this is more compatible, and avoids making the user install MSVCR???? dlls where ???? could totally be anything.
Reasons why you should use CRT functions:
  • To avoid dependency hell through USER32, ADVAPI32, or SHELL32. You can use CRT functions like fopen() like in the latest commit I did to $rsp before my Internet died, or system(), to avoid problems with entry points in intermediary updates to the standard WINAPI DLLs.
  • When building an EXE, and not an entry-point-free resource DLL, a CRT dependency table is unconditionally generated by Visual Studio. So your EXE is going to use CRT functions sooner or later anyway if it's not a DLL, so why not use even more CRT functions to take advantage of this already inevitable dependency?
  • Portability, duh.
  • More lower-level than the bloated, "secure" versions by Microsoft, thus more likely to optimize to function-free, call-less direct hardware interrupts or syscalls when compiled on other operating systems (so smaller and faster code).
So just because I say, you can avoid using CRT functions in a DLL plugin all the time, does not mean you assume that I am one-sidedly suggest that everyone except me becomes adverse to using the CRT at all in their problems. Thx, bye
You guys are great ty
Reply With Quote
  #10  
Old 16th August 2013, 07:54 AM
shunyuan's Avatar
shunyuan shunyuan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Apr 2013
Posts: 491
Default

Quote:
Originally Posted by FatCat View Post
DirectInput, XInput, RawInput, ... I don't care.
In other words, you don't know these input API at all.
__________________
---------------------
CPU: Intel U7300 1.3 GHz
GPU: Mobile Intel 4 Series (on board)
AUDIO: Realtek HD Audio (on board)
RAM: 4 GB
OS: Windows 7 - 32 bit
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT. The time now is 10:47 PM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.