Port of glide wrapper with hardware frame buffer emulation

[Eck]

I guess. I suppose I could find a link to that someplace here. I might also be able to use the one that comes with the official Mupin64 package.

But all that isn't really correct is it? Isn't a specific ini file for the version 12 plugin supposed to come with the tarball or get created along with the Glide64.so when running make? Not sure how that's supposed to work.

How do you guys who are using this version of the plugin do it? At the end of the make process which successfully creates the Glide64.so, the last line of it reads to copy the so file AND (and it's in caps to show its importance) the ini file to the plugins folder. Where is it? Is it not being created because of a problem with some newer library on my system or something else going wrong, or is this just supposed to be included in the tarball and for some reason was left out?

I appreciate the reply but, heh heh, you don't sound sure about this either. I'd appreciate someone who could tell me what's wrong here replying if they happen to spot the post.

The glN64 plugin works okay for a lot of games and then there is Rice's, but I know that newer version of Glide64 got a lot of things working better and I'd sure love to take advantage of it. A proper ini that's supposed to be used with it is likely in order here. But of course, I don't know that. I suppose I'll try extracting the Mupen64 release and just copy that Glide64.ini along with the newer .so file created, delete that Mupen64 as the newer SUSE specific version might in itself have some improvements in it and it's installed and working so I might as well use it, and see what happens.

Hmm, sure hope that has an ini in it!

 

[Eck]

That worked! I just used the ini from the released binary Mupen64 but put the Glide64.so that got created by make of the version 12 and just played SuperMario64.

Hmm, flashing areas that are supposed to be solid aren't right. But the shadows are now there. Different, eh? I wonder if I mess with the configuration whether I could fix it up. But for Mario64 it seems the glN64 was better overall. Don't know since I just did the Princess's Slide and came back to report.

Anyway, I don't know whether using a specific ini for this version is supposed to be done or that the original one is just fine, but at least it runs the games.

Edit -

Ooh, Namco Museum works. Believe it or not that was one of the missing Linux links that got me booting into Windows every so often for Microsoft Return Of Arcade games. Essentially, that's what Namco Museum is. And that thing never worked whichever plugin I tried until this version of Glide64. Mainly for Galaxian, but it's nice to see they all work. And Crusin USA works best with Glide64, even with the original extracted Mupen64. Works fine here as well. I guess I'll use glN64 for SuperMario 64. Too much flashing scenery with Glide64.

I'll check out some other stuff later. Too bad that Dr. Mario still has the disappearing pills. If you can't see them you can't play that too well.

I have it running. But would this be even better with a newer ini?

 

[Richard42]

Eck,

I am currently working on improving the Linux builds of Mupen64 and Rice Video and have fixed quite a few things over the past couple of weeks. I tried the games you mentioned below and all of them except Dr Mario work well. Cruisin USA, Namco Museum, and Super Mario 64 all look near-perfect. My SVN server is public but there will also be a release coming in the next few days.

 

[Gonetz]

I just noticed this post.
Eck, Glide64 will not work correct without original ini file.
Smcd is right, you may take glide64.ini from the windows release of Glide64, which you can download from Glide64 homepage. The ini file from the released binary Mupen64 should be the same, but I did not check it. So, it worth at least to take the windows release and compare its ini with yours.
BTW, Glide64 for windows should work on Linux via WINE. There was a thread here on emutalk about it.

 

[Eck]

Thanks so much for the info, Gonetz. I've been enjoying the noticeable improvements since using that updated wonder plus for Linux version along with the Mupen64 as installed by the OpenSUSE Build Service repository. I have a feeling that fixes were made to the rpm there as opposed to the released Mupen64 0.5 binary that just extracts. For some time I wondered how to get that newer Glide64 plugin installed, to replace the original one, and when this Mupen64 didn't even come with Glide64, I extracted the latest wonder plus version 12 to try it again.

I usually distro hop between my two favorites, OpenSUSE and Debian. On Debian I've just used the Mupen64 binary because I couldn't get the plugins added to install into Mupen if I compiled the source. Maybe now, with a tiny bit more Linux experience I can do better but we'll see next time I install Debian. Maybe it was just a matter of skipping configure and just using make to build the plugin? That was the secret to the elusive building of Glide64 that I finally succeeded with this time.

I must have never located his INSTALL text file before! I had been trying to do ./configure on it and that never worked, complaining of a missing config file. Just doing make was the trick. Strange that it does not create or come with the ini file yet instructs the user to copy it over just the same. But the one from the Mupen64 binary has been working fine for me.

I'll look for the Glide64 homepage so I can download the Windows version and check out the differences, if any. That's a good idea since perhaps you improved something in there with the newer versions of the plugin.

Mupen64 is certainly a great application for Linux users who enjoy N64 gaming on the PC! Still, I am hoping for the next official release to appear with more games fixed up to work properly. I just recall more games running right when using Project64, whether 1.6 or the 1.7 beta (I subscribe to that so have mostly used 1.7 for some time). I see that there is a new version available now with fixes made to the Rice Video plugin and so will likely check that out in the mean time, but do still hope for a full new complete GUI official version. Something like that would likely incorporate some of those automatic settings improvements that the Project64 folks have been enjoying for years, lessening the need for the user to try experimenting with plugin settings, different plugins for different games, etc. I know I rarely needed to change much from the Project64 default settings, besides some initial raising of 3D quality settings or resolutions when first installing it.

On Mupen64 I've found that it is necessary to jump back and forth between Glide64 and glN64, and mostly haven't used Rice too much since I hadn't had as much success with it when trying it. I see that's likely much improved now though, with that new update just offered on the other thread. I'm concerned a bit about needing to manually edit the ini files but I'll check it out and see if I can figure out what I need to do.

 

[sl1pkn07]

is possible port this plugin for 64bits?

thanks

 

[Richard42]

is possible port this plugin for 64bits?

Anything's possible, with enough effort. Someone would need to port both the Glide64 plugin itself and the OpenGL/Glide wrapper. If it is already running properly in Linux it shouldn't be too difficult to port to the 64-bit architecture.

 

[DarkJezter]

This plugin rocks! A major improvement from the version that was included with the mupen64 0.5. Glad this turned up when I was trying to find a way to get the windows version of Glide64 to compile in linux