How we BEAT the Limitations that defined the N64s Artstyle

the N64 has a very distinct but famous art style that seemingly more and more games are trying to emulate I find it to be a very Charming aesthetic and the low polygon count and low resolutions have an almost dreamlike feeling that leaves a lot to the imagination the N64 Aesthetics were not only defined by limitations but also by some choices and oversights that were made back in the day the most significant factors of this aesthetic are its low polygon count the blurry textures the simple ligh effects and the way animated characters have these interlocking fat rolles for limbs now there are very good reasons for some of these but not all four of these aspects have to be present on the N64 I've been programming for the N64 for 4 years now and I will explain how limitations affected this art style and how some techniques were overlooked that could have been used to get around some of these art style limitations all of these require ingenious Solutions and insane knowledge about the inner workings of the hardware so it shouldn't come as a surprise to anyone that these were not implemented at the time or only later during the n64's lifespan and the blurry textures were mostly caused by the lack of cash space available for textures the texture cache of this console was only 4 kiloby in size meaning the biggest texture you could load into it were 64x 64 250 step grayscale textures 32 x 64 full color textures or 64x 64 textures with only 16 colors or even 128 by 64 16st step gray scale textures but I've never seen that last one being used in any official game ever I'm guessing the low step count just looks too weird in game to actually use this one while that was a high resolution back then by modern standards this gave the N64 the trademark blurry texture aesthetic and to be honest I don't think having a higher resolution would really have helped anything considering most games on the console rendered than 240p but there is one option that was underused here the N64 is capable of holding two different textures loaded at the same time and it's also capable of even just using one texture twice and different sizes to make the tiling less obvious Mario 64 only used this technique a single time on the bza painting right here and it didn't use it to increase resolution but rather for this cool blending effect this opens up the possibility of using one texture As a detail texture and another as a contrast texture or any other combination You' like to do this technique is basically mandatory to make a big fields look good and Nintendo also used it whenever they had a grass plane in games like Aina of time or maj's mask if you look closely you can see that there's one big grass color texture here and one repeatedly tiling detail texture you would think that using two textures is more expensive and I assume that is why they often avoided using it but once you actually Benchmark the numbers you find that this can actually be cheaper than using one texture and it's often the same cost due to a hardware Quirk how can that be normally the console renders triangles in one cycle mode but using two textures requires the two cycle mode one cycle and two cycle mode are different in ways that I'm not even sure I understand correctly but thoro and wise Sky have independently benchmarked both one cycle and two cycle mode speed and they found that two cycle mode is about 5% faster when the drawing depth test never fails and the triangle is always in front and at most 30% slower when the depth test always fails and the hidden behind another triangle meaning if you have a material that renders at least 83% of the time in front front this technique is faster or equal to one cycle this is often used in the mod I am working on to both save performance and look better and it's become a pretty popular technique in the modern Community it looks awesome on emulators though admittedly it makes less of a difference on real console not sure if I'd call this an oversight considering it was used but it's definitely underused and should have been taken much bigger advantage of just goes to show you that you should always Benchmark your processes before you try to make any statements about optimization I think they could easily get high enough resolutions out of textures using this method to not actually need a bigger cash that's right I am disagreeing with what everyone says sucked about the N64 I think the texture cach was big enough actually crucify me another work around here is also dividing a texture into multiple Parts which also is very expensive James Lambert has a pretty cool demo that dust us at runtime to render is seen with HD Tech just on real Hardware this is obviously very expensive to render and it takes a lot of storage space so this is pretty unreasonable to use on actual games but you can use this to a lesser degree on logos around the world most N64 games also use a technique like this to render backgrounds Mario 64 specifically uses the 248 by 248 texture split up 64 times for its backgrounds although it is scaled so big that it still looks super blurry another significant part of the Nintendo 64's art style was the low polygon count polygons are being calculated by a dedicated hardware part called the RSP the RSP would receive a micro code from the game that it is running which it would then use to compute triangle data and figure out how to display triangles on the screen for games with early micro codes like Mario 64 or games with less efficient micro codes like Diddy Kong Racing this makes sense the RSP in these games is pretty busy calculating all these triangles but almost every N64 game ran on the mud meta FX or frx2 and if you profile them you'll find out that the RSP actually only needs a few milliseconds to compute all these triangles in the scene here you can see it takes only 8 milliseconds despite the scene having 3,000 triangles realistically you can probably get away with 10,000 triangles in the camera view on the N64 as I've showcased before in a dedicated video about why poon count is not as important as most people think to render a game in 60 FPS you need to finish in 16.7 milliseconds and if you look at super low py games like Mario Party it probably only ever renders 1,500 triangles at most so unless those games had something horrific going on on the hood their polygon budget was a lot higher and even though low poly Mario is charming they absolutely could have gotten away with just using Mario 64s model though keep in mind even with the RSP finishing in just a few milliseconds it doesn't mean it's free the N64 has a shared memory architecture meaning the CPU and GPU all share the same memory transfer speed the RSP is going to use a lot of memory transfers to send all the triangle data between memory and RSP meaning it will slow down other parts of the n64s architecture like the CPU and the render output for this reason I think this is a bit of a blurry line between oversight and not an oversight I think low poly was way overemphasized back in the N64 day but there were benefits to going low poy for almost all the games it's always cheaper easier and safer development cost wise to just cut the triangle budget in half and not worry about having to squeeze every bit of performance out of the machine when we talk about the visual charm of the N64 one element often overlooked yet pivotal is the lighting in the realm of modern gaming engines we are smiled with Reflections occlusions and sophisticated light play but the N64 with its more modest capabilities had to approach lighting differently the N64 was not nearly strong enough to do those computations also all the available micro codes on the N64 have almost all their effects work per vertex instead of per pixel meaning the vertices had to hold the entire render State and colors could only be interpolated between these vertices most commonly the game would just store a light source with a light color and then multiply the vertices color with how much it is facing the light you can see this easily in Mario 64 the camera is the light source and you can pretty easily see how everything gets brighter when the light source is shining at it and goes darker when the light is facing away some games took this a little further and pregenerated the light stored into a Vertex colors or even use triangular Shadow cutouts into fake real Shadows while the light looks pretty cool in the scene from my mod here this was all stuff that was done back in the N64 days especially in rareware and Factor 5 Games the new f3d X3 San is working on these days adds a few cool new things such as cell shading and ambient occlusion though these were not easily available and probably not even invented yet at the time of the N64 so let's not count those as oversights but there was one super cool feature or maybe even Buck the N64 head that you could use to get some beautiful light effects that were never used as far as I can tell usually colors of a texture are multiplied with a light source color to Output in the final color this is one disadvantage it looks like there's no reflectiveness to the materials and this becomes is very apparent if you watch out for it even stuff like the metac cap just had a whsh texture with no actual Reflections going on but there is a way around this the N64 uses a color combiner instead of a Shader where artists can input a math equation that calculates a pixel's color so for example we can multiply a texture with our shade color here to get a nicely shaded sphere or we could even multiply it with a flat primitive color to get an unshaded sphere and this combiner came with a cool Quirk If a color Channel grew bigger than 255 but output a value lower than 384 the console would clamp the output back to 255 so channels would slowly max out you can achieve this by doing some additive combining in the color combiner for example look at the shade multiplied by texture zero plus primitive combiner here as I increased the Primitive color the sphere slowly kept out on Cala values and it looks like it has a reflective spot people like goplay have been using this Quirk to get some awesome lighting Effects by abusing the clamping you get some cool overexposure effects and the materials will actually look reflective for this reason the N64 was capable of much more impressive lighting effects than we'd usually see though you do need to be clever with it to actually make it look any good the overlap between math skills and art skills required to effectively take advantage of this is so huge so I imagine this was just too difficult to work with or to figure out back then but the biggest strategy of it all was what happened to animated characters limb connections the people developing the first N64 micro code Fast 3D had a cool technique built in that I don't think was used at all for games released in the first three years of the n64's life and this technique would have got gotten rid of the iconic fat roles on the characters let's talk about why they exist in the first place transforming vertices one by one like in modern games is very expensive most games opted not to do that and just supplied a display list plus transformation matrix per body part on the RSP a transformation matrix is basically just a 4x4 table of numbers that you can multiply with a Vertex coordinate to get a new position it can easily information such as scale translation and rotation the transformation matrix will be calculated from where the animation bones were so they simplified animations into just Computing a handful of Bones instead of hundreds of vertices the common chain for this looked like this we load our Matrix and then we load our vertices in and whenever the N64 loads in the Vertes they instantly being multiplied by the last transformation matrix and then we draw a triangle connecting our premultiplied vertices this has a drawback any limb is not going to know where the previous limb ended so for example an elbow is not going to know where the upper arm vertices are and it can't connect to them all it knows is where to render and with what transformation this means they have to make Clos of Limbs like that to avoid visual holds in between limbs which adds a bunch of polygons and it looks a little odd but the developers of the micro code and Hardware have built a way around this that is entirely free of cost and would have prevented this odity while also lowering the amount of polygons the game has to render to use this we can take advantage of the fact that vertices are transformed onload by the current Matrix supplied that means if we lay out our Commons like this we load the Matrix we load the vertices we load another Matrix and then we load a few more vertices and then we draw triangles connecting the old vertices to our new vertices now we can use the vertic is transformed by a previous Matrix in our drawing which in the case of an elbow would be the upper arm and connect the mesh without any holds I've manually added Mario 64 to do this to connect Mario's limb in a hex editor a long time ago and this saved 124 out of Mario's 760 polygons while removing the gaps between the limbs yes I did it in a hex editor I 3D modeled in a freaking hex editor look at it can you see anything what the [ __ ] was I thinking back then unfortunately it seems most games completely overlook this capability leading to the look we are all familiar with it's especially unfortunate because it lets you get away with less polygons too and doing this in Super Mario 64 with its Fast 3D micro code is actually super difficult because the early micro code that Mario 64 had only allowed you to keep 16 vertices loaded at a time meaning you could only connect a maximum of 15 of them to the previous limbs but in later micro codes such as FDX you'd get 32 vertices making this much easier and even better yet with saur's modern fx3 we can even use 56 vertices allowing for even more complex skins nowadays we can use this technique really easily with fast 64 and almost everyone working on mods uses it now by just connecting the limbs the tool will out automatically set up the rig correctly for you and it will work no more hack seted off 3D modeling the children are playing and the birds are cheaping life isn't so bad it's not implemented perfectly yet though but it works well enough if anyone's willing to use Python and offer their free time on perfecting this come join the fast 64 Discord and help them out we're still missing some features to avoid repeat vertex loads which would make this technique even more efficient than it already is in conclusion if we were still developing games for the N64 nowadays most of these characteristics making the N64 eras art style so distinct probably would have slowly disappeared over time but they certainly have a charm to them I'm going to try to get the best looking game out of my mod so even though it is an N64 game its textures will look less blurry the poly counts will be higher rigs will be connected and there will be a few lighting effects and I hope you don't mind and I also hope you enjoyed this video and that I will see you in the next video big shout out to all my patreons for supporting me on my journey without you guys I would have stopped making videos a while ago if you want to appear in the patreon credits make sure to check out my patreon I really appreciate the support [Music] wow [Music] here we go

Channel: Kaze Emanuar

Views: 345,134

Keywords: super mario 64, kaze emanuar, n64, nintendo, mod, download, mario, rom, emulator, retro

Id: xwls5SpNn1s

Length: 17min 8sec (1028 seconds)

Published: Sat Feb 10 2024