Full support for Banjo-Tooie
 

Okay I hope I don't totally sound like a complete idiot posting this, but here it goes. I was wondering if you guys could create full support for Banjo-Tooie for Project 64 1.7. I just got the U.S.A ROM a while ago and noticed every 15-25 minutes its been freezing on me like crazy! Most of the time it's random. It's at the point where I have to press Ctrl+Alt+Delete and end program, since I play in full-screen and the Esc key does not respond when the game has froze. Now, this could just be my computer acting up, but I can assure you that others have this same exact problem. I believe that it is possibly a Project 64 error (I apologize if it isn't). I can get further into detail if needed.

One thing you can do is press f5 when it freezes and supposedly it will save (at least thats whats game faq said [see squall I DO read the manual:p])

Just one question though. How are you able to play 1.7? I thought that was only available for donators/beta testers.

He stole it :eek: jk idk

Well, the truth is I don't have 1.7. Should I not have posted if I don't?

He didn't say he had 1.7 so...


No, it is OK.

It works better in 1964 0.8.5 or Mupen64 (or Project64 1.7), but on 1.6 you might still have some issues. Using the save state backup method ryancollins suggested should be pretty good for getting around that if you don't make save states too frequently and save natively, too.

Also make sure no cheats are on. The stability of this game is very much affected by certain ones.

Okay, thanks! It's just the 1964 input configuration is just such a pain to change the controls on.

Well 1964 1.0 and 1.1 have a more simplistic input configuration plugin, but even so far back as the 0.8.5 version of 1964 you can still always change the controller input plugin to the one Project64 uses to have that interface for changing the controls.

1964
 

I tried 1964 1.1 today, and it didn't go so well at all! Maybe it's just my computer, but that did not run well for me at all! I appreciate your guy's help, but I think I'll wait for a public release of 1.7 or maybe even donate (if the problem is fixed in the beta version). I first noticed the small lag, which was a pain, then I realized that when I put it in full-screen the screen flickers. I had other issues as well.

Well, about 1964, what's important is if you eventually find that the game crashes if you patiently try to play through it anyway?

The flickering and other graphics issues can be fixed in 1964, but I'd like to know if you find that the memory CPU is stable more-so than as with playing whilst using Project64.

Oh, and like I said, Mupen64 also plays the game pretty well, so whichever one has more stable memory. Don't worry about graphics or sound (or ease of input configuration) for now; those things can all be changed later.

For me 1964 doesn't freeze with Banjo-Tooie, but it does with PJ64.

I use 1964 exclusively for B-T. I wish PJ64 didn't have this issue, and I'd be happy to donate and get 1.7 if the developers could solve this problem definitively.

That's what I thought. Thanks for verifying, and I have read that Banjo-Tooie has been improved in the beta but have not tested that particular game thoroughly on 1.7.

However, what confuses me is this.
I did in fact test it thoroughly on 1.6, just not 1.7.

In fact, I completely played through Banjo-Tooie on Project64 1.6 without any cheats. I've been reading a couple reports of this game freezing on 1.6 recently and forgot about the confusing fact that I myself played through it on 1.6 without any issue.
So why am I the only one here noting the game to be working fine in Project64?

Could it be the RDB settings I am using? Someone want to test the RDB configuration I've described above?

I would be willing to test if I knew what the heck RDB settings were.

I left all settings on default when I played Banjo-Tooie on Project 64 1.6.

Alright first, the only easy way to access the RDB settings is if "Hide Advanced Settings" is disabled. You can disable that setting from the "Options" tab of the Options/Settings... dialogue in Project64.

Once you've done that, when you right-click Banjo-Tooie in the ROM browser, you should be able to pick "Edit Game Settings".

There are a lot of options you could set here, but the modifications I have made from the default are:

• Self-modifying Code Method: "Check Memory Advance"
• Advanced Block Linking: "Off"
• Use TLB: "Off"

Okay thanks, I'm going to try this right now! Hopefully it works :D!

I don't see the "Edit game settings" option, but I just chose my ROM directory (just now) and the status says "Issues (core)".

That's where you right-click on the entry for "Banjo-Tooie" to find the "Edit Game Settings" option.

Again, that option isn't visible in the right-click / context menu if "Hide Advanced Settings" was not turned on.

Okay I see now. The settings:
Self-modifying code Method: Check Memory Advance
Advanced Block Linking: Default (which I will change to off)
Use TLB: unchecked

Could having the Advanced Block Linking on default be the problem?

It could yes. It's one of the re-compiler controls.

For ABL, "Default" does indeed mean "On", unless the internal default was changed in the advanced settings.

Well then I'm going to test on from the start and see how it goes, thanks!

Sorry if I've confused myself on this, but just in case you meant testing it on as in with advanced block linking set to "On" in the RDB settings the testing I think should be done as with it set to off. Since the "Default" value basically already means "On" it was what you were already testing.

