Glide64-wonder++ compiles, doesn't initiate

[Eck]

This is new for me since changing Linux distros from Debian Lenny to OpenSUSE 10.3.

On Debian I could just do the make and copy the glide64.so from the Glide64-wonder++ v.12 pack to the Mupen64 plugin folder and copy the Windows version glide64.ini from the Glide64-wonder++ Windows pack over there too, and it would initiate and run fine.

Got a dual-boot Vista/Linux now. I'm using the included older Glide64 in OpenSUSE just to have it available, but since glN64 works without the problems that older Glide64 had I just normally use that there.

It would be nice to figure out why the compiled version doesn't initialize the plugins when trying to start a game, and the panel for it doesn't open either. The included Mupen64-0.5 version runs as well as it has run, but the version 12 one is much better. Can't use it.

Actually, I've got a lot more available using these things on Vista. Project64 1.7 (I'm a subscriber), adding Glide64-Wonder++ (doesn't have the problems the same original version has on Linux so that Linux version 12 of it isn't needed), and then also installing the Windows Mupen64 0.5.1 and replacing its Glide64 with the Windows wonder++ gives me all sorts of options there. I run the emu's in administrator mode so they all can do what they're supposed to without permission and access problems.

Glide64-wonder++ doesn't end emulation on Mupen64 gracefully because of frame buffer being activated (or so I've read that's the reason), but at least the frame buffer thing works on Windows. On Linux it never activated that screen in MarioKart64, but on Vista it's there. And with Project64 1.7, it DOES end emulation fine, so it seems to be a Mupen64 thing. On Mupen64 I have to end the process in Task Manager.

Anyway, the central question is regarding using version 12 of Glide64-wonder++ on OpenSUSE. Does anyone know why Mupen64 can't initialize it? Is it not being built correctly and fully with the version of the build tools on OpenSUSE 10.3? I get various warnings while make is running but got some of that on Debian while building the thing and it worked fine regardless.

I saw that there were problems getting Glide64 running with the new ricevideolinux64 version of Mupen64 now in subversion, or so I've read in the forum here. Is this related to my problem? Possibly newer build tools playing havoc with building the plugin the way the make stuff is currently setup?

Heh, I haven't learned how to patch make files yet. Hopefully the coming this spring version of Glide64-Napalm will have something released for Linux as well that will compile using today's distro build tools. Or if someone has figured out the problem and solved it, they can show me how to patch the version 12 so it'll build in a way that'll initialize again. Or release something we could just replace in the build folder? I'm just guessing that it isn't building correctly, but I know it doesn't run anymore. The file is built. It just doesn't work.

 

[mudlord]

Heh, I haven't learned how to patch make files yet. Hopefully the coming this spring version of Glide64-Napalm will have something released for Linux as well that will compile using today's distro build tools. Or if someone has figured out the problem and solved it, they can show me how to patch the version 12 so it'll build in a way that'll initialize again. Or release something we could just replace in the build folder? I'm just guessing that it isn't building correctly, but I know it doesn't run anymore. The file is built. It just doesn't work.

Sorry, at the moment, the code is for Windows. Same goes for the updated wrapper with texture compression and 32-bit texture support. The wrapper should be easy to port to Linux, although the plugin, might need to be ported over manually again, due to how many changes it had.

 

[Eck]

No problem then. Nothing stopping me from playing stuff here but I was just used to using Glide64-wonder++ v.12 on Linux. There's still plenty of play there with Mupen64 using glN64, what plays with the original Glide64-wonder that comes with Mupen64, and the various choices on Windows as well.

Maybe Ziggy will get back to testing building the plugin again under today's distro's? If he can get it working again perhaps a version 13 could be released of Glide64-wonder++ that fixes the build again. Kind of makes one wonder what other older things wouldn't build properly as I normally just install packaged stuff using YaST Software Management on OpenSUSE and don't compile on my own. Same with Debian and Aptitude. Perhaps there wouldn't be too many problems as usually one does ./configure for building which uses what's on the current system, rather than this plugin which comes preconfigured with no ./configure to run.

It's been nice playing Dr. Mario finally since it works with the original Glide64-wonder++ on Windows whereas it didn't run without the pills not being seen dropping no matter what plugin used on Linux. I was playing it with fceultra but the N64 version is prettier than the NES version of course.

 

[Eck]

Ah! The secret was checking under the Glide Wrapper category to disable dithered alpha and disable FLSL Combiners. Also, checking get frame buffer info got Dr. Mario to show the pills he's throwing!

I discovered this by downloading from another thread the git version of Glide64 V9 that is being worked on for the 64 bit version. I tried that on the released version of Mupen64-ricevideolinux and the Glide64.ini included once that V9 is made has those two options checked by default and Glide64 worked.

