Well, I already have the base code for a tile-based editor, so all I needed to do was adjust the CoordsToAddress function, and implement the PLY reading, which took most of the time.
Not exactly... This only changes the floor layout (the flat area along the bottom of all courses except Radiant Emerald).
Wow, impressive. So, you could technically just do all that but byteswapped for the Saturn ISO (the tile editing for the floor, that is)?
Heh, tried to edit the levels with hex a while ago without knowing which tile what was. Thanks, that'll be helpful!
I don't know if the byteswapping would apply to these files. It generally only makes a difference when dealing with values larger than one byte. The map files store tiles as one byte, and the ply files store colors in RGB format, but I would have to look at the files to know for sure. If you have a cd/iso, try opening a map file (if there are any) with this. Also, I was able to use Cheat Engine with this (not very well), and I found: 8FB8EC - Course 8FD50C - Rings 8FD5E6 - Character 8FD6D4 - Character Model+Animations
Kinda annoying to browse through all tiles with just seing one at a time. Make it more like SonED, so you can see a few of the next and the past tiles please. Besides that, of course, awesome job!
New program! RAW2BMP is exactly what it sounds like, it converts raw files to bitmap files (only bmp files by design). However, it also converts bitmaps (png/gif/jpg should also work) to raw files. Something important to note is that you can convert any size bitmap to a raw file (it will warn you if it doesn't match a known size), but you can only convert raw files to bitmaps if they match the sizes listed here or are a ply file. There are at least 20 different ways I could convert any given raw file to a bitmap, but only one way to convert a bitmap to raw. You can download it here. This will save you from having to remember all the sizes and mess with the raw import dialog. There's really no way to prove it works with a picture, but I converted ruin\parallax\_r.raw to a bmp and back to a raw and it was identical to the original.
IDA is [The] Interactive DisAssembler, and for some reason, unless you run Sonic R with this as the debugger, it won't accept input.
According to the video that I saw it's some sort of processor clock speed check; if your computer is too fast then it'll basically produce a divide-by-zero error because, if I have this correct, it keeps calling the time and checks the time difference between instruction calls for finding the processor speed -- divide the number of instructions by the time they took to be processed. Obviously if the time interval is too small that's how the divide-by-zero error comes up. http://www.youtube.com/watch?v=baJhaDuJlZA Using a breakpoint artificially changes the result for the time-check function so the game can run. Could easily be fixed by, say, adding one to the time before doing the division. :P
You said "for some reason" and to my knowledge that is the reason -- the two errors seem to be tied to each other, considering that all that's been done is a breakpoint has been added in the machine code. EDIT: I just tried running it with Fusion in turbo mode in the background. I got some sort of Direct3D Init error, something about the application not being able to use exclusive mode. EDIT2: That might have been because S&K Collection was still running in the background? EDIT3: The message is "Unable to create primary surface: Operation requires the application to have exclusive mode but the application does not have exclusive mode." This means I probably can't overdrive fusion as a processor instruction limiter. Bummer.
