Developing a Retro-Roguelike Game for Multiple Platforms in C(retrogamecoders.com)
retrogamecoders.com
Developing a Retro-Roguelike Game for Multiple Platforms in C
https://retrogamecoders.com/roguelike-multiplatform/
18 comments
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
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.
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.
> 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
[0] https://github.com/SuperIlu/DOjS
You write 16kb demos daily in JS/TS right?
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?
Lovely. However the poster of the original article would have trouble getting it to even parse on a C64?
[deleted]
Maybe to target retro computers and systems?
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.