I made wonderplus version 12 again and used the ini from the wonder++ Windows version, but checked those two disables. Once I also turned on the frame buffer info the Dr. Mario pills could be seen.

The video screen in MarioKart64 still doesn't show up. I tried the various checkmarks but none of them made that show up. It DOES show up in Windows Vista with the original wonder++ Glide64 plugin. Strange. Maybe it's an NVidia Linux driver thing.

So the files make fine I guess, although that new git from the 64 version doesn't have all the error messages while it's being made like version 12 does, but they both work in Linux as long as I enable those two disabling options in the configuration. Funny that it used to work without that.

Rice Video in the new version is nice too! Lots of problems in the old version no longer appear so that's another plugin and Mupen64 version to use. I have both installed in Linux now. Glide64 (reports as V9), the new 64 fork is used on the ricevideo fork, and the version 12 on Mupen64-0.5.

Get frame buffer info does something since Dr. Mario shows the pills when it's on. I wonder why the MarioKart64 video screen doesn't show up?

 

[Richard42]

I discovered this by downloading from another thread the git version of Glide64 V9 that is being worked on for the 64 bit version. I tried that on the released version of Mupen64-ricevideolinux and the Glide64.ini included once that V9 is made has those two options checked by default and Glide64 worked.
...
Rice Video in the new version is nice too! Lots of problems in the old version no longer appear so that's another plugin and Mupen64 version to use. I have both installed in Linux now. Glide64 (reports as V9), the new 64 fork is used on the ricevideo fork, and the version 12 on Mupen64-0.5.

Gunther's version of Glide64 is actually based on Wonder+ v12. It used to report version "Wonder+" but he changed it to report "0.9"; not sure why he did that, cause it is based on v12. I believe the source in his Git repository is the same as the source in my SVN.

I did the fixes in Rice Video; there were a lot of problems that I fixed but there are still quite a few remaining.

We're going to be making a new release of Mupen64-amd64 soon, but we're also changing the project name to Mupen64Plus to downplay the 64-bit compatibility, since it also still runs under 32-bit systems. This release will include Glide64.

 

[Eck]

That name change for Mupen64Plus is good. I kind of stumbled into that Gunther Glide64 version, at first thinking it was only for 64 bit since he was saying it was redone for 64 bit. Later in the thread I noticed that he said it should build fine on 32 bit too, so I clicked the link and guessed my way to the download link. I'd think that folks might just pass by the new improvements included in Mupen64 if they think it is only for 64 bit systems, so Mupen64Plus is nice.

The improvements to the GUI are important to me since I like GUI's. Given a choice of typing in startup commands or just mouse clicking my options, the mouse click wins hands down for me. So as long as kept seeing comments such as "I'm working on that," and " yeah, that's something only available to work right using the nogui version," I held back from trying things out. But I haven't seen anything like that recently and was struggling with this Glide64 and getting some games to work right with ANY plugin, and so took the binary and gave it a whirl.

Works great! And nice new icons too. Having Mupen64 run on a user basis is nice since one can have both and make links to both on the KDE Menu. I see there really is no actual need for having both versions since the new one runs just fine, but it's a nice option to have for those slow to trust upgrades and forks, like me.

So far it is preferable to use your binaries rather than the packages available from the OpenSUSE Build Service repos. They still have the older ricevideo version of yours on there, with it still named just Mupen64, and still confusingly offer the original version on another repo. And, I've found in these emulators (except the ones on the Debian repos surprisingly. They don't have Mupen64, but the fceu and zsnes packages are more complete with full openGL support and most plugins than the ones built and offered on the OpenSUSE repos) that generally it is preferable to download and install them from upstream directly. That is unlike just about anything else, but so it is with emulation. Everyone is worried about licensing issues for different included plugins and such, and so things tend to get removed from the versions packaged on the distro repos.

Well, however we get this stuff installed I'm happy that work continues and our game lists get more and more playable on our computers. Unlike most, I'd guess anyway, I do own most games, however don't have the machines hooked up to my TV anymore as I found it interfered somewhat with my normal TV reception as well as slightly weakening my cable internet. Plus I sit in front of my computer a lot more than I watch TV! It's just easier to fire up a game I might have a yen for right away on the computer. And with the Adaptoid and whatever other gamepad (now the Logitech Rumblepad 2 since the rubber pads on my Thrustmaster tore) I don't feel I'm missing anything using these emulators. Sometimes the games actually look better! I've got a CRT monitor so that helps.

Anyway, thanks so much for all that continued work you're all doing on Mupen64!

 

[ebenblues]

Works great! And nice new icons too. Having Mupen64 run on a user basis is nice since one can have both and make links to both on the KDE Menu. I see there really is no actual need for having both versions since the new one runs just fine, but it's a nice option to have for those slow to trust upgrades and forks, like me.

