purplemarshmallow / z64 Goto Github PK

The only warning message left now when doing make on this plugin on Linux is

Package kbproto was not found in the pkg-config search path.
Perhaps you should add the directory containing `kbproto.pc'
to the PKG_CONFIG_PATH environment variable
Package 'kbproto', required by 'x11', not found

I always just ignored it, and never tried to fix it, since the plugin has always just worked all the same.

Since it's the only remaining message though I think I might look at what is causing that once I patch a few warning fixes for the C++ code first.

Just was wondering if it would be possible to allow for rendering at a ingame res or at a low enough res that covers all possible n64 resolutions, and then using a high quality GPU based rescaler (such as NEDI or jinc) to rescale the image back up to native window resolution.

Might help with performance when implementing programmable blending or N64 depth mode emulation on the GPU.

Setting it to 1, doesn't allow me to enable fb reading.

I want to get this working. Buffers are overlapping in this game. z64gl currently just removes overlapping buffers. From what I can see this effect should work if the content of the old buffer is copied to the new buffer before removing it (exactly at this point https://github.com/purplemarshmallow/z64/blob/master/src/rgl.cpp#L646 )

I can't find a good way to copy from one texture to another texture. Does someone who knows Opengl better have an idea? Maybe @mudlord ?

This image is not quite correct, first Buffer 2 is rendered and then Buffer 1 is rendered on top of that

Would it work out if we try to do all blending on the GPU? There is one other plugin apart from GlideN64 that does this, but that plugin doesn't do noise, alpha compare, depth as well as other things. It uses neat things like rectangle packing though to pack all textures into one quad to minimize GL state changes.

GLideN64 and Glide64 both use per-game hacks to emulate this but is it really necessary? Looks like a normal FB effect but the texture format is special (8 bit CI?)

Something to do with tiles goes wrong in these games. I think the load_tile command works incorrect (?)

https://github.com/purplemarshmallow/z64/blob/master/src/rgl_rendermode.cpp#L309

const char * write;
 if ((...)
    write = "gl_FragDepth = c[0];";

write is a pointer and there is no malloc anywhere. Isn't this a serious problem, or do I miss something?

Hi,
I was wondering if there is any compilation guide or instructions.
I want to try out some things in a private fork, and I was wondering how to compile this.

Thanks.

• Starcraft corrupt images in menus
• Glover crash after intro
• F-Zero X texture garbage in menus
• Vigilante 8 texture garbage
• Mario no Photopi corrupt images

Quest 64, Mario, Virtual Chess, Bomberman, Zelda, Banjo-Kazooie ...
Seems any game with 3-D in it will suddenly terminate z64gl (but not z64) after a few seconds.

Virtual Chess 64 doesn't crash if I press through the 3-D in the intro and switch from the 3-D to the 2-D chessboard, then I can play forever without any crashing, I think.

Could this be a 64-bit issue or an issue just with the Linux build, or even a driver issue on my end?

Can somebody use Visual Studio to do a 64-bit build of this plugin? I know we have a working 64-bit interpreter-only Windows emulator, Project64, that people should be able to plug z64gl into.

Otherwise when I wake up tomorrow I will start to look at debugging this.

@purplemarshmallow do you know which commit(s) got the HUD to even display? Nice work. I would like to find out so I can port it to other plugins like Glide64 if possible.

Angrylion's commit r96 fixed this issue, I believe. https://sourceforge.net/p/angrylions-stuff/code/96/tree/trunk/mylittle-nocomment/n64video.cpp?diff=55bb05dc27184618d775bec1:95&diformat=regular

Your hands and your weapon ingame are invisible

Some characters are red. Correct with angrylion's plugin

combiner?

Performace is significantly worse with the threaded=1 option on my system (Intel Core i5-2450M)

Tmem address needs to be wrapped in case of overflow. see gonetz/GLideN64#571

This is currently WIP I want to upload it when I finished cleaning the code. I'm planning to integrate angrylion's plugin and support both hardware and software rendering. There should be as much common code as possible. The plugin already shows improvements. The crash in Glover is gone and textures in Chopper attack are fixed. The problem is that correct code can cause bugs because another part of the plugin relies on incorrect results. Some textures are buggy in this branch.

@LegendOfDragoon you said you are interested in development. I think you should know in which direction I want to move this.

Only older intel GPUs are affected. Happens on intel HD 3000 but correct on intel HD 5500.
The z64 software plugin has the same problem. Coincidence?

The problem here is the load_tile or load_tlut command or both
works with the angrylion integration branch

At least from a brand new file, Mupen64 0.5 instantly segfaults without any error messages to the console at the stroke of 12 at the Night of the Final Day, at the instant in which the cutscene for the Clock Tower unwinding and opening the door to the top should normally begin to play.

Works fine in angrylion LLE.

I will look at debugging this issue myself, but in case anyone else is interested, here is the Mupen64 0.5 saved state I used to double-check that this happens more than just one random time (not sure whether or not it will load on Mupen64 for Windows):
https://dl.dropboxusercontent.com/u/16494013/n64/drdram/Legend%20of%20Zelda%2C%20The%20-%20Majora's%20Mask%20(U)%20%5B!%5D.st0

https://github.com/purplemarshmallow/z64/blob/master/src/rgl_rendermode.cpp#L27
N64 depth compare modes can be approximated with OpenGL depth compare. In this article it's described very well http://gliden64.blogspot.co.at/2014/07/depth-buffer-emulation.html
GLideN64 does not have as many depth compare issues I think that's a good reference here.

I can confirm these issues in z64gl come from incorrect depth compare emulation (and other plugins with hardware rendering work correctly):

• Super Mario 64 missing hand at title screen
• Winback missing HUD
• Duke Nukem 64 missing menus and HUD
• Superman incorrect background assembling effect during intro
• Hexen missing weapons(?)

With fullscreen res set to 1024x768, going full screen appears to be the same res as 640x480 fullscreen, only difference is larger screen.

640x480

1024x768

happens randomly and only if linker optimizations are enabled. So I'm wondering if there are more memory issues.

It just seems to make games slow for no benefit. Battle for Naboo, for example.

This is a design flaw in this plugin. The UpdateScreen call from the emulator is ignored in fact. Instead the plugin updates the screen at VI origin change. This has some bad consequences. Character models in Dark Rift disappear because buffers are displayed at the wrong time. Also single buffered games do not work because VI origin never changes (Quake/Quake II underwater, Vigilante8 pause menu, Taz Express pause menu).

The force swap option in this plugin sloves these problems but it's very hacky and it breaks Mario Party. With force swap UpdateScreen is still ignored. Any attempt from me to fix it properly also broke Mario Party. It causes very strange problems broken rendering and flickering.

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.

What's wrong with the backgrounds in this game? The z64 software plugin renders both, the broken background and the correct image

z64gl:

z64:

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Merry Christmas!
z64gl now supports these fancy VI scaling effects used in Rogue Squadron, Jet Force Gemini and many other games. Since this has just been added it may not work perfectly.
Here's a build for anyone interested:
z64gl.zip

Ever since I got a "new" laptop (it's actually older but that was on purpose), I notice how much slower z64gl is on this mobile chipset integrated piece of Intel. Err I mean shit.

Really any game with plenty of 3-D triangles on the screen seems to be full speed all the same. The FPS just tanks massively when there are lots of texture objects and tiles being drawn and created. I think it's something under rglTiles exploiting Intel's inept graphics driver design for efficient texture creation and deletion calls. z64gl seems to call glCreateTexture and DeleteTexture a ton of times. Or maybe it's something else. I briefly tried to play around with breaking things on purpose to see what was slowing everything down but that ended up fooling myself. Was definitely full speed tho....

If there are any plans on the side or ideas for rewriting z64gl's 2-D tile and texture rendering code that would be great.

correct with the z64 software renderer!

It crashes with the official r17 version and also with the current master
Savestate: Kirby 64 - The Crystal Shards (E).pj.zip

No crash with the angrylion integration branch. So the problem is either in the load_tile, load_tlut or load_block commands or in rdp_process_list (because I replaced these parts in this branch)

These games used to run very slow with z64gl and gfx were broken.
I made a half-fix, the slowdown is fixed and gfx look better but still not correct
65cf203

The probem is in the load_block command

I was interested in testing the improvements you've made to this fork, but I can't get PJ64 or mupen64plus to recognise the dlls the Visual Studio Project file produces.

Both games use the same kind of framebuffer effect. (Color buffer data is coupied correctly but not depth buffer data?)