Otherwise I'd like to know how your test session goes. I want to find out why this game worked just fine for me all the time but not you guys.

Yeah I was testing it on "off". However I was playing for about 50 minutes and it froze again. A new record by far without freezing, but it still froze :(. But the weired thing about it is that it freezes my whole computer and even if I press F5 to save it won't let me, the only thing that responds is Ctrl+Alt+Delete and thats to end the program. Strange!

Also I'd like to say that maybe putting the setting on "off" did help more though because usually with it on default it freezes 15-30 and putting it on "off" gave me 50 minutes. Maybe it did help maybe it didn't.

It's possible, though that's quite a weird case of it freezing only then in that effect of your system's stability.
Man, got to find out why I played 100% through the game without freezing.

The biggest stability thing you can set in the RDB,
is if you change "CPU core style" from "Recompiler" to "Interpreter"

but that will slow the emulation down a lot ... if you can use small resolutions, speed-optimized settings and stuff to keep it as close to full speed as possible that should be interesting, but I'd like to know if you can get BT to freeze while using the interpreter

Again the problem is that the interpreter is slow heh...well I don't know how slow for you.

It's slow as hell when I put the game on Interpreter! I wouldn't know if it were to freeze though. If this means anything the Notes (Core) and Notes (default plugins) says R4300i_unhandled_opco[video](see GameFAQ).

"R4300i_unhandled_opco"
Ah weird that's totally not mentioned in the 1.6 database. Might be a different RDB file though.

Well how about, if you want to test one more time with the re-compiler, keep advanced block linking forced to "Off", but try changing the "self-modifying code method" to "Protect Memory" this time. Also, when I was testing BT just fine, I was using the "glN64 0.4.1" graphics plugin. See if you can install the glN64 plugin and use that in place of Jabo's Direct3D in Project64.

glN64 will not work with my graphics card (Radeon 9700) for whatever reason. Everything is black and white and you can't see anything but large white and black pixels. But I will try to put it on "Protect Memory". I think it's going to freeze, but it's always worth a try.

I tried testing it, but it won't stop lagging on the "Protect Memory" setting. It's going about 30 fps when I do it.

Darn. Then the next best thing would be to have back at "Check Memory Advance" while using saved states in case of a freeze.

The other really stable setting is "Change Memory & Cache", but I'm not quite sure. That might actually introduce one or two crashes known to happen in the game at some point, since both that and "Check Memory Advance" can be either faster or slower or more or less stable than the other, depending on the game. You might experiment, but don't be surprised if that doesn't cut it.

Otherwise 1964 0.8.5 and mupen should still work pretty good. The problem is that it sounds like you don't have top-end graphics hardware there (though glN64 is known to not be so stable lol). If you'd like see how Glide64 works, which if you install Mupen64 you get it bundled and ready to use.

I have a question about my graphics card. I have a Radeon 9700 from ATI. Are the HD Series better even though it is lower than 9700? (ex: Radeon 6990 HD better than Radeon 9700?) I don't really care about the HD just the performance. So what would be better for performance? I'm not quite sure if I made sense of that correctly or not, but hopefully I did. Also what video card do you recommend?

Isn't a Radeon 9700 an old 128MB card? I'd say you'd be better off using a HD5750.

I don't even know! This computer is from 2002 so I don't even really know XD. At the time though this type of computer was really good!

glN64 was updated officially last in 2003 afaik.

I don't know much of anything about Radeon cards. I've always wound up with the NVIDIA series for some reason.

From what I've read though I'm pretty sure Theshawty is right about that.

Can you even use a modern video card on your PC? If you have a radeon 9700 and your PC is 9 years old, you have an AGP slot, more recent cards are PCI express only. I think the last bunch of Ati cards that had AGP versions were the x1900 family. I have a 7 year old PC myself and i use an Ati X1950pro AGP which is, one of the very best cards you can possibly have on an AGP system (after that generation they stopped supporting the AGP slot).

So, if you just want to upgrade your card, your best bet is a x1900 family AGP card (good luck finding one though). It supports shader 3 and even though its a somewhat old card you won't need anything better than that for emulators, even for more demanding ones (PS2, Gamecube emulators for instance). Emulators are CPU intensive programs, you will get more performance gain if you upgrade that, although i have no idea what is the best CPU your motherboard can handle.

AMD stopped making reference design agp cards, but there are agp variants all the way till the 4000 series.

Really? I had no idea they went so far. I've never seen an AGP card ever since the x1900 family in my country and i thought they dropped support. Still, the best CPU my 7 year old Motherboard can handle is a Pentium 4 3.2 / 800mhz FSB, so even with an Ati x1950pro the CPU is a bottleneck, i don't think a better card would do any good at all, especially for emulators.

Hmm.
 

I may just get a new computer altogether.

Undoubtedly that's the easiest way to upgrade the video card at least. Other parts might not be needed, but aside from cost, well it was what I had to go with to get a high-enough-end system.