next »

[gimymblert]

YES!

[deadcast]

YES!

Good to hear from you again and yes I'm excited to be back!

[Octopus Tophat]

BUDDDY! 
Welcome back! Glad to see you're still doin stuff!

[deadcast]

BUDDDY! 
Welcome back! Glad to see you're still doin stuff!

Thanks for the welcome! I'm glad to be back and working on my favorite console!

[Ishi]

Fantastic

[deadcast]

Fantastic

Hello again! Also your game is looking really nice. I like the fluid animations of the main character. Seems like she has good speed.

[deadcast]

Small update and I'm probably too tired to be writing this lol.

I'm still working on getting the UV mapping right since the n64 wants UV data sent a little differently than what I'm used to. Most rendering systems like UV info per face but the n64, well the RSP, wants UV info per vertex. Kind of annoying because of how my data format is laid out but I can "post process" the vertex data arrays to get the info I need in the right order. Since I'll have to send more vertices down the pipeline I'll have to split things up in 32 vertex batches or use a microcode that allows for larger polygon buffers. I just need to make all of my models VERY low poly lol. Oh well I'll get things sorted eventually!

Here's what the little cannon I modeled looks like right now on the n64.





gn

[gimymblert]

http://Most rendering systems like UV info per face but the n64, well the RSP, wants UV info per vertex.

I'm surprise by that, I only know UV stored per vertex, which mean splitting vertex, even in modern engine, though 3d software handle this for you.

[deadcast]

http://Most rendering systems like UV info per face but the n64, well the RSP, wants UV info per vertex.

I'm surprise by that, I only know UV stored per vertex, which mean splitting vertex, even in modern engine, though 3d software handle this for you.

Haha I'm probably wrong about saying that. I made that statement with my limited knowledge of rendering systems and I shouldn't have. I guess I thought that since I recall doing it in OpenGL and maybe Direct3D (hard to remember) I assumed most systems wanted UVs per face. Seems like it just depends on the system and how it's designed. So ignore my statement lol.

I'll probably end up changing my Blender model exporter to add the UV's for each vertex even though it'll add some more data. That might not ever be an issue though.

[gimymblert]

I'm just surprise by your statement I didn't mean you are wrong, lol I just never seen that, I don't have that much experience either, except unity and blitz, lol and general advice on modeling board ...

[oahda]

cannon I modeled

Huh, I thought for sure that was the one from SM64, haha. p:

[deadcast]

I'm just surprise by your statement I didn't mean you are wrong, lol I just never seen that, I don't have that much experience either, except unity and blitz, lol and general advice on modeling board ...

Haha no worries! Yeah my limited knowledge extends into Unity and I've never used blitz. I remember checking it out a long time ago and thought it looked cool. Not sure why I never played with it.

[deadcast]

cannon I modeled

Huh, I thought for sure that was the one from SM64, haha. p:

Lol cool! I posted my models on github and the link to the cannon is here https://github.com/deadcast/3d-models/tree/master/cannon. I made it in Blender. I like just re-creating props from Mario 64 lol.

[deadcast]

Hello again!

Thought I'd share some progress that I'm really excited about! I managed to get the UV issue sorted so now the texture mapping looks much better on the models. I figured out a way to "post-process" the model once it was loaded into memory from the ROM to set the UV information correctly. While doing that I also implemented vertex buffer load batching.



Since the current microcode I'm using only supports loading up to 32 vertices at a time to draw with I had to figure out a way for my model rendering code to automatically break up the vertices if over 32 and send the data in separate chunks to the Reality Display Processor. I also had to do some polygon index remapping to construct the correct faces but that wasn't too difficult. I definitely need to do some maintenance to the code because there are some easy refactorings in there to make things simpler. The above table shows the available microcodes and their vertex limits. I could've just used a larger microcode program but I wanted my models to just get divided and processed correctly.



That example image shows the typical way vertices are loaded and then you connect them together to form the triangles.

I also learned something pretty neat a few days ago while trying to get PNG support working. The open source library I'm using returns a byte buffer to a 24 bits per pixel image but the Nintendo wants the format to be 16 bits per pixel. So via experimenting with bit shifting I was able to take a RGB888 24bpp image which is 8 bits for red, 8 bits for green, 8 bits for blue and convert it to RGB5551. 5 bits for red, 5 bits for green, 5 bits for blue and 1 bit for the alpha channel. I'm losing some color info in this process but I haven't really noticed the difference.



That's the macro I'm using to convert the color data to 16bpp. If you're not used to shifting bits that code snippet may look a bit weird lol. Remove some bits and then pack it all nicely into a short or 2 byte value.

That's my update for now and I leave with some videos. Thanks for reading!




A cool multicolor N a friend sent me to test with.





https://www.youtube.com/watch?v=kPyJqQOXl1Y

[deadcast]

Also this is what happens when you try to load too many vertices lol.

[deadcast]

Yo!

Decided to refactor my model loading code tonight so it would be easier to render multiple models in a scene. I made some good progress and can now easily load N models and they each have their own transform (position/rotation/scale). I need to work eventually on a camera space coordinate system so I can move around the world.





I'm just taking small pieces at a time and I think next I want to play with controller input and maybe play some audio. My goal before GDC is to make a little tech demo. Lol I'll see how far I get!

That's it for now. Cheers!

[deadcast]

Hello





I decided to see if I could get audio working on the N64 and after a few hours figured it out! In the video I added a cool song from @online_frog and a cool slappy hand!

Getting the audio process down was a little confusing since there are multiple tools you have to use to prepare the audio data. You first have to convert your sound effect to AIFF with only a single channel. From there you have to compute a coefficient table used later in the chain to efficiently compress the audio with the highest quality. You then need to use the computed table to compress the AIFF to an ADPCM compressed format. Next you need to create a sequence bank and assign the sound to an instrument and then finally you can compile the sound to its final form. Loading it into the system is pretty simple via the Nu System audio API.

Also I figured out how to create a world-space matrix to have more flexibility with object transform manipulation. Had to get my head around the matrix load, multiply, push and pop operations. The Nintendo docs definitely have been coming in real handy!

Later!

[gimymblert]

I wonder how many polygon you can have with a fixed axis align camera, lower precision, and axis swap rotation (for example turning x into y or -x or -y, basically like old school sprite 90° rotation), as it remove all the mul (I knew a programmer who ported a version of crash bandicoot on gba using that and it was cancel because it was too close to teh ps version lol)

[deadcast]

I wonder how many polygon you can have with a fixed axis align camera, lower precision, and axis swap rotation (for example turning x into y or -x or -y, basically like old school sprite 90° rotation), as it remove all the mul (I knew a programmer who ported a version of crash bandicoot on gba using that and it was cancel because it was too close to teh ps version lol)

Yeah you probably could push a TON more objects to screen but using those old billboarding tricks! Kinda like Chuckya in SM64 and the various other enemies.



I want to eventually implement that trick and create a 2D tree and make it always face the camera. Lol also just like SM64. Discovering that technique was really smart to overcome the drawing limitations.



I'm not quite sure yet what the max poly rendering capacity is. I think I have some performance tools available to me via the Nu System that can output some sort of stats.

[gimymblert]

BTW those camera facing quads also have some depth data, you can clip partially in the tree leaves, I have no idea how it's made internally lol