Tiny3D - Particles [N64 Homebrew]
ฝัง
- เผยแพร่เมื่อ 25 ม.ค. 2025
- I've now added a completely new ucode specifically for particles.
That is 3D points with a size/color that got expanded into rectangles in screen-space.
This is incredibly cheap for the RSP compared to full triangles.
Transformations with a matrix, and depth checks are also supported.
More information in the N64Brew discord: / discord
Repo: github.com/Hai...
_______
Music:
Botanic Fields Race - John Oestmann
![Tiny3D - Textured-Particles [N64 Homebrew]](http://i.ytimg.com/vi/ulyNfc03UIo/mqdefault.jpg)
![Tiny3D - Textured-Particles [N64 Homebrew]](/img/tr.png)
![Coin Rush - GameJam 2024 [N64 Homebrew]](http://i.ytimg.com/vi/4Ra2c5847Gs/mqdefault.jpg)
we need a freaking time machine to go back to 1996 and hand over today's N64 code libraries to developers as well as documentation so they can save the system lol
And hand a gamecube controller to whoever made the 64 analog stick.
@@zangl2955you were probably using it upside down.. and tilted
@@zangl2955 Nah, it's the most precise stick ever made.
This is a really astonishing effect, considering the hardware limitations.
50k particles and still running at a better framerate than many official N64 releases.
I absolutely love how the community is finally starting to turn so much attention toward the N64 and uncovering all kinds of never before seen tricks and optimizations to unlock more of its full potential.
This effect is without a doubt really impressive to look at visually.
I'm curious tho.
Are the particles limited to squares or would shapes like triangles or circles be possible without a severe hot to performance.
Those could really smooth out some of those effects even more
This new Unreal Engine tech is looking impressive. I've never seen lighting and particles look this realistic.
Just top of my head, this is approximately 800,000 particles/sec. Very impressive!
This is incredible. Thanks for sharing. n64 microcode has fascinated me ever since reading about how (allegedly) Nintendo had some secret microcode that could run dramatically faster, but was really buggy. Then Factor 5 came along and made the n64 just sing. Really nice to be able to actually read the code behind all of this finally. Thank you for posting this.
There were a couple different Nintendo supplied "microcode" programs (kind of a misnomer, it was just code for the MIPS-based RSP). Some are specialized (for lines, 2D graphics, etc), but the 3D microcodes mostly just provided different features and different levels of precision. I'm not aware of any "bugginess" unless you consider uglier graphics buggy. Most games used "Fast 3D", but there was also "Turbo 3D" which did less precise math and didn't support various features (no clipping, no perspective correct texturing, no matrix stack, no anti aliasing, no dynamic lighting).
The issue is that by providing only really one viable microcode* which did everything, all games paid the cost for features they didn't use.
* - there was also a z sort microcode, and a version of fast 3D with no near clipping, but I'm not sure how commonly they were used.
this is what my nightmares are like, not because this is frickin awsome but hundreds of tiny squares moving around frightens me😰
AAA SHAPES!
I've always had the idea that anything can be cool or anything can suck, it just depends on the programmers and devs behind the project. Your stuff is amazing on the N64 and I'm sure if the N64 had a longer life span we would have seen some really cool commercial games for it.
Thankfully we have tools and flashcarts so that anyone can now get into N64 development. Also back in 1996-ish this stuff was mind-blowing.
Incroyable, autant de particules, l'effet de neige serait magnifique. L'herbe est très belle aussi, mais consomme beaucoup plus de ressource. Bravo c'est incroyable de voir tout ça de manière fluide en plus sur la console d'origine !
ooooo this is exciting, i hope to get into homebrew development one day, and i might take a perusing at this when i wanna make n64 homebrew 👀
Gorgeous.
Wow this is insane. Super cool to see!
That is really cool. Any chance the particles could accept a texture?
Thanks, yup textured particles will be added too in the future.
I already had a working version in an older prototype of the ucode (there are some videos in the brew discord), so it just needs a proper implementation.
The plan is to make the loaded texture cover the entire particle, but allow for a global+local tile setting that way you can do sprite-animations.
That's also needed to e.g. fake rotation via an animation sheet.
But details may change when i actually get to implement this.
Oh he's goated... he's goated with it.
The grass looks so beautiful!!!!
It's pretty impressive how you got this at 60 fps. This system's processor is so weird and bizzare when it comes to how fast or slow it can be. Honestly, I'd much prefer to make homebrew for the SNES over this. But you know different people have different preferences when it comes to what platform they would use.
N64 is a beast!
this is insanity
Those are a lot of moving things. W o a h .
Fantastic one! Greetings from Brazil!
i always thought the n64 was a powerful system, almost up to the PS2 if some of the specs were more up to date because holy, that first footage looks like a modern indie game running on PC with that shading
glad to see your channel taking off!
Absolutely loving this
Oh this is some primo fantastic stuff right here! I'm excited for this.
I wonder if there's a way to backend this into Armory 3D?
this is amazing
When a new n64 techdemo is more optimized than 99% of modern games out there. Thats crazy ♥
Modern AAA games. There are many greatly optimised smaller games. I'm so tired of people claiming that these cashgrabs are the entire game industry
Also this is N64, you either make it very optimised or it just doesn't work
@@manender1020 optimized as a word loses its meaning if every working n64 game is optimized. surely a program running on the n64 can be more optimized
@@scrung it doesn't, the process of optimisation is a thing on N64 software too I believe
Donkey Kong 64 had a memory leak
@@manender1020 yeah that’s what i’m saying. you said ’you either make it very optimised or it just doesn’t work’ but i’m sure there are plenty of less than optimally performant games on the system
wicked :3
:3
meow :3
looks amazing
would love to play this
Wizard!
john oestmann! cool guy, sampled one of his songs a while ago
Awesome, would love to hear it :)
pretty sure you have lol, i'll ping you on discord
I'm curious how it would perform in higher resolutions
This is pretty cool!
Poggers.
Are you making a game or is this just a programming exercise? Cool stuff regardless
Whaaaaaaaaaaaaaooooh
the graphics are genuinely gorgeous for an N64
it looks super good, i wonder if it could make a really cool rain effect but i don't know sh**
can someone explain to me like i'm 5 whats the difference with something like libdragon or f3dex3?
is it more like open gl or directx compared to f3ex3 being a driver?
i'm a layman i didnt understand much in the github link to be honest
libdragon is an open source SDK for N64 development - it replaces the original proprietary SDK from nintendo called libUltra with a modern and much improved developer experience. f3dex3, f3dex2 and tiny3d are microcodes that essentially tell the N64 "GPU"(not really a gpu in the modern sense) how to draw stuff. f3dex3 is a custom modern rewrite/improvement of the f3dex2 microcode that was available back then. Tiny3d is a completely new microcode to be used in combination with the libdragon SDK. Libdragon also comes ootb with a OpenGL 1 implementation but native microcode like t3d are faster
Do you think Sega Saturn or Playstation could pull this effect off?
Not a chance.
@@trashtrash2169Its ok to be wrong.
@@sebastiankulche Literally do anything to prove it, maybe? Playstation could barely do 100 particles without dropping frames, but MAYBE it could do it at 1/10 the performance. Saturn is the weakest of the three. Quite literally impossible.
@trashtrash2169 There is literally a tech demo hidden on Toy Story 2 with "almost" PS2 particle effects.
@@sebastiankulche Can you link a video? TH-cam search either sucks, which it does, or that doesn't exist.
Can it go past 65536 particles in particular?
Each draw command can do up to 344 particles at once, but you can ofc do as many as you want of those.
So there is no real limit other than the drop in performance it creates at some point.
@@hailtododongo out of curiosity, why 344? i mean obviously it wasn't an arbitrary limit you added for the hell of it haha, just wondering as to why its the case
@@jumbledfox2098 ucode on the N64 runs on a different processor called the RSP, which has it's own memory.
This only has a whopping 4kb to work with, so i have to balance the particle buffer i can hold at once against other stuff that needs to be there too.
344 just happened to be the number that did fit in the end.
It's only really a limit in the background though, in the public C API you can pass any size you want and it is batched correctly internally
Wow🎉
BRO! There is only 76k pixel at n64 default resolution and you get to 64k particles, just output to frame buffer and skip the RDP at this point. You just demonstrated that a nanite like system might work on n64 😂 maybe with bitwise coverage buffer. I heard you do batch of 344 particles, nanite use only 256 primitives per batches. If we do quad subdivision it would be simpler than the unordered polygon soup of nanite, maybe ROAM like algorithm ❤
The grass makes overdraw jump up lke crazy and fill rate fire up I would expect, am I right? Id there some culling that check per "square" or is all per pixel (z-test all the time). What resolution is this as well? The typical 240p most games use?
yeah it's 320x240, and fill rate is the main issue with performance as always.
This here uses the regular z-buffer, so checks per pixel. You could disable that though if you can guarantee a fixed order.
I did try to implement some sorting on a particle level in the ucode before, but there is no efficient way to do it so it was extremely slow even with low particle counts. In the end i scrapped it.
@@hailtododongo I was expecting it to be that way, in that case, if these checks are done on the GPU (Idk if RSP RDP) that means the N64 GPU is very capable. I had one more question, but it was solved reading at the description, This is 2D and that's why is so cheap, as it look from above, and this is done on the RSP saving some matrix math, so pretty much fill rate limited.
Is the first example with the knight anywhere in the repository?
The first bit of footage is from my entry for the still ongoing gamejam.
Will end in 2 Weeks and then that project (incl. all from other people) will be open-source.
The rest of the demos are available in the t3d repo already.
@@hailtododongo Omg, very exciting
This reminds me of micro maniacs for ps1