Regarding Graphics - www.ezboard.com

Re: Regarding Graphics

Heh. I'll give you a hint that might get you started. Notice how the csg1i.dat file length is divisible by 16. This file is made up of 16-byte entries (structures). The first 4 bytes of each structure are offsets into the csg1.dat file. Not all of these pointers point to graphic elements (sprites), but a lot of them do. For instance, element number 57,090 points to a piece of the pyramid scenery. The 5th and 6th byte are a WORD that represents the width of the sprite. The 7th and 8th bytes are the height.

Remember where you got this information! You saw it here first. I don't want to see somebody else claiming they figured it out by themselves in the future. In particular, DoctorJ you are welcome to use this information on your site.

The sprites are not stored as bitmaps. You will, however, have to understand the structure of a bitmap, both in memory and how they are stored in files on disk in order to make use of the information. The bytes pointed to in the csg1.dat file are a table of pointers followed by data "chunks". Each pointer in the table points to a chunk. The first pointer points to the first chunk, naturally, and everything up to that first chunk data byte are pointers. The chunks themselves contain a 2 byte vector followed by bytes of data. The data bytes each represent an index into a 256-color palette. The 2-byte vector represents the length and position of the data bytes on the scan line. Each scan line in the bitmap is flagged with the high-order bit of one of the length bytes. Pixels not covered by any color data are transparent.

That should be enough to get you going. Look around and you'll figure it out. Sometimes I wonder, though. It didn't take a lot of brain cells to figure out what the general layout of the csg1i.dat file was and it surprises me that nobody else even came up with THAT. I leave it up to you to figure out where the palette information is. HINT: it's a regular windoze bitmap indexed palette.

Henry Winkelstein

P.S.

The "new" information on the track files was originally figured out by ME last summer. Others have expanded on it since then, but the initial discovery about the RLE encoding and the first extraction of practical information from the track data files was my doing. It's not "new" at all, although some good work has been done by others in utilizing that information to make some nice utilities.

Henry Winkelstein

P.P.S

RCT checks the size and timestamp of the csg1.dat file. So if you replace any graphics in it you have to take steps to make sure those are preserved. Either that or patch rct.exe to circumvent that check. This check is NOT new anti-cheat code in the add-on pack. The original RCT did this also.

Henry Winkelstein

Re: csg1.dat

I've replaced graphics in csg1.dat before and the game always loaded and displayed them. I didn't know there was a time stamp check but it didn't seem to keep the graphics I changed from being loaded.

Techno

Re: csg1.dat

You could be right. I haven't really looked at that recently but I know I've seen it referenced somewhere. The date/time/size might be stored in sc.idx and/or css0.dat. I'll double check tomorrow and see what really happens there.

Techno, I'm telling you - trainer/game hacking book. The masses cry out for it! Check out http://www.gamedev.net/community/forums/forum.asp?forum_id=13&forum_title=Isometric+Land and look at the topics for the last 30 days. The moderator there, TANSTAAFL, is writing a book on Isometric game programming and I bet it will be a big seller. RCT uses an Isometric game engine and I found some useful material there for the editor I'm doing. There's a lot of noise in that forum and a lot of half-baked tutorials if you look around but there is some good stuff in some of the links. Not a lot of useful code, though, so I'm still rolling my own.

You've done trainers for other games. I've only done RCT. You would have a better idea than me about how much demand there might be for some of our programming secrets. It seems to me like a lot of younger people would like to get their feet wet with this sort of thing, and game hacking is much better than the kind done by script kiddies and other malicious types. It's legal, challenging, educational and fun too! What could be better than that?

Henry Winkelstein

Re: csg1.dat

I only looked at the csg1.dat file once before to see if the game graphics could be changed and the ones I came across were the icons, which I was able to change.

Using your information above I made a small utility today to view the graphics just to see what else was in there. Most of the data seemed to be in the format you described although some were stored "whole". Offset 0x0C of the 16 byte structures in csg1i.dat seemed to identify this, although I haven't had time to look at it fully. There's some things I must be missing though as not all the bitmaps are displayed right, though all the ones with a 1 or 5 in offset 0x0C are. You did a good job figuring all this out.

