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.
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.
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.
> 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.
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.
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.
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
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.
DOjS [0] and friends often have memory requirements that outstrip what these platforms even can have.
[0] https://github.com/SuperIlu/DOjS
These are machines where having 64 KB was already great, many had 16 or 8 KB!
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]