SVG Levels

[assertivist]

Transition from using PICT resources to SVG drawings, establishing a feature parity between the two formats. This will enable level diffs, better editing, easier hashing, and brings us one step closer to not requiring the original resource forks.

[assertivist]

I actually have this working somewhat:

• Converter has edge cases with embedded bitmap data that sometimes cause it to fail export of certain PICTs (not incredibly worried about this one, its less than 1% of imported levels so far)
• Need to clean up the python script that pulls this off, reconcile it with the existing converter code and combine with BSP export, streamline and add a Makefile step for running it against everything in the levels/ directory
• Establish a file structure/hierarchy for storing level files, LEDI information, BSPs etc. and loading these files instead of data from the resource forks
• Perhaps most importantly, establish testing coverage that confirms SVG translations and the original PICT resources provide the same game world as output

[assertivist]

Dan added hsnd2wav, which allows us to export sounds from resources using the same code the game does.

currently the level files are in levels/<set_file>.r

my proposed format is as follows:

levels/set_name/
│   ledi.json
│   hull.json
└───bsp/
│   │    100.json
│   │    ...
│   hsnd.json
└───hsnd/
│   │   100.wav
│   │   ...
└───svg/
│   │   1000.svg
│   │   ...
│   text.json

where the json files are sort of mapping files that contain the same data from the resource forks of the same name but updated to point at the new svg, json, and wav files.

[assertivist]

I did some research at replacing the arc segment concept with something a little easier to deal with, simple line segments. Basically you can have a line segment, with a start and end, with decorations that show the start and end in the drawing. This would allow us to do away with arc segments that are complicated to deal with and not very intuitive to people that haven't made Avara levels before.

The problem with this is that Inkscape will make lines relative to the pen position to save space in the SVG, as well as the necessary decorations having templates in the header of the svg, which means that the parser must also read the decorations header in order to read out which portion of the line is the start point.

[assertivist]

We've updated the PICT parsing, and I've ported those fixes to the converter. There are still edge case levels we are seeing that have issues, specifically Hazel's entries in T Plus 5, but older levels as well (Data Path in net-99 for example).

The converter exports these, but...

Still some stuff going on. state problem causing lines to get drawn when it should just be moving the pen?

Other than those though, the coverage of the converter being able to export some kind of SVG is pretty good. I think the remaining problems are things like doing line breaks correctly for different styles, and probably some other things i haven't seen yet with PICTs from alternate editors, which hopefully shouldn't be so vastly different that it can't be accounted for easily.

[dcwatson]

We did transition away from PICT, but to our own XML-based ALF instead of SVG.