The next version of Mupen64Plus will include support for multiuser environments (the multiuser support that was in mupen64 v0.5 was stripped out when mupen64-amd64 was originally branched). I just wanted to offer a word of warning because by default, Mupen64Plus still uses the mupen64 name for install and user config directories, e.g. ~/.mupen64 and /usr/local/share/mupen64. You can read the preliminary README file explaining the changes here. We didn't really take into account that some may want to run mupen64 v0.5 along with Mupen64Plus, so the install/user directory names could conflict. We do offer the --configdir and --installdir commandline options which can help you get around this issue. Maybe now that we have a new name, we could change our install/user dirs to mupen64plus? Richard42, what do you think?

The hope is that the multiuser support will make Mupen64Plus easier for distros to package, so any feedback on this would be appreciated.

Anyway, thanks so much for all that continued work you're all doing on Mupen64!

Glad people are enjoying the emulator. I know I am.

 

[Eck]

Naming it Mupen64Plus might be a better way to go for reasons you mentioned. I might add that for those who just extract the binary original Mupen64-0.5 there still would not be a problem in most cases. The binary extracts to wherever you do the extract here in. So, as I do, one would extract here in my home directory and get a mupen64-0.5 directory. The only problem might be the input plugin, which installs itself to ~.blight-input.ini or some such. If Mupen64Plus does that too then there might be a conflict, or not if it's the same plugin and same configuration. They they'd simply be able to share the same file, I would think.

Those that install the original multi-user like would get the problems you mentioned though. I've only done that when experimenting with using the OpenSUSE Build Service packaged version. A second, different Mupen64 would then conflict. Even with a rename, the plugin files might overlap and replace each-other. That wouldn't be good.

I don't know how many use that OpenSUSE Build Service home:/(etc...) repository though. I did until I noticed that a couple of plugins weren't in there and now just use the original binary extracted to its folder in my home directory. I haven't noticed that it creates any hidden files besides the blight-input ini file. Mupen64-ricevideolinux doesn't create any when installed the same way, as far as I've seen. Installing it with the system package manager changes that of course, but that is the way to go if one wants more users to have access easily to Mupen64. Most folks want to just search for it in their package manager and install it, and have that easy shortcut in the KDE and Gnome menus that run it. Distro acceptance and inclusion is likely a major goal for many serious projects such as this.

Of course, as long as Mupen64Plus does everything and more than the original one does then there is no conflict as it would be the one everyone would want to use. Keeping in mind though, that Hackturux has stated his intention to return to Mupen64 to release a new version as well. Perhaps choosing a title (like Mupen64Plus) and sticking to it as far as folder and file naming is the best way to go. A user can then use both and presumably each would excel in its own way and have no installation or usage conflicts with the other no matter how it was installed. As long as work continued on both until hopefully a merging at some future date, similarly to what went on with Compiz - Beryl -Compiz Fusion, a lot of folks would likely desire to keep both usable on their system. Some folks for a time actually did keep Compiz on their system and switch between that and Beryl as I recall. Sometimes that worked out and sometimes not, but a lot of folks did it.

 

[Richard42]

We didn't really take into account that some may want to run mupen64 v0.5 along with Mupen64Plus, so the install/user directory names could conflict. We do offer the --configdir and --installdir commandline options which can help you get around this issue. Maybe now that we have a new name, we could change our install/user dirs to mupen64plus? Richard42, what do you think?

I didn't previously consider this use case, but since we should be able to do it without too much difficulty or adverse effects, it's probably a good idea.

 

[Tillin9]

Just to add, along with the ~/.mupen64plus home we should probably also change the executable name from mupen64 to mupen64plus or mupen64p, etc. in case people want to have both in their path.

 

[Eck]

Just to update for anyone checking out this thread based upon the title of it, on Debian Lenny with xorg-xserver-core 1.4, video, and input taken from Sid with the Debian way NVidia 169.09 Sid packages installed I no longer need to disable those Glide64 options in order to get the plugin it initialize.

I don't know whether it was the 169.12 driver itself or the OpenSUSE implementation of it, but those features shouldn't need to be disabled and they work fine on Debian with the above combination. I could be xorg related too as OpenSUSE 10.3, unless upgraded with the Build Service xorg 1.4 repo, uses xorg 7.2. Still, the older drivers on OpenSUSE in the past hadn't required me to disable those Glide64 features.

Nice to know that 3D is working fully for me on Debian. That's today. Today/tomorrow Lenny's getting the Linux 2.6.24 Kernel so I'll see what happens after the upgrading of the NVidia kernel. (Prays for module-assistant to work right.) Lots of fun in store! Then some time after that the NVidia maintainer will be releasing the newer NVidia driver too, as I saw on his home page blog.