glN64 v0.4

[mojo]

In zelda, the sun in the background splits to 2.

 

[mojo]

In zelda majora mask, the sun texture in the background splits to 2.

 

[nullroute]

For people with a crash when starting full screen, there was a problem with v0.3.2 and 1964 where starting full screen would cause a crash. simple work around is to start in window and press Alt+Enter to switch to full screen. The problem may still exist in v0.4, but I've grown to accustom to starting in a window to test.
I'd like to appologize for my previous posting about performance, after updating drivers to detonator 45.23, performance went back to normal. For some reason this plugin finds all the bugs in nvidia's drivers.

Keep up the good work

 

[DrewDown]

Zelda Oot Opening Screen shot

Hello all. When I use glN64 0.4 with 1964 and play Zelda Oot, the opening screen with Link laying down in his room is all green and messed up. Is anyone else having this problem, or is there a way to fix this?





Thanks all,

DrewDown

 

[Clements]

Hello all. When I use glN64 0.4 with 1964 and play Zelda Oot, the opening screen with Link laying down in his room is all green and messed up. Is anyone else having this problem, or is there a way to fix this?

Enable the RSP.dll for these to appear correctly (copy from PJ64 to the 1964 plugin folder)


Maybe for the next version of 1964 it should be bundled with an RSP (Perhaps Rice's Unofficial, if PJ64's RSP is to only be bundled with PJ64)

 

[loleoc]

Project 64 1.5 SP1 works well to me with this plugin. Must be a Radeon problem.

 

[DrewDown]

Hey Clements, thanks for the advice but I already tried that and the problem is still there.... darn!! Now what??

Thanks Again,

DrewDown

 

[xenSity]

Plugin Perils

Project 64 1.5 SP1 works well to me with this plugin. Must be a Radeon problem.

Must be. I've tried getting this plugin working with PJ64 since the early-mid glNintendo64() days and with no luck.
Hopefully my system specs are listed below (if not, i'll post them later) but I have always ran Win2K SP3+ on a Radeon 9700.
The end result with previous glNintendo64() versions was a "This program has caused an error" dialog or something similar, letting drwatson dump a lot of memory into an error log. (I hated that, disabled now)
With the newest glN64 instead of an error, PJ64 waits for a few seconds and then closes without message.
It works in 1964 fine. I'd rather use PJ64 because the sound works much better for me.
Anyway hopefully my configuration might assist in some way.

 

[The Khan Artist]

Sorry if all these bug reports are getting you down, Orkin. We still love you. :*

Anyway, I'm getting random lockups when using pure 32-bit textures in combination with 2xSaI. I have, however, found one that is completely repeateable, in both 1964 and Mupen:

Set Texture Bit Depth to 32-bit only, and enable 2xSaI. Start Super Smash Brothers. Do a standard single player game, choose Link. You'll see the briefing screen and hear the announcer say "Link vs. Link". Then... nothing. The game locks up.

And another one that doesn't seem to be affected by 2xSaI setting, or emulator. Do single player as Link and get up to the "break the targets" level, level 4, IIRC. Play for a few seconds and it freezes.

 

[dukenukem]

damn gln64.4 was working now it's back to the black screen of death and freezing my system.

 

[xenSity]

Lingering Lockup

I'm getting random lockups when using pure 32-bit textures in combination with 2xSaI. I have, however, found one that is completely repeateable, in both 1964 and Mupen:

Wow, I was wondering what that was. I ran into that just recently.
Fired up Mario Kart 64 and let it run in the demos. During some portion of the demos, it locks up when in that configuration. [edit: I don't know if it changes for other people or not].
Some observations were that in the status bar at the bottom of 1964, all processing halts to 0%, yet the emulator itself is still responsive.
Perhaps it is waiting for something.
Oh well. It is still an awesome plugin having gone so far so fast.
Figured I would throw a shoe at that tiny bug.
Keep it up.

 

[mojo]

I found another bad bug if you run on 1964. When press F12 to capture screenshot, the toolbar graphic runs up along the program. It's hard to describe. Everyone should see this bug really clear if press F12.

 

[nullroute]

I found a cafine deficency in the source code (simple type-o that could have been avoided by drinking more coffee).

File: FrameBuffer.cpp
Line: 26
Was: frameBuffer.top == NULL;
Should Be: frameBuffer.top = NULL;

I'm not sure what conditions are needed to invoke this bug, but it would cause free'd memory to continue to be referenced. That could most definately cause random crashes, freezes, and even purple screens of death. Try dl'ing the src and changing that line... see if it fixes some of the reproducable crashes.

 

[mojo]

With Paper Mario, there's small gliches when Mario's moving. the gliches is triangle black shape texture.

 

[Ninja Turtle]

Bad thing

conditions are needed to invoke this bug, but it would cause free'd memory to continue to be referenced. That could most definately cause random crashes, freezes, and even purple screens of death. Try dl'ing the src and changing that line... see if it fixes some of the reproducable crashes.

Freezes! Yes thats the point! :huh: Thanks for this information.
I hope this change will take effect! I figured out that this cool PlugIn freezes my screen sometimes an causes the emulator to crash seriously.

 

[The Khan Artist]

What do I need to compile glN64?

Also, regarding the "random lockup when using pure 32-bit textures and 2xSaI bug": My testing was done with the default 32MB texture cache size. Raising this limit to 128 or 256 makes lockups far less likely, although they still happen. Perhaps there is a memory leak somewhere?

 

[Moose Jr.]

Also, regarding the "random lockup when using pure 32-bit textures and 2xSaI bug": My testing was done with the default 32MB texture cache size. Raising this limit to 128 or 256 makes lockups far less likely, although they still happen. Perhaps there is a memory leak somewhere?

Sounds like a good hypothesis.... I had the same problems and noticed that the fewer memory-hogging options I had selected the longer it would go before locking. Have yet to try increasing cache size. Is the cache of the virtual type, like a page file? Or does it actually use your memory? I ask because I don't want to enter a number that exceeds my memory size (512 system, 128 video).

 

[nullroute]

Yes, this code is directly related to texture cache, so increasing the cache size would reduce its likelyhood. To compile, you need Micro$hit Visul Studio.NUTz. also, I'd like to correct my post. the line in question is actually line 27. I had to remove the line #include <windows.h> for reasons that I'm not going to post for fear of getting too many people's expectations too high.

 

[Remote]

Yeah, we wouldn't want to increase expectations anymore then you just did...

 

[The Khan Artist]

To compile, you need Micro$hit Visul Studio.NUTz.

.NET? or .NET 2003?

And I would assume you need some sort of OpenGL SDK, but I have no idea what to look for.

And, uh, what #include statement are you referring to?