next »

[deadcast]

I have no idea how you're doing any of this, but I love everything about it

Haha thanks! I'm not too sure how I know I'm doing this either yet.   I've been doing little bits of research over the years on engines and now it's finally time to try and make something. Not sure if the n64 is such a good place to start. lol

Well you need to test overlapping and intersecting triangles first

Yea that's eventually on the feature list. Calculating the z buffer coefficients doesn't look TOO bad but the n64 does things pretty weird.

Well I have nothing new and cool to show yet. Right now I've been working on more of the engine aspects instead of implementing new  hardware operations. Tonight I got a little bit of the matrix stuff done.



Need some more things like setting up rotations and perspective calculations for all of the coordinate space transformations: object -> world -> camera -> projection. Boring work kind of but it's cool to be learning about how 3d points get projected on to a 2d screen space. Matrix multiplication is really interesting how it can combine multiple operations(scaling, rotation, translation) into one operation. Pretty efficient!

Later

[deadcast]

Hello once again.

Well I have a bit of sad news. I'm going to be starting over again. ;-; I feel like the direction I was taking the project was wrong. After learning more about the architecture of the n64 I realized that it's a must that all of the processors be utilized correctly. So no just skipping the Reality Co-Processor and writing straight to the framebuffer or sending direct commands to the Reality Display Processor. A correct approach would be to write new RSP microcode to do all of the rendering setup. This will in the end free up resources on the CPU and allow for MUCH MUCH faster 3d operations since the RSP has an SIMD(single instruction multiple data) architecture. This means having to write some data processing code in assembly which sucks but no way around that. I did find a good community of n64 devs on irc channel #n64dev that are willing to help and have been working on some really cool projects.

So my plan for now is to keep studying any available nintendo documentation and making lots of mistakes. I'm actually going to start using the n64tool chain by marathonman for development since it is more modern and utilizes the VR4300 cpu to supposedly its full potential. Also the creator of that lib also created cen64. A cycle accurate emu that wants to deeply support the RSP to its fullest. So I'm going to begin working on trying to write a mini microcode program and then attempt to correctly load it onto the RSP(IMEM/DMEM). I think once I get that working I'll be on my way to getting the RDP rendering things again and eventually maybe on to making a game! :D

Thanks everyone for the interest so far. I won't have anything pretty to show for a while.

[gimymblert]

That was expected, the n64 is unconventional, it will take time anyway, never give up!

Rendering textured triangles correctly should be your project right now, not thinking about game, it's the base, "the black triangle"

[Octopus Tophat]

That's a little sad, but it'll make it much better in the long run. Please don't give up!

[oahda]

Now you need to get this N64 song working on it!





Also, are there really no libraries? Surely not every N64 dev back in the day could've been reïnventing this wheel (or even had the skills to do so)? Maybe there are, but not publicly available, I guess...

[Conker]

This is such an amazing project

[deadcast]

That was expected, the n64 is unconventional, it will take time anyway, never give up!

Rendering textured triangles correctly should be your project right now, not thinking about game, it's the base, "the black triangle"

lol yeah it sure is unconventional. the more i work on this project it just makes me wanna go back to unity. haha the black triangle is the goal. i will one day draw one that has textures and maybe even shading! it will be beautiful.

That's a little sad, but it'll make it much better in the long run. Please don't give up!

;-; i know but you're definitely right. it will make things better in the end. ill have the ability to utilize more of the power of the system and hopefully render some more polys to the screen.

Now you need to get this N64 song working on it!





Also, are there really no libraries? Surely not every N64 dev back in the day could've been reïnventing this wheel (or even had the skills to do so)? Maybe there are, but not publicly available, I guess...

lmao that song! i havent heard it in years. played that game sooo much. that will most definitely be my test song whenever i venture into the audio interface world of the n64.

