Hello, I've been obsessively hacking on Tr64GL for the last week and have cleaned alot of stuff up....
There was a bug with an assignment in a conditional as in if (foo = bar) instead of if(foo==bar)...
I cleaned up all the warnings...
I noticed that there are two seperate implementations of the matrices, one in the register file and the other in math.c....
I'm now trying to get it to run using only the OpenGL Projection matrix, no luck yet. =\
KEY QUESTION: DOES TR64 STORE MATRICES IN C ORDER OR OGL ORDER??? (row major or column major?)
Are vector-matrix multiplies done on rows or columns?
-- You really should go to great lengths to avoid custom code where commonly available libraries exist. Libararies may be slow now but they'll have fewer bugs, be more robust, and over time they'll be tweaked to take advantage of new hardware and methods.
I've done many cleanups across the board.
Another tweak I've found is that the code, in a number of places, copies color variables into a temporary vector to be passed to some other function.
Guess what? C always lays out structures the way you write them, so the g, b, and a variables are layed out in memory just as they are written. -- all you need to do is send it a pointer to red. -- it works great!! =P
Another major speedup is to allow the compiler to use the full instruction set instead of only the position independant subset of it. Plugins are never used in a configuration where position independant code is a benefit. -- remove "-fPIC" from the makefiles. It appears to be a myth in the plugin developer community that shared libraries MUST be position independant.
Current issues:
Zelda: OoT ###
Stone walls and the Death Mountain trail is translucent. =\
Some of the fixed-perspective models in the city are completely untextured.
Zelda: M's M ###
Unrecongnised opcodes 0x09 and 0x0A in the introduction scene... I don't know what they do, I copied uc00's code for 0x09 but it doesn't appear to be doing anything.
Your version crashed when moving between complex scenes, most notably, trying to enter the witch's hut would usually crash it.
My version doesn't generally have that problem but it tends to crash in an extremely unpredictable manner with no visual clues as to what's going foobar. -- ddd/gdb indicates the crash is in the main interpreter loop not in the plugin, maybe something in VM memory is being hosed by my changes...
While it may seem faster to manually inline everything, it is much easier to maintain code that is seperated out and use the inline directive to tell the compiler to do inlining.
Missing polygons, esp in the second chamber of Snowhead, entire floor is missing.
Clipping is broken... If you look at a partially transparent texture from the right, you see only the raw background (usually sky), but from the left it displays some partial version of what should be behind it .
Alpha values are broken, (at least in my version), there is no masking of the backgrounds of things like hearts and magic decanters. There seemed to be some bugs in the texture combining routine, I went thorugh that and made sure that everything seemed to match up to its description.
The 32-bit texture decompression for the title logo has issues, I was able to clean up the texture copy routine a little but I havn't found the decompressor yet.
It seems plausable that you can parameterize OGL enough that it will accept vertex arrays streight from the core memory without any need to go through a lengthy unpacking process.
At least one of the files linked into the binary serves no function, the finished binary is probably more cachable (more efficient) with it removed.
Also in M's M, all the textures in the pirate's fortress are not tiled correctly. -- Does the rom change uCodes mid-flight???
I need to get some sleep (but will end up spending the rest of the night trying to migrate the projection matrix to OGL. =P
There was a bug with an assignment in a conditional as in if (foo = bar) instead of if(foo==bar)...
I cleaned up all the warnings...
I noticed that there are two seperate implementations of the matrices, one in the register file and the other in math.c....
I'm now trying to get it to run using only the OpenGL Projection matrix, no luck yet. =\
KEY QUESTION: DOES TR64 STORE MATRICES IN C ORDER OR OGL ORDER??? (row major or column major?)
Are vector-matrix multiplies done on rows or columns?
-- You really should go to great lengths to avoid custom code where commonly available libraries exist. Libararies may be slow now but they'll have fewer bugs, be more robust, and over time they'll be tweaked to take advantage of new hardware and methods.
I've done many cleanups across the board.
Another tweak I've found is that the code, in a number of places, copies color variables into a temporary vector to be passed to some other function.
Guess what? C always lays out structures the way you write them, so the g, b, and a variables are layed out in memory just as they are written. -- all you need to do is send it a pointer to red. -- it works great!! =P
Another major speedup is to allow the compiler to use the full instruction set instead of only the position independant subset of it. Plugins are never used in a configuration where position independant code is a benefit. -- remove "-fPIC" from the makefiles. It appears to be a myth in the plugin developer community that shared libraries MUST be position independant.
Current issues:
Zelda: OoT ###
Stone walls and the Death Mountain trail is translucent. =\
Some of the fixed-perspective models in the city are completely untextured.
Zelda: M's M ###
Unrecongnised opcodes 0x09 and 0x0A in the introduction scene... I don't know what they do, I copied uc00's code for 0x09 but it doesn't appear to be doing anything.
Your version crashed when moving between complex scenes, most notably, trying to enter the witch's hut would usually crash it.
My version doesn't generally have that problem but it tends to crash in an extremely unpredictable manner with no visual clues as to what's going foobar. -- ddd/gdb indicates the crash is in the main interpreter loop not in the plugin, maybe something in VM memory is being hosed by my changes...
While it may seem faster to manually inline everything, it is much easier to maintain code that is seperated out and use the inline directive to tell the compiler to do inlining.
Missing polygons, esp in the second chamber of Snowhead, entire floor is missing.
Clipping is broken... If you look at a partially transparent texture from the right, you see only the raw background (usually sky), but from the left it displays some partial version of what should be behind it .
Alpha values are broken, (at least in my version), there is no masking of the backgrounds of things like hearts and magic decanters. There seemed to be some bugs in the texture combining routine, I went thorugh that and made sure that everything seemed to match up to its description.
The 32-bit texture decompression for the title logo has issues, I was able to clean up the texture copy routine a little but I havn't found the decompressor yet.
It seems plausable that you can parameterize OGL enough that it will accept vertex arrays streight from the core memory without any need to go through a lengthy unpacking process.
At least one of the files linked into the binary serves no function, the finished binary is probably more cachable (more efficient) with it removed.
Also in M's M, all the textures in the pirate's fortress are not tiled correctly. -- Does the rom change uCodes mid-flight???
I need to get some sleep (but will end up spending the rest of the night trying to migrate the projection matrix to OGL. =P