Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

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.

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.  

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

             THE FORMAT OF GOBFILES

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:

https://web.archive.org/web/20001008094625if_/http://www.brainchilddesign.com:80...

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!

:-D

I know, I know... it's out of scope for now but... would it be easier to use "gobpack.exe -u" (included in the zip I sent via mail) to unpack the gobs to pcx and text files and then convert the pcx to png and in the end use png + text files as input instead of the gob files?

Cheers!
/MODOOSFT

Hahah, glad you like your new title.

Well that would save part of the work, but still there has to be some data level conversion since the "mask.pcx" file is a black & white image which is literally used as a mask at the pixel level in their rendering engine, while mine is actually just a full colour image that is laid over the top of everything.  So like I described earlier, when converting an old level, the mask.pcx has to be used to copy the graphics from the actual level background and paste them into a new file.

And as for the sprites, I would still need to interpret the gob data to know how to interpret the sprites.pcx files to find the images and their hotspots.

Those points are really where the bulk of the work is...