well yeah there are official nintendo libraries(like opengl'ish) "floating around" that could help you get up to speed but I'd rather help develop something that doesn't mess with any proprietary code. pretty much all devs back in the day had to roll their own. from my understanding companies had to write their own OS for the system and 3d engine. also the architecture of the system was designed to be very flexible for devs. nintendo designed each processor of the system to have access to all the sam RDRAM. this allowed devs to split up the memory in any way they chose. the programmers at Rare, Factor 5 and Angel Studios did some INCREDIBLE engineering on the hardware. They all pushed the system to the limits and even made the ps1 games look bad at times.

This is such an amazing project

haha thanks so much. glad you're liking it so far. i really plan to help contribute to the main dev scene for the n64 and allow others to have better tools for making new content for the system.



Btw, just bought a SUPER cheap linux computer that im going to start doing all of my n64 dev on. just bought this model for 90$ mint condition on ebay. this little system should be perfect since I'm going to just be living in a terminal window and writing c/asm. nice and portable too!

[Octopus Tophat]

LUL is that an EEE pc? Awesome! I had one of those as a kid. Except I put windows on it. Ran like shit.

[deadcast]

LUL is that an EEE pc? Awesome! I had one of those as a kid. Except I put windows on it. Ran like shit.

lol yeah. it's an Eee NetBook PC 701. Just found out about these computers. Good reviews on it and I'm happy that they run linux out of the box. Kinda old now but I'll be rocking an almost 2GB memory machine.

Haha i totally imagine that installing windows on this thing would be horrible.

[gimymblert]

You could also have an odoid series, the c1 start at 34$ and has the power of a netbook

[Pizzamakesgames]

I hope in a couple decades you'll be professor at game college, holding lectures on n64 programming so I can make my kids attend them. Jokes aside though, this is pretty damn cool and if you ever get somewhere majestic or feel like condesing all your accumulated n64 programming knowledge into a book, it'd be awesome. It's already awesome though.

[gimymblert]

yes! a book!

[Sik]

Well I have a bit of sad news. I'm going to be starting over again. ;-; I feel like the direction I was taking the project was wrong.

So, like what happened with Echo, where I had nearly the entire engine done and had to ditch it and restart from scratch because the original design made it unable to output PCM without timing issues? (but on the other hand, that first iteration taught me enough to make the second one not have any serious issues, and yes, the second iteration has better PCM timing than most existing engines )

[Conker]

I did that with my game too, but it took a year to realize I had to start over.
Its a tough decision but I think its a really important skill to know when to keep pushing towards completion on a certain version, and when its time to scrap and restart it.

[Sik]

Well, it's usually easier with engines since they're technically smaller, reusable (i.e. the change will affect everything already using them) and you can keep around the old code while you're busy making the new one. Yes, you're throwing away a lot of work (sorta, since you keep the knowledge of the biggest pitfalls), but it's not a complete stop like it is with a game.

Also I don't think that this engine still saw some heavy use yet, so it's probably easier to scrap than it was with Echo. I just wonder how the custom microcode will be since as far as I know that part isn't that well documented yet, at least how it behaves on real hardware (I could be wrong though!). I mean, chances are there's probably some opcode that behaves different than expected because the situation hadn't come up in licensed games =P (I know this happened with the division instructions in the 68000, where nearly nothing relies on the value of one of the flags on overflow)

[deadcast]

You could also have an odoid series, the c1 start at 34$ and has the power of a netbook

Dang those look sick! I might actually get one of those. I restored a Dragons Lair arcade a few years ago and it really needs a new computer. This thing could probably run the Daphne emu perfect. : )

I hope in a couple decades you'll be professor at game college, holding lectures on n64 programming so I can make my kids attend them. Jokes aside though, this is pretty damn cool and if you ever get somewhere majestic or feel like condesing all your accumulated n64 programming knowledge into a book, it'd be awesome. It's already awesome though.

