glXn64 v0.4.1-beta

[killthegene]

judging by the windows shots of this plugin id say this was a bug: (perfect dark) screenshot attached

 

[nullroute]

I'd have to agree, that certainly does look like a bug, I currently do not have a copy of Perfect Dark, so I'll have to procure one first. Thank you, and please inform me of any other games that are having this kind of problem. Also, please test these games on windows (with the win version of the same emulator if possible). I've tested with Mario64 and Zelda so far and not seen any problems... I hope other games don't look _that_ bad.

EDIT : I realize that I did do some gcc specific things in the x86 asm (only saving registers that gcc requires preserving of). I'll fix that to preserve all registers that I use in the next release as this is poor practice and might not even be compatible with older/newer versions of gcc. (although, I imagine that this would cause a segfault before it would cause graphics glitches, but I'm sure it would cause _unexpected_ behavior on other compilers)

reEDIT : It seems that I have broken all 3D graphics between beta1 and beta2... oops. I'll try to have this fixed before the end of the day (probably a caffine deficiency somewhere)

re-re-EDIT : My mistake, 3d works... I'm working on removing Intel endian stuff... and forgot to add -DINTEL_BYTE_ORDER to make file, so was getting bad byte order in fixed point matrix translations. This is not part of the beta2 release so... 3d was only broken here. (told you it was a lack of coffee).

As for the problem with perfect dark... there was a slight oops in RSP.cpp that affects all 8MB-RDRAM games. Change RSP.cpp line 274
from : RDRAMSize = 4 * 1024 * 1024;
to : RDRAMSize = 8 * 1024 * 1024;

This fixes similar problems in Zelda MM. Sorry bout that

 

[killthegene]

the blur effect in pd seems to be missing now (the windows shot aint mine, i got it from the other thread)

 

[nullroute]

the blur effect in pd seems to be missing now (the windows shot aint mine, i got it from the other thread)

I'm seeing the same output from the windows version. It seems that Clements was able to take a screenshot that has the blur effect working. Not sure if it was from a beta that Orkin gave him or what, but no matter what settings I try, I can't get the blur effect in win32 or linux. Perhaps you should post this on the glN64 thread as Orkin knows more about the actual hardware emulation.

