7 thoughts on “Hi-Octane (1995) Level Inspector and Editor”
Wolf Alexander
Thank you very much for your response, I will gladly keep you updated 🙂 I am very sorry but I have to correct my information already, I should have not only tested the idea with the texture tile IDs in the first level where it worked well. In the second level already I saw that at the shield charger place the green shield charger tiles are not present. Therefore please forget my idea. It must be something else, I hope I will find out in the near future. I am happy that other people also share my interest in this specific game.
Some time ago I already spent quite some time trying to disassemble the game exe file in IDA Pro. I know I have good valid assembly code, and together with DosBox in Debugging mode and by setting breakpoints and stepping I was able to identify some routines in the assembly, for example I know where the Sky is drawn, the Rendering of Triangles occurs, where the HUD is drawn etc. But I almost gave up because for the time invested I almost got no return. Its just a big pointer mess, jumps where the final address depends on other variables, switch case jump tables with 57 different jump options, ... But maybe with a lot of patience one day I can figure it out. It just feels its easier and more rewarding to just try to reproduce it kind of with own source code and ideas. I would really like to know how it was possible for you to figure out the file formats. I tried to figure out how I can read the game supplied 3D Model files, but I still did not succeed.
Besides IDA you can try the reko decompiler (https://github.com/uxmal/reko) which produces C code and supports DOS executables - makes it a little easier.
For this project we almost exclusively just looked at the hex values of the data files and tried to make sense of everything step by step. The binary file formats back then were all very simple and from previous reverse engineering projects we've learned a lot in that regard. I don't remember the details of the 3D model file format right now but I remember that the 3 component vectors for vertices are in there just as you would expect.
I've developed a little tool to inspect binary files, much like a hex editor but with formatting and comment features (https://blog.thrill-project.com/binmap/) that I used extensively on this project - but srtuss did most of the work on these files.
Thank you very much for your great work on the reverse engineering and documentation of one of my most favorite game of all times. I still remember when I first saw Hi-Octane running on a 80486 from someone else during a visit. The graphics blew my mind back in the day 🙂 I always hoped I can understand the game better, and try to recreate it, but I was lacking the reverse engineering skills. Thanks to your work I am finally able to understand the game mechanics and data formats good enough so that I am able to try to recreate it myself. Its a slow process, but also a lot of fun. One note: You wrote you are not sure where the positions of the fuel, ammo and shield chargers are in the level file. Same goes with the player start locations. I believe the game simply looks at the Terrain tile Texture ID values, and then searches/knows where all of the stuff is. At least thats what I implemented for the charging stations, and it works well. Keep up the great work!
Thank you for your comment and for sharing your idea about the different locations - sounds very coherent to me and if it works as you said, we can close this chapter 🙂
Have fun and keep me updated on your remake!
Wolf Alexander
Thank you very much for your response, I will gladly keep you updated 🙂 I am very sorry but I have to correct my information already, I should have not only tested the idea with the texture tile IDs in the first level where it worked well. In the second level already I saw that at the shield charger place the green shield charger tiles are not present. Therefore please forget my idea. It must be something else, I hope I will find out in the near future. I am happy that other people also share my interest in this specific game.
movAX13h
Post authorAh right, I see, haha 🙂
I think it's possible that they hard-coded the locations in the code for each level, but I have no proof of this.
Wolf Alexander
Some time ago I already spent quite some time trying to disassemble the game exe file in IDA Pro. I know I have good valid assembly code, and together with DosBox in Debugging mode and by setting breakpoints and stepping I was able to identify some routines in the assembly, for example I know where the Sky is drawn, the Rendering of Triangles occurs, where the HUD is drawn etc. But I almost gave up because for the time invested I almost got no return. Its just a big pointer mess, jumps where the final address depends on other variables, switch case jump tables with 57 different jump options, ... But maybe with a lot of patience one day I can figure it out. It just feels its easier and more rewarding to just try to reproduce it kind of with own source code and ideas. I would really like to know how it was possible for you to figure out the file formats. I tried to figure out how I can read the game supplied 3D Model files, but I still did not succeed.
movAX13h
Post authorBesides IDA you can try the reko decompiler (https://github.com/uxmal/reko) which produces C code and supports DOS executables - makes it a little easier.
For this project we almost exclusively just looked at the hex values of the data files and tried to make sense of everything step by step. The binary file formats back then were all very simple and from previous reverse engineering projects we've learned a lot in that regard. I don't remember the details of the 3D model file format right now but I remember that the 3 component vectors for vertices are in there just as you would expect.
I've developed a little tool to inspect binary files, much like a hex editor but with formatting and comment features (https://blog.thrill-project.com/binmap/) that I used extensively on this project - but srtuss did most of the work on these files.
movAX13h
Post authorThe class that reads the 3D model files is not part of the Inspector or Editor but a separate project: https://github.com/movAX13h/HiOctaneTools/blob/master/ObjectsConverter/ObjectDatFile.cs
My converter (to wavefront obj) does not handle UVs and also does not calculate normals but srtuss has a tool for it.
Wolf Alexander
Thank you very much for your great work on the reverse engineering and documentation of one of my most favorite game of all times. I still remember when I first saw Hi-Octane running on a 80486 from someone else during a visit. The graphics blew my mind back in the day 🙂 I always hoped I can understand the game better, and try to recreate it, but I was lacking the reverse engineering skills. Thanks to your work I am finally able to understand the game mechanics and data formats good enough so that I am able to try to recreate it myself. Its a slow process, but also a lot of fun. One note: You wrote you are not sure where the positions of the fuel, ammo and shield chargers are in the level file. Same goes with the player start locations. I believe the game simply looks at the Terrain tile Texture ID values, and then searches/knows where all of the stuff is. At least thats what I implemented for the charging stations, and it works well. Keep up the great work!
movAX13h
Post authorThank you for your comment and for sharing your idea about the different locations - sounds very coherent to me and if it works as you said, we can close this chapter 🙂
Have fun and keep me updated on your remake!