Sprite editing, anyone?

[YoloSweggLord]

So I've been thinking about trying to edit the g1.dat file to try to replace/improve some of the in-game sprites (especially the track sprites). @X7123M3-256 did something like this with the steel twister track to turn it into IBox track, but wasn't fully successful. I found a tool called Trigger's Graphics Extractor which allows you to extract all the g1.dat file into .rct2img and .png files. I've played around with scenery and ride creators enough to understand the basic design of sprites in RCT2, but I still have a ways to go until I completely understand the process. So I thought maybe I would try to see if anyone else wanted to get on board. Here's a list of things I have yet to figure out:

• Creating the image files in the correct format (this could probably be accomplished with something like the RCT2 Object Editor (available from nedesign.com's utilities section, I haven't found the "original" location of its release))
• Coding the image files to have the correct recolorability (this would be automatically be done if we used the aforementioned method of using something like RCT2 Object Editor)
• "Re-packing" the g1.dat file with the edited sprites

I'm thinking this would be a lot easier if we could get together a group of people with a bit of knowledge about RCT2 files. So if any of you know a bit about RCT2 files and want to try this out, please let me know. We could collaborate using something like Onedrive or Google Docs. If we can get a decent amount of people willing to participate, we could do some pretty amazing stuff.

Also @X7123M3-256 if you still have those IBox sprite files, could you give me a copy? We could try finishing up the uncompleted sprites (from what I've managed to figure out you had problems with some of the turn sprites), and they'd be a useful example for us to follow if we could study them.

[X7123M3-256]

11 hours ago, YoloSweggLord said:

Creating the image files in the correct format (this could probably be accomplished with something like the RCT2 Object Editor (available from nedesign.com's utilities section, I haven't found the "original" location of its release))

I don't think the object editor can edit g1.dat, it is, as the name suggests, meant for editing object files. The images themselves are in the same format, but object files contain a lot of additional data on top of that. Also, some g1.dat sprites use several flags not used in object files, so a loader for object files may not be able to handle them correctly (mine did not, and I only found out what was wrong fairly recently). I am not sure if Trigger's Graphics Extractor can modify the file either, but it's something that could probably be added if you wanted to do that.

 

11 hours ago, YoloSweggLord said:

Coding the image files to have the correct recolorability (this would be automatically be done if we used the aforementioned method of using something like RCT2 Object Editor)

The way recolorability is handled is that certain palette indices are marked recolorable - wherever those colors appear, they can be substituted for another according to a lookup table that I can post here if you want. The primary two remap colors are always remapped and never show up in the game, while the third set of remap colors doubles as the yellow pixels. Usually, there are flags to set on the object to enable each remap color, but not in g1.dat - it is sufficient to use the correct palette indices.

 

11 hours ago, YoloSweggLord said:

Also @X7123M3-256 if you still have those IBox sprite files, could you give me a copy? We could try finishing up the uncompleted sprites (from what I've managed to figure out you had problems with some of the turn sprites), and they'd be a useful example for us to follow if we could study them.

Here's a dump of all files associated with that project. This includes the modified g1.dat and the code used to generate it. Be aware that this will break your terrain sprites, because they are missing a field I did not know was required. I know how to fix it now, but this code is unchanged from what I had when I did this originally. Do back up your original g1.dat somewhere before trying this out.

[YoloSweggLord]

Thank you for all the advice you've given me on this, and also for the files. I've looked through them and, I have to say, they look a bit complicated, but I'm already looking at the files, particularly the generation code.

[X7123M3-256]

If I revisit this project I'd likely take a different approach to the sprite generation. For those sprites, I extruded a 2D cross section of the track shape along the shape of the track. It works for relatively simple tracks, but doesn't generalize well. A better approach would be to start with a full 3D model of a straight section of track and transform it to match the desired track profile. Another issue is the splitting of the sprites - that code assumes it's one sprite per tile, like for large scenery, but I know now that that's not the case - track pieces have their own draw logic. I don't fully understand what that is yet.

[YoloSweggLord]

Yes, I was a bit confused by the separate sprites as well.

[RobWhlkRT12P]

How about storing the objects at someplace online, like Google Drive or GitHub?!  I already have an area on GitHub set up for OpenRCT2.

 

[X7123M3-256]

5 hours ago, RobWhlkRT12P said:

How about storing the objects at someplace online, like Google Drive or GitHub?!  I already have an area on GitHub set up for OpenRCT2.

If you're referring to the sprites I linked above, that project is obsolete. Since OpenRCT2 is now entirely independent of vanilla code, it's now possible to add new track sprites in g2.dat rather than replacing existing sprites, so that's what I do now. I also have a new track renderer that's more flexible and less glitchy.