May 21, 2019, 10:51:03 PM

Author Topic: [bmx] Xbox 360 Controller Left & Right Triggers not correctly readable w/ JoyZ()  (Read 2508 times)

Offline IanMartin

  • Full Member
  • ***
  • Posts: 122
    • Retrolutionary.com
Yep:
‪C:\BlitzMax\mod\srs.mod\xbox360.mod\xbox360.bmx
is where it's located.

Yes, it's still stopping on "freeaudio"


Platfinity (made with BlitzMax) on Steam:
http://store.steampowered.com/app/365440/Platfinity/

Offline col

  • Sr. Member
  • ****
  • Posts: 416
Do you get any other error messages or still that g++ has crashed?

You may want to adjust Windows Defender to not monitor your BlitzMax folder, and also any of your project folders.

Failing that...
I guess you could try another MinGW such as the one from the BlitzMax build at https://github.com/blitz-research/blitzmax. For me , using a Win7 unit, his version will build debug versions OK but Release builds give me an EAV, but it's worth a shot if the above doesn't fix things.
Any bugs in my code are proof of its hand-coded nature.
https://github.com/davecamp

Offline IanMartin

  • Full Member
  • ***
  • Posts: 122
    • Retrolutionary.com
It's not saying g++ has crashed anymore.

But it's still stopping on the freeaudio one:

Compiling:eventqueue.bmx
ar: creating C:/BlitzMax/mod/brl.mod/directsoundaudio.mod/directsoundaudio.debug.win32.x86.a
flat assembler  version 1.69.14  (786431 kilobytes memory)
3 passes, 11183 bytes.
Archiving:eventqueue.debug.win32.x86.a
Compiling:freeaudio.cpp
ar: creating C:/BlitzMax/mod/brl.mod/eventqueue.mod/eventqueue.debug.win32.x86.a
Build Error: failed to compile C:/BlitzMax/mod/pub.mod/freeaudio.mod/freeaudio.cpp
Process complete

I tried copying the freeaudio.cpp file from the version of BlitzMax at the link you posted...and I downloaded and installed the other MinGW.  Windows Defender has an exception for the BlitzMax folder now...and it would pop up a notification if it was blocking something. 

I'm not sure what's going on.

Does the mod have to be built on my machine?  Or can it be copied from someone else?

Since it's using a .dll, could I use Extern "C" functions to run the code in the dll?
Platfinity (made with BlitzMax) on Steam:
http://store.steampowered.com/app/365440/Platfinity/

Offline col

  • Sr. Member
  • ****
  • Posts: 416
I would think there is an issue with the MinGW setup and it's not compiling cpp files, which requires g++. g++ is a part of the MinGW installation. Also in your previous pic that shows the MaxIDE information, it's not picking up g++ which also explains why it not compiling the freeaudio.cpp file.

Even stranger is the version of MinGW from the first link that I gave you should give you gcc and g++ 3.4.5 as opposed to gcc 3.4.2. I've attached a pic of my Win7 BlitzIDE setup for comparison. I have MinGW installed on a different drive to the OS so it shows up as d:\MinGW. A standard install to a pc with 1 hard drive would usually install to c:\MinGW.

Quote
Since it's using a .dll, could I use Extern "C" functions to run the code in the dll?
If you want to use functions from a dll then you would use LoadLibraryA and GetProcAddress to load the dll and get a function pointer to the function that you want to use. You can look though the module source to see how that part is done. There's nothing stopping you from using that kind of approach in your main code as opposed to using it in a module. However, modules can be thought of as 'libraries' of code, ( well, they are libraries of code  :P ) that you can either import or not. They are a great concept for keeping your code organised. Also, once they are compiled then you just Import them. After the first compilation then they don't require re-compiling unless they are changed, this helps will faster build times too.

BlitzMax modules worked because they have already been compiled, and more importantly they were compiled using the same compiler for all modules. When you install MinGW it may be a different version to what was used to build the original modules and this *can* create headaches due to possible incompatibilities between the runtime libraries of gcc -
 which is why I suggested to Rebuild All Modules. I guess you don't have to do that but you'll never know if any problems would be due to an incompatibility of the compiled code produced by MinGW, the gcc runtime or 3rd party modules ( including your own ) that you'd build that have c/c++ code in them ( there are many! ).
Any bugs in my code are proof of its hand-coded nature.
https://github.com/davecamp

Offline Henri

  • Full Member
  • ***
  • Posts: 196
Hi,

I've made a pre-built version for convenience with enhanced bmk & MaxIDE.

Download from https://ufile.io/wpwf7

   1. Extract zip-file to C:\Blitzmax (not necessary, but preferred)

   2. Configure Windows enviroment variables;   (assuming you extracted in preferred location)
      - Add / modify  user variable named MinGW with value C:\BlitzMax\MinGW32
      - Modify  system variable named Path by adding value C:\BlitzMax\MinGW32\bin (this value should be seperated from other values by semicolon ; )

Part 2 ensures that build modules option is visible in MaxIDE and versions are showed correctly in 'About'-menu. MinGW gcc version included in zip-file is 4.7.1

Thats it :-)

-Henri
- Got 01100011 problems, but the bit ain't 00000001

Offline col

  • Sr. Member
  • ****
  • Posts: 416
Nice one Henri, thanks!
Such a cool community  8)
Any bugs in my code are proof of its hand-coded nature.
https://github.com/davecamp

Offline IanMartin

  • Full Member
  • ***
  • Posts: 122
    • Retrolutionary.com
