An opengl Glide64 for linux ?

[ciruZ]

Hm, I don't think that that's the reason, because the CPU load isn't too high. The sound works well and everything, and sometimes I get ~ 30 fps. Even If I have other programs running that need 50% of the CPU so that mupen doesn't have the full CPU. And it runs as fast as if Mupen has the full CPU .

 

[markos]

afaik, it wasn't really possible to use glide3x directly. It was designed to be used by the DRI driver only. But maybe i'm wrong...

It's not an external library but well... it'll be open source and it should be very easy to link it with the glide library : i think it'll only require changing the makefile to not link the wrapper files, and add a link flag to use the glide3x lib. But again i can't test it myself.

Hacktarux, can you compile a version linked against the glide library? I have a voodoo 5 5500 and am very curious to see how it performs with the glide64 linux port. If not, can you explain exactly what changes need to be made to the make file to get it to compile on my system? (using the glide libraries)

 

[Hacktarux]

i can't compile it myself, i don't have a voodoo, i have no way to test if it works and i'm not sure how the glide library is working on linux...

Theoretically, you have to remove all wrapper files in the makefile and add something like "-lglide3x" in your linker flags (you have to check what's the exact name).
Maybe it's enough or maybe not.... maybe you have to change some parameters of grSstWinOpen, i can't answer to those questions because i can't try.

 

[markos]

After trying all weekend, I didnt have any luck linking to the glide libraries. All the documentation on glide for linux is pretty out of date and not very useful. Hacktarux, if you want to give it a try let me know and I will send you a Voodoo 2. Its the least I can do for your work on Mupen64.

 

[fffortune]

Maybe I'm a moron and missed something obvious, but...

Is there any way to cap gamespeed to 100%, as games often play to fast as it is. I've looked around without any luck. And what is VI/s?

Anyway, the plugin is great!

 

[Hacktarux]

On linux, speed is limited by the sound plugin. VI means vertical interupt there should be around 60 VI per seconds for a NTSC game and 50 for a PAL game.

 

[korrel]

Hi,
Im trying to make a rpm for mandrakelinux. The complilation is working and I compiled mupen64 to work systemwide
under /usr. mupen64 is working with the other plugins but when I use The glide64 plugin it is not working and mupen is not starting the rom.
In a user account the glide64 plugin is working fine.

When I start super mario 64 I get this error.

file found
rom byteswaped
rom loaded succesfully
80 37 12 40
ClockRate=f
Version:1446
CRC: a03cf036 bcc1c5d2
name: SUPER MARIO 64
Manufacturer: Nintendo
Cartridge_ID: 4d53
European cartridge
size: 4096
PC= 80241800
md5 code:45676429EF6B90E65B517129B700308E
eeprom type:0
init timer!
memory initialized
Signal number 11 caught:
errno = 0 (Success)
Xlib: unexpected async reply (sequence 0x4c81)!

Do you know maybe of a line in the source code I have to change to let glide64 work systemwide.

Thanks

 

[Hacktarux]

Try to look at the code that's opening the ini file. If i remember right, this plugin needs write permission to its ini file.

 

[korrel]

Thank you for you quick reply.
I have given full read write permission to the ini file but I still get the same error message :-(
Is there a other file or place that could give this problem? a temp file maybe ?
The strange thing is that this same plugin works fine in a user account.

 

[Hacktarux]

it's probably searching the ini file at a wrong place...

 

[korrel]

I tested the place of the ini file - no luck

I tried running as root - no luck

tried to find the error on google I get these:

http://www.faqs.org/faqs/x-faq/part7/section-15.html
-----------------------------------------------------------------------------------------------------------------------
163)! What are these "Xlib: unexpected async reply" errors?

You'll typically get these errors if you are writing a multi-threaded
application and are making X calls from more than one thread -- one of the
more common new ways to introduce memory corruption into Xlib (using bogus
pointers is another, as is mixing up XFree/XtFree/free calls. Even an
operation as simple as XSendEvent can't be called from a second thread.).
Prior to X11R6, X doesn't support multi-threading; check the X11R6
documentation for how to write a threaded application safely with X11R6 and
later versions of X (including being sure to enable Xlib's multi-thread
support).

Common widget sets are also unsafe to use except from within one thread. The
versions of Motif from OSF, for example, offer no support for
multi-threading.
-----------------------------------------------------------------------------------------------------------------------

so I think it is not so easy to change :-(.

I can try a other approach by compiling it just as user and give write right to the config file.
Problem with this, is that every user can change somebody else configuration.

Do you have a other suggestion what can be the problem ?

thanks for your help so far

marco meijer

 

[Hacktarux]

The best solution is to compile everything with -g option (and to comment the strip command). Then run it through gdb and it'll probably tell at which line it's crashing....

 

[The Wanderer]

(Hopefully, being "only" a couple of weeks old, this is recent enough to not be considered an old, dead, or otherwise verboten thread. If 'tis, then I suppose I could start a new one to set out the problem afresh... but I prefer to avoid repetition when I can manage it.)


Well, I'm not the previous poster, but I have much the same problem (except that installing in a user directory changes nothing for me). I recompiled the plugin with -g even before finding this thread, and gdb reports the segfault as being in rewind() in libc6.so - not exactly helpful. I've since recompiled the main emulator with -g as well, but gdb still provides the exact same information.

Running the emulator and plugin (both with debugging symbols) under valgrind, in an attempt to get even a little vaguely useful information about the problem, does not result in visibly the same crash (which can normally be produced either by trying to run a game or by simply pressing the plugin's "Config" button in the Plugins tab), but does nonetheless result in a crash; the most visible differences are A) that the "Config" button now no longer produces a crash, and B) that instead of comng as soon as the ROM is loaded, the crash comes a little while after the game window appears (but before anything but black is displayed).

Configuring to run in a user directory, for me, does not change anything; what looks like the same crash occurs under the same conditions.

This feels most unhelpful, but I'm not sure what information you might need; if you want to try to track down the problem, however, I'm more than willing to try whatever measures seem appropriate and report whatever parts of the results you ask for.