One correction Sauraen brought up after watching this video: "You said 320x240x4x10 = about 3 MB with 4 bytes per pixel (2 for color and 2 for Z). But that's not true, it has to both read and write the Z buffer (so the real value is 320x240x6x10 = about 4.5 MB""
Even more impressive is the credits sequence, where the entire levels are rendered all at once without culling. And MK64 is an early N64 game that's only somewhat more optimized than SM64.
@@seronymusThe N64 had a separate microcode dedicated to 2D, but the limited texture cache meant that you're hitting memory more and using more polygons to render more detailed textures. It was doable, but was a delicate balancing act.
They require really really few polygons actually. Mario kart for the N64 was mostly sub 1000 polys loaded at any point in time. It has a lot less geometry than normal SuperMario64.
It's funny how one of the keys to better performance is not having large objects in the center of your level when so many of SM64s levels are exactly that. It's usually all centered around some sort of mountain or large object.
Not large objects, large stacked textures. So not really comparable, those mountains are made of lots of smaller textures and what's behind _should_ be culled(don't quote me on that)
actually quite the opposite, building a level around a big centerpiece makes optimization easier, assuming you have access to good optimization tools (unlike the guys making an n64 launch title)
I'm glad nothing has stopped you from persuing your passion like this. I've been watching your content for years, and it's always a treat to see what you've been cooking up.
Oh yeah, much of this was discovered over the course of the N64's life. Mario 64 has a ton of places where they did something exactly wrong for the N64 because that would be the right way to do it on the NES and SNES.
@@benamisai-kham5892 They certainly were. Quite a few games were developed with the DD in mind and then turned into a somewhat janky mess when they had to be downported to base-hardware.
Just when I thought we've almost reached the limit enter people like you who simply rewrite the code of the N64 itself. Love your dedication to pushing the boundaries, keep on keeping on!
So long story short, the N64 doesn't like shuffling around memory that much, but is more than happy to bang out uber complicated formulas. It is really showing off its SGI heritage with that one!
Well, if I remember correctly, it was nintento's decision to cheap out on RAM (both size and speed). Sad, with the cartridge read speed, if the RAM bus could go more vroom vroom, you would have a really good console for it's time. Imagine streaming big texture directly from the cartridge...
@@huaweiphone4357 there is at least one developer that did exactly this, and the results are as stunning as you'd expect. As for cheaping out, it's not like the Nintendo 64 was built to be a cheap kid's toy or anything...😜
@@johnrickard8512 the high res texture tech demo? Nope, he didn't. He use clever mip mapping, and (a lot) of texture swaps. He loaded small chunks of textures as fast as possible to simulate big textures. The working memory is extremely limited for the gpu, and accessing it is time consuming. As far as I know, you can't ask the gpu to go fetch a texture (big or small) directly from the cartridge, you need the cpu to fetch it, copy to ram, and then ask the gpu to use it. And you are limited by the (byte) size of the texture (so lower color depth mathematically gives you bigger textures). I can be wrong, but I don't think so.
@@gamephreak5 yes, and the PlayStation also had super slow memory and an even slower CPU, and the Sega Saturn....well if you weren't someone like Traveler's Tales you would find it to be impossible to use to its fullest.
Yep. The fastest way to render something is to skip it, no matter whether it's triangles or memory that's killing performance! Then they went and flagged the sub as dynamic. Oops.
@@danolantern6030Yep! Use the camera lock feature and swim through the connecting tunnel and you'll see the first area unload and the second area load in
@@danolantern6030 yeah, honestly my smooth brain thought, "if a polygon is covered up by other polygons, it doesnt affect performance" lol but no they have to unload the polygons
These are the insane benefits you get when one person has an indepth understanding of both game design and code. Modern video games have become so unoptimized because of how complex both aspects have become. I don't think any individual developer holistically understands a modern game such as Baldur's Gate 3 or Spiderman in the same way you understand SM64. I wonder if that's even possible.
From what I've read large game studios don't make effective use of generalists due to the management style. There are probably quite a few people who know a bit about the entire stack but if a game has 300 people working on it most of them will work on one narrow part of the project. On top of that companies like Bethesda outsource parts of the work (like with Starfield), which makes the communication problem even worse. People like that probably shine more in indie projects. For example there was a PS4 exclusive indie game which used real-time cone tracing (faster version of ray tracing) for the graphics, built from scratch and years before hardware was designed to accelerate it.
@@FlamespeedyAMVthat's not it the devs they hire are usually overworked and put to work only in specific areas of the game while not knowing everything else about it and it's not their fault as it's mandated by their manager
@@SaHaRaSquadyup, this. A lot of studios separate their workers with lacks of communication between teams. If the teams could all communicate freely and work creatively together we'd probably have so many better end products... Or they'll split teams to work on different projects at random.
10k is about the polycount of an environment on the Gamecube, for reference. Main characters in that gaming gen would usually be a couple of thousand. Nowadays, for games with the Triple A Aesthetic TM, a single important character would easily be over 10k. 10k would still be considered lowpoly by modern rendering standards in film and animation. But film and animation have always been able to utilise higher polycounts than gaming, as their 3D doesn't have to render in real time.
On a game where you can create your own content like VRChat, 60-70k polys is generally the standard, though often custom content goes way above and beyond that.
If only modern games made processing efficiency more of a priority Imagine the leaps in capabilities new hardware could have when optimized to the level you're getting the N64 to... absolute legend Edit: "Try a bit more" doesn't mean "it must be the only thing devs do before anything else happens with a project" but I really shouldn't be surprised that people are trying to twist my words for the sake of forcing discussion
My university prof always tells us "Don't worry about efficient coding too much, computers are fast enough these days" For me this hurts to hear, while it's true for many applications it leads to lazy programming... using inefficient algorithms and data structures because they are easier to implement... And then you have shitty software as a result :(
id software's idtech 6 and 7 engines are a good modern example of making the most of modern computers doom eternal's vulkan renderer is pure art with how hyperoptimised and efficient it is while pushing beautiful visuals
The part about not having a big thing in the center of the level to improve performance is so interesting because that's how most levels in early 3D platformers like Super Mario 64 and Banjo-Kazooie were designed, having a big thing in the center gets the player's attention and gives them a sense of direction which helps since you can't just go to the right like in 2D.
You are single handedly moving Super Mario 64 and it's modding forward. Without you who knows when a person would even think to take up this work. Literally making history. I don't care how long I have to wait for all of your work and documentation to be done. All of your optimizations are well worth all the wait. An actual revolution of content will be made from your efforts. Nintendo should literally be paying you at this point. Thanks for your work Kaze, I hope you're as proud as we all are.
It most likely is moving N64 retrogaming forward as a whole because some of these optimization-approaches should be universal in at least a broad sense.
@@mirabilis decomp; decompilation. They are reverse engineering code. This is a code rewrite to give it a better more efficient engine. There are plenty of modders who've done great work, and more great work will be done, especially when this is finished. I don't see why you feel it's necessary to deminish Kazes work. Even in this video he talked about getting more outside work. But Kaze is the forefront for this project. That doesn't mean that others don't deserve recognition, but the "meh" is blatantly trying to deminish the work he's done for no reason, as if Kaze doesn't deserve recognition. If you want to do that, maybe don't play any of the mods that will be built off the back of this project. I understand there are others doing great work. I just want to show my appreciation for Kaze. Maybe you think "single handedly" is too strong of a statement, and that's fine, fair even, but I don't think I need to remind you of the potential this project will bring to other modders. If you feel I was trying to deminish others works, I apologize, I wasn't.
N64's potential getting unlocked countless times I'll never get tired of it lol Also quick question. For Mario's model to switch different hand forms or without his hat and what not, is that simple model swapping or a use of shape keying?
quick question actually; are some objects being deloaded before they actually leave the camera? I saw a few moving platforms get deloaded on screen instead of off screen.
I noticed the crate your standing on at 6:52 is having its vertices warp and wobble in a similar way the PS1 used to do. and even the side of the crate's edges seem to tear at 6:56 Is this a result of the Z-Buffer optimizations or something to do with the Sine Cosine optimizations. or was it older footage? I am a bit curious but i am also not very much a programmer at all.
It might be due to the crate being a dynamic object or similar. In many games (software Quake by example), models aren't rendered with perspective-correct texturing with a few exceptions (ammo pickups).
@@Calinouuh, check the bounding box size and turn on correction. It is like two instructions in RISCV and uh x86 code is a bit more inefficient, but not much.
Could be a glitch. The Z buffer makes fuck all difference in that sense. Anyways, apparently there's a bug in the SGI silicon that causes texture glitches in some situations.
Crazy I believe the N64’s official hardware figures were 150,000 polygons per second, so at 30fps, 5,000 would be the targeted polygon count-maybe a bit more depending on amount of shading and textures Mario 64 played things safe-the simpler maps being only around 1,000 tris, and the larger maps being segmented via loading tunnels, I doubt the game often exceeded 3,000 and definitely not 4,000 tris Ocarina of Time optimised things more, though the game was capped at 20fps the maps had a lot with surprisingly low poly count-Kokiri Forest was only about 2,000 tris and Hyrule Field 1,600 tris Then there was Rare’s stuff-they were very talented but didn’t quite focus on stable performance Click Clock Wood in Banjo-Kazooie pushes over 4,000 tris, and Mayahem Temple in Banjo-Tooie pushes over 6,000 And that’s all before objects and characters
Yeah though keep in mind these higher poly levels use a lot of culling and rooms so i find it unfair to count that. If wed count like that then only up 64 would be a 50 thousand triangle level which it clearly is not haha
@@KazeN64 Those numbers are only for the main “foyer” area, so to speak, and Banjo has flight pads allowing the whole terrain to be visible at once-at a wonky framerate though of course
This stuff is generally understood now. Back then they were pioneering this kind of stuff and the limitations were less understood. Suffice to say if they were to make Mario 64 with the knowledge they possess today, even on the N64, you'd see them pursue similar techniques and ideas that Kaze is doing.
Yep modern compilers are so much more efficient than older ones to the point where assembly or other low level code is only useful in very certain niche scenarios
@@daskampffredchen9242 No reason to go to GameCube as the progress on this N64 stuff is far more interesting. The N64 was a complex beast with alot of untapped potential... Kaze is doing things on N64 at framerates that defy all other games in its lifespan. GameCube was already so well optimised there's nothing else to unearth performance wise.
I can remember when Skelux showed the Star Road 2 preview a long time ago and that felt like the peak of sm64 hacking at6 the time. In a comment about one of Kaze's early hacks he said something along the lines of "nobodys as good (at modelling) as skelux". And while Skelux's artistic vision is still S tier and godlike, I'd say Kaze has gotten closer to that level of polish.
Yeah, I have little talent for art. I am decent at it know because I've practiced it so much. Though I do have biobak helping me rework some of my earlier levels and he's the most talented artist I know. I think we can make something much prettier than even star road 2 with him on the team!
@@KazeN64 I definitely think its far surpassed star road 2 I just wanted to say it in a polite way lol. and of course the artists u collaborate with are dope
That's not exactly the issue here. Drawing the background after opaque objects requires reading and writing the Z-buffer on every pixel, and as explained in this video, reading and writing the Z-buffer is really slow.
N64 has a pipeline. It loads the whole texture no matter the z tests. Stupid Jaguar would not even tell me if a portal passes any z-tests. I mean it would, but so slow that it does not help me.
What I learn in your videos @kaze, I really try to find ways I can plug this type of looking at problems in my day to day engineering tasks. Thank you for a fresh look from a completely different segment of software engineering and application design.
I'd already heard that fill rate and bandwidth were bigger issues than poly count, but this is far more extreme than I expected! Also does this mean that Mario is going to get a poly count boost for the final build of RtYI, at least in cutscenes? :)
Dude this is amazing, I just absolutely love this kind of stuff, your mods are amazing and it's so cool to see such advancements made on this console even after so long, makes me proud of the video game community to see there is still so much you can do with old tech.
Diggi es ist echt otherworldly mit welcher hingabe du das alles machst. Bin super gespannt auf den Mod und kanns kaum erwarten den zu zocken :)! Wird ein guter Winter dieses Jahr.
Yeah. I'm also wondering what could be done with extensive use of AI for further optimizations making also the graphics better. At least when AI becomes better at coding leaded by Kaze to what he will want to do.
Awesome vid! Just out of curiosity, if n64 bottleneck is memory what could be the bottleneck for ps1 and saturn? I know this channel is for n64 but I ask just for curiousness.
I've not watched the video but I agree with the thumbnail because I've spent so long doing low poly art that when I see it in ps1 style games and stuff I'm not like "wow its like a real retro game" I'm like "wow they really just got 5% of the way of doing a medium poly model and just applied awful oiled up textures and said 'it's just the style we chose'"
I am curious do you think any of the things your engine does could apply to other games, and if so, do you plan on letting modders in future use your code to work on new games or old ones? I seem to recall you mentioned Open-Sourcing your code once the game was done, but I don't remember the details or if that is even correct.
yes it will be open source once the mod releases! im sure some of it could apply to other engines as well. though the code itself will be less interesting than the techniques used i think
This project inspired me to get into pico8 development. I know it's not the same as making games for the n64, but the restrictions it puts in place give a similar need for creative solutions to problems, and I highly recommend it to anyone who wants to make 'retro' games. The work you've put into this project is incredible, I can't wait to one day play the game for myself! Keep the devlogs coming, I'm finding it so fascinating learning how you've optimised the engine.
This is very interesting and impressive. Im definitely gonna make some time to try some mod games from now on. Just out of curiosity, how do you regard the level of optimization that devs achieved in the later n64 games such as conker's bad fur day?
I might be wrong but didnt the N64 have just 4kb of texture cache? The CPU and GPU of the N64 were really powerful for their time, even featuring texture filtering but fitting "high res" textures through that cache was basically impossible. You had to chop textures into multiple parts or leave them los res, thats why many games looked blurry
amazing job! Games like Banjo Kazooie actually improved the visuals a lot by having transitions in the textures. Also you can try to use vertex colors to make your game even prettier or add shadows without needing any additional memory as its done by the GPU in real time. Again, gute Arbeit!@@KazeN64
Am not a coder but can your engine be adapted for fps, 3d fighting games or racing games ? Would be amazing if in the near future it can be easily adapted for those types of games so others can use it and do crazy ports, maybe a tekken or bloody roar port for the n64 😅
Probably but it's more then likely deeply tied into the game code. He could potentially strip out all the Mario related code to make it more general purpose.
The fighting genre is one the few that actually did benefit CD-media. PSX had only 2MB RAM, but on fighting games they could actually utilize CD -space for lots of characters, arenas and FMV's. However, take a look of most recent build of Smash Remix for N64, to see how N64 can handle tons of characters & arenas as well these days.
Well because it's not economically viable to optimize a device to its fullest. Kaze took this many years to achieve this then the developers back in the 90s will too. Sooner or Later consumers will get bored of the N64 weak power and low poly visuals when they can just upgrade to a better console hardware for more power.
@@deltex8526That's pretty much it. It takes several YEARS, sometimes Decades for a system's hardware to be pushed to it's limits. And simply put, you cannot have a system stay around that long. Especially when, for a company like Nintendo, you can simply upgrade the hardware after 7 or so years and get VASTLY better improvements at a fraction of the cost.
I'm thankful we do too lol. We never really get full potential out of the hardware and even when they get close, it's usually decades after the demise of the hardware. Optimising takes time and money to do and in most cases, it makes more sense to throw more hardware power at the problem than to go overkill on optimisation. But maybe A.I. in the near future could help to change that if it gets really good that it can help us optimise code to get better use out of the hardware.
I like the low poly look of 64 games, and low poly games run pretty well on my pc and phone aswell Edit: i wasn't talking about emulators but they also run well
Very impressive but as someone who also programs 3D on retro consoles, I have something to add. It technically can draw that many polys, but it's a whole other thing to check backface culling, behind the player polygon clipping, 3D texture clipping, and ground collisions with that many extra polygons. There are only a finite number of cycle the n64 can do per second and you can't have it all without the framerate dropping pretty low. That's why the enemies in Goldeneye has to be so boxy so there can be more on screen. 1 single enemy could be several thousand polys if there was was just 1 floating in space always in front of the player like that landscape you show.
The pcEngine had one cycle to spare per pixel. PSX and Saturn have 4 cycles per pixel. N64 has 7 cycles per pixel. Multiplication is single cycle since Jaguar. To cull back faces you need two multiplications. I think hardware designers and game developers need to justify all those cycles they use up. SNES could spit out mode-7 at 1 px per cycle. N64 blitter runs at 1px per cycle. It is all a pipeline.
I like this resurgence of fifth gen hardware getting pushed to its absolute limits, first we had a team porting over the first two levels of Unreal to the Saturn (big draw distance and all) and now the N64 is being pushed to its limits, I'd like to see what people could do on the PS1 now.
So overdraw tanks performance, while lots of polygons don't. So kinda like the switch then saw that one video once that showed that apprently having polygons for individuals leaves is faster then a cutout shader.
That's pretty much why Age of Calamity just kinda dies when the switch is docked. It basically overdraws nearly everything with all the semi-transparent effects and because docked mode uses a higher resolution compared to handheld, it also has to overdraw much more. Rip Switch.
A nice example of "optimization is a waste of time, unless you optimize that really is causing the bottleneck". If your entire processing passes through 10 steps, the slowest step is what dictates the overall speed almost alone. You can optimize all the steps but unless you optimize the slowest one, you won't see any larger improvement, if you can see an improvement at all. Only once you've eliminated the bottleneck, you can check for whose now the slowest step and try to optimize this step as well, and so on. That's why profiling is so important for optimization as only profiling will tell you what the slowest step really is.
If this can be accomplished on an N64, imagine what could be done on a Gamecube? I know we sort f saw with the Wii, but I'd want to see what it could do with it's original limitations.
Star Fox Adventures is a very good technical showpiece of the Gamecube hardware where it looks much more like an early 7th gen title than a Gamecube title.@@jeremycole9809 There was a lot of unique tricks to get the fur simulation to look that good and for other things like grass. And also, how the game data is streamed to eliminate loadtimes.
Hey this is a bit of a non-sequitur but do you know of any tutorials for getting a toolchain set up in Linux to compile for N64? I had an old version of the actual dev kit running in an Virtualbox VM but I can't seem to get it running in VMM and that got me wondering if I could just build natively instead of having to emulate an entire dev kit.
I have a question (it may be a dumb one, but anyway...): Is it posible to implement someting like a dumb down version of nanite to run on a N64 to render triangles? @KazeN64 P.S.: Love you work, absolutely amazing!
All these advances in N64 rendering has got me wondering how good 2D could look like on the hardware. As far as I’m aware the N64 doesn’t have any dedicated sprite hardware, but given what’s possible on consoles like the PS1 and Saturn I think it could look awesome.
The n64 really bad at sprites, the reason the saturn and ps1 can do it is because they are designed to do it. No amount of optimization changes the n64s limitations.
@@RetroDark2008 Ok, then explain Bangai-O, Mischief Makers, Ogre Battle, Super Robot Taisen 64, Dr. Mario 64, Puyo Puyo Sun and ~n Party, Yoshi’s Story and various other sprite-based games on the console. The N64 is very capable of doing stuff like this and I’d like to see it taken further.
@@8squared007 A lot of the spritework was limited in animation and in clarity. In mischief makers the sprites are blurry. Same with yoshis story. It’s just that the N64 was designed by a cgi company, and this video is just improving what the n64 was good at, 2d sprites are something it was quite bad at compared to the PS1 and Saturn.
@@RetroDark2008 Ok, but there are other examples I’ve listed like Bangai-O which prove that it can do great 2D without looking blurry and recent homebrew projects that also serve to help my argument. “Harder to program” does not mean “Worse”, people simply need to do more research.
@@8squared007 It is also harder to program, but again the 2d on Saturn and Ps1 is more fluid and detailed than anything on n64. The n64 had a lot of issues, memory is a big one. I get you like the n64, but it has it limits. I have played a lot of sprite based n64 games and they really weren’t anything special visual wise. It’s impressive, but not that good.
Brilliant! I’m not keen on the technical knowhow behind n64 development, but as usual the video excellently explains it on a basic level that I can comprehend. Man, I wish that developers nowadays perform these micro-optimizations on their games, particularly Switch ports. Nintendo, hire this man!
5:56 I love that you mention how bad lookup tables for trig functions are. My game uses inverse tangent and, to optimize a part of my code, I used a lookup table to approximate it thinking it would be faster, but it ended up being *slower* than just calculating it.
Kaze are you currently using some kind of custom microcode, or are you using a legacy microcode like F3DFX2? Additionally, when F3DFX3 will be released could we except another major performance jump?
I know nothing on game development, but was really impressed with the high poly count you demonstrated. It's inspiring to see people's passions for a +25-year-old game engine and showing us how performance can be optimized. Thank you.
sadly kaze himself admits he can only do this stuff with the knowledge gained since the n64s launch, its more like if kaze was a dev back then and they developed the game for 10 years and it came out in like 2006
no amount of time constraints can ever excuse the abomination that is shadow.c - 4 raycasts to find the same surface 4 times, taking up upwards of 20% of your games performance in some areas (or the dynamic collision on the DDD sub)
Because of the small texture cache, and the higher amount of polys I've noticed in N64 games, especially recent projects like yours, I've always wondered why more textures on surfaces weren't drawn using polys instead. People would use blurry text or arrows, when drawing simple shapes and even some text should be more performant on the N64. And this video just furthers that question. I see even recent projects like the Portal 64 project (not yours) creating simple shapes on surfaces using low quality textures instead of triangles, and I have no idea why. Do you have any idea why that might be the case? Because I just simply am not enlightened enough to understand this trend in N64 game design.
The equivalent of a 64×64 texture with vertex colors requires 4096 vertices to be representable, and unlike a texture, it can't be repeated unless you also repeat this 4096-vertex lattice. Vertex colors work better for low-frequency data, such as lighting or ambient occlusion.
Basically because the only thing you get that way is flat colors and gradients. It can look cool (characters and enemies in FF7 is a good example) but it's a very particular style and not something that can actually replace texture mapping.
That's my point. More complicated stuff can be textures, but an arrow, or even a bit of text? Why not triangles? Think of all the blurry text and simple shapes on flat surfaces that are textures instead of polygons in various n64 games. Why not use triangles for those?
Wonderful vid, as always! I have a doubt : do you believe than your engine could be able to render "poxels" : the tech which was used on worms 3d,4 on Ps2, cube and Xbox. If you are interested I can send you the documentation I found. They are a level editor but is very slow rendering
Man, if you can overhaul and improve Super Mario 64's code THIS much for optimal performance, I'd love to see you do the same thing for Conker's Bad Fur Day! That game has aged horrendously. Way too many areas have the framerate tanking to borderline unplayable levels. It's crazy how much love that game had back in the day considering. I don't think I've ever played an N64 game that struggled to the same degree as Conker.
Might be a silly question, but if you're locking your hack to 30fps, why not push the system much further to the point that it would barely stay above 30fps even when unlocked?
That's what I am doing! The earlier levels were not designed with this powerful of an engine in mind so it's often not fully taken advantage of. But the newest levels are designed in a way that the most laggy view often struggles to hit 30.
i CANT wait for your game. I love the insane optimization and learning, it's so inspiring and really relaxes my OCD :-D Idea: it would be great to take the Mario model from galaxy and see if you can render just that with full polygons and look and feel, but on the n64
I love 3d modeling and kinda hate the modern "low poly" artstyle, you know the one with the solid pastel colors and no textures. It felt unique once it first became popular but Ive grown to mostly hate it. Thats a complete aside though, for n64 mods high poly really fits the artstyle imo, It gives the feeling of "old console with a game way ahead of its time" and I think that really fits the console modding scene! Edit: when thinking about it, does the memory limitation mean that game engines that can get depth buffers without the normal, "calculate distance and compare" method, like bsp algorithms can get a ordered depth buffer without a typicalZ buffer. I know the quake and doom engines (both of which appeared on the n64) could improve preformance a lot. It also uses the cpu to sort through it so thats another good use of CPU time!
@@hughjanes4883 Yeah but that's not relevant to retro inspired modern games, they never incorporate that. Also it doesn't come up with emulation which is how i do everything today.
And Nintendo repeats this mistake yet again with the Nintendo Switch. The Switch struggles massively on games with large, multipass post-processing chains or that render big transparency effects right on the camera, because of its slow DRAM.
It's funny how once again games are bottlenecked by memory bandwidth/latency yet all people ever talk about is being cpu or gpu limited. It's been memory access all along. On modern CPUs fetching a value from main RAM takes 100x as many cycles as from L1 cache! Most of the time the CPU is just waiting for data.
@@tinoesrohoElectrically, RAM gets slower when it gets larger. This is due to the fan out and parasitic capacity of the bit and word lines. Also the address generator gets power hungry.
This optimization is absolutely insane throughout your work on this mod. Do these specific tips only work on the N64 or can it apply to more general 3D modeling in games?
what do you use to make these mods.. how do you make textures look n64 style I guess is what im asking. i want to make a game but everything is way too high detail today.
I wonder if it would be possible to do something like UE5's nanite on N64 that culls and resizes triangles based on the camera position so you can get the best quality to performance ratio.
This video is even good for modern computers. Today even ram and memory is considered slow and writings code to keep braching low is worth it (if you need speed). We even have cryptography functions that are "memory hard" meaning it slows down hackers by making it slower to compute by making it use ram access times in a way that cant be shortcut-ed, slowing down brute force attacks.
I'm so happy to see the N64 modding/homebrew community going strong and getting better and better. ‘Return to Yoshi’s Island’ is the most anticipated mod ever! Can’t wait. You’re a genius!
This game has dpad left/right to slowly adjust your camera angle and the cbuttons to work like in bowser levels in sm64. it doesn't work like parallel as the camera and level design here never acknowledges the world axis (i believe those should never be visible to the player). the camera by default does follow mario like the mario cam in vanilla does, but you can turn that off in the options.