I checked out GameDev. Tile based maps have always interested me, as well as isometric views. I'm looking forward to seeing what you come up with for your edit

Techno

Re: csg1.dat

Thanks for sharing this information, Henry. I will include it on my site in the near future. I have been asked about this by several folks but I haven't looked at the csg files anymore than assuming that " csg" stands for " Chris Sawyer Graphics", (and that " css" stands for " Chris Sawyer Sound")

The reason I started my site was that several months ago, someone asked you if you could make public your information on the game's data structures. You refused at that time and someone speculated that your information may be built into your software or simply not in a form amenable for publication. I wanted to collect similar information and, considering those speculations, decided then that I should put the information in html format. Luke pointed me to his site where he had JW's (your dear friend!) post which described the TD4 structure as well as "annonymous"'s post about RLE encoding.

Incidentally, I determined the "first" checksum method by building a very long coaster which was truncated in TD4 format. The last several track elements were brakes so that I could change the speed and thereby change individual bytes of the file. This allowed me to work out the check sum method. It seemed like such a silly method that I then researched on deja.com and found that it had been determined and published long ago by "annonymous". I had wasted so much time! At least it told me the final number to add for the SV4 files!

I want to continue making public whatever I can determine about the save file data structures (including the "second" cehcksum which is also described at my site). Many people have helped in this endeavor. It's a shame that you and JW are at each other's throats; I have tried to stay out of it! There is a benifit to public dialog. During a chat, someone asked me if it was possible to change vehicle type on a ride. I had had the ability to do that for several months but had never had the idea. I tried it (during the chat) and it worked! Techno has implemented such a feature in his latest trainer and now everybody is having more fun ( Except Chris Sawyer who is now busy making code to check for altered vehicle type!)

Sorry for the long ramble but you and I have not communicated about these things before. Once again, thanks for sharing the information about the csg file structure.

Doctor J

Visit the RCT Tech Info Depot

Re: csg1.dat

That's OK, Dr. J. For awhile I thought you *were* JW but since then I've learned that you are a real bonafide M.D. so that notion has been thouroughly discarded. Nice to see a physician still having fun without all the arrogance and pretensions that I'm sure your friends at the AMA will try to convince you to display :-)

I'm not really all that much at odds with JW. It's more of a teacher/student relationship in my view where the student won't or can't do his own homework. That's a long story and would be a waste of time and energy to rehash it. I'll let that sleeping dog lie.

Henry Winkelstein

Hey techno

Can I have your program that views the RCT graphics? I would write my own, except that I dont know how to change the palette to the correct one in windows. That and I say, why reinvent the wheel?
Please send it to jonwil@tpgi.com.au, I would really like it, especially if it has a way to save a graphic, I want the graphics for some stuff for something I am working on (not related to RCT).

and if you feel like giving me the source code that would be nice

There is one thing I dont understand...

I dont understand this vector at the start of each line, what exactly do I do to each of the bytes to get the length and start values?

Re: There is one thing I dont understand...

I would rather not give out the program as I used Henry's info to make it, and if he wanted one released he would have done so. Its only a viewer anyway, no way to save or change the graphics so it wouldn't do you much good.

The vector is the offset(1 byte) and length(1 byte) of the pixels to plot for each line. The first byte can be ANDed with 0x7F to get the actual value. The high bit is set if the data ends the scan line, if its zero then another vector and more data follows that goes on the same scan line. Not all graphics in the file are stored in this format though.

Techno

I think I have it...

I have a ripper that I will send to anyone who wants it (ftp.xoom.com is stuffed so I cant upload it )
It rips type 1 and 5 images. Does anyone know what the other types are for? Also where do I get the palette from? I cant find it in any of the data files, I am just using a palette grabed from a screenshot, there is probobly one in csg1.dat somewhere but where?