I'm tinkering with a PlayStation homebrew (voxel space renderer) and development for fifth generation consoles has never been easier.
Modern toolchains, programming languages, dev cartridges and libraries from the community makes all the difference. Outside of some niceties like ICE (gotta write that GDB stub for target hardware at some point), it's not that different from what you'd experience with modern embedded work.
I am still amazed my own minimalist PS1 tutorial series [1] became as popular as it did, given that prior to it basically all learning material on the internet was written around the decent-for-the-time-but-horrible-now Sony SDK and often based on 30-year-old example code full of 30-year-old C practices (in particular the complete disregard for aliasing and concurrency, which resulted in plenty of headaches once people started using those ancient libraries and example code with modern GCC). We even have bleeding-edge C++ SDK options [2] complete with an STL and coroutine support, so if anybody here wants to try their hand at PS1 homebrew development I would highly encourage checking out the modern tooling we have now.
To put this into perspective for youngsters, that horrible Sony SDK was considered a wonder for its time, and what kickstarted the movement away from Assembly into C for home console development, as main language.
Until then, only arcades had already made the switch.
On PS2, PS2Linux, Dreamcast there was already C++ support, by the way.
I’ve started to adapt my historic accounting of gaming away from hardware centric (console generations) and toward languages and compilers, and the force-multiplication they provided to developers which is tangibly evident in the products. Though these do correlate strongly with orders of magnitude of RAM being made available.
- Physical logic gate era of gaming.
- Assembly era
- C era
- OOP era
- Interpreted languages and game logic living in scripts on top of c++ engines
FWIW, interpreted languages living on top of a native code engine has been a pretty common theme throughout. It goes back to early PC days (when PC meant IBM, Apple II, etc), where it was common that engine would be written in ASM, but it would implement a VM with all of the game business logic would exist to ease porting to very differnt systems. Almost all the early LucasArts games were written this way (hence ScummVM), Another World, the Sierra Games, etc.
boricj · · focus · HN ↗
Modern toolchains, programming languages, dev cartridges and libraries from the community makes all the difference. Outside of some niceties like ICE (gotta write that GDB stub for target hardware at some point), it's not that different from what you'd experience with modern embedded work.
spicyjpeg · · focus · HN ↗
[1] <a href="https://github.com/spicyjpeg/ps1-bare-metal" rel="nofollow">https://github.com/spicyjpeg/ps1-bare-metal
[2] <a href="https://github.com/grumpycoders/pcsx-redux/tree/main/src/mips/psyqo" rel="nofollow">https://github.com/grumpycoders/pcsx-redux/tree/main/src/mip...
pjmlp · · focus · HN ↗
Until then, only arcades had already made the switch.
On PS2, PS2Linux, Dreamcast there was already C++ support, by the way.
kridsdale1 · · focus · HN ↗
- Physical logic gate era of gaming.
- Assembly era
- C era
- OOP era
- Interpreted languages and game logic living in scripts on top of c++ engines
- Fully Gen-AI era?
monocasa · · focus · HN ↗
rightbyte · · focus · HN ↗