Menu
What's new
By:
Filters

Port of glide wrapper with hardware frame buffer emulation

J

JoshTriplett

New member
I've taken the source from http://www.emuxhaven.net/forums/showthread.php?t=6123 (linked from the news item at http://glide64.emuxhaven.net/) for the newer glide wrapper with hardware frame buffer emulation, and merged it with the wrapper included in the glide64 plugin at http://mupen64.emulation64.com/files/0.5/glide64-0.7.SP8.tar.bz2 (linked from the mupen64 source code post at http://www.emutalk.net/showthread.php?t=29643). I've tested the resulting plugin with Mupen64, and it seems to run fine. Patch attached; apply with:
Code: 
patch -p1 < glide64-newer-wrapper.patch.txt

Note that in order to build the Glide64 plugin with a current GCC compiler, I had to change -O3 to -O2 in the Makefile, which disables inlining; otherwise, GCC will inline functions from TexLoad*.h in several places, and since those functions contain inline assembly, this leads to duplicate labels in the resulting assembly files, breaking the build. You may want to edit the CFLAGS in the Makefile anyway, to optimize for your particular processor.
 
OP
J

JoshTriplett

New member
Patch to fix rendering for sign on Mario's house in Paper Mario

The attached patch fixes a bug in the new glide wrapper, which caused texture rendering issues on the sign on Mario's house in Paper Mario.
 
Doomulation

Doomulation

?????????????????????????
Hey! Are you planning on keeping the plugin up-to-date as well if and when a new version is released?
And what API are you porting it to? OpenGL or DirectX or something else? Curious.
But this sounds very nice :)
 
Legend

Legend

New member
JoshTriplett said:
Currently in the process of porting Glide64 0.8 "Wonder Plus" (http://glide64.emuxhaven.net/files/Glide64_WonderPlus_src.zip). I've done all the porting work, and the plugin compiles and loads; just need to debug a few issues.
Click to expand...

HOLY CRAP!!!! If you do this you would be changing the face of N64 Emulation!!
I assume its OpenGL your porting it to. Maybe after you do this, Gonetz will start continuing THIS version. I think he would probably like to do that these days but who knows. Good luck man!
:bouncy: :bouncy: :bouncy: :bouncy: :bouncy: :bouncy:
 
mudlord

mudlord

Banned
Wow...JoshTriplett, good work!

What I'm really wondering is whether the code in Hacktarux's wrapper is used to port the plugin, or whether Glide64 is recoded completely for OpenGL..as it seems to me that its just using code from the wrapper (like what was done for the opengl version of Glide64 0.7 SP8 for Linux). I was wondering also if you are interesting in my hi-resolution code as well (which basically allows for the exact same reses that are used in Glide64, to be used in the wrapper as well).
 
OP
J

JoshTriplett

New member
Glide64 0.8 "Wonder Plus" ported

Patch attached. Apply on top of my previous patches in this thread.

A few caveats:
  • The new version of the plugin does fix a number of rendering issues, such as Bowser's fire breath in the Paper Mario intro story (before the title screen); it does not fix all of them though, and it introduces at least one new one (now the sign on Mario's house doesn't appear at all, with or without my small wrapper patch to geometry.cpp).
  • The Windows version tests for the necessary extensions for GLSL, with a configuration option to force GLSL off even if available. In doing this, it needs to create a temporary window to query extensions with, and then destroy it. In this first pass port, I didn't add the necessary create/destroy window functions, so querying the extensions won't work; thus, the configuration option actually forces GLSL on or off regardless of what your system supports, and causes the plugin to segfault if you enable GLSL when you don't have support for it. For this reason, I've changed Glide64.ini to disable GLSL by default.
  • I don't have GLSL, so I'd particularly welcome testers with GLSL; you'll need to turn on the configuration option.
  • Most of the new options default to off; feel free to experiment with them.
  • I may not have categorized the options in the appropriate groups in the configuration dialog; feel free to suggest moving an option to a different location that makes more sense.
  • Look for "JOSH FIXME" to find places where my port needs some work.
  • In particular, in a couple of places, I replaced inline assembly statements with equivalent C, or ignored the assembly equivalents of C functions, to avoid the need to translate from MSVC to GCC assembly syntax for the initial port. No obvious performance impact, and I can always port the assembly later.
  • The 0.7 SP8 port appears to reindent a lot of code; in some cases, I didn't reindent newly-ported code to match, as I ignored whitespace due to the reindentations when merging.

mudlord said:
What I'm really wondering is whether the code in Hacktarux's wrapper is used to port the plugin, or whether Glide64 is recoded completely for OpenGL..as it seems to me that its just using code from the wrapper (like what was done for the opengl version of Glide64 0.7 SP8 for Linux).
Click to expand...
This port uses Hacktarux's wrapper, as with Glide64 0.7 SP8, using the port I posted previously in this thread.
 
Legend

Legend

New member
I don't have the capability of putting this all together or don't know how. Can somebody do that and post it here?
 
OP
J

JoshTriplett

New member
Compiled version of Glide64 0.8 "Wonder Plus" for Linux

Extract the attached tarball in your Mupen64 plugins directory (cd plugins && tar xvzf /path/to/glide64-wonder-plus-linux.tar.gz), and Mupen64 should find the plugin.

This assumes that your shared library versions match (the nature of plugins prevents me from compiling statically); if they don't, this compiled version won't work for you, so you'll have to compile from source yourself, which just requires grabbing and extracting the 0.7 SP8 tarball linked in the first post of this thread, applying the three patches from this thread in order ("patch -p1 < the.patch" for each patch), installing the build dependencies through your distro (SDL, OpenGL, GTK+ 2), and typing "make" to get a Glide64.so .
 
Legend

Legend

New member
Can someone put a compiled version here so I can use it? Alot of people are like me and can't do anything with this. I'm dying to try this!!! Josh!!:bouncy:
 
mudlord

mudlord

Banned
I guess you want a Windows port...

Well, I haven't had much progress in patching the Glide64 0.7 SP8 source with the newest patches from JoshTriplett under mingw32 (doesnt seem to work for me at all). Maybe, if the patch source code can be hosted fully, with makefiles, then a compiled Windows port can be made...

EDIT: My patching problems were caused by not using the proper patching commands...I'll try again with the proper commands this time.
 
OP
J

JoshTriplett

New member
Full patched source code; Re: windows port

mudlord said:
I guess you want a Windows port...
Click to expand...

Not entirely sure what you mean by this; Glide64 0.8 already exists for Windows. Or does the existing Glide64 0.8 for Windows not work with Mupen64, or not work with Glide wrappers? If so, these bits should indeed help you out.

Any interested Linux testers? :linux:

mudlord said:
Well, I haven't had much progress in patching the Glide64 0.7 SP8 source with the newest patches from JoshTriplett under mingw32 (doesnt seem to work for me at all)
Click to expand...

You'll need some additional porting work to make the plugin build under mingw32. Hacktarux's port of 0.7 SP8 and of the wrapper assumes the following:
Code: 
#ifdef _WIN32
/* Windows and MSVC */
#else
/* Linux and GCC */
#endif
My port of 0.8 does not remove this assumption. In order to build under mingw32, you'll need to go through the various ifdefs and remove this assumption. All the ifdefs which choose between MSVC and GCC (such as for inline assembly) should use #ifdef __GNUC__ instead, while the ones deciding between Windows and Linux (such as wgl versus SDL_GL_) should continue to use _WIN32. (On the other hand, since SDL does have a Windows port... :) ) Also, long ago when I used mingw32, a bug existed where a binary linking nasm-generated objects and mingw32-gcc-generated objects together would crash mysteriously, due to an issue with the bss section; I think this got fixed with recent mingw32 binutils, but as I haven't used mingw32 (or Windows) in a long time, I don't know for sure.

mudlord said:
if the patch source code can be hosted fully, with makefiles
Click to expand...

Hmmm; I tried to attach it to this message, but I keep getting the message "upload failed"; I tried .tar.gz, .tgz, .tar.bz2, and .zip, with various filenames, and all of them gave the same result. The files came in well under the size limit. Oh well; it sounds like you managed to get the right command to apply the patch anyway.
 
Legend

Legend

New member
Ok, I assumed this was a PORT from GLIDE to OPENGL api for windows like we've all been waiting for (so you don't have to use a wrapper). I did'nt see anything really about linux till the end here.
 
