What's new

Port of glide wrapper with hardware frame buffer emulation

Sri Narayan

New member
Thanks for the nice port!!
The only game that do not work with framebuffer emulation is Perfect Dark.
Without framebuffer emu it works,

ciu
 

Illissius

New member
I have just one issue to report with this plugin: it leaks memory at a prodigous rate. After a few games of SSB, it was using well upwards of 700MB. The only practical consequence of this is I have to restart it every once in a while, which is still much preferable to not being able to play it at all, so I will suffer it gladly -- but I thought I should report it.
 
OP
J

JoshTriplett

New member
I have just one issue to report with this plugin: it leaks memory at a prodigous rate. After a few games of SSB, it was using well upwards of 700MB. The only practical consequence of this is I have to restart it every once in a while, which is still much preferable to not being able to play it at all, so I will suffer it gladly -- but I thought I should report it.

Thank you very much for reporting it. I don't *think* any of the changes made by the Linux port should cause memory leaks, but the possibility exists; alternatively, Glide64 or Hactarux's wrapper might already have had the leaks you observed. One thing that might help here: can you tell me if the Linux port of Glide64 0.7 leaks for you too?

I tried running the Valgrind memory debugger on it, to track down the leaks, but unfortunately it doesn't seem to support some of the x86 instructions that Mupen64 uses (some part of SSE, most likely), and in any case it looks like Mupen64 already leaks memory which makes it harder to track this down. However, I will look into it further and see if I can track down the problem; I can't guarantee that'll happen soon, though. :) Also, if it turns out to only leak when using the hardware framebuffer emulation, which my video card doesn't support, then I can't reproduce the problem to track it down.

Glad to hear that the plugin otherwise works for you.
 

Flash

Technomage
Thanks for such nice work, everything compiled without problems and (finally) we have linux gfx plugin update, but i've found one strange thing in Mickey's Speedway USA - everything is ok at Nintendo logo (waves, etc) but right before race there's another ripple effect, and it's slow like hell, about 3 fps or less with sound hickups. I can't test this on real Voodoo & windows right now (i'll do it next week, when it will be possible to reboot my machine) but if i remember correctly it isn't that slow on native glide stuff.

Also there's some texture glitches in Buck Bumble,for example, when you see the pipes and a pond of some green chemical goo, it looks like only water textures affected by this problem, also game runs slower than with Hack's 0.7 ME SP8 that comes with Mupen64 at this point (camera flyby)
 

mudlord

Banned
I did some testing for that problem, and the Windows plugin runs Mickey's Speedway USA perfectly, with no slowdowns with HWFBE on, in the wrapper.

I also noticed the memory leak too. I also have no idea whether its the plugin or the wrapper, but I will for sure, check out whether its related to the framebuffer emulation in the wrapper. I also recently did some changes relating to how hardware framebuffer textures are generated (it now uses standard OpenGL glGenTextures/glDeleteTexture calls), which might help a bit with speed.

EDIT: Performed the testing. There is definately a memory leak. It occurs regardless whether HWFBE is on or not, however for me the leakage occurs at a faster rate with HWFBE turned on. Don't know whether the wrapper or the plugin is at fault.
 
Last edited:

Nonno Cicala

New member
Thank you very much JoshTriplett!
I tried your precompiled binary on my AMD64 system and it's my favourite plugin, but I don't understand how to make the framebuffer emulation work (without reading every frame). I have the same Glide64.ini for both windows and Linux but Banjo-Kazooie or Mario Kart 64 don't show the effects with my beloved penguin (btw, the sign on Mario's house in Paper Mario appears in windows).
:linux: I have a Radeon 9500 Pro, and I tried both the DRI (16 and 32 bits) and fglrx drivers (with or without GLSL).
 

Illissius

New member
Anyone know what sort of video card is required for this plugin? I imagine my current GeForce 6600 is well more than adequate, but I'll be exchanging it for a laptop in the near future, and my choice is between a Radeon 7500 and 9000. Are both sufficient, neither, or only the 9000?
 