As for a Config dialog, I'm working on that and debug dialog too. I'm also working on getting rid of intel dependencies (although I don't have a mac to test on). Next beta will have (at least) a working config dlg.

 

[Gaenya]

Nullroute i need help compiling the sources:

g++ -O2 -mcpu=athlon -fomit-frame-pointer -c -o Combiner.o Combiner.cpp
In file included from OpenGL.h:24,
from Combiner.cpp:2:
/usr/include/GL/glxext.h:363: syntax error before `(' token
/usr/include/GL/glxext.h:365: `PFNGLXGETPROCADDRESSPROC' was not declared in
this scope
/usr/include/GL/glxext.h:365: typedef `__GLXextFuncPtr' is initialized (use
__typeof__ instead)
In file included from FrameBuffer.h:5,
from gDP.h:5,
from gSP.h:6,
from OpenGL.h:52,
from Combiner.cpp:2:
Textures.h:87: syntax error before `)' token
In file included from Combiner.cpp:2:
OpenGL.h:75: syntax error before `,' token
OpenGL.h:79: 'BOOL' is used as a type, but is not defined as a type.
OpenGL.h:80: 'BOOL' is used as a type, but is not defined as a type.
OpenGL.h:82: 'BOOL' is used as a type, but is not defined as a type.
OpenGL.h:83: 'BOOL' is used as a type, but is not defined as a type.
OpenGL.h:84: 'BOOL' is used as a type, but is not defined as a type.
OpenGL.h:86: 'BOOL' is used as a type, but is not defined as a type.
OpenGL.h:87: 'BOOL' is used as a type, but is not defined as a type.
OpenGL.h:88: 'BOOL' is used as a type, but is not defined as a type.
OpenGL.h:90: 'BOOL' is used as a type, but is not defined as a type.
OpenGL.h:91: 'BOOL' is used as a type, but is not defined as a type.
OpenGL.h:92: 'BOOL' is used as a type, but is not defined as a type.
OpenGL.h:93: 'BOOL' is used as a type, but is not defined as a type.
OpenGL.h:94: 'BOOL' is used as a type, but is not defined as a type.
OpenGL.h:95: 'BOOL' is used as a type, but is not defined as a type.
OpenGL.h:101: 'BOOL' is used as a type, but is not defined as a type.
OpenGL.h:102: 'BOOL' is used as a type, but is not defined as a type.
OpenGL.h:107: syntax error before `[' token
OpenGL.h:108: 'BYTE' is used as a type, but is not defined as a type.
OpenGL.h:109: 'BYTE' is used as a type, but is not defined as a type.
OpenGL.h:112: 'BOOL' is used as a type, but is not defined as a type.
OpenGL.h:114: 'BYTE' is used as a type, but is not defined as a type.
OpenGL.h:116: 'BYTE' is used as a type, but is not defined as a type.
OpenGL.h:126: syntax error before `;' token
OpenGL.h:127: syntax error before `;' token
OpenGL.h:128: syntax error before `;' token
OpenGL.h:130: syntax error before `;' token
OpenGL.h:131: syntax error before `;' token
OpenGL.h:132: syntax error before `;' token
OpenGL.h:133: syntax error before `;' token
OpenGL.h:134: syntax error before `;' token
OpenGL.h:135: syntax error before `;' token
OpenGL.h:136: syntax error before `;' token
OpenGL.h:137: syntax error before `;' token
OpenGL.h:138: syntax error before `;' token
OpenGL.h:139: syntax error before `;' token
OpenGL.h:151: syntax error before `;' token
OpenGL.h:152: syntax error before `;' token
OpenGL.h:153: syntax error before `;' token
OpenGL.h:160: syntax error before `;' token
OpenGL.h:162: syntax error before `;' token
OpenGL.h:163: syntax error before `;' token
OpenGL.h:164: syntax error before `;' token
OpenGL.h:165: syntax error before `;' token
OpenGL.h:166: syntax error before `;' token
OpenGL.h:167: syntax error before `;' token
OpenGL.h:168: syntax error before `;' token
OpenGL.h:169: syntax error before `;' token
OpenGL.h:170: syntax error before `;' token
OpenGL.h:171: syntax error before `;' token
OpenGL.h:172: syntax error before `;' token
OpenGL.h:173: syntax error before `;' token
OpenGL.h:174: syntax error before `;' token
OpenGL.h:175: syntax error before `;' token
OpenGL.h:176: syntax error before `;' token
OpenGL.h:177: syntax error before `;' token
OpenGL.h:178: syntax error before `;' token
In file included from Combiner.cpp:3:
Combiner.h:293: syntax error before `,' token
In file included from Combiner.cpp:4:
NV_register_combiners.h:18: 'BOOL' is used as a type, but is not defined as a
type.
NV_register_combiners.h:54: syntax error before `,' token
In file included from Combiner.cpp:5:
texture_env_combine.h:12: 'BOOL' is used as a type, but is not defined as a
type.
texture_env_combine.h:20: syntax error before `,' token
In file included from Combiner.cpp:6:
texture_env.h:13: syntax error before `,' token
In file included from Combiner.cpp:7:
Debug.h:26: syntax error before `,' token
Debug.h:36: syntax error before `;' token
Combiner.cpp: In function `void Combiner_Init()':
Combiner.cpp:15: `struct GLInfo' has no member named `NV_register_combiners'
Combiner.cpp:17: `struct GLInfo' has no member named `EXT_texture_env_combine'
Combiner.cpp:17: `struct GLInfo' has no member named `ARB_texture_env_combine'
Combiner.cpp: In function `void Combiner_Destroy()':
Combiner.cpp:310: `ptr_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



thats on my gentoo box.

Thanks

 

[nullroute]

Nullroute i need help compiling the sources:
thats on my gentoo box.
Thanks

This looks like a rather interesting combination of problems. I'd like to know what version of gcc generated these errors. Also, it looks like your gl headers aren't behaving properly. You can get the gcc version by typing 'g++ --version'. If you could, I'd also like for you to post a tar of your gl headers. I've found that the gl headers on SuSE need special case code or they will produce compile errors; this may be true with Gentoo's headers as well. Make a tar of them like this :

cd /usr/include/
tar czvf GL_Headers.tgz GL/

hmm...[shaking his head] this discourages me a little (not about the port) because I've started a poll-thread trying to determine what distro of linux will be my next development platform (since I've gotten irritated with SuSE and RedHat)... and so far Gentoo has been the dominant choice.

 

[blight]

gentoo feels a bit like debian, clean and straight!

 

[Gaenya]