M

Magic SysRQ

New member
just to back up the linux faction :linux:

everything runs like expected and fine. pre- and self-compiled.
thanks for the work :bouncy:
 
OP
J

JoshTriplett

New member
Wrapper integrated; no separate wrapper needed

Legend said:
Ok, I assumed this was a PORT from GLIDE to OPENGL api for windows like we've all been waiting for (so you don't have to use a wrapper).
Click to expand...

Ah. My changes here do actually provide that to some extent, as they integrate Glide64 with the wrapper in one plugin with no additional wrapper .so/.dll needed. So while it doesn't actually eliminate the wrapper entirely, it does turn it entirely into an implementation detail that you can ignore as a user of the plugin.
 
Legend

Legend

New member
Thanks for the reply but I'm still not sure how I can use this yet. These are text docs that you use to patch the glide64 plugin? I guess we'll just wait and see if Mudlord can do something with it.

I want to try this out since this should be faster than using a wrapper I assume.
 
Last edited:
mudlord

mudlord

Banned
Legend said:
Thanks for the reply but I'm still not sure how I can use this yet. These are text docs that you use to patch the glide64 plugin? I guess we'll just wait and see if Mudlord can do something with it.

I want to try this out since this should be faster than using a wrapper I assume.
Click to expand...

OK, after a couple of attempts, even while using the correct patching commands, the source code won't patch for me under mingw32 (even though I have "patch" in my mingw32 distribution). I guess the the patched source code can be hosted somewhere like Rapidshare (so then I can finally have a chance to compile a Windows port).

As for the speed issue, I guess the speed would be the same as using a wrapper, as the wrapper code is still being used,albiet being integrated into the plugin.
 
You must log in or register to reply here.

Top