Open Frank-74 opened 8 years ago
strange, the white textute disappears and the gun looks correctly after switching fullscreen/window...
Edit: Pain in the **\ getting a screen. Save screen from emulator doesn't work with this plugin. Had to use snipping tool in windows 8.1.
screenshots are not implemented in z64gl
Screenshots are something I could implement (if I was back on a home desktop). It's pretty easy really; I'd file a separate ticket about it myself right now if I was able to just add it in right afterwards.
Ok, would be nice to have screenshot support
@cxd4 If it's easy, surely its easy to describe what needs to be done to add it. ;)
I suppose this version needs to be able to be built in a Linux environment for you to contribute easily.
Still working on getting back to having PC access. These public computers all use crap like Windows 10, and I don't really feel like I have time to install and play with N64 emulators on them yet.
It's easy to code, but maybe I misrepresent whether it's easy to teach.
Use glReadPixels
to return a pointer to the canvas viewport for what RGBA to write into an array of bytes, then store that into something like a BMP file to export it as a BMP screenshot if you're not worried about compression. I have an example in bitmap.c
from the sources to my GL fork of angrylion's plugin, but it's probably messy to read when unfamiliar with the BMP specs and such.
OK, well I had some time and added a GTK menu option in 64-bit Mupen64 for Linux screen shots. https://github.com/cxd4/mupen86/commit/7a96ef0fd6f0ba27695a79e306c624d73caaceaa
So I should be able to test adding a screen capture function in z64gl on Linux now.
This seems to be fixed in the build I just did.
Edit: Nope, it came back when restarting the level...
Bond's head is white
Both of you guys' screenshots look a million times better than what I get on the Linux build.
You're lucky the game even has any textures at all.
What do you get on the Linux build?
Bond's head is white
The first time I ran my new build, the gun and bond's hair was ok. Until the end of dam sequence, bond's hair was white like above before his bungee jumping. I was too late, to hit fn+F3 to take a screenshot, restarted the level and then the gun was white again.
What do you get on the Linux build?
http://i.imgur.com/TdfNX4r.png http://i.imgur.com/3LTBGC7.png
Looks like that GLSL z64gl is running off of isn't very friendly with optimizations done on Linux.
You kids these days and your 3-D textures...why, when I was your age....
@cxd4 Is it just goldeneye? Or do you get the same errors in other games too?
Perfect Dark, too.
Really only spots at games that use the lightning effects of the microcode and cause the GLSL errors in the console you can see from my screenshots. (You and Frank might only be getting a fraction of them, since the GLSL optimizer on Windows doesn't optimize as many parameters out of the code and risk errors as much.)
Or just games using that type of microcode.
There's a new fixed ucode for Goldeneye here: https://github.com/gonetz/GLideN64/commit/efd9b0fa5fe1010d68af60c3db7265bf0ddbc57e
I doubt it makes a difference with the textures though.
Also for Majora's Mask here: https://github.com/gonetz/GLideN64/commit/9e8b32fc8928531b5d17eeec1a10ddaefd2af009
I thought LLE could work without them though.
Is there a way to see the logger output in windows for z64gl?
Is there a way to see the logger output in windows for z64gl?
FILE *file;
file=fopen("loggerout.txt","a+");
fprintf(file,"Label: %d", blah); //
fclose(file);
Perfect Dark, too
I think there was a similar problem in Diddy Kong racing, I can check when I get home
Is there a way to see the logger output in windows for z64gl?
It writes everything to logfiles if you compile with RGL_ASSERT
@Frank-74 This plugin does not implement ucodes
It still goes to the console, but Windows hides it from you.
Try launching 1964.exe or whatever from a command prompt window instead. If you're lucky and the choice of Windows subsystem interacted with doesn't screw up the stdout
reference, you'll see printf output there.
I can confirm there are the same GLSL errors on Windows. If I test Goldeneye or Perfect Dark it fills z64log.txt with shaders, so something goes wrong
But not in Diddy Kong Racing, there's a different problem
Thanks for the responses. I tried launching 1964 through command prompt and it doesn't show. I think it has something to do with the emulator because I just tried m64p 1.5 on windows and it shows the z64gl output on a cmd window. For now, I guess i can just use m64p or log to a text file. Maybe later, i'll look into figuring out how to get it to display cmd window in 1964.
The Windows subsystem IIRC is set to reconfigure the STDOUT stream by default, so Mupen64Plus probably either uses the console subsystem or has it showing in the console because it re-uncorrupts the standard output stream that Windows corrupts while initializing the UI cruft.
There's some function to fix Microsoft's hackiness and re-attach the console to stdout. I forgot which one.
Actually paying attention to it, I notice only one type of error, really.
Let me know if anyone sees any GLSL error other than this type:
uniform sampler2D texture0;
uniform sampler2D texture2;
void main()
{
vec4 c = vec4(0,0,0,0);
vec4 e = gl_TextureEnvColor[0];
float k5 = gl_TextureEnvColor[1][0];
vec4 p = gl_LightSource[0].specular;
vec4 fog = gl_LightSource[0].diffuse;
vec4 b = gl_LightSource[0].ambient;
vec4 t1 = texture2D(texture0, vec2(gl_TexCoord[0]));
vec4 t2 = texture2D(texture2, vec2(gl_TexCoord[2]));
c = clamp(
vec4(
(vec3(t2) - vec3(t1)) * vec3(0/*LOD_FRACTION*/) + vec3(t1),
(t2.a - t1.a) * 0/*LOD_FRACTION*/ + t1.a
),
0.0,
1.0
);
c = clamp(
vec4(
(vec3(c) - vec3(0.0)) * vec3(gl_Color/*SHADE*/) + vec3(0.0),
(0.0 - 0.0) * 0.0 + c.a
),
0.0,
1.0
);
c = vec4(
float(gl_Color.a/*SHADEA*/) * vec3(fog/*FOG*/) + float((1.0 - gl_Color.a/*SHADEA*/)) * vec3(c/*PREV*/),
1.0
);
gl_FragColor = c;
}
It's generated in rgl_rendermode.cpp
, by the way, but I don't have time to look at it.
There are still white/missing textures. I looked into it and it seems to be a problem with the hardware framebuffer code. The plugin generates white fb textures for Bond's head for some reason...
I thought maybe it could be combiner-related, but the white textures went away in GoldenEye for me when I made the change locally. It's probably something else then.
I can confirm there are the same GLSL errors on Windows. If I test Goldeneye or Perfect Dark it fills z64log.txt with shaders, so something goes wrong
I was suspecting that these should be fixed, if they have been fixed on Linux, but I guess whether a graphical difference is amounted to from the errors was a point of variance I did not foresee.
Bond's watch is all white for me (press start ingame)
Hmm yeah it is that way here as well. It turns gray once it fully loads in to the watch menus though.
I guess it was hard to spot with such a drastic removal of blank whiteness after fixing the shader compile.
I noticed this is partially fixed in my fb-valid branch. I merged it now, it's better than no implementation. There are still white textures. The first level looks ok but the watch is white again in the frigate level https://github.com/purplemarshmallow/z64/commit/d45e6baaae47acad62401a06355fdea878367156
The gun has missing texture, also the red/white stripe texture has error when you move closer to it.
Edit: Pain in the **\ getting a screen. Save screen from emulator doesn't work with this plugin. Had to use snipping tool in windows 8.1.