This looks like a rather interesting combination of problems. I'd like to know what version of gcc generated these errors. Also, it looks like your gl headers aren't behaving properly. You can get the gcc version by typing 'g++ --version'. If you could, I'd also like for you to post a tar of your gl headers. I've found that the gl headers on SuSE need special case code or they will produce compile errors; this may be true with Gentoo's headers as well. Make a tar of them like this :

cd /usr/include/
tar czvf GL_Headers.tgz GL/

hmm...[shaking his head] this discourages me a little (not about the port) because I've started a poll-thread trying to determine what distro of linux will be my next development platform (since I've gotten irritated with SuSE and RedHat)... and so far Gentoo has been the dominant choice.

g++ (GCC) 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r2, propolice)

some files from the GLHeaders file were links so the real files are on the GL file

 

[nullroute]

I had suspected that this was probably compiled with a developmental branch of gcc, but that was not the case. As for the gl header problem(s), it seems that you have the same problem with attachments that I do (hence my avatar). I have downloaded the Athlon GRP iso's of Gentoo linux and plan to install them some time this weekend. I'm not sure if this will help solve Geanya's problem, but it may help my own distro woes (see my thread in Tech Talk). Currently, I've been compiling with gcc 3.2, M$ VS.NET and VS.NET 2003 (all of which build working plugins on my test systems)

A note for all : I was rushing to get this port completed before school restarted, but I have missed that target by a little. I will continue work on this and post my progress, but I don't want people to expect the same rate of progress or response as previously because I will be devoting a bulk of my time to studies (and drinking). Sometime soon, I will have someone post a binary of beta2a (as attachments don't seem to work for me either), and I will try to have beta3 posted within a week. But, after that, development may take a backseat for a while (sorry , but school comes 1st). I hope you all (who can get it built and working) enjoy my contribution. I want to encourage you to keep this thread open and active as I am not abondoning this project... I just don't want people to expect more than I can give.

 

[Orkin]

A note for all : I was rushing to get this port completed before school restarted, but I have missed that target by a little. I will continue work on this and post my progress, but I don't want people to expect the same rate of progress or response as previously because I will be devoting a bulk of my time to studies (and drinking). Sometime soon, I will have someone post a binary of beta2a (as attachments don't seem to work for me either), and I will try to have beta3 posted within a week. But, after that, development may take a backseat for a while (sorry , but school comes 1st). I hope you all (who can get it built and working) enjoy my contribution. I want to encourage you to keep this thread open and active as I am not abondoning this project... I just don't want people to expect more than I can give.

Thanks nullroute for all your work, it's greatly appreciated!

I understand being too busy to devote much time to it. That's basically where I am with glN64 right now too. v0.4 was slightly rushed (hence the bugs) because school was starting, and I wanted to get it out the door before I got too busy. Now that school has started, I haven't had time to touch it in nearly a week.

I'll still be working on it, I'm just not able to as much as I'd like anymore...

 

[mojo]

Nice work, now the plugin compile flawlessly in my Linux. I'm looking forward to seeing a cfgPlugin written in GTK2 (GTK+ is OK but I hate its design).

 

[mojo]

Now, here's a feedback for this plugin port. This plugin port compile with no trouble at all with nvidia OpenGL driver. The plugin can run most game but I still encountered some seg fault error everytime I resest a game. And some games has seriously bad gliches such as some Japaneses game like Doreamon. The 2nd thing is this port still lack of cfgPlugin to change the settings. One thing I have to imply here that speed is implemented much in this port. Mario 64 runs at 15fps compared to 7fps of old port of blight. And one thing happen is the Up Button does not work with this plugin. Dun no the reason why. So overall, this plugin is good for playing basic game like Mario64 or Mario Kart64. Nice work, I think blight and you should corporate to develop linux port of glN64.

 

[blight]

what about my new port?
http://www.emutalk.net/showthread.php?threadid=15879

 

[nullroute]

Now, here's a feedback for this plugin port... but I still encountered some seg fault error everytime I resest a game.

Thanks for the feedback. I had noticed the segfault, but it doesn't occure on all games, and I think I noticed similar crashes using a different plugin (assuming maybe a bug in mupen), but I haven't done enough testing to be certain.

The 2nd thing is this port still lack of cfgPlugin to change the settings.

You can edit the file '~/.glXn64.conf' after the plugin has run once. It has all of the options available in the win32 version although fullscreen res doesn't have an effect, windowed res is used for fullscreen too.
As for a cfgPlugin, I have attempted to make one, but SuSE's glade packages are seriously broken (not compatible with autoconf/automake packages, and their gtk/gnome devel packages are missing important header files... like gnome.h). I've dl'd Gentoo, but haven't had the time to install yet.

