ramlib_PPC data access exception

[Karlos]

This is very commonly happening with Warp3D libraries which are totally bogus, calling recursive OpenLibrary inside library init code... This will explode with standard ramlib stack. Warp3D doesn't work reliably without some sort of ramlib stack patching

Are you sure about that? I've never seen it do this.

[Karlos]

Well, I meant "the recursively calling OpenLibrary()" bit for warp3d libraries.

Regarding the ramlib crash, I think my 3.x installation was protected by MCP's ramlib patch anyway. I also used stack attack to increase stack allocation generally.

[Karlos]

 

Vincent wrote:

God knows what happened (or what installation, or me getting libs from Karlos to try Quake stuff...), but it seems to be happy now :-)

The libs you got from me are implemented rather differently from the original 4.2 - the 680x0 driver really is 93K and really does support everything its 579K predecessor did (and a lot more). The WOS version is a bit larger (180K). The 4.2 driver you had from me was just a quick bug fix and recompile of the original 4.2 source.

Compatibility wise, the 4.3 drivers should work with everything that obeys the W3D API. There is a known conflict with some versions of MiniGL (affects BlitzQuake, for example) which is due to aggressive optimisations in that version of MiniGL making assumptions about the driver and taking shortcuts.

Everything else I have tested worked OK (as I tend to use them on a daily basis ;-) )

[Karlos]

You only have the 680x0 half, so unless you are running 680x0 3D apps you won't see a difference at all. Lemme know if you want the PPC version too.

I haven't as of yet had any chance to benchmark directly the gain of the PPC version (at the function level) since I need to compile a WOS friendly benchmarking tool for it. I doubt the gain will be as great as the 680x0 side (which is more than 2x faster in some cases) since the PPC will most likely reach bus saturation anyway.