Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
(1 edit)

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!

Neat that the nogore option is in. :-)

Custom level loading would be really great even if it was just a command line option.

I’m happy to be a supporter of this project even though I understand that the donations don’t cover a lot of dev time.

Good luck with them de-makes!

You can of course still mod your own levels in without a level loader, just like the original (but easier), just replace the files in the "custom" folder.

OK. I’m considering making a solution where double clicking on a level file will automatically place it in the custom folder and start the game. Should work.

Yep you should definitely be able to make a batch file solution for that.

(1 edit)

The original files inside the .dat files seem to be in another format and other file names.

Level images are .PCX
Sprites are .GOB
Sound effects are .SMP
And music is .MOD

See here for description of the files:

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.  

I must be a master of digging out old stuff from the void ;-)
"GOB file documentation:


Do YOU want to make your own GOB-files?
Then you have to know the GOB format!
Here you can find a brief desciption of it.
(this is all about how the file is saved)
Note: Everything is saved in Intel byteorder,
ie the least significant byte first.

                  THE HEADER

Offset   Size   Description
 0        2      Number of images in the file

For I=1 to Number of images

   Offset   Size   Description
    2+I*4    4      Offset in file to image data

End repeat

The above offsets are offsets from the beginning of
the file. Each image has it's own image data.
The image data is like this:

                THE IMAGE DATA

Offset   Size   Description
 0        2      Image width in pixels (W)
 2        2      Image height in pixels (H)
 4        2      Hotspot x
 6        2      Hotspot y
 8        W*H    Bitmap data

The offsets above are offsets in the image data (for each image).

The Hotspot x/y of a specific image works like this:
Whenever a sprite is drawn at (x, y) with that image,
the image is drawn at (x - hotspot x, y - hotspot y),
where hotspot x/y are the hotspots for that image.

The bitmap data is just a block of colordata for each pixel.
It scans the image horisontally left/down. This means that
the first byte represents the upper left pixel, the second
represents the pixel to the right of that and so on.
If the width is 10  pixels then the 10th byte of bitmap data
will represent the pixel (0, 1)."

Found it in a text file in this zip:

I understand that it's probably out of scope, just found it very amusing that I actually found it :-)

Anyhow, when I find the time I'll see if I can get an old level working and then see if I can automate the process to get all old levels working.

I now crown you "Master Of Digging Out Old Stuff From The Void"!  MODOOSFTV for short.  Pronounced "Mo-doo-sif-tiv".  Hahah.  It's like every time I think it's a dead end, you find something :D

I can't write this off completely now.  This has to be on the list to support at some point.  I've saved what you just posted.  I'd like to think I'll do this someday, I just can't say when.  But it would be really cool to achieve this, now that I have the specs!