One thing I have to imply here that speed is implemented much in this port. Mario 64 runs at 15fps compared to 7fps of old port of blight.

Thanks for the note about the speed (it probably wasn't really my doings, but the fact that its compiled with optimizations on your local machine rather than a binary distribution compiled for i386)... although, 15fps sounds a bit slow... I guess I should test on a system that's not as dosed up on steriods as my development system.

And one thing happen is the Up Button does not work with this plugin. Dun no the reason why.

hmm... but other buttons <i>do</i> work?... that's a problem that doesn't seem to make much since ( should be all or none, I'd think? ). I don't do any input processing at all. SDL forwards all of the input to wherever it needs to send it, and I just let it fly by.

Nice work, I think blight and you should corporate to develop linux port of glN64.

Thank you. Perhaps Blight and I getting together is not a bad idea, if time permits. There's still plenty to be done to remove intel-isms, do some clean-ups/speed-ups, and merge in any changes that Orkin might post (as the goal is to deliver a single code-base back to Orkin which will compile on linux, win32, and maybe macosx )... but the problem is that school takes priority.

 

[mojo]

Yes, your new port is fascinating blight.
But I found a weird bug with Mario 64. At the Intro, the Mario Face has a red left eye, this bug just occur in 0.41, old 0.4 didn't produce this.
And I have to say one thing, your plugin run SUPER SMOOTH with Diddy Kong racing *Hacked*. The sound is so smooth, the speed is also the best, graphic has no glirches at all. I'm quite suprised that a young emu like Mupen can emulate successfully a game that some WIN emu can't perform at the best.
And the speed is improved alots, Mario 64 and Mario Kart 64, Diddy Kong Racing, Doraemon, GASP Fighter, Dumble Bucke runs at high fps. But with some games such as such as Doom 64, Duke Nukem, Centre Court Tennis glN64 of nullroute achieve a higher fps and the graphic looks sharper.

And new H/W Buffer and Aplha Dither creates many seg fault, sometimes I was playing with those settings enabled, my Linux runs super slow and crash up. And some games can't run if those settings are enabled such as Battle Phoenix 64, Dark Rift, 007 Golden Eye. I think because the plugin takes up all the resources of Linux.

 

[mojo]

And yeah, blight has a nice GUI configurator. As I've said before, my point of view about GUI on GNOME must be GTK2. So it would be nice if you use GTK2 for next version.

And I also found a bug related to Pad plugin. Blight's gLN64 somehow make some Pad plugin not work properly (bligh's SDL or default Mupen), this bug happens at both 2 ports, the Up button doesn't work, sometimes Direction Buttons freeze up.

 

[mojo]

So, blight and nullroute, I have a tons of graphic glitches report here, do u need me to post them up?

And one problem I have with Paper Mario, the game freeze up at the intro when Koopa command his wizard to cast spell on Stars. Is that your plugin fault or emu fault? The TR64 plugin not work with this game so I can't test it.

 

[blight]

mojo: these are glN64 bugs and most likely not related to the ports (except for the weird red eye )
maybe you have noticed that the HW framebuffer is still experimental and needs a lot of texture memory from your card (which will go into RAM when texture mem is full i guess) if glXN64 produces sharper results, then most likely you use different settings for both...
also i do not see any reason for that gtk+-2 sh** - not everyone uses gnome2, i do not know it + gtk+-1.2 and 2.0 cannot exist in the same process space at the same time i think because of naming conflicts and functions with same names but different args, ... - it segfaults pretty soon when gtk 1.2/2 calls are mixed kinda randomly

 

[nullroute]

I think I might have left 2xSai enabled per default in my port, as before I had config file support, this was the only way to change configuration options. That might explain the sharpness difference.
Also, I didn't know that gtk 1.2 and 2.0 couldn't coexist (I've not messed with gui programming in linux). I'd thought that the gtk project was more mature and design oriented than one that would introduce versionability issues like that. I know that kde will have versionability issues as long as they are based on Qt which has inherent binary-versionability issues unless they start using an object-request model. (sigh... the joys of modern software engineering)

 

[blight]

the issues come from using both versions at the same time in the same process space dude - this won't work with most libs - if mupen was totally gtk+-2 then gtk+-2 plugins would work, but not 1.2 anymore