Custom tilesets - any preference on how these would be created?

[namida]

As you're probably aware, I'm writing an app which would include the ability to make custom graphic files. (Actually, I've already acheived almost all the nessecary steps - I've successfully compressed *and* decompressed DAT files, as well as extracted images, so I already know how to do this, it's just a matter of writing the code.)
I'm wondering if anyone has any preference about the input format for these.

I'm thinking of going with, for simplicity's sake, BMP formats with magenta(#FF00FF) representing transparent. Since Lemmings only uses 6-bit color values, if you actually wanted this color in your image, you could just use #FC00FC; both would come out as 3F 00 3F when converted to 6-bit anyway. A possible alternative is going with 256-color BMP images, and regarding anything that doesn't use the first 16 colors to be transparent. I would rather avoid formats like PNG and GIF that use compression (though I'll probably include GIF as an export option, for Lemmini/jLevelBuilder), simply because I don't particularly like writing decompression routines.

For objects, would you rather have a seperate image for each frame, or have them all in one (like Lemmini)?

What about defining object information? Would you prefer to have a menu in the app for this, or set the values in an external text file (or for the trigger area, maybe a seperate image file like Lemmini has)?

Of course, I could include more than one option, if there's enough demand for several of them. In the meantime, I'll work on the underlying code for inserting/extracting graphics into a simple internal format.


EDIT: Okay, don't worry about file formats. I've just found out QB64 has a very good built-in command for opening various formats - BMP, JPG, PNG, GIF, PNM, XPM, XCF, PCX, TIF, LBM, and TGA. Output on the other hand seems limited to BMP, but I can write my own subroutine to make GIF files for Lemmini.

EDIT: ...or maybe not. For some reason, trying to use QB64's built-in image handling code causes crashes, so I'll have to rely on custom routines. Which means we're back to the question of what formats. Probably going to be BMP, realistically.

[ccexplore]

There are enough free programs out there for file format conversion, sticking to BMPs should be fine.  I'd suggest 24-bit BMP because I think it's actually slightly harder nowadays for people to create non-24-bit BMPs.  Using color key for transparency (ie. one specific color is transparent) is fine, although I'd suggest the ability for the user to specify the color key to use rather than being fixed to magenta.

You'll also want to think about how to handle the fact that the Lemmings graphics format has a limited color palette.  As a simple start of course, you can simply only handle BMPs that use no more than 7 different colors.

As for the rest, obviously the more (to a point) options you support the better, but there's no harm in starting simple first and just implement whatever makes it easiest for you to come up with something that achieves the goal.  External text files is probably a decent way to go in lieu of implementing a full GUI editor directly for the groundXo.dat files where the object information are defined.  (By "editor" I'm implying the ability to load from an existing groundXo.dat file of the custom graphics set as well as saving it.)

Good luck!

[LJLPM]

For objects, would you rather have a seperate image for each frame, or have them all in one (like Lemmini)?

for Objects, jLevelBuilder uses Lemmini's single images.

[namida]

Yep, I know. That format is probably a tad more convenient for level editors or Lemmings emulators to use - but if you're actually CREATING a tileset, what's more convenient to you while you're making it? (Though at the same time, I'll also say that it would NOT be hard to support both.)

[ccexplore]

We may not have enough people here at the moment who've done creating a tileset before (eg. in Cheapo or maybe Lix) to say one way or another.    My guess is that all frames in one graphics file makes it generally easier for people creating and editing the graphics, by not having to potentially open multiple files at the same time.  One potentially disadvantage of the "one file" approach is that if it turns out you need a bigger area for a frame than you originally allotted, you'll likely have to do a lot of moving things around, since the frames are likely placed too close to one another to fit with the new expanded size.  (That said, seems like the user can usually plan things out better beforehand to avoid having to do such resizing.)  Similarly, inserting new frames and re-ordering frames are likely easier with the separate-files approach, though probably not too annoying even with one-file approach.

It's also possible that instead of creating graphics from scratch, the user may try to make use of rips of graphics from other games, which may come in a variety of formats.  With that in mind, being able to support both would be a good thing.

I would also suggest that for the "one file" approach, you devote one color that represents "not part of any graphics of any frames, not even the transparent color", and use that as the basis to scan and find the individual frames in the file, rather than relying on precise spacing and therefore requiring the user to manually and precisely position the frames in the file.  In other words, something like Cheapo's approach basically.

[namida]

I was thinking of the approach of each OBJECT in a seperate file (like how Lemmini has it), with the question being whether individual frames should be seperate files too or combined like in Lemmini. However, your suggestion of doing it Cheapo-style is actually also a very good one, and it shouldn't be overly difficult to implement either. This would even mean, at least to *some* extent, existing Cheapo styles could be ported to Lemmings/Lemmix.

[ccexplore]

Sorry for confusion, I actually was talking about the same two options you have in mind.  I mentioned Cheapo not so much for its ability/requirement of having all objects in one file, but instead simply that its "scanning" approach for frame handling is better than an approach where, say, the program requires the bitmap to be of width N*w where N is number of frames and w is frame width of the object, and thus the user has to manually positioned all their frames in that precise manner.

But yes, actually supporting Cheapo styles is also something to consider.

BTW, do you plan on making the program's source code available as well once you're finished?

[namida]

Parts of it. The program itself no, but the subs and functions to read from Lemmings data files, sure. Written in QB64, which for those who don't know it is basically just a cross-platform (Windows/Mac/Linux/Android) version of QBasic, with some extra functions.

[namida]

It's coming along nicely. I've successfully generated a half-valid GROUNDxO.DAT/VGAGRx.DAT combination - specifically, the terrain and pallete valid but something's glitching in the objects. That being said, the tool's not quite release-ready yet even once that's fixed - everything that goes into the GROUNDxO.dat file, except the stuff that can be acquired from the images, is hardcoded (so number of frames, trigger areas, etc). But it does mean we're getting close.

[namida]

And as proof of concept, here's a small but nonetheless working custom graphic set, along with a level to show it off. =)
EDIT: And a video, for those who want to see it in action but can't/won't download it. http://www.youtube.com/watch?v=dQ8U-6AgnKE" class="bbc_link" target="_blank">http://www.youtube.com/watch?v=dQ8U-6AgnKE

At the moment, both LemEdit and CustLemm throw a fuss at files compressed by my program. T.T However, if I just output the uncompressed data, then use Mindless's program to compress it, it works fine. Interestingly though, Mindless's program can decompress my files just fine (and if I recompress the files that it extracts, LemEdit/CustLemm accept them just fine). ccexplore (or anyone else of course xD), any other details about the compression that might cause this?