And don't miss Fabian Sanglard's review of the code. He was featured on HN recently for the reviews of the engine behind Another World/Out of this World and how it was ported to different platforms.

http://fabiensanglard.net/second_reality/index.php

I have not seen this at all, thank you for sharing!

I'll have to check out some of the old issues, I thought it was more of an industry magazine and not covering algorithms or coding.

Archive.org has most (all?) issues in a collection: https://archive.org/details/game_developer_magazine

gopher://

I don't think that's been the case for a long, long time. Almost every new game on modern consoles and PCs will see one (or many) updates in its lifetime. Game cartridges, things we used to think of as immutable, are merely storage devices for delivery of the original game code. Two recent games I purchased for the Nintendo Switch, on cartridge, both required a download before I could play them.

It's more blurry but Games are still DONE in a way that an ongoing project where new features are constantly being added aren't. There are some exceptions like Minecraft but on average most games can not economically justify multiple full time engineers working on them for over a decade.

There is also the side issue of game engines which many teams reuse from game to game so maybe that doesn't really apply.

It does now. But will that be the case in the future? History seems to indicate that the interfaces and paradigms will continue to change. There will be an awkward period (now?) where you need to know both types of interfaces, but there may be a period where touch, voice, or other interfaces replace the now-archaic file cabinet metaphor that the desktop uses today. Look at Windows and all the metaphors that a child today has no context with which to relate: a manila folder, a file cabinet, a floppy disk, an address book, a wall calendar. It seems likely that this will change, and with it the need to understand today's (and that of the last 20-30 years) desktop computer.

FPGA still has some advantages over ASIC development:

- development speed of FPGA over the typical ASIC lifecycle is much shorter

- the ability to field-program and correct a design flaw can not only save expensive iterations, but also to add new hardware features essentially as a "firmware" upgrade (provided the FPGA in the system has extra capacity)

There will always be a place for ASIC, but FPGAs provide some capabilities that are not available (impossible?) for ASIC.

My first thought: I wonder if I can invoke this with ctypes from Python? I'll check this out, thanks!

My plan of action is result-driven: incrementally port nuklear's demo overview.c file to python. Each new piece of that requires adding more ctypes bindings.

Help/patches are welcome, as I only have limited free time to implement this.

They've also lowered the price significantly since then. Entry-level units can be had for $199, much less than the $399/$499 launch prices of the PS4 and Xbox One, respectively.

That's a good point, didn't think about that.

My nephew has been making Transformers out of his LEGO sets for a few months now. I asked him how many hinges he had (thinking he must have a lot). He said "I dunno... 2?"

I went to the LEGO store and raided their pick a brick wall. He'll be getting lots pieces that are hinged, wings for transforming planes, and tons of small plates for decoration. I think he's going to like it.

LEGO has increasingly made a number of pieces with Studs Not On Top (or SNOT, as the adult LEGO community refers to them). These allow you to attach standard bricks in a number of different directions and angles.