Clements

Active member
Moderator
I believe hardware OpenGL 1.5 support is a requirement to make the most of this plugin. A DirectX 9.0-level card should have no problems with it. The Radeon 9000 is better than the 7500, but still only supports OpenGL 1.4 as far as I know, so you may get some wrapper problems. The 9000 will definitely work better with other plugins than the 7500.
 
Last edited:

Clements

Active member
Moderator
Wikipedia is frequently incorrect with respect to specs for graphics cards. In this instance, I strongly doubt a 7500 can support OpenGL 1.4 without some support in hardware for pixel shaders. Also stating that the older DX7 part has a better feature set than a newer DX8.1 part (like the Radeon 9000) does sound impossible.

The 7500 supports either OpenGL 1.2 or 1.3 and 9000 supports OpenGL 1.3/1.4, but can't find a quick, reliable source right now for OpenGL support across GPUs that is actively updated.
 
Last edited:

mudlord

Banned
Wikipedia is frequently incorrect with respect to specs for graphics cards. In this instance, I strongly doubt a 7500 can support OpenGL 1.4 without some support in hardware for pixel shaders. Also stating that the older DX7 part has a better feature set than a newer DX8.1 part (like the Radeon 9000) does sound impossible.

The 7500 supports either OpenGL 1.2 or 1.3 and 9000 supports OpenGL 1.3/1.4, but can't find a quick, reliable source right now for OpenGL support across GPUs that is actively updated.


Actually, the Wikipedia article is partially correct, in that the OpenGL specs for the Radeon 7500 are right, but the Radeon 9000's sound like BS. Radeon 7500's DO support programmable shaders in OpenGL (by GL_ARB_vertex_program, but it doesnt support GLSL, required for compatibility for OGL 1.5/2.0), its just they don't support the technology used by DirectX in Microsoft's implementation of shaders, thus not supporting Shader Model 1.0/1.1 in DX8.
 

ziggy

New member
Hi Josh,

Thanks for your porting ! I've been working on this plugin for about two weeks and have made some improvements :