Got it working finally!

Wow!  You guys are awesome, thank you!

Something must have been wrong with my setup.  It's been a long time since I set up BlitzMax.  I used the download from the BlitzBasic site.  Henri's download package worked fine though.  I just copied it to C: and did Rebuild All Modules, and bang!  It's working.  My About MaxIDE now says:
FASM Version: 1.69.14
GCC Version: 5.1.0
G++ Version 5.1.0
So it must have been my G++ wasn't being recognized for some reason...maybe pointing to the wrong place?  I dunno...

col's code is great!  Everything reads as it should and it looks like there's support for vibration there too.  Awesome!  This is going to be a big help!

I'm very much looking forward to being about to use the triggers.  A gunfighter game and games with tanks spring to mind.  I'd like to do a tank game with real tank controls for the treads. 


I have a couple of questions about the code:

Do I have your permission to use this code in my games?  It has a copyright notice on it and I like to respect copyright! 

Is there a 4 player limit on controllers in Windows?  I searched the internet a bit, but can't find a definitive answer.  MS says theres a limit of 4 wireless Xbox 360 controllers, but I could not find anything on wired controllers.  Is it possible to do 8 or even 12 controllers?  Does anyone know?

In the function XBox360Update there is a
Delay 17
statement.  Wouldn't that make a delay in your game where it's reading the stick(s)?  I saw in the other thread something about the non threaded version lowering the frame rate significantly?  So I'm wondering why there's a Delay statement in there?  17 millisecs is approximately one frame at 60 FPS, so I'm confused about the purpose of the delay.

If you're doing this as threaded you don't have to call XB.Update()?  I've never done a threaded build.  Is it as easy as just changing Build Options to Threaded Build?  How will that effect the rest of my code?

How can I be sure the user's computer will have the XInput9_1_0.dll or XInput1_3.dll files on their computer?  Could they be included next to your .exe when you install your game?  Is one of them the newer one or the one that's preferable to use?

Thanks so much for this code and the help getting me up to speed Dave!  And thanks Henri for the package with MinGW included, I thought I was never going to get this going...  This Xbox controller thing has been bugging me for a couple of years now.



Platfinity (made with BlitzMax) on Steam:
http://store.steampowered.com/app/365440/Platfinity/

Offline col

  • Sr. Member
  • ****
  • Posts: 416
Thats great that you have it working now.

Quote
Do I have your permission to use this code in my games?  It has a copyright notice on it and I like to respect copyright!
Yes sure, no probs.

Quote
Is there a 4 player limit on controllers in Windows?
Yes. It's a hard limit imposed by MS.

Quote
In the function XBox360Update there is a
Delay 17
statement.  Wouldn't that make a delay in your game where it's reading the stick(s)?
There's no need to call that function. To summarise, if you are building in 'non-threaded' then call XB.Update, if you are building 'threaded' then don't call XB.Update ( well, you can but it doesn't do anything in a 'threaded build' so is just a wasted function call ). Everything is taken care of for you automatically by using 'conditional compile switches'. XBox360Update is called in a separate thread so there is no slowdown, Delay 17 prevents the thread from running too fast.

Quote
If you're doing this as threaded you don't have to call XB.Update()?
Correct. Nothing strange/bad will happen even if you do, it would be just a wasted function call.

Quote
I've never done a threaded build.  Is it as easy as just changing Build Options to Threaded Build?  How will that effect the rest of my code
Yes, it is as simple as ticking the threaded build option, as everything should work exactly the same. Threaded builds give the option of creating and using extra threads and thread synchronisation types in your code.
There are a couple of significant differences behind the scenes but everything should behave in the same way as a regular non-threaded ( single-threaded ) build. If things don't behave the same way then something is wrong in the code.

Quote
How can I be sure the user's computer will have the XInput9_1_0.dll or XInput1_3.dll files on their computer
Either one will be installed with the OS.

Quote
Could they be included next to your .exe when you install your game?
They could be, but one of them should already in the \Windows\System32 folder.

Quote
Is one of them the newer one or the one that's preferable to use?
There is more functionality in the 1_3 version but it doesn't make much difference as to the way it's being used in the module.
https://msdn.microsoft.com/en-us/library/windows/desktop/hh405051(v=vs.85).aspx



Enjoy and have fun! 8)




Any bugs in my code are proof of its hand-coded nature.
https://github.com/davecamp

Offline IanMartin

  • Full Member
  • ***
  • Posts: 122
    • Retrolutionary.com
Ugh, I meant to reply to this earlier!  I guess I got lost finishing up my latest update.  I haven't been on here in forever...

Anyway, this is super cool awesome!  Thanks for letting me use your code :)
I'm going to be doing a 4 player local co-op game at some point, so hopefully I'll be able to share some usable code and give a little something back.  It seems like everything is pretty much there though, great job on this!
I'll be doing vibration too I think, so maybe I can share some values for that that work well?

I just checked my PC and it has all these XInput dlls:
xinput1_1.dll
xinput1_2.dll
xinput1_3.dll
Xinput1_4.dll
Xinput9_1_0.dll
XinputUap.dll
...and I'm running Windows 10 64 bit.  I'll have to check my older PCs when I get a chance, but I'll bet these are on everyone's PC these days.

Thanks again for the help on this.  I still haven't found anything that even looks like a good option for me besides BlitzMax, so it's great to see people on here still willing to help out with it! :D
Platfinity (made with BlitzMax) on Steam:
http://store.steampowered.com/app/365440/Platfinity/