What's new

Hacking on the code.


New member
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. =\


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


Master of the Emulation Flame
Nice to hear, that someone is keeping this source alive... looking forward to an updated binary...


New member
I accidentially close the flaming crashzilla edit window every time I get close to finisihng this responsee. =( (by hiting ctrl-w instead of shift-w)

This version of the plugin is the result of my hacking to date.

It is fairly stable unless it is actually responsible for a segfault (null pointer exception) in the Mupen64 0.4 core....

There are a few playability issues in Majora's Mask.

The lense of truth is broken...
and some of the faeries in Snowhead are invisible.

The binary will run on linux and work only with Zelda Roms. (the other ucodes will need to be fixed by reverting the attempt to use glMultMatrix(). )

On that game, Opcode 09 is probably broken as well as 0B, which it reports. (the error code is wrong because I couldn't find the table of error codes).

The biggest mystery that I really need to solve before I can do much more with it is to determine why I can't remove lines 572 and 576 from 3dmath.c... -- What other code is using the GL_PROJECTVIEW matrix without saving its value before executing the code in 3dmath.c???


New member
New Development Release

This is a new development release of the code...

It is an attempt to fix the combiner. The previous one was a hopeless mess... It would have needed a roughly 18,144 entry switch statement for the color values, and an 8,000 entry tree for the alpha values! =P

This one tries to get by with only a few dozen, mostly following a very regular pattern and a single unspeakably evil goto loop. =P

It already works better than the previous one in alot of ways but it has some major regressions against the previous, most notably the text portions of many games is currently broken. I suspect that this may be a result of poor changes to texture.c (needed to fix the transparent rocks on death mountain!!) Or a problem in decoding the opcodes for setting the texture parameters.

The big difference between this version and the previous is that I may live to see a fully functional revision of this version! =P

Also, the interface between combine1.c and texture.c is VASTLY improved. Simply changing all the macro and variable names in the previous release of combine1.c to the current one (and using it with the current source) should yield as much as a 30% performance boost! =P

Please please please help me find the remaining bugs in this release! =P

By the way, this video plugin is the only one in existance that comes even close to working well on my hardware/software configuration. Others either A: Instantly segfault, B: produce no textures and generally don't work. or C: run OK but come to a screeching crawl when certain visuals are used that my card can't handle.


Master of the Emulation Flame
Hey, did you try to contact the original author? Probably he can help you a little bit in enhancing his plugin... I will try the plugin asap and tell the bugs I've found!


New member
MasterPhW said:
Hey, did you try to contact the original author? Probably he can help you a little bit in enhancing his plugin... I will try the plugin asap and tell the bugs I've found!

yeah contact him, i'm sure he'll help you a bit


All you need to do is ask. :)

I'm still working on it but haven't had any real amount of time to get much done.

The matrix are stored in OGL order.

I stoped using OGL matrix functions because of strange artifacts happening. also speed was an issuse.




New member
icepir8 said:
I stoped using OGL matrix functions because of strange artifacts happening. also speed was an issuse.

You must have an unusually bad OGL implementation...

On my SSE enabled Athlon MP it's just as fast to load matrices into OGL for the multiplies and copy them back out as it is to do it your way and there are no visable artifacts.

My goal has been to reduce the size of the driver binary to 200k... I'm at 240k now...
;) Please tell me why I can't use the projection matrix with impunity....

My current version looks pretty good in general but has several serious regressions, one of which I am too lazy to fix the other two I havn't isolated yet.

The most critical things that work in my version are:

1. bubbles are now visible.
2. the punchable blocks of the central column of Snowhead are visible.
3. visual effects such as the streaking effects around the rolling goron work.
4. The lava and other floor surface textures work -- for the most part... (others are completely black.. but they aren't transparent as was in the older version.

I've gotta get on with my life so I'm not going to work on this much either...

I might look at it again after a new version of mupen comes out, the current one crashes or goes comatose far too often to allow me to finally beat Majora's Mask. =\