Introduction to Nintendo 64 Programming (1999)
n64.icequake.net
n64.icequake.net
Did that ever happen?
A fantastic and critical read to anyone interested in this sort of thing: https://www.gamasutra.com/view/feature/131556/postmortem_ang...
Just tell the client how long it will take! Of course! This makes me a bit suspicious about the relevance of the rest of the author's advice, given that I certainly don't have access to whatever eldritch magics he channeled in 1999 to gain these powers.
Huge games!
Mario 64 was impressive for its time, but the worlds are pretty darn small by modern standards.
The game also uses multiple mission objectives (and a requirement that you return to the start of the map after each mission) to pad out the length.
I've been playing through the first two Thief games, released 20 years ago, and I put 60 hours into beating the first and am already 30 hours into the second.
Gotta say I'm extremely impressed given most games I've played in the last few years are on the order of a few hours' playtime.
She was amazed by how many things are packed into this game and how each room or character feels way more unique than the last assassin creed game.
I would not say that all modern games suffer from this but I have come to deeply appreciate games that did the best with the limitation imposed by them by their tech.
In addition to N64 games, I have always been impressed by how Grim Fandango took a low poly graphical engine and turned it into an amazing art style.
Especially when I compare it to so many AAA games with huge budgets and a brown "photorealist" approach as interesting as a wet carrot and that look extremely dated 3 years later.
Sorry, is this a typo or is there a specific niche of "people who are girlfriends" (?) reviewing games?
In older Assassins Creed games you could tell loving thought went into how you would traverse things, climbing things took a lot more skill and there were secrets to find.
The newer ones the other hand have just tons of bland, and climbing is basically automatic, just push forward. It’s kind of sad to see one of my favorite series become so dull.
I could play it for free during the stadia demo. If I had played for more than one hour, I would have been able to keep the game. The tech itself is amazing, but after skipping 2 or 3 asscreeds games, I was very surprised to see health bars.
The series always had a bad tendency to pad its length by relying to the endowed progress effect with lots of copy paste content like "collect the 100 feathers".
The health bars and levels already made the first fights boring, not to mention that I don't think they have anything to do in a stealth action game. They just sound like another way to pad the game length.
If the platforming also got worse ? damn, I don't regret letting this franchise go.
What does this even mean? Each of those does pretty much “has one job”; does malloc give you memory and free only reclaim half of it or something?
> Even though a typical C program can rely on the system to handle initializations
Uh, not if this is an automatic variable…
You could drop in your own allocate/free for everything in-game and ignore their implementation (you had pretty much complete control over what went where in the memory so long as things to be copied to the RSP/RDP were aligned correctly and the display buffers were on some specific boundary).
Allocating from pools per system was very common (eg particle effects got a 16kb memory pool for vertices and the code had to gracefully handle hitting that limit). Another common practice was to store a high-water marker at the start of a level load and just roll back to that marker when you changed level.
(In case anyone is wondering: I can't think of a single commonly-used standard C library that doesn't accept null pointers to free(), i.e. the nullcheck is in the free() itself. Embedded systems, however, may vary widely in how closely they follow the standard.)
I always was in awe of the low level stuff though, so I took every opportunity to move closer and closer to the hardware over the years. I'm now a firmware developer!
Point being, where there's a will there's a way. If you can align some DIVs, you can malloc() some memory and pack bytes efficiently in a struct :) It all comes down to where your interest is.
It has allowed me to work on some very cool robotics, and IoT projects. I've been able to learn a ton in the process about how computers work. Things like having to learn about how our FreeRTOS scheduler works, have been a fun process and provide some insight (albeit not 1:1) on how larger scale OS's work.
I feel like it's also made me a better programmer on the higher level stuff too. Hard to explain why though. It's not the kind of thing that makes obvious sense. It's not like knowing how to efficiently pack bytes into a struct, somehow helps you be a better Scala or iOS developer. That's just not the case. Rather, there's something about knowing the low-level stuff that just eases my mind when it comes to writing higher level code. I've always been the type of person that gets distracted by needing to know the deeper layer of how something works.
Even in undergraduate classes like biology, I needed to know HOW that mitochondria ACTUALLY handles metabolism. That's what I mean when I say that the lower level stuff "eases my mind". I can call a higher level function, or use some higher level framework, with a clear understanding of how it could (and probably) is implemented. That makes me a better developer, because I can stop asking questions and start making things.
But having worked in many languages (Java, Swift, Scala, Dart, etc.) I have to say, I love C.
I think I remember reading that game programmers developing for new (or not yet released) consoles of bygone eras had to contend with sparse documentation, shifting specs, and inadequate access to real hardware... It would be wonderful if someone with experience or knowledge from this era could elaborate on what it was like getting a black box in the mail and trying to stand up some working code.
I'm imagining lots code written by trial and error under intense time pressure, that nobody on the team really understands and that nobody wants to touch. I'm a sucker for this kind of folklore of ancient programming heroism. :)
https://github.com/monocasa/sides-bsw19
If you want to use some of the same stuff hit me up on GitHub.
Edit: the general thesis was that while we as embedded fairly treat new languages in the embedded space with skepticism, Rust is a legitimate entry. It's not GCed (in the traditional sense) has similar perf and (more importantly) determinism. And by the very nature that the slides are on an N64, it's remarkably possible to support off the beaten path boards.
“The RSP executes both graphics and audio processes. A graphics process sometimes extends over one frame, but an audio process must be provided in each frame to prevent inappropriate pausing. Therefore, in each frame, if the graphics task is executing, the Scheduler suspends it and saves the task state. Then it starts the audio task executing and prepares the RSP for the restart of the graphics task execution when the audio task finishes.”
[1] http://n64.icequake.net/doc/n64intro/kantan/step2/1-7.html
I think the thread here, really means it is a conceptually independent 'processing unit' on its own, which reads the global state of some sort, then make the modification to it. They have multiple such 'threads', each corresponding to some particular task, but with no explicit locks.
Now it makes more sense to me. Threads here are more logical isolation of functionalities, not really parallel execution workers.
I was automatically associating threading with parallelism, but this makes sense for 'concurrency' even if there is only one of them are working at the time.
In win95 there is preemption. The kernel can swap out threads on a timer interrupt to create the illusion despite no actual multiprocessing. You don't need real multicore to have that. But the programming model is the same as if you had it.
Elsewhere on this thread (uhh the other kind) it sounds like the threads here are not preemptible. So cooperative multitasking.
In other words data races will still potentially cause another thread to see a data structure in an intermediate state. It will just be a rare bug instead of a potentially more common one.