Has anyone yet made a tool to extract/remake VGAGR files?

[namida]

(By this, I mean extract/remake the actual graphics pieces from the uncompressed data, not to compress/decompress the VGAGR files themself)

I know the format is known and documented (and, apart from compression, is relatively straightforward), but wondering if any actual tool had been made yet?

[Mr. K]

I thought there was, but I might be wrong.  Maybe it was just for the VGASPEC files...

[namida]

Yeah, there's one for VGASPEC, as well as Lemmix having a built-in ability to do it.

[ccexplore]

I'm not aware of any, certainly nothing for remaking VGAGRx files.

Of course, now that you're proficient with making source code changes to LemmixPlayer, perhaps you can think about actually changing LemmixPlayer itself so that it can accept a different format than VGAGRx/groundXo files.  A format that simply takes one text file and a set of bitmaps (similar to how Cheapo styles are defined) would be much easier to remake than VGAGRx.

I'm also curious what you plan to do that would require extracting/remaking VGAGRx files?

[namida]

No plans really, was just curious.

Modifying the Lemmix player would indeed be simpler in terms of formats, but it would mean incompatibility with the Lemmix editor (unless that too was modified) and LemEdit, as well as the original version of the game.

[Simon]

Both Lemmix and L++ have code that takes VGAGRx/GROUNDxO files and makes bitmaps and spritesheets for internal use. Neither has code that takes bitmap files and make L1-compatible files other than VGASPEC from them.

I have a zip archive with all the graphics from all L1, ONML and Holiday 94 styles somewhere, if you just need the sprites and not a standalone tool to extract them. They're in double resolution though, each pixel of the original graphic is a 2x2 block in these files. Making a standalone extractor should cost me a few hours <_<

-- Simon

[ccexplore]

Modifying the Lemmix player would indeed be simpler in terms of formats, but it would mean incompatibility with the Lemmix editor (unless that too was modified) and LemEdit, as well as the original version of the game.

Hmm, that's a fair point.

Unfortunately I'm simply too overworked these days to do much Lemmings-related.  Making a minimal program that can remake VGAGRx/GROUNDxO from:

  a) a set of bitmaps
  b) a palette bitmap you have to provide (else the program starts getting not-so-minimal )
  c) some miscellaneous data from text file, mainly for trap trigger areas

is really not too difficult, now that I think about it.

[namida]

I could possibly put one together... a question though... I think I get the idea of the planar bitmap, but does Lemmings pad the bitmaps out in any way?

[ccexplore]

No padding; however, because the planar format implies 8 horizontal pixels in a byte, all bitmaps will naturally need to have a width that's a multiple of 8 pixels.  This means you'd need to pad out any bitmaps with non-conforming widths (either as a requirement on the user, or do it in the program).

Actually, I just remember something:  I believe at some point when I was writing myvgaspec.exe, I toyed with the idea (because Lemmix didn't exist at the time, and LemEdit doesn't support VGASPEC levels) of making VGASPEC levels viewable in LemEdit via a custom VGAGRx, where the "terrain pieces" are basically just the whole 960x160 VGASPEC bitmap carved out into 60 64x40 bitmaps in a 15x4 grid.  Position the terrain pieces correspondingly in the LVL data, and you can view and edit your VGASPEC level in LemEdit!

This idea soon became obsolete with the emergence of Lemmix (which finally allows proper viewing and editing of VGASPEC levels), but one thing I remember out of that attempt was that the VGAGRx file (compressed) needs to be below a certain size, or you'll get strange graphical glitches in CustLemm/DOS Lemmings.  It's not clear what that maximize size is.  The point is that you want a really good compression algorithm on the VGAGRx data, though fortunately I think Mindless's tool for compression is excellent in that regard.

[namida]

I see. No such restrictions on vertical size, though?

Also, while looking around at it, I found that the gap between frames did have a value on the exit in Style 0, which only has one frame... any point to this or is it just random meaningless data? (Unless of course I was reading it wrong... I didn't use any tools apart from Mindless's decompressor, just trying to manually interpret the data from a hex editor)

[ccexplore]

Yeah, no restrictions on vertical sizes.

It's been ages, but if I recall correctly, my understanding of the groundXo data and how it relates to VGAGRx is based on disassembly of the Lemmings game code, so data in the gap is probably not relevant (unless it's due to a misreading on your part).  Since I never actually wrote any programs to examine the data in detail, I'm in fact not even aware of such gaps.  It could potentially be graphics that were created during game development but never used, who knows.

One thing you may want to confirm is whether you're working on the right section in the VGAGRx file.  That file has 2 sections and I don't remember off top of my head which is which, and more importantly, I'm not 100% positive whether I had it correct (ie. which section I said is for terrain vs object graphics) in the various documentation I may have released on the VGAGRx format.  It may be worthwhile to try to confirm your understanding of the format by first writing an extractor program, backwards as it may sound.  [edit: actually better idea--instead of writing your own extractor program, you can simply check with LemmixPlayer's source code to confirm that what it's doing matches your understanding of the format]

[namida]

I hadn't even looked in the file yet - it was that, the size the data should be based on the GROUND file, didn't match what it should be based on the object's dimensions.

[ccexplore]

Did you use the correct byte ordering when reading WORDs (2-byte integers) in GROUND files?  PC Lemming's GROUND files follow x86's "little-endian" convention, which means a hex value like 0x1234 (decimal 4660) will be stored in bytes as 0x34 followed by 0x12.

Also make sure you have the correct number of planes.  Unlike vgaspec whose format uses 3 planes, if I recall correctly VGAGRx graphics uses 4 planes if I recall.

[namida]

Yep. 4-plane, little endian. I'll check again when I can, in case I did read it wrong. I don't think it even matters that much with single-frame objects, I didn't have enough time to check the multi-frame ones.

[ccexplore]

Then maybe there are indeed gaps after all I guess.  Apparently I even said that might be possible in my own documentation.

In the meanwhile, you can gain better confidence whether you're right or not by either comparing with LemmixPlayer source code, or try writing your own extractor (hint: at this stage you don't even to actually output a bitmap file, you can just pick object #0's 1st frame to extract, and simply print out in ASCII which pixels are black and which aren't, like this:

Code: [Select]

X   X
 X X
  X
)

[edit: or, you can pick a random horizontal segment of 8 consecutive pixels in the exit graphics (ie. make a screenshot of it from Lemmix editor or something and then examine the pixels in MS Paint, say), with some pixels same color while others different, and calculate to find the 4 bytes in the data that should define the 8 pixels.  Look up the values in a hex editor, convert to binary, de-plane, and see if the pixel values match the pattern of pixel colors.  Repeat as necessary with different pixels in the graphics to increase confidence further.]