Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs

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...

Tested now to modify the png files in the custom folder but no matter what I do it still uses the original images. Changing the collision text file works though.

Am I missing something or doing it wrong?

Argh you're right.  I found the problem - Godot is including my custom folder in the package, so the game is using the files it's finding internally in its data.pck rather than the ones from the actual external "custom" folder.  I found the export settings to correct this and fixed the problem, but I spent most of the day creating an export script that will one-click export all platforms and external files and then push to itch.io, so no human error can be introduced :)

Nice! Will try again when the magic script has pushed the next build to itch. :-)

How hard would it be to add support for levels that fit modern screens? Like 16:9 ratio levels. Could be good to have some extra space for 8 player matches.

Once again, possible, but not free :) Definitely something I'd look at for the paid version, because I can appreciate the benefits.  It's not the technical considerations, it's the design considerations. I made this game to support 4:3 screens, it doesn't seem right to re-release it and not have it played in its original style - I have an arcade cabinet that uses a real CRT and want to keep playing it on that (and I was contacted by someone else doing the same thing!) so adding support for widescreen levels would mean handling what happens when it's on a CRT - probably labelling them as "widescreen" in the level select interface, and either popping up a warning and just cropping out the extra space (and letting the players get lost off screen), maybe instead zooming out (but that would be hard to see on a CRT), or just locking those levels altogether... you can see how this affects development from a design perspective!  Open to ideas though.

(1 edit)

Ok you can be the first to test if my magic script did its job properly! I fixed the bug and all the builds were updated with the script.  Try it out and let me know!

Also this interface is horrible for long conversations - next order of business is getting the forums up,  so I'll let you know and you can post there from now on.

Great! It works!

Tested to load of the old levels I had converted extracted and converted to png and it worked straight away. :-)

Thanks for the nogore option as well!

And you can also be the first to test out the new forums on my website!  Could you head over to www.domariusgames.com, find the forum, and make a new thread there?