What's new

glXn64 v0.4.1-beta

nullroute

Lost and loving it
I've gotten glN64 v0.4.1 ported to linux... in beta stages now. Unfortunately, I can't post attachments for some reasons, so I had to get Hacktarux to post it. Beta1 is posted in the glN64 v0.4 thread (right next door). I need people to tell me about any compile issues that they have. I fear there will be some incompatibilities with different opengl implementations, so let me know what ogl you have installed (mesa, xf86, uthaglx, nvidia, ati... etc) when reporting build errors.

Problems with games should be posted in the glN64 thread unless they are only occurring under linux and run fine on win32. N64 gpu hardware isn't exactly my bag of tricks... but porting is.
 
Last edited:

mojo

New member
ogl using: NVIDIA

I got bug for compiling on RH 9 Shrike:

g++ -g3 -DDEBUG -c -o Combiner.o Combiner.cpp
Combiner.cpp: In function `void Combiner_Destroy()':
Combiner.cpp:310: `glActiveTextureARB' undeclared (first use this function)
Combiner.cpp:310: (Each undeclared identifier is reported only once for each
function it appears in.)
make: *** [Combiner.o] Error 1

I'll have a check on Combiner.o to see the source of error.
 

killthegene

One Kool dude
g++ -g3 -DDEBUG -c -o Combiner.o Combiner.cpp
Combiner.cpp: In function `void Combiner_Destroy()':
Combiner.cpp:310: `glActiveTextureARB' undeclared (first use this function)
Combiner.cpp:310: (Each undeclared identifier is reported only once for each
function it appears in.)
make: *** [Combiner.o] Error 1

same error here. using mandrake 9.1 + nvidia drivers
 
OP
nullroute

nullroute

Lost and loving it
mojo said:
ogl using: NVIDIA

I got bug for compiling on RH 9 Shrike:

Combiner.cpp:310: `glActiveTextureARB' undeclared (first use this function)

I actually anticipated this error. The gl.h that I have declares the GL_ARB_multitexture extension prototypes always, I didn't know if this was standard on linux or a mistake in my gl.h. Anyways, on line 147 of OpenGL.h, there is a #define GL_ARB_multitexture_protos_declared. Just comment out or delete that line.

Before I can actually fix this problem, I'm going to need to use autoconf and write a script to detect this broken gl.h file.
 
OP
nullroute

nullroute

Lost and loving it
I haven't drank any coffee yet, so if you have already commented that line out and are still getting compile errors... It would be because I didn't get those compile errors. Prepend the function name with ptr_. I'll fix that in the src today... and I'll also make the BROKEN_GL_H fix a little more convenient. Sorry 'bout that.
 
OP
nullroute

nullroute

Lost and loving it
One more thing, could one of you post a copy of your gl.h file. SuSE ships with a defective one, and nVidia glx doesn't replace it.

And another thing, I accidently left the Makefile in debug mode, if you edit the make file, you'll see near the top a set of defines for CPPFLAGS, ASMFLAGS, and LDFLAGS for both debug and release. Just comment out the debug options and uncomment the release options. If you have an athlon processor, O2 will give you better performance than O3, so there are 2 sets of CPPFLAGS. It should make it run a little faster.
 
Last edited:
OP
nullroute

nullroute

Lost and loving it
killthegene said:
where would i find it?
/usr/include/GL/gl.h (hopefully)
if not there, then try /usr/local/include/GL/ or /usr/X11/include/GL.
I'm pritty sure that I've got the problem licked, but I'd like to have a properly functioning gl.h on my system. Stay tuned, beta2 is getting the final icing put on it now.
 
OP
nullroute

nullroute

Lost and loving it
glXn64-v0.4.1-beta2

Lets see if I have better luck using Mozilla to post attachments... here goes nothing.

Ok, heres the changes:
- new and improved... working Makefile
- config file support
- fullscreen is working
- changed the way ARB_multitexture ext's are guarded becuase of defective gl.h file shipped with SuSE 8.1
- tested and given stamp af aproval on linux and win2k from the same codebase

and if this post works... shipped, signed, and deliverred.
 
OP
nullroute

nullroute

Lost and loving it
Trotterwatch said:
Not sure why you can't attach things though Nullroute :(
It might have something to do with my ipmasq firewall... shouldn't though. I've already found a problem in the config file support... It apears that using "~/.gln64.conf" doesn't work as I hoped when bash isn't expanding the ~ character... Looks like I'll have to figure out how to get the home directory of the current user... shouldn't be too hard. Current workaround is to make a directory called ~ in the directory that your emu runs in. You'll need to escape it with a backslash. And make sure that you can write to that directory (chmod/own or just be root). I'll fix it in beta3.
 

blight

New member
Code:
#include <stdlib.h> // getenv
#include <stdio.h>

snprintf( filename, xxx, "%s/.gln64.conf", getenv( "HOME" ) );
 
OP
nullroute

nullroute

Lost and loving it
blight said:
Code:
#include <stdlib.h> // getenv
#include <stdio.h>

snprintf( filename, xxx, "%s/.gln64.conf", getenv( "HOME" ) );

Thank you very much blight. I knew there had to be an easyer way to do it... I just got done writing a passwd file parser to do it the hard way <i>(it gets funnier)</i> only to find that when I tested it as an unprivledged user, mupen64 segfaults. and if I make mupen suid, then GTK+ complains and sais I need to make a helper program for it. I'll add the feature, but it will be unused for a while since only root can run mupen.
 
OP
nullroute

nullroute

Lost and loving it
Quick patch to v0.4.1-beta2a, special thanks to blight and a coffee/cigarette break... since I can't attach files you'll need to cut along the dotted lines. put this text into a file called Config.cpp.patch (or anything you want to call it.)

EDIT : for some reason, the include line is not showing properly on my browser... even though its in a code block?...
the file is supposed to be stdlib.h. if you are not seeing it either, you might want to tell you browser to show you the page source and copy the patch from there.

reEDIT : more concise patch (don't bother if you have already patched)
Code:
9a10
> #include <stdlib.h>
23c24,25
< 	const char * CONFIG_PATH = "~/.glN64.conf";
---
> 	char * CONFIG_PATH = NULL;
> 	char config_path_buf[1024];
27a30,39
> #ifndef WIN32
> 	if( NULL == CONFIG_PATH )
> 	{
> 		snprintf(	config_path_buf,
> 					sizeof(config_path_buf),
> 					"%s/.gln64.conf", getenv("HOME") );
> 		config_path_buf[sizeof(config_path_buf)-1] = 0;
> 		CONFIG_PATH = config_path_buf;
> 	}
> #endif

then say the magic words :
Code:
bash# > patch Config.cpp Config.cpp.patch
bash# > make
And presto-chango, you have working config file code.
 
Last edited:

blight

New member
... and if I make mupen suid ...
are you CRAZY!? :gunman: :w00t: :ranting: (<-- don't take this too serious)
making mupen suid root is very bad... it runs other programs which could easily take over control of mupen, if designed to do so - i know it's not a target an attacker would choose, but still it is just stupid to setuid root mupen!
but you know the right way anyway now :)
we designed our plugins to use the CWD... mupen should be used with some wrapper script (like loki did with their games... ;)) which noone has written yet

about the include lines: use &lt; instead of < and &gt; instead of > - the forum doesn't seem to do that automatically for some reason so it gets either stripped or is invisible because it's an unknown tag (i bet it gets stripped ;))

--blight
 

Top