Interesting article, and it also shows why in the end, for most games we would mainly use Assembly directly.
What many are not aware is that after graduating from bedroom coders, having not much more than what one could acquire thanks to parents support, or small kids jobs, in proper studios cross-compiling with more powerful Assemblers, or indeed K&R C like languages were an improved developer experience.
This post really resonated with me because it highlights the exact challenges I’ve been facing with portability, memory management, and UI adaptation. To streamline development, I’ve recently started using https://www.code-maestro.com/ , and it’s made a noticeable difference. It doesn’t just assist with generating or optimizing code—it also helps document and explain it, which is incredibly useful when juggling legacy logic or trying to restructure older modules without breaking things. I’ve found the ability to explore my own architecture interactively saves a lot of time during debugging or porting. For anyone juggling a multi-platform project in C, it’s worth exploring tools that genuinely help keep things manageable.
Back in the dim dark ages of the 80s, I persuaded one of the system programmers to print out the source for the curses library, which I the diligently typed in to my CPM/80 machine, I then got the source for rogue, which someone else had done a partial port for, using overlays. It was a bit big for the 48k you could reasonably expect a Z80 CPM machine to have. Mostly worked...
I would think that rather than ifdefs, one could use separate port files. And regarding C89/99, a solution here is to use ANSI C, which is what Lua does.
> regarding C89/99, a solution here is to use ANSI C, which is what Lua does
C89 and C99 are both standards that are endorsed by ANSI. [0] (At least, they were endorsed, as they're now both behind the times.)
The Lua interpreter is written in a subset of C that behaves identically when compiled as C++, they call this 'Clean C'. [1]
I had always heard that C was ill-suited for 6502 targets because of the way the language uses registers and the stack.
The language doesn't really have any opinion on that though?
But I could imagine assumptions about it being a problem if you try to add a 6502 backend to an existing compiler for other platforms.
Sometimes a source language can be an awkward fit for a target architecture. For one thing the 6502 is 8-bit and the C standard guarantees that the int type must be at least 16-bits. More generally, quirks of a hardware architecture can make it difficult for compilers to generate efficient code.
Why not in JS/TS?
Right at the very top of the article:
> Let me tell you the story so far; the process, obstacles, and solutions involved in making a roguelike dungeon crawler playable on systems like the Commodore 64, Commodore PET, and even more constrained machines.
Javascript is not running on a Commodore 64 with decent performance.
These are machines where having 64 KB was already great, many had 16 or 8 KB!
DOjS [0] and friends often have memory requirements that outstrip what these platforms even can have.
Interesting article, and it also shows why in the end, for most games we would mainly use Assembly directly.
What many are not aware is that after graduating from bedroom coders, having not much more than what one could acquire thanks to parents support, or small kids jobs, in proper studios cross-compiling with more powerful Assemblers, or indeed K&R C like languages were an improved developer experience.
This post really resonated with me because it highlights the exact challenges I’ve been facing with portability, memory management, and UI adaptation. To streamline development, I’ve recently started using https://www.code-maestro.com/ , and it’s made a noticeable difference. It doesn’t just assist with generating or optimizing code—it also helps document and explain it, which is incredibly useful when juggling legacy logic or trying to restructure older modules without breaking things. I’ve found the ability to explore my own architecture interactively saves a lot of time during debugging or porting. For anyone juggling a multi-platform project in C, it’s worth exploring tools that genuinely help keep things manageable.
Back in the dim dark ages of the 80s, I persuaded one of the system programmers to print out the source for the curses library, which I the diligently typed in to my CPM/80 machine, I then got the source for rogue, which someone else had done a partial port for, using overlays. It was a bit big for the 48k you could reasonably expect a Z80 CPM machine to have. Mostly worked...
I would think that rather than ifdefs, one could use separate port files. And regarding C89/99, a solution here is to use ANSI C, which is what Lua does.
> regarding C89/99, a solution here is to use ANSI C, which is what Lua does
C89 and C99 are both standards that are endorsed by ANSI. [0] (At least, they were endorsed, as they're now both behind the times.)
The Lua interpreter is written in a subset of C that behaves identically when compiled as C++, they call this 'Clean C'. [1]
[0] https://en.wikipedia.org/wiki/ANSI_C
[1] https://www.lua.org/manual/5.4/manual.html
I had always heard that C was ill-suited for 6502 targets because of the way the language uses registers and the stack.
The language doesn't really have any opinion on that though?
But I could imagine assumptions about it being a problem if you try to add a 6502 backend to an existing compiler for other platforms.
Sometimes a source language can be an awkward fit for a target architecture. For one thing the 6502 is 8-bit and the C standard guarantees that the int type must be at least 16-bits. More generally, quirks of a hardware architecture can make it difficult for compilers to generate efficient code.
Why not in JS/TS?
Right at the very top of the article:
> Let me tell you the story so far; the process, obstacles, and solutions involved in making a roguelike dungeon crawler playable on systems like the Commodore 64, Commodore PET, and even more constrained machines.
Javascript is not running on a Commodore 64 with decent performance.
These are machines where having 64 KB was already great, many had 16 or 8 KB!
DOjS [0] and friends often have memory requirements that outstrip what these platforms even can have.
[0] https://github.com/SuperIlu/DOjS
You write 16kb demos daily in JS/TS right?
https://pastebin.com/aBJ7eWQ1
8K (7K) Roguelike (ignore 800mb browser)
Lovely. However the poster of the original article would have trouble getting it to even parse on a C64?
Maybe to target retro computers and systems?
[dead]