@@scottcaramelI swear these comments are from bots. If you notice, every top comment on every video is just basically a recap of why the video exists in the first place. If you watch a video of like, a man falling down, the top comment is usually like “Omg the way he fell was so funny.”
The N64 was a fascinating piece of hardware even today, and I always had the feeling that developers never got to push it to its true limits. It's great to see you doing just that!
I’ve felt for a long time that it has gotten an unreasonable amount of criticism. Aside from how the texture cache works (not being an associative cache backed up by dedicated fast VRAM for buffering texture atlases like on PS1), some of the performance or memory limits on N64 stem from Nintendo-mandated rendering features that aren’t exactly life-or-death vital (mip-mapping, Z-buffering etc.) but had to exist in commercial games to keep the seal of quality and the approval of Nintendo (not sure how true this is, however, so correct me if I come across as a total bullsh*tter). Another trend I have noticed playing (and owning) both PS1 and N64 is that most (if not all) non-linear adventure and platformers on N64 (that weren’t already already enforcing a limited draw distance for one reason or another) never rely on any level-of-detail reduction when drawing larger landscapes, sometimes not even limiting how far away objects/characters are visible. The PS1’s most complex creations like the Spyro series, Ape Escape, Tench 2, Quake II, Terracon, Sheep Raider (etc.) all either (1) have severely reduced draw distances, (2) don’t do anything because the level sizes are already limited in scope and geometrically boxy (such as in Quake II) or (3) use extremely obvious LOD transitions for environment (and character?) meshes or models (see Spyro). There is always this highly noticeable detail reduction factor in every complex PS1 I have played. When playing stuff like Goldeneye 007, Mystical Ninja, Jet Force Gemini, CBFD or Ocarina of Time, it makes me appreciate how far into the distance I can squint and still not see any environmental detail pop-in happening.
I heard that the way Smash 64 and F-Zero X managed 60fps was by disabling the Z-buffer. It's of course possible that the mandate did exist and they simply chose not to stick to their own rules of course.
Honestly, no console has ever really been pushed to its absolute limits due to time and budgeting constraints. That's why we see incredibly detailed and impressive things from the modding community, due to having all the time in the world.
They wouldn't really be that surprised. Rare programmers knew the N64 was a powerhouse full of potential but had little time to fuck around with the hardware in order to release games on schedule
@@pretzelboi64 yeah, but not even the best demo's at the time looked anywhere near this good. I was obsessed with the N64 and remember being blown away with the really blurry underwater shark demo pics released in the Next Generation magazine in late 1995.
@@The8bitbeard I'm not saying it's not impressive but real-time triangle rasterization with perspective-correct texturing was achieved in Ultima Underworld back in 1992 on a CPU
Your ability to consistently stretch the boundaries of this console with every video you release is mind blowing. You have no idea how incredible and inspirational what you do is to me. Great work as always!
One way to save texture space in a game is to have all the rooms decorated in the same style, and a small number of game objects used repeatedly in each room. Like, say, Portal does
....... No hope in going to the past come to the loving savior today Seek his Holy Spirit in prayer today he can give you peace confort and guidance today Romans 6:23 For the wages of sin is death, but the free gift of God is eternal life in Christ Jesus our Lord. Come to Jesus Christ today Jesus Christ is only way to heaven Repent and follow him today seek his heart Jesus Christ can fill the emptiness he can fill the void Heaven and hell is real cone to the loving savior today Today is the day of salvation tomorrow might be to late come to the loving savior today John 3:16-21 16 For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life. 17 For God sent not his Son into the world to condemn the world; but that the world through him might be saved. 18 He that believeth on him is not condemned: but he that believeth not is condemned already, because he hath not believed in the name of the only begotten Son of God. 19 And this is the condemnation, that light is come into the world, and men loved darkness rather than light, because their deeds were evil. 20 For every one that doeth evil hateth the light, neither cometh to the light, lest his deeds should be reproved. 21 But he that doeth truth cometh to the light, that his deeds may be made manifest, that they are wrought in God. Mark 1.15 15 And saying, The time is fulfilled, and the kingdom of God is at hand: repent ye, and believe the gospel. 2 Peter 3:9 The Lord is not slack concerning his promise, as some men count slackness; but is longsuffering to us-ward, not willing that any should perish, but that all should come to repentance. Hebrews 11:6 6 But without faith it is impossible to please him: for he that cometh to God must believe that he is, and that he is a rewarder of them that diligently seek him. Jesus
I think a simple sort of escape room game would be a really cool idea for this method. You can keep the game small and the game code itself is little more than a character mover, the interaction with some puzzles, and checking if they've won yet. That leaves a lot of space for this implementation to use some very high-res textures that would be visually really interesting as you could involve them in the puzzles in different ways.
ปีที่แล้ว +2
Or place the story in a puzzle-ish world that could make possible to reuse the textures by using different combinations and positions. Maybe?
@@Syncrotron9001 Probably but the idea of mega textures didn't exist till the PS3 and they've always had tons of issues which is why they never took off.
@@theninjamaster67 someone fixed the framerate on mario 64 on the original hardware, if the FPS fix and mega textures ever get mixed into a working home brew that works on the original hardware that would be amazing.
Incredible! I know you refer to MegaTextures and MIP Mapping, but you’ve also implemented a form of Sampler Feedback Streaming taking advantage of the cartridge speed that wasn’t possible with CDs. SFS is now possible with the fast SSDs in modern consoles and PCs.
Sampler Feedback Streaming is a specific technique that requires hardware support with direct control over the memory hardware / page tables. The concept of streaming textures is an old one and you'll see the beginnings on older 2D systems like the SNES and on sophisticated PS2 games which required streaming textures from main memory into VRAM and from disc into main memory. This tech demo is a great example of this general concept but is not a form of Sampler Feedback Streaming.
@@djmipsbut isn’t checking for visible tiles ( so small on this system ) almost like sampling? The rendere processes all geometry, culling clipping and z buffer occlusion culling and in a second stage would load sampled tiles which not already reside in RAM? The demo does not use the z buffer. Weird choice. And how is it gonna render dynamic objects? Bipeds ?
Its absolutely is a feedback system, and Rage has lots of GDC slides about using Feedback in much the same way. SFS via hardware just makes the process easier.@@djmips
@@gibletto Correct. I did not say it wasn't a feedback system. Any pre-existing system that virtualizes GPU resources uses some form of feedback. Sampler Feedback is a specific patented hardware system and I'm trying to educate the OP that MegaTextures is a good enough description and there is no insight in calling this a form of SFS but of course I understand how the OP was only trying to fit the technique described into their own frame of reference.
For the ratman posters, you could use a 1024x2048 intensity texture and multiply that by your normal wall texture. Then for anything else you could have mini stickers
Keep in mind also that the screen resolution is going to be capped at 480i on original hardware no matter what you do, so redesigning the assets to be clear at low resolution is going to be essential anyway.
@@james.lambert Background data decompression maybe, like Metroid Prime used on Gamecube? ...Assuming there's actually any spare CPU cycles left to use, heh.
That's really cool. Texture streaming was around as far back as the SNES and perhaps earlier (They were called tiles but same idea). Whenever you have a limited amount of VRAM but a big world, the concept becomes necessary. It is a generic design pattern that you see in any system that has a limitation on a local resource cache and the ability to stream from ROM, storage, or Internet. Texture streaming in a 3D game was a halmark of many PS2 games and a lot of coffee was consumed in the creation of fantastic DMA schemes to make it all work. It looks like the Falcon was another early example!
It may or may not be baked global illumination. Maybe raytracing, maybe other algo like photon mapping, voxel cone tracing, radiosity and their variations like bidirectional scattered, pathtracing or instant radiosity.
@@TUUK2006 it's baked raytracing. the room and it's light baked textures were made in blender, which uses ray tracing to light bake textures. on the n64 end, the room is completely unshaded textures
...... Do you know Jesus Christ can set you free from sins and save you from hell today Jesus Christ is the only hope in this world no other gods will lead you to heaven There is no security or hope with out Jesus Christ in this world come and repent of all sins today Today is the day of salvation come to the loving savior Today repent and do not go to hell Come to Jesus Christ today Jesus Christ is only way to heaven Repent and follow him today seek his heart Jesus Christ can fill the emptiness he can fill the void Heaven and hell is real cone to the loving savior today Today is the day of salvation tomorrow might be to late come to the loving savior today Romans 6.23 For the wages of sin is death; but the gift of God is eternal life through Jesus Christ our Lord. John 3:16-21 16 For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life. 17 For God sent not his Son into the world to condemn the world; but that the world through him might be saved. 18 He that believeth on him is not condemned: but he that believeth not is condemned already, because he hath not believed in the name of the only begotten Son of God. 19 And this is the condemnation, that light is come into the world, and men loved darkness rather than light, because their deeds were evil. 20 For every one that doeth evil hateth the light, neither cometh to the light, lest his deeds should be reproved. 21 But he that doeth truth cometh to the light, that his deeds may be made manifest, that they are wrought in God. Mark 1.15 15 And saying, The time is fulfilled, and the kingdom of God is at hand: repent ye, and believe the gospel. 2 Peter 3:9 The Lord is not slack concerning his promise, as some men count slackness; but is longsuffering to us-ward, not willing that any should perish, but that all should come to repentance. Hebrews 11:6 6 But without faith it is impossible to please him: for he that cometh to God must believe that he is, and that he is a rewarder of them that diligently seek him. Jesus
Apart from the technical marvel you have showcased in the N64, you finally able to explain to me (a person with a goldfish brain) how Megatexture works in most Id software games. It makes a whole lotta sense why somes parts of their games are blurry.
Stunning work, that little piece of SGI hardware has so much hidden potential. We can only imagine what could have been had developers access to the knowledge and technical prowess you, Kaze and others on the N64 home brew scene today.
At the time some developers were also quite experienced. LucasArts or Factor 5 even wrote custom microcode for their N64 games, something I haven't seen from the homebrew scene yet.
He implemented the Painters Algorithm which was used by the Playstation 1 because they didn't have the memory capacity for using depth buffers. The n64 was able to use a depth buffer because it was built with more memory. The techniques and algorithms existed at the time, but with tight time crunch and deadlines developers didn't necessarily have time to experiment with optimizing their codebase for the hardware.
@@TTOOS nah, PS1 was totally maxed out and more in its lifetime and it really did make it's pseudo 3D tech look good for what it was. It couldn't do this better - with it's texture warping, lack of texture filtering and other features required to make solid surfaces there would be no point in even attempting to use textures like this on a PS1.
Curious what you can do with the Expansion Pak added in the system, doubling the ram. Would LOVE to see what games other people make using this! Perhaps even just texture mods to games that already exist with blurry textures? Keep up all the great N64 innovations James!
Don’t forget that adding an Expansion Pak to an N64 adds latency to a Rambus memory bus. If this technique is latency-bound, adding an Expansion Pak could slow down this technique. On the other hand, more texture data and maybe a Z-buffer could be stored in the RAM at the same time, giving optimization opportunities that are not possible without the Expansion Pak.
@@jnvivian I thought that unlike PSX GSRAM , RamBus has one bank per chip? Or was temperature the problem. The signal goes through all chips. Usually, each chip just sense the signal using an nMOSFET. The Signal is strong enough even at the final chip and then eaten by the impedance matched terminator. It works like TV tech, like radio. You just still cannot use two banks at the same time of course. That’s why Jaguar rather accessed all chips in parallel using 64 traces on the PCB for data.
@@ArneChristianRosenfeldt I believe that Rambus requires each RDRAM chip terminate the bus on one end and then regenerate the bus on the other end, turning the “bus” into a chain of alternating point-to-point links and RDRAM chips in order to maintain signal integrity since point-to-point links keep signals a lot cleaner than true buses. Each chip adds latency, and the slowest chip in the channel determines the channel’s maximum frequency.
The texture management reminds me of the sparse virtual textures demo in bgfx. When I saw it I thought it was borderline revolutionary, but I've never seen that kind of technique used elsewhere. Until, y'know, now. A memory constrained environment like this seems like the perfect use for it, too!
It's actually use in most game, just not everywhere, it trade details for surfaces, so more surface mean less details, modern game has surfaces pressure, so it's used mostly for terrain, like in far cry. Nanite is an extension of this to generalize it to mesh, so it's back in a modern form.
0:30 I don't think you were trying to misinform, but MegaTextures were first implemented in 2007's Enemy Territory: Quake Wars, not Rage (even though the technology is used in Rage as well). Excellent video!
In reality Mega Texturing exists since Doom 3 days, even thou the first game with MT was indeed Quake Wars. Doom 3 engine (idTech 4) has MT capabilities, for terrain only, since at lest 2003. (they disabled it for the source release but moders were able to bring it back) But the MT in Doom 3 engine is, lets say a first gen system, still not ready for prime time, it worked but still add a major drawback, no compression for the MT data, meaning If id used MT in Doom 3, a relatively small 4k terrain MT, would take GB of disk space, for comparation, in Quake Wars a 8k terrain MT, was only a couple of MB on disk. John Carmack at Doom 3 time, was still working on a compression system for the Mega Texturing data and it seems that was hard because it took a very long time to come.
ET:QW and Rage implementations are completely different. If I understood correctly, James used approach similar to Virtual Textures from Rage, not Clip Map used in Quake Wars. This is how paper Software Virtual Textures (by J.M.P Waveren) describes Clip Map: "The clip-map [7, 8, 9, 10, 11, 12] is one of the first effective schemes for virtual textures with per fragment texture address translation. The clip-map, introduced by Tanner et al. in 1998 [7], consist of a stack of images similar to a mip-map hierarchy. However, whereas mip-map levels cover the whole texture with images of increasing size, the clip-map uses fixed size levels that cover a decreasing area around a single focus point that is placed somewhere on the texture. Using a region of interest around a single focus point significantly simplifies the mapping of texture data to geometry and the texture address translation during rendering has minimal complexity. However, the single focus point of a clip-map limits this texture management scheme to environments with a natural spatial correlation between the texture data and the geometry, like for instance mostly flat contiguous terrain." and Virtual Textures: "Recent virtual texture systems are more flexible and mimic the virtual memory management of an operating system on modern CPUs [16, 17, 18, 19, 20, 21, 22, 23, 24]. Textures are divided into small pages that are automatically cached and loaded into video memory as required for rendering. These systems use real-time per fragment texture address translation through page tables and/or mapping textures. Because there is not necessarily a natural correlation between the geometry and texture pages, these virtual texture systems require feedback from the rendering pipeline to determine which pages need to be resident [13, 14, 15].
@@kwahoo5746good writeup! And in fact even going back to the SNES and PS2 days there were systems to essentially virtualize and prepare textures (tiles on SNES) for just in time usage on the 'GPU' so you were constantly using DMA to stream data into the relatively smaller VRAM aperture.
Could you use smaller mipmaps for parts of the scene that are closer to the edge of the screen? Most of the time while you're playing a game you're looking at the center of the screen and move the camera if you want to look at something off to the side, so if you took advantage of that maybe you could get more fps with a smaller noticeable graphics impact
Or for parts of faces that are closer to the camera. Downside is, if this requires more than the two mipmaps normally loaded, you're going to have a bad time. Maybe it can be prioritized over what's on the screen, and if space allows, go for it. Another thing that would help is simply dividing faces of large size or aspect ratio into smaller pieces -- the PS1 way of dealing with its affine mapping. But this incurs more geometry, and being that it's already rather limited...
Dude, thank you so much for this. I always imagined that this was possible, I don't understand anything about n64 programming, but I made sketches and studied the limitations a little and arrived at the exact theory of what you proved to be possible. If I may give you a tip, you can use black and white textures that contain an alpha channel, to overlay only the vertex color. I know that some games used this technique. This allows you to use the same texture of (for example) "brick", creating the variation red brick, and yellow brick, on walls to create a brick effect, but by stretching it over the floor, it can become a floor. I believe that many textures using snap-together tiles with abstract geometric shapes can fit into multiple locations in the same scene. I don't know very well the technical programming capabilities of the n64, but you can also use images superimposed on a single texture, and change the color palette to completely change the image present in the texture, like the "SEGA" intro of Sonic 3D from mega drive. I believe that changing the palette requires fewer cycles and certainly less memory than loading a new texture, so the stone texture can be transformed into the tree gravel texture just by activating some bits of the palette (which would make the wood grains visible) and changing the gray tones of the stone to brown.
Man i wish i understood half of this video but i always love to watch them for what ever reason. Im so fascinated by technical work arounds for something that sound impossible. Good stuff
It's cool you stuck to the stock n64 4MB but I think anyone experimenting with homebrew is going to have an expansion pack. I don't know how useful doubling the RAM would really be as you're being limited by the CPU in this demo by the sounds of it. Still, you can never have too much RAM.
At 40 MB of textures for this scene, that's larger than most N64 carts. Though might be an interesting essay to compare things that are known here with what Rare did to bring Conker's Bad Fur Day to light. Large cart, so many visually distinct areas and blending between nearby textures.
Love what you're doing and presentations are always concise and insightful, not infested with cuts, no padding, no bullshit, straight to the point. Big fan.
Wow. Even though it’s just a demo and it couldn’t really be used on a large scale game. The fact that this was even achieved is incredible. I hope you or someone is able to utilize this to create some fun small games. Just to be able to play something on n64 that looks that good would be so cool. Perhaps something like a mod for goldeneye or something that recreates the old “shipment” map from modern warfare. That’s a nice small multiplayer map that was a lot of fun.
Consider that this features 1024x1024 textures which quickly fill up the total available memory. 512x512 is still very crisp for N64 and contains only 25% of the pixel data, so if the highest LOD was skipped you could theoretically have up to 4x as many unique textures. Still can't say how it would perform in a more complex game environment during gameplay, but it seems possible to implement in some way for sure!
5:04 look at the floor, from the green to orange to red (less detailed to more detail). This is exactly what I noticed in MGS3D, how the developers made it possible to run this on the 3DS.
Same in Mariokart wii with a lot of the road textures. You don't really notice it much at first, only a little bit, but when I replaced them all with the CS missing texture (for reasons), it was much more apparent.
I immediately imagined this being used in a game like Silent Hill 1. Small, confined areas would probably work great for this visual technique. Like you said, you're also not limited to using it all the time, so somebody could choose to use it for specific set pieces or special effects.
this is fascinating. and great work! makes me wonder what sort of tricks studios like rare, boss, iguana, and a few others did to get their textures on the console to look so much better than most of their competition. later in the console's life it certainly did have parts of some games that approached this level of fidelity, but definitely not a whole room that looked like this. really interesting what you can accomplish on the N64 if you're willing to make the right trade offs and implement some clever programming.
Oh this is insane, and extremely cool!! It also gets me thinking what kind of visuals can be delivered with a mix of balancing these textures, and smart vertex coloring to simulate baked lighting, especially on parts like walls or floors (or any objects with repeating textures, and less detailed mesh). It could save some memory considering you'd be cutting out loading textures that, despite redundant in a way, are being loaded for having baked lighting on them... Of course, faking that with vertex coloring wouldn't deliver the same level of fidelity as baked lighting on these textures deliver, but that would be a cool thing to try!
I bet you could make a fun Myst-esque first person puzzle game with this sort of style! You could keep gameplay limited to small rooms, and have puzzles that involve inspecting detailed surfaces or reading small notes to justify the new texture size.
It's amazing that there is someone putting time and effort to make technical innovation for a console this old. The N64 must have a lot of personal value for you, or is it the challenge alone that drives you? I can definitely relate to putting effort into something that most of the world has left behind. Keep up the awesome work!
I could see this working really good with a narative/detective/escape room/myst type of game. Even if the frame rate gets a bit chunky it wouldn't matter too much. Making it so you could only be in one room at a time. Abandoned building exploration. Or anything else more focused of atmosphere. This is extremely interesting. Your knowledge of the n64 is beautiful. Thank you for explaining and showing the world your works :)
I super enjoy all of your experiments projects and info about the n64. It’s cool after so many years using my n64 I can still learn new things,mind blowing things. Also if this took second place in the game jam what the heck took first ?
Maybe use AI and fractals to compress textures into generated textures. Or how do you fill 64MB ? Two types of textures? Kkrieger has long loading times.
Brilliant, I never would have thought that this tech could be implemented on N64. I was recently reading up on MegaTextures/SVT for the simple fact that it has a lower file size than other virtual texturing methods. It's too bad no one considers it to be a viable alternative with the emergence of RTXIO & DirectStorage which would eliminate drawbacks many consider to be a deal breaker.
Game didn't stop using them, if you play far cry or call of duty, it's de facto the technique used. At least for terrain. You trade texture per surface, so game used it where it's needed. Nanites is using such a techniques too.
I wonder if it would be possible to make an entire game like this with gigabytes of data, where the cartridge has a lot of hardware built in to bank 40 mb chunks for the N64 to read at a time.
I'm really thrilled. The Nintendo 64 is a very important console for me. It was a gift from my late mother. I've had this console for over 18 years, I've always played Resident Evil 2 on it and seeing these textures really moved me. Thanks for the work. Greetings from Brazil.
when i saw this i was thinking kaze made another break through. but no its yours! im glad there more than one genius working on n64 and figuring out new innovations :P
I'm curious how it would behave with the memory card expansion. Would 8MB of total system memory help at all by being able to cache more reusable assets? Would it cut down on the pop in?
How about distance fields next? Valve's solution for crisp vector-like graphics from bitmaps. Would be great for text in Portal 64. Not sure how it would look with N64's diamond-like interpolation, but maybe that can be exploited in the textures. There's several ways to do distance fields beyond the basic 1-channel gradient in the "improved alpha-tested magnification for vector textures and special effects" paper that might allow for sharper results with smaller tiles. I don't recall their names off the top of my head but I know they're typically used for encoding fonts to bitmaps.
@@ArneChristianRosenfeldt It should be as simple as a threshold or boolean, but that's simple in modern computers. I don't know if that's possible on a per texture basis from the camera view.
Did you consult libdragon documentation? It makes everything sound so complicated. But if we skip the "comfort function", the 2d and the blurry stuff, it makes sense. It is a data flow: Load texture, pixel shader, blender ( reads the frame buffer, blends in the triangle ). At first it is weird that it is not just a "writer" as on PSX, but z-buffer and alpha need to "blend" in. Also maybe memory is not 18bit granular? I so hope that Rambus at least has the advantage that you can start bursts on any byte address . Now I just don't have the energy to go into libdragon again and be disappointed. @@jacobcrowley8207
this scene easily looks like it would have been from 2 whole generations ahead of the actual hardware, like on a PS3 or something, wow :D even if this isnt particularly reasonable to be your defacto graphics standard for a full-feature game on the N64, i still think this could have had some potentially useful applications if only developers for the N64 had thought of it ~30 years ago, such as very high quality ingame, not pre-rendered, cutscenes, or for the particular use case you're thinking of using it for Portal64, to make really clear illustrations and text on certain surfaces. the funny thing is,a similar technique was actually used pretty frequently on older hardware of the time, such as the SEGA Genesis, Super Nintendo, and even the OG NES, to make really large and detailed-looking sprites despite the limitations of those consoles. i wonder why you never really saw it on N64 games.
@@johnsch8634that's fair, but then the implication is that they would have thought of it, but decided not to use it, which also seems somewhat unbelievable to me.
@@Templarfreak Well, then you gotta think about factors like the price of ROM carts. and recall that Mario 64 was only 8MB and even Zelda was only 32MB, so a 1MB set of textures for a super-HQ cut-scene would not likely be seen as a wise investment of resources.
@@johnsch8634 that was just an idea in the OP, but there are plenty of other applications that could be done that would hardly take that much more space at all that could still vastly improve the texture quality in very specific situations. there's a few places in OOT that could have benefitted from using multiple segmented textures to display much higher-quality images and still be very fast as well but it is simply never done in that game. in such a case where it's just 1 image on a wall, and maybe this is done in 4 or 5 places throughout the game, would hardly impact the size of the game much at all. the images dont have to rise into MBs territory to achieve good readable quality.
Is 64MB a hard limit, or was that just the limit of the ROM cart sizes of the time? If there's a hard limit imposed because of the ROM interface, is it possible that limit might be bypassed somehow through the 64DD interface? I remember it being rumored early in development that 64DD would have 100MB disks. Not sure if there's any truth to that, or if it even matters if that interface might be slower than the cart interface.
I have the same question. Paging the cartridge should be possible, I would think (though require custom cartridge hardware), by accessing a specific address to request a different page (essentially swapping cartridges mid-game).
I believe the limit is 256MB, and I think the 64drive is the only flash cart which supports that. It wouldn't surprise me if someone worked out how to use more than 256MB.
I'm going to ask my default question again - would this be possible on the PS1? Here is my speculation: I imagine the lazy loading would be more noticeable due to relatively slow CD reads. I think it's an interesting problem - presumably this could be offset by the larger texture cache, but there's also far less RAM to play with. However, I just realised that on the PS1 you have an entire powerful coprocessor that usually sits unused most of the time in a majority of games - the video frame decoder! You could load the (much smaller) compressed frame chunks to ram as your initial data and gain a much larger set of (admittedly jpegged) initial tiles, or include more layers of mips before the CD needs to be read.
MDEC compressing textures is a really interesting idea. But I think what really gets you with the CDs even beyond much lower bandwidth is the enormous random access latency. I think this technique pretty unavoidably requires a good deal of random access.
@@espfusionand if access is not random. Like you record a speed run and lay out the data for it. Maybe with gaps and varying compression levels to avoid speed changes? If the player is too slow, seek back one or two tracks. Also you don’t need to hit the exact seek position as it is a guess mostly where the player will look at in 1 s. Just stream in the bits, 10to8 decode , cycle error correct , bunzip the blocks. Even for jpeg, doesn’t the CPU do the Huffman?
If a higher resolution tile is already loaded for an up close object but is used again on one further away, another minor optimization you could attempt is to just use the higher resolution tile already available. Also, I can see situations where so much stuff can be up close that it tries to overload the high resolution section of the buffer, how does it deal with that? does it focus the high resolution towards the center of the screen and drop to lower quality states for the stuff along the edges more likely to be replaced sooner as the camera moves?
@@ArneChristianRosenfeldt The buffer is shared, but it is still split into different segments depending on the resolution of the texture loaded, which is represented visually in the video displayed on either side of the shown demo at one point.
Isn't it nice that rounding errors don't lead to segmentation faults because we load whole segments using pure integer math? Und ist es nicht herlich, dass selbst bei Rundungsfehlern kein einzelnes Texel vom Nachbar Segment gerendert wird, weil wir es gar nicht in TMEM laden? Kein Windows "segmentation fault" möglich @@kmemz
It's like an alternate reality where companies stopped making new consoles, and as a consequence, developers just had to keep pushing hardware and keep optimizing and learning every trick they could, and this is the logical conclusion. Pretty freakin' neat.
Imo the performance penalty for swapping textures in and out of the texture cache makes this basically unusable for an actual game scenario, the fps already looked kind of bad in that basic test scene and it barely had any geometry which proves my point. It would be best to just stick with a few 64x64 4 bit textures or 64x128 greyscale ones to maximize the average level of detail since those can actually fit in the texture cache without having to worry about mipmap levels (in fact to even get textures of that size you have to disable mipmaps in the texture settings anyway)
Yeah, let’s add geometry! Also seems like omission of the z-buffer didn’t help much as games use it. The tiles fit into the cache. Greyscale does not work for everything. So you want to sort by texture?
This is really cool. There's something so interesting in seeing what the furthest you could push these old systems with newer techniques. I've had getting a Dreamcast on my radar as of late just because I'm seeing new games come out for it. Now you're making me interested in getting an N64 for the same reason.
A little grammar help is in order. Use "farthest" when talking about a measurable distance, and "furthest" for figurative or other uses. For example: "The Tree in back is the farthest element from the camera.", and "That was the furthest thing from my mind." Great vid! All good wishes.
one of those rare videos you can hit like and subscribe before even watching it.. I was just about to comment that somebody needs to port portal to the n64 but then you commented on it and I saw you actually did do a portal port. pretty hilarious timing.
I never expected those gorgeous textures would actually be possible on the N64 with its cripplingly small texture cache.
Yeah that’s the point of the video
@@scottcaramelthat’s the point of his comment
Thanks me too.
@@scottcaramelI swear these comments are from bots. If you notice, every top comment on every video is just basically a recap of why the video exists in the first place. If you watch a video of like, a man falling down, the top comment is usually like “Omg the way he fell was so funny.”
@@ro25988 probably to help the algorithm do its thing
The N64 was a fascinating piece of hardware even today, and I always had the feeling that developers never got to push it to its true limits. It's great to see you doing just that!
Especially that this is new tech at their time that they had to work with.
I’ve felt for a long time that it has gotten an unreasonable amount of criticism. Aside from how the texture cache works (not being an associative cache backed up by dedicated fast VRAM for buffering texture atlases like on PS1), some of the performance or memory limits on N64 stem from Nintendo-mandated rendering features that aren’t exactly life-or-death vital (mip-mapping, Z-buffering etc.) but had to exist in commercial games to keep the seal of quality and the approval of Nintendo (not sure how true this is, however, so correct me if I come across as a total bullsh*tter).
Another trend I have noticed playing (and owning) both PS1 and N64 is that most (if not all) non-linear adventure and platformers on N64 (that weren’t already already enforcing a limited draw distance for one reason or another) never rely on any level-of-detail reduction when drawing larger landscapes, sometimes not even limiting how far away objects/characters are visible. The PS1’s most complex creations like the Spyro series, Ape Escape, Tench 2, Quake II, Terracon, Sheep Raider (etc.) all either (1) have severely reduced draw distances, (2) don’t do anything because the level sizes are already limited in scope and geometrically boxy (such as in Quake II) or (3) use extremely obvious LOD transitions for environment (and character?) meshes or models (see Spyro). There is always this highly noticeable detail reduction factor in every complex PS1 I have played. When playing stuff like Goldeneye 007, Mystical Ninja, Jet Force Gemini, CBFD or Ocarina of Time, it makes me appreciate how far into the distance I can squint and still not see any environmental detail pop-in happening.
I heard that the way Smash 64 and F-Zero X managed 60fps was by disabling the Z-buffer. It's of course possible that the mandate did exist and they simply chose not to stick to their own rules of course.
I’m sure it’s a cartridge limitation
Honestly, no console has ever really been pushed to its absolute limits due to time and budgeting constraints. That's why we see incredibly detailed and impressive things from the modding community, due to having all the time in the world.
Imagine the people's reaction in 1996 if they saw this demo.
They wouldn't really be that surprised. Rare programmers knew the N64 was a powerhouse full of potential but had little time to fuck around with the hardware in order to release games on schedule
@@pretzelboi64 yeah, but not even the best demo's at the time looked anywhere near this good. I was obsessed with the N64 and remember being blown away with the really blurry underwater shark demo pics released in the Next Generation magazine in late 1995.
@@pretzelboi64 Going back to my teenage years and putting myself into a 1998 mindset, this completely blows my mind.
@@The8bitbeard I'm not saying it's not impressive but real-time triangle rasterization with perspective-correct texturing was achieved in Ultima Underworld back in 1992 on a CPU
They all would have had a headache because the frames are choppy asf
Your ability to consistently stretch the boundaries of this console with every video you release is mind blowing. You have no idea how incredible and inspirational what you do is to me. Great work as always!
One way to save texture space in a game is to have all the rooms decorated in the same style, and a small number of game objects used repeatedly in each room. Like, say, Portal does
So the usual way we do in game, that this techniques expend on ? 😂
Insane to find you here
.......
No hope in going to the past come to the loving savior today
Seek his Holy Spirit in prayer today he can give you peace confort and guidance today
Romans 6:23
For the wages of sin is death, but the free gift of God is eternal life in Christ Jesus our Lord.
Come to Jesus Christ today
Jesus Christ is only way to heaven
Repent and follow him today seek his heart Jesus Christ can fill the emptiness he can fill the void
Heaven and hell is real cone to the loving savior today
Today is the day of salvation tomorrow might be to late come to the loving savior today
John 3:16-21
16 For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life. 17 For God sent not his Son into the world to condemn the world; but that the world through him might be saved. 18 He that believeth on him is not condemned: but he that believeth not is condemned already, because he hath not believed in the name of the only begotten Son of God. 19 And this is the condemnation, that light is come into the world, and men loved darkness rather than light, because their deeds were evil. 20 For every one that doeth evil hateth the light, neither cometh to the light, lest his deeds should be reproved. 21 But he that doeth truth cometh to the light, that his deeds may be made manifest, that they are wrought in God.
Mark 1.15
15 And saying, The time is fulfilled, and the kingdom of God is at hand: repent ye, and believe the gospel.
2 Peter 3:9
The Lord is not slack concerning his promise, as some men count slackness; but is longsuffering to us-ward, not willing that any should perish, but that all should come to repentance.
Hebrews 11:6
6 But without faith it is impossible to please him: for he that cometh to God must believe that he is, and that he is a rewarder of them that diligently seek him.
Jesus
I think a simple sort of escape room game would be a really cool idea for this method. You can keep the game small and the game code itself is little more than a character mover, the interaction with some puzzles, and checking if they've won yet. That leaves a lot of space for this implementation to use some very high-res textures that would be visually really interesting as you could involve them in the puzzles in different ways.
Or place the story in a puzzle-ish world that could make possible to reuse the textures by using different combinations and positions. Maybe?
i think this would be perfect for an n64 version of the stanley parable
I feel like the limited textures of portal would lend itself pretty well to this kind of mipmap/LOD texture swapping
Imagine using a scaled down version of this method for baked lightmaps in Portal 64!
What?
@@sgashe is making portal for the n64
That file size would be massive
@@niko5008 not anymore :(
Seeing an n64 even being able to make readable textures is amazing, you're doing an amazing job with such limited hardware!
Now to add variable rate shading
If the n64 looked like this in the 90s it would have blown playstation out of the water
@@Syncrotron9001 Probably but the idea of mega textures didn't exist till the PS3 and they've always had tons of issues which is why they never took off.
@@theninjamaster67 someone fixed the framerate on mario 64 on the original hardware, if the FPS fix and mega textures ever get mixed into a working home brew that works on the original hardware that would be amazing.
Are you saying "L is real 2401" is not readable on SM64?? 😅
This guy is a genius hobbyist - a rare breed.
seems more like his career/profession than just a hobby lol
like kaze emanuar
@@BBWahoo Yes very much the same! Limitation breeds creativity I suppose.
They are rare, but there are a ton of them on youtube
the rarest part is that he looks and acts like a regular guy xD
I love your channel. You just causally drop near photorealistic baked lighting on N64 and explain it so nicely.
Incredible! I know you refer to MegaTextures and MIP Mapping, but you’ve also implemented a form of Sampler Feedback Streaming taking advantage of the cartridge speed that wasn’t possible with CDs. SFS is now possible with the fast SSDs in modern consoles and PCs.
Gotta love direct storage
Sampler Feedback Streaming is a specific technique that requires hardware support with direct control over the memory hardware / page tables. The concept of streaming textures is an old one and you'll see the beginnings on older 2D systems like the SNES and on sophisticated PS2 games which required streaming textures from main memory into VRAM and from disc into main memory. This tech demo is a great example of this general concept but is not a form of Sampler Feedback Streaming.
@@djmipsbut isn’t checking for visible tiles ( so small on this system ) almost like sampling? The rendere processes all geometry, culling clipping and z buffer occlusion culling and in a second stage would load sampled tiles which not already reside in RAM?
The demo does not use the z buffer. Weird choice. And how is it gonna render dynamic objects? Bipeds ?
Its absolutely is a feedback system, and Rage has lots of GDC slides about using Feedback in much the same way. SFS via hardware just makes the process easier.@@djmips
@@gibletto Correct. I did not say it wasn't a feedback system. Any pre-existing system that virtualizes GPU resources uses some form of feedback. Sampler Feedback is a specific patented hardware system and I'm trying to educate the OP that MegaTextures is a good enough description and there is no insight in calling this a form of SFS but of course I understand how the OP was only trying to fit the technique described into their own frame of reference.
Wow, really cool. I feel like you and @KazeN64 should collaborate! Great work on all this N64 advancement, and your Portal project looks great.
I was thinking the same!
Me too!
Me third!
Guys just upvote if you agree
@@hyperteleXii uh oh yt police is here...
For the ratman posters, you could use a 1024x2048 intensity texture and multiply that by your normal wall texture. Then for anything else you could have mini stickers
I think 1024 is the hard limit on the uv precision, the proper name for the sticker are decals.
I don't think the textures are that big in the original game. I may also need to reduce texture size to save memory on the cartridge
Keep in mind also that the screen resolution is going to be capped at 480i on original hardware no matter what you do, so redesigning the assets to be clear at low resolution is going to be essential anyway.
@@james.lambert Background data decompression maybe, like Metroid Prime used on Gamecube?
...Assuming there's actually any spare CPU cycles left to use, heh.
I'm reminded of the "texture streaming" that was added by DML on their port of Quake's renderer to the 1992 Atari Falcon (!)
That's really cool. Texture streaming was around as far back as the SNES and perhaps earlier (They were called tiles but same idea). Whenever you have a limited amount of VRAM but a big world, the concept becomes necessary. It is a generic design pattern that you see in any system that has a limitation on a local resource cache and the ability to stream from ROM, storage, or Internet. Texture streaming in a 3D game was a halmark of many PS2 games and a lot of coffee was consumed in the creation of fantastic DMA schemes to make it all work. It looks like the Falcon was another early example!
These are the kind of people I admire... the fact that you can make so much out of so little is astonishing...
That’s why I’m obsessed with making Gameboy games
@@MaxOaklandwhere can I download your games? Would like to try them out.
The colorized lights are incredible, it almost looks like some ray tracing! You never cease to amaze me :)
its likely prebaked along the shadows since you also see normal maps
It may or may not be baked global illumination. Maybe raytracing, maybe other algo like photon mapping, voxel cone tracing, radiosity and their variations like bidirectional scattered, pathtracing or instant radiosity.
@@uis246 Of COURSE it's not raytraced. As soon as some people hear a term that they don't understand, they feel the need to use it whenever possible.
@@TUUK2006 it's baked raytracing. the room and it's light baked textures were made in blender, which uses ray tracing to light bake textures. on the n64 end, the room is completely unshaded textures
......
Do you know Jesus Christ can set you free from sins and save you from hell today
Jesus Christ is the only hope in this world no other gods will lead you to heaven
There is no security or hope with out Jesus Christ in this world come and repent of all sins today
Today is the day of salvation come to the loving savior Today repent and do not go to hell
Come to Jesus Christ today
Jesus Christ is only way to heaven
Repent and follow him today seek his heart Jesus Christ can fill the emptiness he can fill the void
Heaven and hell is real cone to the loving savior today
Today is the day of salvation tomorrow might be to late come to the loving savior today
Romans 6.23
For the wages of sin is death; but the gift of God is eternal life through Jesus Christ our Lord.
John 3:16-21
16 For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life. 17 For God sent not his Son into the world to condemn the world; but that the world through him might be saved. 18 He that believeth on him is not condemned: but he that believeth not is condemned already, because he hath not believed in the name of the only begotten Son of God. 19 And this is the condemnation, that light is come into the world, and men loved darkness rather than light, because their deeds were evil. 20 For every one that doeth evil hateth the light, neither cometh to the light, lest his deeds should be reproved. 21 But he that doeth truth cometh to the light, that his deeds may be made manifest, that they are wrought in God.
Mark 1.15
15 And saying, The time is fulfilled, and the kingdom of God is at hand: repent ye, and believe the gospel.
2 Peter 3:9
The Lord is not slack concerning his promise, as some men count slackness; but is longsuffering to us-ward, not willing that any should perish, but that all should come to repentance.
Hebrews 11:6
6 But without faith it is impossible to please him: for he that cometh to God must believe that he is, and that he is a rewarder of them that diligently seek him.
Jesus
Apart from the technical marvel you have showcased in the N64, you finally able to explain to me (a person with a goldfish brain) how Megatexture works in most Id software games. It makes a whole lotta sense why somes parts of their games are blurry.
Stunning work, that little piece of SGI hardware has so much hidden potential.
We can only imagine what could have been had developers access to the knowledge and technical prowess you, Kaze and others on the N64 home brew scene today.
At the time some developers were also quite experienced. LucasArts or Factor 5 even wrote custom microcode for their N64 games, something I haven't seen from the homebrew scene yet.
He implemented the Painters Algorithm which was used by the Playstation 1 because they didn't have the memory capacity for using depth buffers. The n64 was able to use a depth buffer because it was built with more memory. The techniques and algorithms existed at the time, but with tight time crunch and deadlines developers didn't necessarily have time to experiment with optimizing their codebase for the hardware.
@@TTOOS No it couldn't, the CD drive reading speed was too low.
@@TTOOS nah, PS1 was totally maxed out and more in its lifetime and it really did make it's pseudo 3D tech look good for what it was. It couldn't do this better - with it's texture warping, lack of texture filtering and other features required to make solid surfaces there would be no point in even attempting to use textures like this on a PS1.
Wish we got a new team of retro Devs together to make these types of games again
Curious what you can do with the Expansion Pak added in the system, doubling the ram. Would LOVE to see what games other people make using this! Perhaps even just texture mods to games that already exist with blurry textures? Keep up all the great N64 innovations James!
Mods are unlikely. It's too CPU intensive, and the lack of the z buffer is not something n64 games are prepared for.
Some games ran faster with expansion pack. Except this here also.
Don’t forget that adding an Expansion Pak to an N64 adds latency to a Rambus memory bus. If this technique is latency-bound, adding an Expansion Pak could slow down this technique. On the other hand, more texture data and maybe a Z-buffer could be stored in the RAM at the same time, giving optimization opportunities that are not possible without the Expansion Pak.
@@jnvivian I thought that unlike PSX GSRAM , RamBus has one bank per chip? Or was temperature the problem. The signal goes through all chips. Usually, each chip just sense the signal using an nMOSFET. The Signal is strong enough even at the final chip and then eaten by the impedance matched terminator. It works like TV tech, like radio. You just still cannot use two banks at the same time of course. That’s why Jaguar rather accessed all chips in parallel using 64 traces on the PCB for data.
@@ArneChristianRosenfeldt I believe that Rambus requires each RDRAM chip terminate the bus on one end and then regenerate the bus on the other end, turning the “bus” into a chain of alternating point-to-point links and RDRAM chips in order to maintain signal integrity since point-to-point links keep signals a lot cleaner than true buses. Each chip adds latency, and the slowest chip in the channel determines the channel’s maximum frequency.
Given the small-scale/high-detail tradeoff, I think this could be really cool for Escape Room style games.
I love seeing these modern techniques used on old hardware and how efficient it can be. Thank you!
The texture management reminds me of the sparse virtual textures demo in bgfx. When I saw it I thought it was borderline revolutionary, but I've never seen that kind of technique used elsewhere. Until, y'know, now. A memory constrained environment like this seems like the perfect use for it, too!
It's actually use in most game, just not everywhere, it trade details for surfaces, so more surface mean less details, modern game has surfaces pressure, so it's used mostly for terrain, like in far cry. Nanite is an extension of this to generalize it to mesh, so it's back in a modern form.
Sparse virtual textures is a programming technique where the GPU does part of the work
I feel like this man and Kaze needs to do a collab of some sort one day
Wow. That is incredibly impressive.
That’s pretty impressive, I really admire you! Thank you for keeping the N64 alive.
0:30 I don't think you were trying to misinform, but MegaTextures were first implemented in 2007's Enemy Territory: Quake Wars, not Rage (even though the technology is used in Rage as well). Excellent video!
In reality Mega Texturing exists since Doom 3 days, even thou the first game with MT was indeed Quake Wars.
Doom 3 engine (idTech 4) has MT capabilities, for terrain only, since at lest 2003. (they disabled it for the source release but moders were able to bring it back)
But the MT in Doom 3 engine is, lets say a first gen system, still not ready for prime time, it worked but still add a major drawback, no compression for the MT data, meaning If id used MT in Doom 3, a relatively small 4k terrain MT, would take GB of disk space, for comparation, in Quake Wars a 8k terrain MT, was only a couple of MB on disk.
John Carmack at Doom 3 time, was still working on a compression system for the Mega Texturing data and it seems that was hard because it took a very long time to come.
ET:QW and Rage implementations are completely different. If I understood correctly, James used approach similar to Virtual Textures from Rage, not Clip Map used in Quake Wars. This is how paper Software Virtual Textures (by J.M.P Waveren) describes Clip Map:
"The clip-map [7, 8, 9, 10, 11, 12] is one of the first effective schemes for virtual textures with per
fragment texture address translation. The clip-map, introduced by Tanner et al. in 1998 [7],
consist of a stack of images similar to a mip-map hierarchy. However, whereas mip-map levels
cover the whole texture with images of increasing size, the clip-map uses fixed size levels that
cover a decreasing area around a single focus point that is placed somewhere on the texture.
Using a region of interest around a single focus point significantly simplifies the mapping of
texture data to geometry and the texture address translation during rendering has minimal
complexity. However, the single focus point of a clip-map limits this texture management
scheme to environments with a natural spatial correlation between the texture data and the
geometry, like for instance mostly flat contiguous terrain."
and Virtual Textures:
"Recent virtual texture systems are more flexible and mimic the virtual memory management of
an operating system on modern CPUs [16, 17, 18, 19, 20, 21, 22, 23, 24]. Textures are divided
into small pages that are automatically cached and loaded into video memory as required for
rendering. These systems use real-time per fragment texture address translation through page
tables and/or mapping textures. Because there is not necessarily a natural correlation between the
geometry and texture pages, these virtual texture systems require feedback from the rendering
pipeline to determine which pages need to be resident [13, 14, 15].
@@kwahoo5746good writeup! And in fact even going back to the SNES and PS2 days there were systems to essentially virtualize and prepare textures (tiles on SNES) for just in time usage on the 'GPU' so you were constantly using DMA to stream data into the relatively smaller VRAM aperture.
This is real interesting stuff. I like that you're really taking advantage of the fast read speeds from thr cartridge.
Could you use smaller mipmaps for parts of the scene that are closer to the edge of the screen? Most of the time while you're playing a game you're looking at the center of the screen and move the camera if you want to look at something off to the side, so if you took advantage of that maybe you could get more fps with a smaller noticeable graphics impact
Or for parts of faces that are closer to the camera. Downside is, if this requires more than the two mipmaps normally loaded, you're going to have a bad time. Maybe it can be prioritized over what's on the screen, and if space allows, go for it.
Another thing that would help is simply dividing faces of large size or aspect ratio into smaller pieces -- the PS1 way of dealing with its affine mapping. But this incurs more geometry, and being that it's already rather limited...
Ah, the fixed foveated rendering approach I see!
That sounds like foveated rendering, which is used by VR headsets like Apple Vision Pro. Another option is Variable Rate Shading.
Imagine the game is blurry at the edges. There's your answer.
Does Fixed Foveated Rendering look good in practice? Eye tracking is a necessary component IMO.
As a computer engineering student, this channel is a goldmine. Thanks for a great video
This explanation was excellent!
You’re doing incredible work. I’m loving seeing the limits of its hardware
Dude, thank you so much for this. I always imagined that this was possible, I don't understand anything about n64 programming, but I made sketches and studied the limitations a little and arrived at the exact theory of what you proved to be possible.
If I may give you a tip, you can use black and white textures that contain an alpha channel, to overlay only the vertex color. I know that some games used this technique. This allows you to use the same texture of (for example) "brick", creating the variation red brick, and yellow brick, on walls to create a brick effect, but by stretching it over the floor, it can become a floor. I believe that many textures using snap-together tiles with abstract geometric shapes can fit into multiple locations in the same scene. I don't know very well the technical programming capabilities of the n64, but you can also use images superimposed on a single texture, and change the color palette to completely change the image present in the texture, like the "SEGA" intro of Sonic 3D from mega drive.
I believe that changing the palette requires fewer cycles and certainly less memory than loading a new texture, so the stone texture can be transformed into the tree gravel texture just by activating some bits of the palette (which would make the wood grains visible) and changing the gray tones of the stone to brown.
Next video: "How I got geometric tesselation working on a Nintendo 64"
Man i wish i understood half of this video but i always love to watch them for what ever reason. Im so fascinated by technical work arounds for something that sound impossible. Good stuff
🤯Never thought I'd see mega textures running on a 5th gen console! Very cool!
I feel like there was probably a title that may have used this approach in the 6th gen but I'm not aware of any other on the 5th. Very cool demo!
This + baking lighting into vertex colors could probably offer a nice graphical edge without going INSANE with the amount of unique tiles
It's cool you stuck to the stock n64 4MB but I think anyone experimenting with homebrew is going to have an expansion pack. I don't know how useful doubling the RAM would really be as you're being limited by the CPU in this demo by the sounds of it. Still, you can never have too much RAM.
At 40 MB of textures for this scene, that's larger than most N64 carts. Though might be an interesting essay to compare things that are known here with what Rare did to bring Conker's Bad Fur Day to light. Large cart, so many visually distinct areas and blending between nearby textures.
You can never have too much RAM, unless you're playing Space Station Silicon Valley
@@TheWaterMiners What's the significance of that?
@@Kurusan Space Station Silicon Valley does not work if your N64 has an Expansion Pak inserted. This is the only game to do this.
@@TheWaterMiners Wow that's so weird! Anyone ever figure out why?
Love what you're doing and presentations are always concise and insightful, not infested with cuts, no padding, no bullshit, straight to the point. Big fan.
Wow. Even though it’s just a demo and it couldn’t really be used on a large scale game. The fact that this was even achieved is incredible. I hope you or someone is able to utilize this to create some fun small games. Just to be able to play something on n64 that looks that good would be so cool.
Perhaps something like a mod for goldeneye or something that recreates the old “shipment” map from modern warfare. That’s a nice small multiplayer map that was a lot of fun.
Consider that this features 1024x1024 textures which quickly fill up the total available memory. 512x512 is still very crisp for N64 and contains only 25% of the pixel data, so if the highest LOD was skipped you could theoretically have up to 4x as many unique textures. Still can't say how it would perform in a more complex game environment during gameplay, but it seems possible to implement in some way for sure!
We want to beat PSX with its limited RAM in a single level. If 64 MB cartridge is not enough, I don’t know. RPG likes CD.
@@ArneChristianRosenfeldtEven at just 256x256 textures the N64 gets access to texture filtering, a feature the PSX did not support.
5:04 look at the floor, from the green to orange to red (less detailed to more detail). This is exactly what I noticed in MGS3D, how the developers made it possible to run this on the 3DS.
Same in Mariokart wii with a lot of the road textures. You don't really notice it much at first, only a little bit, but when I replaced them all with the CS missing texture (for reasons), it was much more apparent.
A P.T. (Silent Hill) demake would work great with that tech.
Slow turning, basically just one hallway...
Oh wow! I saw this demo on another video and I didn't realise you were the one that made it!!
I immediately imagined this being used in a game like Silent Hill 1. Small, confined areas would probably work great for this visual technique. Like you said, you're also not limited to using it all the time, so somebody could choose to use it for specific set pieces or special effects.
Man created LODs for pixels, this is so genuinely amazing
this is fascinating. and great work! makes me wonder what sort of tricks studios like rare, boss, iguana, and a few others did to get their textures on the console to look so much better than most of their competition. later in the console's life it certainly did have parts of some games that approached this level of fidelity, but definitely not a whole room that looked like this. really interesting what you can accomplish on the N64 if you're willing to make the right trade offs and implement some clever programming.
Oh this is insane, and extremely cool!!
It also gets me thinking what kind of visuals can be delivered with a mix of balancing these textures, and smart vertex coloring to simulate baked lighting, especially on parts like walls or floors (or any objects with repeating textures, and less detailed mesh). It could save some memory considering you'd be cutting out loading textures that, despite redundant in a way, are being loaded for having baked lighting on them... Of course, faking that with vertex coloring wouldn't deliver the same level of fidelity as baked lighting on these textures deliver, but that would be a cool thing to try!
I bet you could make a fun Myst-esque first person puzzle game with this sort of style! You could keep gameplay limited to small rooms, and have puzzles that involve inspecting detailed surfaces or reading small notes to justify the new texture size.
This was my top pick from the jam. Just amazing seeing what’s possible these days
Oh shoot, I saw your demo on Hard4Games and didn't realize it was you! Working on a few really cool N64 projects, huh?
It's amazing that there is someone putting time and effort to make technical innovation for a console this old. The N64 must have a lot of personal value for you, or is it the challenge alone that drives you? I can definitely relate to putting effort into something that most of the world has left behind. Keep up the awesome work!
Ready to have my mind blown again…
Same. lol
Thank's for the ROM
It's look amaizing on CRT plug to my trusty old RGB mod N64
I can't wait to see the Portal port complete to play it 🤤
I could see this working really good with a narative/detective/escape room/myst type of game. Even if the frame rate gets a bit chunky it wouldn't matter too much. Making it so you could only be in one room at a time. Abandoned building exploration. Or anything else more focused of atmosphere. This is extremely interesting. Your knowledge of the n64 is beautiful. Thank you for explaining and showing the world your works :)
4:08 the blurry tiles that don't manage to get replaced immediately when turning actually looks so cool
I super enjoy all of your experiments projects and info about the n64. It’s cool after so many years using my n64 I can still learn new things,mind blowing things. Also if this took second place in the game jam what the heck took first ?
Wow. Great explanation and awesome to see a scene made with this. It'd be cool to see if anyone takes this further.
Maybe using this technique with procedurally generated textures like you have in Krieger could make it feasible for larger scenes.
Maybe use AI and fractals to compress textures into generated textures. Or how do you fill 64MB ? Two types of textures? Kkrieger has long loading times.
I love this. You managed to retain the that plastic sheen that 90's 3D model posters had.
Brilliant, I never would have thought that this tech could be implemented on N64. I was recently reading up on MegaTextures/SVT for the simple fact that it has a lower file size than other virtual texturing methods. It's too bad no one considers it to be a viable alternative with the emergence of RTXIO & DirectStorage which would eliminate drawbacks many consider to be a deal breaker.
Game didn't stop using them, if you play far cry or call of duty, it's de facto the technique used. At least for terrain. You trade texture per surface, so game used it where it's needed. Nanites is using such a techniques too.
could you point me to your sources? I got really interested in megatextures after Lex Friedman's interview with Carmack, but I just didn't get far
@@prgnify look on the GDC vault of these game or look for ' advance in real time rendering ' notably 2023 for call of duty in the blog selfshadow
The megatexture technique used in Rage was amazing and I am sad it wasn't used more in games.
I wonder if it would be possible to make an entire game like this with gigabytes of data, where the cartridge has a lot of hardware built in to bank 40 mb chunks for the N64 to read at a time.
The banking itself is real cheap, in comparison to the GBs of storage, certainly. For the time, that would have been a $5000 game 😮
@@SimonBuchanNzWould have been tough to even physically fit in a standard sized cartridge.
Might be possible with an Everdrive
Great texture work!!!! Showing this to someone in 1996 would've blown their mind (Considering this already blows my mind, looks beautiful)
I'm really thrilled. The Nintendo 64 is a very important console for me. It was a gift from my late mother. I've had this console for over 18 years, I've always played Resident Evil 2 on it and seeing these textures really moved me. Thanks for the work. Greetings from Brazil.
when i saw this i was thinking kaze made another break through. but no its yours! im glad there more than one genius working on n64 and figuring out new innovations :P
I'm curious how it would behave with the memory card expansion. Would 8MB of total system memory help at all by being able to cache more reusable assets? Would it cut down on the pop in?
I find it amazing that theres still people out their messing with such old hardware.
How about distance fields next? Valve's solution for crisp vector-like graphics from bitmaps. Would be great for text in Portal 64. Not sure how it would look with N64's diamond-like interpolation, but maybe that can be exploited in the textures. There's several ways to do distance fields beyond the basic 1-channel gradient in the "improved alpha-tested magnification for vector textures and special effects" paper that might allow for sharper results with smaller tiles. I don't recall their names off the top of my head but I know they're typically used for encoding fonts to bitmaps.
On N64 you really pay for complicated pixel shaders. Now I gotta read the paper ..
@@ArneChristianRosenfeldt It should be as simple as a threshold or boolean, but that's simple in modern computers. I don't know if that's possible on a per texture basis from the camera view.
Did you consult libdragon documentation? It makes everything sound so complicated. But if we skip the "comfort function", the 2d and the blurry stuff, it makes sense. It is a data flow: Load texture, pixel shader, blender ( reads the frame buffer, blends in the triangle ). At first it is weird that it is not just a "writer" as on PSX, but z-buffer and alpha need to "blend" in. Also maybe memory is not 18bit granular? I so hope that Rambus at least has the advantage that you can start bursts on any byte address . Now I just don't have the energy to go into libdragon again and be disappointed. @@jacobcrowley8207
This is insane. God bless the demoscene
this scene easily looks like it would have been from 2 whole generations ahead of the actual hardware, like on a PS3 or something, wow :D
even if this isnt particularly reasonable to be your defacto graphics standard for a full-feature game on the N64, i still think this could have had some potentially useful applications if only developers for the N64 had thought of it ~30 years ago, such as very high quality ingame, not pre-rendered, cutscenes, or for the particular use case you're thinking of using it for Portal64, to make really clear illustrations and text on certain surfaces. the funny thing is,a similar technique was actually used pretty frequently on older hardware of the time, such as the SEGA Genesis, Super Nintendo, and even the OG NES, to make really large and detailed-looking sprites despite the limitations of those consoles. i wonder why you never really saw it on N64 games.
I wouldn't assume that the developers back then didn't think of techniques like this... They were very clever programmers.
@@johnsch8634that's fair, but then the implication is that they would have thought of it, but decided not to use it, which also seems somewhat unbelievable to me.
@@Templarfreak Well, then you gotta think about factors like the price of ROM carts. and recall that Mario 64 was only 8MB and even Zelda was only 32MB, so a 1MB set of textures for a super-HQ cut-scene would not likely be seen as a wise investment of resources.
@@johnsch8634 that was just an idea in the OP, but there are plenty of other applications that could be done that would hardly take that much more space at all that could still vastly improve the texture quality in very specific situations. there's a few places in OOT that could have benefitted from using multiple segmented textures to display much higher-quality images and still be very fast as well but it is simply never done in that game. in such a case where it's just 1 image on a wall, and maybe this is done in 4 or 5 places throughout the game, would hardly impact the size of the game much at all. the images dont have to rise into MBs territory to achieve good readable quality.
I’m always so impressed by how people manage to find ways to enhance old technology in ways never thought possible at the time it was mainly used.
Is 64MB a hard limit, or was that just the limit of the ROM cart sizes of the time? If there's a hard limit imposed because of the ROM interface, is it possible that limit might be bypassed somehow through the 64DD interface? I remember it being rumored early in development that 64DD would have 100MB disks. Not sure if there's any truth to that, or if it even matters if that interface might be slower than the cart interface.
i think it turned me gay
I have the same question. Paging the cartridge should be possible, I would think (though require custom cartridge hardware), by accessing a specific address to request a different page (essentially swapping cartridges mid-game).
I believe the limit is 256MB, and I think the 64drive is the only flash cart which supports that. It wouldn't surprise me if someone worked out how to use more than 256MB.
256 Mb not MB 😂 bits vs bytes 😅
@@timmygilbert4102 256Mb is 32MB, so half the biggest cartridge size.
I saw this and thought, "Wow this should be shown to the portal 64 guy" Then heard the voice and saw your face and realized who I was watching.
Could you use the N64 DD? Idk how big or fast those are.
You're a wizard, James Lambert. Seriously, this is some next level homebrew stuff.
I'm going to ask my default question again - would this be possible on the PS1?
Here is my speculation:
I imagine the lazy loading would be more noticeable due to relatively slow CD reads. I think it's an interesting problem - presumably this could be offset by the larger texture cache, but there's also far less RAM to play with.
However, I just realised that on the PS1 you have an entire powerful coprocessor that usually sits unused most of the time in a majority of games - the video frame decoder! You could load the (much smaller) compressed frame chunks to ram as your initial data and gain a much larger set of (admittedly jpegged) initial tiles, or include more layers of mips before the CD needs to be read.
MDEC compressing textures is a really interesting idea. But I think what really gets you with the CDs even beyond much lower bandwidth is the enormous random access latency. I think this technique pretty unavoidably requires a good deal of random access.
@@espfusionand if access is not random. Like you record a speed run and lay out the data for it. Maybe with gaps and varying compression levels to avoid speed changes? If the player is too slow, seek back one or two tracks. Also you don’t need to hit the exact seek position as it is a guess mostly where the player will look at in 1 s. Just stream in the bits, 10to8 decode , cycle error correct , bunzip the blocks.
Even for jpeg, doesn’t the CPU do the Huffman?
@@espfusion Naughty Dog managed to do very impressive streaming on PS1. It could be made with enough effort.
This with @KazeN64 Optimization would make an incredible game.
If a higher resolution tile is already loaded for an up close object but is used again on one further away, another minor optimization you could attempt is to just use the higher resolution tile already available.
Also, I can see situations where so much stuff can be up close that it tries to overload the high resolution section of the buffer, how does it deal with that? does it focus the high resolution towards the center of the screen and drop to lower quality states for the stuff along the edges more likely to be replaced sooner as the camera moves?
At what point in time is there a high resolution section? The color demo at the end suggests a shared buffer.
@@ArneChristianRosenfeldt The buffer is shared, but it is still split into different segments depending on the resolution of the texture loaded, which is represented visually in the video displayed on either side of the shown demo at one point.
Isn't it nice that rounding errors don't lead to segmentation faults because we load whole segments using pure integer math?
Und ist es nicht herlich, dass selbst bei Rundungsfehlern kein einzelnes Texel vom Nachbar Segment gerendert wird, weil wir es gar nicht in TMEM laden? Kein Windows "segmentation fault" möglich @@kmemz
It's like an alternate reality where companies stopped making new consoles, and as a consequence, developers just had to keep pushing hardware and keep optimizing and learning every trick they could, and this is the logical conclusion. Pretty freakin' neat.
Imo the performance penalty for swapping textures in and out of the texture cache makes this basically unusable for an actual game scenario, the fps already looked kind of bad in that basic test scene and it barely had any geometry which proves my point. It would be best to just stick with a few 64x64 4 bit textures or 64x128 greyscale ones to maximize the average level of detail since those can actually fit in the texture cache without having to worry about mipmap levels (in fact to even get textures of that size you have to disable mipmaps in the texture settings anyway)
Yeah, let’s add geometry! Also seems like omission of the z-buffer didn’t help much as games use it. The tiles fit into the cache. Greyscale does not work for everything.
So you want to sort by texture?
I can’t wait to see what you come up with next. This is so impressive
This is so gosh dang cool. I love retro computing and the people who do this stuff
Bro this is genius !! I love the detailed explanation. It was clear and concise. Amazing video!
man this is why i got into games development, there's so many insanely interesting and plain genius things! this is a fantastic lil showcase James :)
This is really cool. There's something so interesting in seeing what the furthest you could push these old systems with newer techniques. I've had getting a Dreamcast on my radar as of late just because I'm seeing new games come out for it. Now you're making me interested in getting an N64 for the same reason.
Congratulations! A beautifull and very good work! I love when fans explorers classic hardware, making excelent works this!
This is insane, I'm blown away. You're a genius, James. I'm glad I subscribed
This is mindblowing! 🔥
Congrats! Keep the awesome work!
dude. wth. why are you fricken good at pushing this hardware. this is amazing and i'm glad youtube suggestd your channel (portal 64 paradox thing lol)
This tingles all my nostalgia and tech sensibilities. Love this guy's work.
That cache visualization at 3:30 🤌
A little grammar help is in order. Use "farthest" when talking about a measurable distance, and "furthest" for figurative or other uses. For example: "The Tree in back is the farthest element from the camera.", and "That was the furthest thing from my mind." Great vid! All good wishes.
The fun of homebrew is creating stuff that developers didn't want to do back in the day but we suspect is possible.
On top of that, the prebaked global illumination makes the scene really gorgeous
Wow just wow this is amazing ! Great tech demo for N64 you should do a saturn tech demo as well
Saturn is ugly. Mainboard and render quality.
Hater @@ArneChristianRosenfeldtdetected!
It looks gorgeous! Congrats for the grat work mate.
These kind of videos are inspiring. Coding a game for a retro console has made it onto my bucket list.
A lot of people have explained what “could” work on the N64 but the fact that you just DID it puts you well above many
You've done incredible work here, Mr. Lambert. Also, this was a great explanation. Even the layman can understand.
one of those rare videos you can hit like and subscribe before even watching it.. I was just about to comment that somebody needs to port portal to the n64 but then you commented on it and I saw you actually did do a portal port. pretty hilarious timing.
Kaze Emanuar must learn about this, It'd be crazy what he can do with his optimized Mario 64 with this