PDA

View Full Version : Full support for Banjo-Tooie


TheLegendaryJames
3rd June 2011, 06:48 AM
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.

ExtremeDude2
3rd June 2011, 12:51 PM
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])

Android
3rd June 2011, 03:19 PM
Just one question though. How are you able to play 1.7? I thought that was only available for donators/beta testers.

ExtremeDude2
3rd June 2011, 03:41 PM
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

TheLegendaryJames
3rd June 2011, 07:48 PM
Well, the truth is I don't have 1.7. Should I not have posted if I don't?

ExtremeDude2
3rd June 2011, 08:08 PM
Just one question though. How are you able to play 1.7? I thought that was only available for donators/beta testers.

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


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

No, it is OK.

HatCat
3rd June 2011, 08:18 PM
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.

TheLegendaryJames
3rd June 2011, 08:21 PM
Okay, thanks! It's just the 1964 input configuration is just such a pain to change the controls on.

HatCat
3rd June 2011, 08:27 PM
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.

TheLegendaryJames
4th June 2011, 07:46 AM
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.

HatCat
4th June 2011, 06:23 PM
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.

regnad
5th June 2011, 02:19 AM
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.

HatCat
5th June 2011, 02:26 AM
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.
Finished Banjo-Tooie with "Check Memory Advance" and ABL and TLB forced off.

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?

TheLegendaryJames
6th June 2011, 02:24 AM
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.

TheLegendaryJames
6th June 2011, 02:26 AM
I left all settings on default when I played Banjo-Tooie on Project 64 1.6.

HatCat
6th June 2011, 02:32 AM
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"

TheLegendaryJames
6th June 2011, 02:33 AM
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!

TheLegendaryJames
6th June 2011, 02:38 AM
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"


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

HatCat
6th June 2011, 02:45 AM
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.

TheLegendaryJames
6th June 2011, 02:52 AM
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?

HatCat
6th June 2011, 03:01 AM
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.

TheLegendaryJames
6th June 2011, 03:37 AM
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!

HatCat
6th June 2011, 03:47 AM
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.

TheLegendaryJames
6th June 2011, 05:07 AM
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!

TheLegendaryJames
6th June 2011, 05:09 AM
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.

HatCat
6th June 2011, 05:11 AM
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.

TheLegendaryJames
6th June 2011, 05:26 AM
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).

HatCat
6th June 2011, 09:00 PM
"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.

TheLegendaryJames
6th June 2011, 09:51 PM
"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.

TheLegendaryJames
6th June 2011, 10:00 PM
"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.

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.

HatCat
6th June 2011, 10:56 PM
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.

TheLegendaryJames
7th June 2011, 05:38 AM
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?

Android
7th June 2011, 08:12 AM
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.

TheLegendaryJames
7th June 2011, 09:11 AM
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!

HatCat
7th June 2011, 06:35 PM
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.

Tasoulis
8th June 2011, 08:50 AM
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?

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.

squall_leonhart
8th June 2011, 08:57 AM
AMD stopped making reference design agp cards, but there are agp variants all the way till the 4000 series.

Tasoulis
8th June 2011, 09:13 AM
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.

TheLegendaryJames
23rd June 2011, 05:46 AM
I may just get a new computer altogether.

HatCat
23rd June 2011, 09:53 PM
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.

TheLegendaryJames
2nd July 2011, 02:42 AM
Is there possibly a way that you can walk very slow on a keyboard? I play on a keyboard and when I press the arrow keys the character just runs fast as possible.

HatCat
2nd July 2011, 04:09 AM
Use the range modifier in the plugin configuration.

squall_leonhart
2nd July 2011, 07:27 AM
it was always 20fps

HatCat
2nd July 2011, 08:02 PM
lololo-yeah XD

But as long as you don't set it below 20% range I don't think you'll end up getting much non-responsiveness from most games.