6 ms·
Is it necessary to build a game like this in C? Could one build a game with comparable computational and graphical requirements in Python or something?
by ss108 4y ago
Is it necessary to build a game like this in C? Could one build a game with comparable computational and graphical requirements in Python or something?
- turing_complete 4y agoOne could. However, many people in game programming care about their craft and having as much control as possible and also being efficient with their resources. In this project specifically, there might be also some kind of nostalgia thing going on. By the way, even though I use Python daily for ML and some web stuff, I find Python very lacking for serious, complex projects because of the dynamic type system, bad performance, and the infamous GIL. I find the idea that programming something in a system-level language is some kind of lost, arcane craft that shouldn't even be attempted quite perplexing.
- ss108 4y ago> By the way, even though I use Python daily for ML and some web stuff, I find Python very lacking for serious, complex projects because of the dynamic type system, bad performance, and the infamous GIL. I don't disagree re: the downsides of Python specifically, just threw it out as an example. > I find the idea that programming something in a system-level language is some kind of lost, arcane craft that shouldn't even be attempted quite perplexing. Well, some of us are self-taught developers and so system-level languages are very unapproachable. Ultimately though, seems like a simply unnecessary headache even if one would be competent in using those languages. Friends of mine with CS degrees still don't opt to do side and hobbyist projects in those languages, for example.
- billfruit 4y agoC has an extremely sloppy type system as well, where basically pointers to objects of differing types are arbitrarily interchangeable.
- blix 4y agoRather than calling it sloppy, I would instead say types barely exist at all in C. A type in C is really just a transient label reminding you and the compiler how to interepret some block of 1's and 0's, which is the only true type. The Python type system really has quite a lot of overhead compared to this :P
- oreally 4y agoAnd as disgusted as you might be that is also part of it's strengths - allowing various optimizations and not having to focus too much on typing.
- bombcar 4y agoThis (original) game came out in 1998. You could write an emulator for x86 in Python that'd be fast enough to run the original operating system and game on modern equipment. Whether that would be the best choice for implementing a game like this today - probably not.
- ahefner 4y agoSeems unlikely. The performance ratio of native code vs. Python is hundreds of times. The original game targeted roughly 100 MHz CPUs. Computers have gotten faster since 1998, but not that much faster in terms of single-threaded performance, the relevant metric here. I'd guess a python x86 emulator would run at 1/5 to 1/10 the required speed.
- WoodenChair 4y agoUnfortunately, that's just not true. At least not in pure Python without using Cython, C-extensions, graphical libraries implemented in C, or the like. In pure Python, you can't even write an NES emulator that operates at full-speed. Look it up. Every NES emulator ever written in Python uses C libraries or some kind of C extension like construct to achieve 60 FPS.
- bvschaik 4y agoCreator of Julius here. Not specifically C, but you do want to have a language that's as close to the hardware as possible. Since Julius supports way higher resolutions than the original, the time required to draw the screen also increases: full-HD resolution requires 6.75 times more pixels to be drawn than 640x480. I've had to make optimizations to the drawing code to get a decent framerate on higher resolutions.