|
The Banjo Kazooie Series General Discussion about the Banjo Kazooie series from the N64 classics to the handheld sequels & new Xbox games. |
|
Thread Tools |
#1
|
|||
|
|||
What if BT used the N64 expansion pack?
What changes or improvements do you think could've happened if like DK64 they decided to use the add on cartridge whatever it was called to boost memory?
Do you think Bottle's Revenge could've been a normal mode with that pack? Could we have finally done stop n swop properly? Would levels have higher details with high draw distance like the Xbox Live version? What are your thoughts on ideas? |
#2
|
||||
|
||||
Hate to say it, but there wouldn't be any improvement at all!
The bottleneck on anything graphical is in the RCP and that's all self-contained. The extra rdram can only really be used for loading more stuff into memory (saving reading it from the cart) or increasing the resolution (which could very well slow everything down because of that bottleneck). Nothing would run faster, but you could have more textures in memory at once or longer & more multilayered audio tracks--that kind of thing. |
#3
|
||||
|
||||
Not to make mention, the expansion pack wasn't even really utilized by DK64. In an interview it was mentioned that DK64 had a game-crashing bug that the team was unable to identify, but it seemed to go away when the game was configured for the expansion pack. All of the marketing that it was such a big game that it needed the expansion pack to contain it all was sort of nonsense...
__________________
...
|
#4
|
||||
|
||||
Quote:
__________________
Check out Banjo's Backpack. Make your own Banjo-Kazooie levels with this program! Also check out this game I worked on! Last edited by Coolboyman; 27th April 2017 at 09:07 PM. |
#5
|
||||
|
||||
What areas of the game had low FPS? I can really only think of two, which I would had assumed were due to graphics... Entering Jolly Rodger's Lagoon, and walking up the path from Banjo's house in Spiral Mountain always caused the FPS to drop. I really can't think of anywhere else..
__________________
Ego Sum Deus Quo Malum Caligo et Barathum Buterflies are insex. ~TwilightVestige |
#6
|
||||
|
||||
Quote:
BK and BT use culling in order to even exist on the N64. Which means that the game only ever renders whatever's onscreen at the moment. Basically if you aren't physically looking at something in the game, it doesn't exist. So Banjo-Tooie will only ever lag if you see too many things onscreen at once. Which is a problem obviously if you can't simply look at things, but you can use the knowledge to your advantage to make it lag less. Like just walk into Hailfire Peaks, go into first person and look up. It'll lag like mad because you are loading the entire mountain by looking at it. |
#7
|
||||
|
||||
Quote:
Okay, redo. I never notice the slowdowns because when the FPS drops, so does the BPM of the music... so even when the frames dropped do garbage the music also slowed down so it felt natural.
__________________
Ego Sum Deus Quo Malum Caligo et Barathum Buterflies are insex. ~TwilightVestige |
#8
|
|||
|
|||
Quote:
If it drops a certain alist, it will move on to the next, and the next, and the next. And in the end, if it cannot process ANYTHING because it was soooooo busy, youll just hear the audio buffer either loop over and over, or it will just go quiet. On BK and BT, the audio buffer is exactly 3 frames, or 1/30th of a second, or 2940 bytes. youre gonna be able to hear choppiness if it slows down THAT much, not just slowed down audio. Even a single sample being incorrect can produce an extremely noticeable fluke in the output, and in this case, youd be talking about the buffer for an entire frame. AALLLso, the audio buffer is read on an interrupt, so it doesnt matter if youre ready or not, its going out. (I'm actually working with the audio engine right now) also cough cough not to mention that the system is threaded and the audio thread is probably fairly high priority seeing as how the audio is a VERY large portion of gameplay. Also CBM is very right about BTs memory handling. Someone who goes by the name "Authentic" was actually working on this today. Even when BT is told it can use more ram (possible verification needed, might not have changed everything), it still swaps an awful lot and it tries to keep memory usage extremely minimal. For ex, if you open up nemu and go to image viewer and just look in ram around the 1.8MB mark and turn on "refresh every frame" and walk into an area, you can see the game load up a whole bunch of shit, and then shift shift shift shift shift shift shift shift things out. Its a pretty damn crazy system thats very hard to work with (object wise) in realtime. Theres very few things that are constantly loaded in ram, most things are only loaded when needed. While more ram COULD improve banjo tooies performance, in the end it would probably negligible because you have 3-4 times as much memory to handle now. (if the memory handling system gets to use ~1.5-2MB, which is what it appears to be) Part of the ram seems to be for your standard "garbage collect" style system, where theres dynamic allocation and the system decides what stay in ram and what doesnt. This is your objects and other routines that get used for things. It seems if the game doesnt see objects that use this system get called in a while, it will move them out of ram. Not sure if each routine in the giant jump table has a bit/byte it sets as a keepalive, but its a possibility. I've yet to find a table related to memory management. Then that is followed by the static allocation system, where things like the level model and textures get loaded. Things that will be required for a long time and where the memory is allocated and released manually. Last edited by jombo23; 2nd May 2017 at 12:16 AM. |
#9
|
|||
|
|||
Tested a bit on real hardware today. Stopping the game from clearing out memory makes the worlds load much faster, but you only get about a minute or so before the memory overflows
|
Thread Tools | |
|
|