Might actually be what happened :-O
Viewing post in Jump 'n Bump - Remastered! comments
It’s an issue with XBox controllers. I have XBox360 controllers but it should be the same for all XInput controllers that don’t have a magic switch on the controller to force them to use Direct Input. What kind of controllers were the 4 usb controllers?
A lot of frameworks allow at least 8 Direct Input controllers and a maximum of 4 XInput controllers. If they do this they use the XInput API for the XInput controllers and Direct Input API for the rest. When doing so they filter out all XInput gamepads on the Direct Input side so they don’t get duplicates. There is no easy way to know which 4xinput controllers are accessed via XInput so they filter out all of them from the direct input enumeration. Some frameworks have a way of disabling XInput altogether in order to access all controllers via Direct Input to get past the 4 controller cap for XInput controllers. As I understand this is only a Windows issue.
Ok, thank you for filling me in on the details of this issue. Yes myself and another user didn't run into the limit because we are both in the same situation of having 4 XBox360 controllers, and then some generic USB gamepads that were kicking around to make up the other 4 controllers.
It seems like this will affect only a percentage of a percentage of users, so I'm not sure how highly I can rate this, especially since it would likely require me cracking open Godot and re-doing how they handle input, OR re-writing it from scratch in SDL etc . and handling the input myself... neither of those options are trivial and would be entire projects in their own right! (The funding just isn't there at the moment!) That's just my current assessment though, and I'll be keeping it in mind and looking out for other complaints. The forum will be up soon where people can post about any issues, and who knows, if the paid version with extra features take off, it could warrant further development in the XInput handling area!
Although I will leave you with a glimmer of hope - I have a set of "de-make" games planned that will be written in SDL (and a rendering engine called "Tilengine") and a de-make of Jump 'n Bump - already itself a simple game, would be really cute. Well, the code is already there in my existing Godot version, most of the changes would be syntactic... maybe the de-make could be the basis of a new version that supports multiple xbox controllers? We will see where things go!
In other news - the nogore option is finished, I made glitter and streamers come out of them :) it was fun. I'll be uploading that on Friday.
Also - your donation makes up of 50% of my total donations. 2 people donated $5 and you donated $10. Yes... interest has been high but donations have been low - but I'm not surprised with it being donation based. So as far as I'm concerned, you're my platinum donator :) I'll reply here to personally let you know when the forum is up and the update is out. Make sure to register at the forum when I do, so I can keep better track of these discussions!
The original files inside the .dat files seem to be in another format and other file names.
Originally:
Level images are .PCX
Sprites are .GOB
Sound effects are .SMP
And music is .MOD
See here for description of the files: http://www.aiei.ch/linux/jumpnbump/level-making/
If I want to get the levels working I guess I need to convert the level images and rename those files to match the filenames currently in the custom folder. Does the game currently support the custom sound effects, sprites and music?
Yeah it's easier to make your own levels than load the old ones at the moment, and that's by design. Loading of the original levels is not out of the question but would require a tonne of work, re-interpreting the binary format of those files. In fact I don't even think the binary format of the GOB files is documented anywhere, so it might not even be feasible...
To convert old levels you can work it out from the existing files - the foreground is no longer a simple black & white mask and is an entirely separate PNG image that's just laid over the top. So you can open the old mask, "select colour" and select all the white, then use that selection mask to copy from the original background and paste it into a new file.
Godot can't play MOD files! Believe me I tried a lot of approaches, but in the end I'd have to build MOD support into Godot myself. Which of course is another huge unjustifiable endeavor. It broke my heart to convert them to OGG files but that's what's it's playing right now. If I make a new version in another system it'll be MOD files all the way. Still Godot makes it far more feasible to make 2D retro games in a more timely manner and I highly recommend it.
Yep I can make the other things customizable (OGG files for music, WAV for sound, horizontal 16x16 PNG strips for sprites) but I was going to gauge interest before putting the extra work in. It's not complex but it's not free in terms of how much time it would take to make it load externally and get it all re-tested.
All that would definitely be in a version 2 "paid update" but yeah I was going to see how this goes.