Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

support parsing data from .graal files #12

Open
Aeva opened this issue Dec 13, 2016 · 2 comments
Open

support parsing data from .graal files #12

Aeva opened this issue Dec 13, 2016 · 2 comments
Assignees
@Aeva
Labels
enhancement

Comments

@Aeva
Copy link
Owner

Aeva commented Dec 13, 2016 •
edited
Loading

From poking around with a hex editor, the following is immediately apparent:

  1. the first 8 characters are always GR-V1.03
  2. tile data starts immediately after the version field
  3. the byte size of the entire level file can change if you change a singular tile, so it looks like there is some kind of compression scheme. A completely blank level is 226 bytes. If each tile in the level is different, the level is about ~6.7kb in size.
  4. chr(10) seems to maybe be used as a delimiter.
  5. the last ten bytes or so seem to be garbage (or maybe they're a checksum or section offsets, or something else)?

I found this page, which has some code that claims to be able to decode the level data, but in reading through it, it doesn't seem like it should work at all - only 3 bits are left over in each "code", which is very much not enough space for the actual sprite index. edit they're being clever with loops.

Perhaps the useful take-aways from that link are this:

  1. the format uses some form of run-length encoding scheme
  2. there is an alternating repeat mode
  3. the left-most bit activates repeating, some other bits determine count and how many
  4. the 1.0 version of the file format allotted 12 bits instead of 13bits per "code"

To take a wild guess, I think a plausible version of this is:

  1. read the first packet (12 or 13 bits depending on version)
  2. if the left-most bit is 0, then the remaining bytes describe a tile
  3. otherwise, the remaining bits describe the repeating behavior, and the packet or two are the tiles to be repeated.
Aeva pushed a commit that referenced this issue Dec 13, 2016
Checked in some reference levels.
91824d5 
This relates to issue #12.  I've assembled some reference levels that
can be used to verify the parser (at least for tile data).  This should
also help for adding support for the older ".graal" format.
Aeva pushed a commit that referenced this issue Dec 13, 2016
Checked in some reference levels.
63efbfb 
This relates to issue #12.  I've assembled some reference levels that
can be used to verify the parser (at least for tile data).  This should
also help for adding support for the older ".graal" format.
Aeva pushed a commit that referenced this issue Dec 16, 2016
Rudimentry implementation of a ".graal" parser.
016cd07 
Nothing is hooked up to this, so no exporting to png just yet.  But its
close!

With a test level that doesn't have any repeating tiles as input, the
parser is able to fill out a full board without overflowing, and
correctly identifies the cut off between tile data and other level data.

Levels feature repeating tiles, however, crash.

There is enough here that I could try to hook it up to the image
converter stuff later and see if the output is anywhere near correct.
This might also engender refactoring the nw parser a bit and providing a
common base class between the two.

This relates to issue #12.
Aeva pushed a commit that referenced this issue Dec 17, 2016
Refactored project to be more object-oriented.
978fc28 
There is now a common level class, and an Actor class.  This commit also
moves a lot of scarping functionality off of nw_parser.py into the
common.py module, so that it can be used by other formats.

The two current parsers are not interchangable just yet, but this is
really close to being able to parse the tile data from some .graal
formatted levels.

This, unfortunately introduces a bug, where seteffect images (or maybe
just all npcs) don't show up in the final render.

This relates to issue #5, and to issue #12.
@Aeva
Copy link
Owner Author

Aeva commented Dec 17, 2016 •
edited
Loading

I started refactoring the project so that the .nw and .graal parsers all use a common base class (see issue #5).

I'm going to be continuing development on this in the "refactor" branch now, until it's mature enough to merge back into master. changes have been merged into master.

@Aeva Aeva self-assigned this Dec 17, 2016
Aeva pushed a commit that referenced this issue Dec 17, 2016
DotGraalParser populates board now (buggy).
ca58ef8 
The DotGraalParser now populates its board.  So, now some levels are
renderable with the now inaccurately named nw2png.py script.

This is, however, but close.  The output is wrong, because it assumes
the tile encoding would have something in common with the .nw format,
but copying the four lines for that didn't have the desired effect.

This relates to issue #12.
Aeva pushed a commit that referenced this issue Dec 17, 2016
DotGraalParser board generation seems to be correct now.
0a5e097 
Removed the weird interlacing scheme that NW had, and now test.graal
renders correctly.

Relates to issue #12.
Aeva pushed a commit that referenced this issue Dec 17, 2016
DotGraalParser produces non-bullshit (ish) tile values.
2378163 
It was using the tile index instead of the tile value.  It looked right
for some values :) because the test maps have a similar layout.

This is still wrong, but its less wrong at least.

Relates to issue #12.
@Aeva
Copy link
Owner Author

Aeva commented Dec 17, 2016 •
edited
Loading

The first 32 tiles parsed from the test map looks like this... seems... wrong :|
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 512, 513, 514, 3, 516, 517, 518, 519, 520, 521, 522, 11, 524, 525, 526, 527

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Aeva Aeva

Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@Aeva