lol that's great. I don't know if I could ever teach and I don't know of a uni that would be eager to offer an n64 class.:p Yeah I think that's a great idea about compiling what I learn into some sort of book. I already have collected a lot of different random bits of info on the system. Maybe once I have everything in my head I could write some high level stuff about the system and of course how to develop for it. Have to keep thinking about that but first I actually gotta get something working on it.

I did that with my game too, but it took a year to realize I had to start over.
Its a tough decision but I think its a really important skill to know when to keep pushing towards completion on a certain version, and when its time to scrap and restart it.

Ugh yeah. That really sucks when you're really deep into something and realize that you may need to scrap it. Always WAY nicer to find out early than way too late. That kinda happened a few times to before and it's kinda sickening but luckily this project didn't get very far before I realized these things!

Well, it's usually easier with engines since they're technically smaller, reusable (i.e. the change will affect everything already using them) and you can keep around the old code while you're busy making the new one. Yes, you're throwing away a lot of work (sorta, since you keep the knowledge of the biggest pitfalls), but it's not a complete stop like it is with a game.

Also I don't think that this engine still saw some heavy use yet, so it's probably easier to scrap than it was with Echo. I just wonder how the custom microcode will be since as far as I know that part isn't that well documented yet, at least how it behaves on real hardware (I could be wrong though!). I mean, chances are there's probably some opcode that behaves different than expected because the situation hadn't come up in licensed games =P (I know this happened with the division instructions in the 68000, where nearly nothing relies on the value of one of the flags on overflow)

Wow that sounds terrible. Being nearly complete and then learning audio didn't work! How big was the code base at the time? Hopefully not like 200,000 lines. :p I'll definitely take a look at what you wrote. I think engine creation is exciting.

Yeah my engine had no use and didn't do anything anyway. So it was much easier to scrap than yours. Yeah my knowledge of the opcodes isn't very vast yet but I have collected some good write ups on it from random devs. Describing most of the important opcodes and I even found an assembly tutorial from patater on how to load up a basic microcode app. And on top of that someone named Krom is doing some really exciting work in bare assembly for the n64. I've been learning from just reading his code. Hopefully the opcodes I use will run as expected but at least I have the ability to test on real hardware.

[karlozalb]

I'm amazed man, this is totally crazy xD. Following for sure

[Sik]

Wow that sounds terrible. Being nearly complete and then learning audio didn't work! How big was the code base at the time? Hopefully not like 200,000 lines. :p I'll definitely take a look at what you wrote. I think engine creation is exciting.

I don't think even my biggest projects have even half that many lines XD (I think the largest I got is in the 30K-something range, comments and blank lines included?)

And eh, be warned that engine is a horrible mess due to being coded in a rush (remember, I had literally rewritten the whole thing from scratch and I wanted to replace the broken engine as quickly as possible). Well, mess mostly in that it needs a lot more of comments >_>; Whoops.

Yeah my knowledge of the opcodes isn't very vast yet but I have collected some good write ups on it from random devs. Describing most of the important opcodes and I even found an assembly tutorial from patater on how to load up a basic microcode app. And on top of that someone named Krom is doing some really exciting work in bare assembly for the n64. I've been learning from just reading his code. Hopefully the opcodes I use will run as expected but at least I have the ability to test on real hardware.

Something tells me you'll end up providing way more information than reverse engineering has done so far =P

Just a question... what were you doing before? I mean using the RDP without setting it up. I don't think it can run without microcode? Were you just using whatever was there before? (also IIRC real hardware has some firmware, since it can't run code directly from cartridge, but no idea if it does any initialization beyond copying boot code to RAM)

[Jondog]

Posting to follow, will be interesting to see how this progresses.

[Mark Mayers]

I wanted to say it's awesome you're doing this.

I might jump into experimenting with N64 dev in the future during a weekend or game jam to take a short break from my game.

I worked as a C developer professionally for a few years; so hopefully the ramp-up would be slightly less terrifying, ha.

Also, have you RTFM?