For the second relative x and y coordinates, just multiply the value by two, and make it signed. which oddly enoough is what seems to work. This transforms the value's range from 512 if the 2nd most significant bit is a 1, to make the value signed. For first relative x and y coordinates, move the most significant bit to the place of the least significant bit, multiply the thing by two, and subtract How do I use these? Tried all I can think of! D: ZBits = (absZ2 > 6) // Controls terrain type NumTris = buffer_read(buffer, buffer_u32) Var buffer = buffer_load("CollisionData.cld") This is my current code for importing the model in GameMaker, in GML(GameMaker Language): I have been struggling with it for more than two whole days with no progress, and am getting rather frustrated. It might be that I've just somehow found a way to use the triangle data that works almost perfectly, but that I'm doing something very, very wrong. I have successfully imported the whole collision model into GameMaker, where I've rendered it like this, with the face color decided by the triangle's position in the list(from black to white): As you see, though there are cracks between the triangles, because I haven't yet figured out exactly how to use the mysterious pair of 2-bit values. Through a good deal of trial and error, I was able to move around the individual invisible collision model triangles, and have Spyro seemingly stand in thin air as you can see here:ġ: xxxx xxxx] | 8 bits for the least significant part of the absolute x coordinateĢ: | 8 bits for the least significant part of the absolute y coordinateĦ: | 8 bits for the least significant part of the absolute z coordinateġ0: [zz zzzz | 2 bits for terrain type, and then 6 bits for the most significant part of absolute z coordinateġ1: | 8 bits for the first relative z coordinateġ2: | 8 bits for the second relative z coordinate When I had done this, I tried randomly changing different values to see if anything happened. Using the Playstation Emulation Cheater,, I was with relative ease able to isolate the game memory values that change when, and only when, the bridge in Skelos Badlands is unfolded. I'm playing with the NTSC/US version of Spyro 2, and so far I've almost solely been focusing on Skelos Badlands, since it's there I've made the most progress, and the data is placed slightly differently in different levels. It would be so very fun to be able to both retexture and remodel the levels and create practically completely new levels, so I decided to see if I could find this other mesh and how it worked. I played with it a bit myself(and it's source code), to find that it also was very possible to move the terrain around, though only the visible model, since the level terrain model that Spyro collides with is slightly different to the one that is drawn and is visible, and is found elsewhere in the game memory. The idea is based on the texture hacking made possible with LXShadow's SpyroEdit. I've decided to make a topic about it to have somewhere to write my discoveries and struggles down, and in case some might find it interesting or perhaps would want to contribute. For about a week now, I've been trying to both understand the level collision system, and extract the data from the game.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |