Imploder compression algo

[jotd]

very professional packaging. I have tested the editor with the CD32 data and I must say it works very well and it looks very convenient.

I have slightly modified a level, saved, and it worked. Good job figuring out all the level / tile codes, and writing such a profesionnal editor.

But even with all those features, it's a lot of work to create levels from scratch. The only easy way to do it is to create a png with PSP (using grid mode) and to import the image.

A suggestion: when adding Lucozade, apples, bonuses... you could automatically couple the apple tile with the "bonus" behaviour. Same thing for spikes, etc... This way it's a lot faster to create levels.

BTW Do you want to try to do the same for Chaos Engine CD32? I think this is a lot tougher. I already figured out the tile layout and the sprites, but there's a lot of other data and I cannot figure them out. Maybe it would require some resourcing...

Anyway, we should rename this thread now, since the Imploder compression works.

[Exl]

Originally Posted by jotd

But even with all those features, it's a lot of work to create levels from scratch. The only easy way to do it is to create a png with PSP (using grid mode) and to import the image.

How would you create a PNG in PSP in grid mode? I'm sure it's possible to convert all the data on a PNG to tiles, but Superfrog only uses 840 (out of 1024 that might be supported, but I haven't tried this). There's also separate collision data for each tile, a 1-bit bitmap.

A suggestion: when adding Lucozade, apples, bonuses... you could automatically couple the apple tile with the "bonus" behaviour. Same thing for spikes, etc... This way it's a lot faster to create levels.

Team17 had this idea too, because the data for this is actually inside the level files! I haven't gotten around to adding it yet though, I want to do it Right, which means adding a sortof sub-editor for this data as well.

BTW Do you want to try to do the same for Chaos Engine CD32? I think this is a lot tougher. I already figured out the tile layout and the sprites, but there's a lot of other data and I cannot figure them out. Maybe it would require some resourcing...

I had a look at Chaos Engine too (also a game I've always wanted to hack up to pieces ), I got as far as making the level layout visible by plotting tiles as pixel. I'd love to make a modified version of Froggy for Chaos Engine, or even have it support both. Turrican II (CDTV version) I've also been looking into, it doesn't look terribly difficult.

Anyway, we should rename this thread now, since the Imploder compression works.

And quite beautifully so I can't rename the thread even as original poster though.

I'm still working on Froggy. While modifying World 1 I got the urge for more features to make the tile editing a bit faster\easier. World 1 and 5 are probably the most difficult to edit because of the "dirt" tiles that need to look align, as well as their shadows when you go underground.

[jotd]

Originally Posted by Exl

How would you create a PNG in PSP in grid mode? I'm sure it's possible to convert all the data on a PNG to tiles, but Superfrog only uses 840 (out of 1024 that might be supported, but I haven't tried this). There's also separate collision data for each tile, a 1-bit bitmap.

In my Gods editor, I usually work like this: I set grid mode to the actual tile size, then I copy/paste entire sections of existing maps with changes, in order to save time and get realistic tile arrangement (I'm no graphic artist).

Then I use the "import" feature of my editor to recognise the tiles (using a simple RGB pixel to pixel comparison) and re-insert the tiles in the editor. This way I can work only with PSP (using the undo feature, etc...) for the background tiles, and then I can import the image in the editor to add things I cannot do with PSP. I can export back to PNG afterwards. That's the best and fastest solution I have found to create levels. Else, you'll have to implement a lot of stuff in your editor and you'll never get the flexibility of PSP.
[QUOTE]

Team17 had this idea too, because the data for this is actually inside the level files! I haven't gotten around to adding it yet though, I want to do it Right, which means adding a sortof sub-editor for this data as well.
[QUOTE/]
you mean that you could not add new bonuses, only change the backgrounds. You need a little more guesswork to create a full Superfrog editor. I don't think people would like tweaked levels. They'd like brand new levels.
I suggest that you check my Gods Editor (if you don't know it, it does not create data for the original Gods game, but for my remake).

I had a look at Chaos Engine too (also a game I've always wanted to hack up to pieces ), I got as far as making the level layout visible by plotting tiles as pixel. I'd love to make a modified version of Froggy for Chaos Engine, or even have it support both. Turrican II (CDTV version) I've also been looking into, it doesn't look terribly difficult.

I suggest that you create different products (copy/paste from a stable state). Because it will be tough enough to make it work, if you have 3 different configurations to support it will be tougher and prone to regression.

I'm able to write maps for Chaos Engine from the level data, but not more. No bonuses locations, no nodes, no exits. I've been daunted by the amount of unknown data. And it exists a possibility that some stuff is code-driven (specially with the Bitmaps and their complex secret stuff). So you won't be able to create a brand new level without actually coding stuff, which is impossible when using the original engine.
But if you can figure out the file format, it will be easier for a Java / C++ remake anyway

And quite beautifully so I can't rename the thread even as original poster though.

I'm still working on Froggy. While modifying World 1 I got the urge for more features to make the tile editing a bit faster\easier. World 1 and 5 are probably the most difficult to edit because of the "dirt" tiles that need to look align, as well as their shadows when you go underground.

Hence the export/import function, and work by block of tiles directly in PSP. In the context, it's much easier.

[Exl]

Originally Posted by jotd

In my Gods editor, I usually work like this: I set grid mode to the actual tile size, then I copy/paste entire sections of existing maps with changes, in order to save time and get realistic tile arrangement (I'm no graphic artist).

Then I use the "import" feature of my editor to recognise the tiles (using a simple RGB pixel to pixel comparison) and re-insert the tiles in the editor. This way I can work only with PSP (using the undo feature, etc...) for the background tiles, and then I can import the image in the editor to add things I cannot do with PSP. I can export back to PNG afterwards. That's the best and fastest solution I have found to create levels. Else, you'll have to implement a lot of stuff in your editor and you'll never get the flexibility of PSP.

Froggy can copy other parts of a level structure too. Holding down shift you can click and drag across tiles. Those will then become your current tile selection. For 1.1 I also have an Undo feature, which helps a lot.

you mean that you could not add new bonuses, only change the backgrounds. You need a little more guesswork to create a full Superfrog editor. I don't think people would like tweaked levels. They'd like brand new levels.
I suggest that you check my Gods Editor (if you don't know it, it does not create data for the original Gods game, but for my remake).

What is also stored in the level data is what type each tile has. For example for a Restart pill tile, it's special type is that of a pickup. For some of the grass tiles in World 1, it's default type is Walkable, and the dirt tiles are marked impassable.

I suggest that you create different products (copy/paste from a stable state). Because it will be tough enough to make it work, if you have 3 different configurations to support it will be tougher and prone to regression.

Depends on how Chaos Engine's levels are made. You can have the editor be controlled by external configuration files. Level data layout, tile layers and whatnot. BUt that's obviously not possible if a game deviates too much.

I'm able to write maps for Chaos Engine from the level data, but not more. No bonuses locations, no nodes, no exits. I've been daunted by the amount of unknown data. And it exists a possibility that some stuff is code-driven (specially with the Bitmaps and their complex secret stuff). So you won't be able to create a brand new level without actually coding stuff, which is impossible when using the original engine.
But if you can figure out the file format, it will be easier for a Java / C++ remake anyway

What do you know of the Chaos Engine so far?

[jotd]

What do you know of the Chaos Engine so far?

Only a part of the map files: the tile layout. I was able to reconstruct the map files from those files in BMP format, after having used GFXRip on the tile gfx files (with the correct palette of course).
(but the mapfiles on EAB are not mine)

the other information in the level files is unknown to me.

[Exl]

I had a closer look at the level files, I've found out only a few bits more besides the level format. If I get something more usable, I'll let you know.

If you're implementing a decompressor you need to implement every feature. But, with a compressor, you can implement a tiny little subset of the features ... anything that outputs something that looks Imploded (and so that SuperFrog accepts). I bet that means you hardly need any code.

[Skope]

Sorry for the topic deviation but:

Originally Posted by WayneK

You could do what some other coders have done... take the really cheap way to port a packer from another architecture - emulation
I've seen some ZX Spectrum packers made into Windows cmdline versions, by simply running a z80 core + writing a tiny shell around it to start up the emulation in the correct way - surely you could do the same with starscream or some 68k core... probably no more than 20-30 lines of code.

That is in fact exactly the answer to my question on how to get LZX to work 100% under Linux. Thanx Wayne, I'm on a mission now. (:

Sorry for necroposting, but this is fully rewritten and fully functional Windows version of FImp.

Used: Musashi 68k, EASy68K, explode.c, IMPLODER.S.

[emufan]

it does work

crunched the Imploder amiga-executable, decrunched with xfddecrunch within winuae - and the result still works

edit: the "imploder test" does hang after mode 02 - tested with the imploder execuable:
Mode 00: 73514 bytes
Mode 01: 72360 byte
Mode 02: 70758 byte

now nothing, program stalled.

Don't know about amiga-executables. I have wrote only data-mode to compress and decompress binary data.

And I'll check this file. It named FImp?

[emufan]

the imploder was just given as an example. you can just try win_imploder.dll, inclued in your archive above. the gui is stalled forever, after displaying Mode 02 of "implosion test".
win7 home premium x64 amd cpu.

is it possible , to insert the output-filename automaticaly. just adding a bin at the end or something?

In "Implode test" it not creates output file, it's just testing compression ratio.

Compression mode up from 03 takes much more time and memory to compress. I think that something going on with stack. And 0x200 bytes is not enough for compression in such cases.

Try to compress small files and it will work.

So, I'll try to do something with this.

[emufan]

you are right, ofcourse

Mode: Implosion test;

Mode 00: 518 bytes
Mode 01: 318 bytes
Mode 02: 282 bytes
Mode 03: 284 bytes
Mode 04: 284 bytes
Mode 05: 284 bytes
Mode 06: 284 bytes
Mode 07: 284 bytes
Mode 08: 284 bytes
Mode 09: 284 bytes
Mode 10: 284 bytes
Mode 11: 284 bytes

Best mode is: 02 (282 bytes).
Done!

tested the readme.txt file

[Dr. MefistO]

Hi! New version of the WinImploder!(LINK)

Info: This tool implements the Amiga’s Imploder util functionality. The new version includes fully rewritten code and open sources.