|
Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes
|
Well messiaen, that sure lit up a fire under my ass to get me to work on TT64 
So I worked on it tonight. I finished the integration of the new scrolling field widget in the interface. I've added the code to deal with what happens if you re-import an obj file with additional or different material names. In that case, materials that didn't have any parameters saved in the level file will simply get default parameters.
At this point, the main thing missing is dealing with custom sky background for imported levels. I'm still not sure how present it in the interface.
Another thing that's left to be done is the "keep existing objects from ROM" option. This option would keep the 0x24 objects (as well as 0x26 warps, 0x36 Music track and 0x31 Terrain type) that are currently in the ROM level slot when a level is re-saved to the ROM. I also wanted to have a "Use objects from level file" option where objects previously saved in the level file would be used instead.
Aside from that, there not that much left... Maybe some error checking, and an interface to warn the users that the ROM will be re-extended and patched if they want to use the importer. And then it will be mainly debugging.
Originally posted by messiaen
I'm having trouble with some trivial things. First, when converting the floats in the .obj file to shorts, I just multiply it by a random scaling number in the hopes of not losing too much precision. Is this how you do it? It seems to be working. To deal with texture coordinates, I multiply "vt" values by the same scaling number and then by * 32, which will move the number 5 bits to the left to get the appropriate float format. Not sure how well it works, I haven't found yet a triangle-only nice .obj file with vexture coordinates.
For vertices coordinates, I normalize them by dividing them by the biggest value (so that the maximum value becomes 1.0), then multiply by the scaling factor. For texture coordinates, I have a 10.5 float conversion function, but I'm still not sure about the scaling of those textures, if the number is too big or too small, I get texture glitches.
Originally posted by messiaen
Since any kind of vertex cache optimization is beyond the reach of this proof-of-concept crappy importer, I have come up with an alternate optimization method for display lists. The vertex cache is always set to that the triangles will be always 1/2/3 4/5/6 7/8/9 10/11/12 13/14/15. Instead of writting this tons of 0xBF triangles, I just call an "master" display list using the 0x06 jump command. Hacky but works .
That's a nice idea which could save a lot of space. But what I was wondering is, would it make it faster? I assume that the drawing list commands are read each frame? If yes, then I guess that about the same number of commands would have to be read with your optimization method. I may implement it eventually even if it's only to save ROM space, but for now I don't want to mess up with my importer code since it does work nicely.
Originally posted by vinnyboiler
Vl-Tone if you don't want people to loose intrest you could release a few OBJ's as levels. That would really get alot of intrest in your work. It dose not have to be master peices heck you could even just realese some of the old SM64 rom files cramming your laptop as patches.
Please
I guess I could do that, but that would only increase the hype, and the number of people asking "when are you gonna release version 0.6?".
____________________
|
  |
|
|