Moderator: Graphics Moderators
I don't have any feedback on the project, but I didn't want this thread to pass by with only cricket noises.
It's an impressive thing to have done
Squid Ate FISH (ships) (Released) | CHIPS Has Improved Players' Stations (Finished)
Iron Horse (trains, released) | Termite (tracks for Iron Horse, released) | Busy Bee (game script, released)
Road Hog (road vehicles, released)
Thanks. I really appreciate that.I don't have any feedback on the project, but I didn't want this thread to pass by with only cricket noises.
In fact, I have recently been speaking to wallyweb, who gave it a quick spin, about how to get a little feedback. To this end, I have switched to working in Windows 10 and created a self-contained binary which hopefully people can run without any trouble. I mostly develop embedded firmware, so I'm a bit new to this whole release-online-for-multiple-platforms thing. For some reason I have not yet determined, the Release build (smallish) is unhappy, but the Debug build (largish) is fine: so I have released the larger image... https://github.com/UnicycleBloke/yagl/releases/tag/v0.3. This was built with Visual Studio 2019 for x64 if it matters.
I'm calling this release an Alpha because there are sure to be a ton of little things wrong with it. I'm pretty sure the coverage of the NewGRF specs is complete or very nearly so, including some stuff which I had to find in the OpenTTD source, but I did spot a lacuna just yesterday...
During development, I have focused on reasonably sizeable GRFs such as FIRS in order to get better coverage, but suggest playing with something small at first. In truth, it seems more likely to be useful for the smaller projects which people might be creating in NFO at the moment, but I'm only guessing. I feel confident that it will fall over pretty soon on some silly oversight. Obviously there is not much in the way of documentation: I'm hoping that the YAGL output is at least half-way comprehensible.
Anyway, please give it a whirl and let me know when it goes bang.
Maybe. The particular error code I get seems related to heap corruption. This is not generally a feature of my code, but no one is perfect. I have used shared_ptr and STL containers throughout, and perform no direct resource management. I'll see if I can track it down this evening.undefined behaviour
Right first time: twice incrementing a counter between sequence points in the chunked tile decoder. At least it wasn't too hard to find.jfs wrote:undefined behaviour
This release build executable should work: Please let me know if not.
The repository is at https://github.com/UnicycleBloke/yagl.
Thanks very much.
yagl is a tool for both compiling and decompiling GRFs from and to a new script language, YAGL. This is broadly comparable in function to grfcodec, which compiles and decompiles GRFs from and to NFO. Unlike NML, YAGL is a low level script: there is a direct one-to-one correspondence between blocks in YAGL and the equivalent records in NFO. The difference is that YAGL is intended to be more human readable than NFO, and things like the sizes of structures, lengths of arrays, lengths of strings, and so on are worked out automatically.
My original goal was just to decompile GRFs created with NML to see what was inside them in terms of the low level NewGRF specs, but I got carried away. I think the most likely use case would be to decompile an existing GRF, make a few mods (e.g add or fix some translations, or whatever), and then re-compile. If you have the NML source for the GRF, using nmlc would probably be the better choice. There is no reason why you could not create a whole new GRF written in YAGL, if you were so minded. This would be equivalent to creating a GRF in NFO. The major barrier to this is that I have not yet written any significant documentation. I'm thinking about that... Also yagl does not have any of the linting capabilities that grfcodec does. I'm not sure to what extent they are needed. Adding specific checks for things wouldn't be too hard.
Since yagl has the ability to read and write a GRF into memory, it would in principle be quite simple to read and write NFO too (at lot easier than YAGL was, at any rate). I don't know if that would be useful at all.
Please have a go with it, and let me know how it works out. There are sure to be some bugs. If you simply decompile/recompile your favourite GRF, and then it no longer works in openttd, I'd very much like to know about that. As far as I can tell, all the discrepancies between the before and after GRFs are innocuous.
Base Music Sets: OpenMSX | Scott Joplin Anthology | Traditional Winter Holiday Music | Modern Motion Music
Other Projects: 2CC Trams | Modern Waypoints | Sprite Sandbox & NewGRF Releases | Ideabox | Town Names | Isle of Sodor Scenario | Random Sprite Repository
Misc Topics: My Screenshots | Forgotten NewGRFs | Unfinished Graphics Sets | Stats Shack | RoadTypes?
Users browsing this forum: No registered users and 3 guests