Can anyone recommend any particular enjoyable home brew games? I can see a few already listed in comments, but it would be nice to gather up a short list.
My top score in 2min is 500,000+.
111–120 of 138 posts
Can anyone recommend any particular enjoyable home brew games? I can see a few already listed in comments, but it would be nice to gather up a short list.
My top score in 2min is 500,000+.
Can anyone recommend any particular enjoyable home brew games? I can see a few already listed in comments, but it would be nice to gather up a short list.
Blade Buster, fast paced modern time attack shmup; very pretty, don’t forget to hit select to increase speed. My top score in 2min is 500,000+.
Having recently discovered OpenEmu, I'm trying to track down good homebrew/freeware games.
Earlier quoted context omitted.
Not necessarily, there are hundreds of embedded devices that can be programmed just like in the old days. Arduino, ESP286, ESP32, . And since we are in the context of games and Nintendo, something like Arduboy. https://arduboy.com
Even worse than that, people still use legacy devices like 8051 MCUs in modern products. I'm currently working on an assembly codebase for a SiLabs part. Like... Please move to an ARM MCU with a C codebase.
Using c does come at the cost of some code compactness, but you can selectively optimize as the need arises.
Earlier quoted context omitted.
Not necessarily, there are hundreds of embedded devices that can be programmed just like in the old days. Arduino, ESP286, ESP32, . And since we are in the context of games and Nintendo, something like Arduboy. https://arduboy.com
> Arduino, ESP286, ESP32, . Both the Arduino libs and Espressif SDK are fairly big chunks of code. Yes, you can program AVRs without libs too, but you did specifically say Arduino. It is also my understanding that ESPs are both bit obscure and fairly complex beasts to be managed without SDK. While there are still some nice cases of simplicity in the embedded world, the complexity and layers of libraries and framework…
http://fingswotidun.com/avr/AvrAsm/Testbed/
It's pretty much a project to scratch the itch being described in this thread. It gives you an in-broswer 8-bit AVR based fantasy console and Assembler.
Earlier quoted context omitted.
Have you done http://nand2tetris.org ? It involves (virtually) building up a CPU that has two registers, which I'm guessing the minimum possible.
You'll need some internal state (one register?) and a program counter. If instructions are long enough, you can encode the address of the next instruction in the instruction itself (sort of a perverse VLIW where everything ends with a jump to a given address) and ditch the program counter. You can make tests destructive, so your status bits end up overwriting the register - it would force some "interesting" programmi…
Earlier quoted context omitted.
They couldn't bother to cite the image apparently but it's from a web comic called Gunshow
Those two panels are well-known as a meme image, over probably the past 4 years. Memes tend to transcend their original source; that's probably why the image wasn't properly cited.
That said, when K C Green ran a Kickstarter for a plush This Is Fine dog it took in more than ten times what he was asking for; how much of that went into his bank account as profit, I dunno.
I recently started work on an NES project, and wrote the first part of it up: https://www.moria.us/blog/2018/03/nes-development It's a lot of work. I've managed to get data from Tiled into my ROM image, and I'm working on figuring out an architecture for scrolling and displaying a status bar. Implementing scrolling and a status bar sounds simple but is actually a total pain. You only have two screens of tiles to work…
I liked this video explanation of NES scrolling ("The Nintendo Entertainment System's Loading Seam" by Retro Game Mechanics Explained) https://www.youtube.com/watch?v=wfrNnwJrujw
Earlier quoted context omitted.
I remember the 16-bit " real mode " assembly of Intel's 286 CPU very well. > focus on the problem Think harder, you might remember that you weren't solving many problems either.
> I remember the 16-bit "real mode" assembly of Intel's 286 CPU very well. Those CPUs already started being complicated enough to make ASM programming less attractive. IIRC, on 286 the string copy instructions were faster than the DMA transfers people used on earlier PCs and, because of that, if you wanted to have optimal performance, you'd need to check which CPU it was running and branch accordingly to the best cod…
The Intel C Compiler still does that. It compiles multiple versions of your code, each optimized for different processor versions.
Earlier quoted context omitted.
I remember the 16-bit " real mode " assembly of Intel's 286 CPU very well. > focus on the problem Think harder, you might remember that you weren't solving many problems either.
> I remember the 16-bit "real mode" assembly of Intel's 286 CPU very well. Those CPUs already started being complicated enough to make ASM programming less attractive. IIRC, on 286 the string copy instructions were faster than the DMA transfers people used on earlier PCs and, because of that, if you wanted to have optimal performance, you'd need to check which CPU it was running and branch accordingly to the best cod…