- support for Framebuffer objets so the option "Hires framebuffer" now works under linux too (this required also a fix in glide64 itself , since we're still using wonder +, Gonetz told me it has been fixed already in wonder ++ though)

- fixed the vertical offset of the rendering : with SDL it is not necessary to shift vertically the rendering wheither you're in fullscreen or not

- fixed glsl pixel programs for bw textures (in your version Josh, I don't know why two pixel programs are different from the original wrapper code, this was a mistake because it prevented the dynamic shadow in Jet Force Gemini to work normally (this effect requires HWFBO too by the way))

Additionally, I made some fixes in glide64 and the wrapper that apply also to the win32 version :

- now the Lens of Truth works in Zelda Majora's mask, and more generally textures are better converted (the effect was not working in wonder +, and was partially working in wonder ++, but there was a hack for that in glide64 itself, now with the real fix in the wrapper, this hack is no more necessary) Also the new texture conversion routine should save some texture video memory.

- z near clipping fix : objets were clipped too early (see this post where I explain the problem : http://www.emuxhaven.net/forums/showpost.php?p=74851&postcount=386)

- I put back what seems to me to be the correct screen height of 240 for PAL games (it was previously set to 230) so that we don't have anymore a black band at the bottom of the screen for PAL games, and also this way framebuffer effects like motion blur works correctly.

Attached are modified source code and a binary build (for linux gentoo, might work on other distributions too).

Ziggy.

EDIT: by the way, it might be a good idea to rename the thread (if that 's possible), since it's also a port of glide64 (not just the wrapper), and also specifying it's a port to linux might be a good idea too :)

EDIT2 : fixed linkage problem due to the unused devil library (IL), thanks Tillman for reporting this
 
Last edited:

Tillmann

Whatever
Dunno why but I wasn't able to compile your sources (ziggy)...
I was able to do it with Mr Triplett sources... do you have any ideas?
after some time of compiling it came up with this error:
"collect2: ld returned 1 exit status
make: ** [Glide64.so] Erro 1"
 

ziggy

New member
Dunno why but I wasn't able to compile your sources (ziggy)...
I was able to do it with Mr Triplett sources... do you have any ideas?
after some time of compiling it came up with this error:
"collect2: ld returned 1 exit status
make: ** [Glide64.so] Erro 1"

Could you copy/paste a few more lines from the output ? These two ones aren't very informating :) (it justs tells it failed basically, but the reason for the failure should be just above)

Also , what is your system/distribution ?
 

Tillmann

Whatever
Could you copy/paste a few more lines from the output ? These two ones aren't very informating :) (it justs tells it failed basically, but the reason for the failure should be just above)

Also , what is your system/distribution ?

CRC.o Combine.o wrapper/combiner.o TexBuffer.o Tmem_nasm.o wrapper/config.o wrapper/filter.o support.o wrapper/2xsai.o wrapper/hq2x.o wrapper/hq4x.o Config.o 3dmath.o DepthBufferRender.o
/usr/bin/ld: cannot find -lIL
collect2: ld returned 1 exit status
make: ** [Glide64.so] Erro 1

Well I've putted my specs down there :)
Tanks For your help!! :linux:
 

ziggy

New member
CRC.o Combine.o wrapper/combiner.o TexBuffer.o Tmem_nasm.o wrapper/config.o wrapper/filter.o support.o wrapper/2xsai.o wrapper/hq2x.o wrapper/hq4x.o Config.o 3dmath.o DepthBufferRender.o
/usr/bin/ld: cannot find -lIL
collect2: ld returned 1 exit status
make: ** [Glide64.so] Erro 1

Well I've putted my specs down there :)
Tanks For your help!! :linux:

Aah, sorry it's a mistake from my part : in the file "Makefile", just remove the "-lIL" part, it's not needed. Alternatively, you could install the devil library (which is missing , hence your error). I'm using this library to dump textures in debug mode, but it's not used in the version I released. I'll upgrade the release to take this into account.
 
Last edited:

Tillmann

Whatever
Aah, sorry it's a mistake from my part : in the file "Makefile", just remove the "-lIL" part, it's not needed. Alternatively, you could install the devil library (which is missing , hence your error). I'm using this library to dump textures in debug mode, but it's not used in the version I released. I'll upgrade the release to take this into account.

Devil lib!?
Can you give us more info about it? :)

Btw compiled n' kicking! EDIT: It gave me a bunch of warnings... could it be gcc version!?
Thanks!
May i request something?
If so: Can't remember exactly now, but I think that windows version has some sort of balloon tips when you pass the mouse over some option is it possible to enable in linux?
These tips are pretty cool n' come handy for noobs like me...
 
Last edited:

ziggy

New member
Devil lib!?
Can you give us more info about it? :)
That library, contrary to what the name may suggest, isn't evil at all, it's just an image manipulation library. I was using it to write textures in .png files (to debug) Its advantage is that it has a very neat API, very similar to the OpenGL API.

Btw compiled n' kicking! EDIT: It gave me a bunch of warnings... could it be gcc version!?
No, I have the warnings too, but they aren't serious.

Thanks!
May i request something?
If so: Can't remember exactly now, but I think that windows version has some sort of balloon tips when you pass the mouse over some option is it possible to enable in linux?
These tips are pretty cool n' come handy for noobs like me...
Yeah, I agree that I'm missing these tooltips from the win32 version too in fact. If I find the time to do that, I'll try to add them.
 

Tillmann

Whatever
I was using it to write textures in .png files (to debug)

SO................
In Any way this could be used to DUMP textures too? Like rice video?


Edit: Almost forgot...
WHen i'm in 1024x768 the gui stays all messed up!
 
Last edited:

Top