6 ms·

I like these challenges, where people rebuild stuff low level and “line efficient” (not saying this is a good idea in general). This makes me curious and I can

I like these challenges, where people rebuild stuff low level and “line efficient” (not saying this is a good idea in general). This makes me curious and I can learn a lot from these examples. I was a bit disappointed though to see that this code used SDL for sprites and more stuff though. That’s not 1000 lines anymore imo. Still the code was an interesting read. Thank you OP

shric 2y ago
It's impossible to do graphics in pure C, so what are the alternatives? Whatever you do at whatever level of abstraction/portability (SDL, OpenGL, Metal, Vulkan, Unity, ...), you're leveraging zillions of lines of other people's code. The only way arguably you could do it in pure C (with undefined behavior) is in enviroments that let you write straight to graphics framebuffers without any abstraction layer and even when you can't do keyboard or mouse input in C without library and/or kernel support.
- tmountain 2y ago
  I wonder what the smallest assembly implementation would look like to provide the minimal graphics API necessary.
  - flohofwoe 2y ago
    You can't directly access the GPU hardware on modern systems (at least without a massive re-engeneering effort like the Asahi Linux GPU driver for Apple hardware), so any 'minimal graphics API' still goes through a massive amount of wrapper code in the operating system and GPU driver. Also, on older home computer systems the hardware was essentially the rendering- and audio-engine. Those systems were designed from the ground up to be convenient to program by directly writing hardware registers from assembly code (e.g. you didn't have to draw a sprite yourself, you just wrote a hardware register with a pointer to the sprite's image data in memory, and then wrote another hardware register to update the current sprite position and the video hardware did the rest). On modern hardware, providing such an interface is the job of drivers.
- pan69 2y ago
  > It's impossible to do graphics in pure C, so what are the alternatives? Back in the days of DOS I used to do this all the time :)
  - fgh 2y ago
    Yes, that brings back the memory of working through books by Andre LaMothe and implementing little games in DOS with C and a little bit of Assembler. I believe there was a very primitive graphics library included in Borland C, but it was not that useful for this task.
    - kevindamm 2y ago
      Andre LaMothe showed me the wonder of alternative graphics memory layout like Mode 13h and Mode Z. Though it confused teenage me at the time why you would have four memory segments each dealing with (offset %4) bytes in a line-oriented graphics buffer, it was magical when it worked and was one of the first times I had to let the code just work and move on. Double buffering was an understandable neat trick and one that would have taken me a bit longer to discover on my own. He also had a custom controller wired through the printer port and some C+ASM for interfacing with it. I had three of his books, I think the Black Art book was constantly on my desk in the 90s. https://archive.org/details/BlackArt3DEBook https://archive.org/details/BlackArt3DEBook
  - oldsecondhand 2y ago
    Didn't you still rely on the DOS HAL (by using system libraries)? The C IDEs came with a lot of graphics util libraries too (e.g. Turbo C).
    - thpx86 2y ago
      You do call a routine stored in VGA ROM (interrupt 0x10) to set up the mode, then do some port I/O to configure VGA registers and then access VGA memory directly. No "system libraries" from DOS involved as such (they are needed for things like filesystem access, allocating memory and dealing with command-line arguments and returning to the system, though). Borland's dev tools came with "BGI" (Borlands Graphics Interface), but that's not necessary and wasn't really used for many games -- it provides abstract high-level drawing routines, like lines, circles, etc... that can be made to work on different graphics devices (CGA, VGA, ...). This was not necessary for direct graphics card access that most games used.
- CodeArtisan 2y ago
  On Linux, you may mmap /dev/fb0 to access the front buffer like you would have on old computers. Not all kernel configs and GPU devices allow that. You can test if fb0 is usable with cat /dev/random > /dev/fb0 to see if the screen is filled with garbage (you may also need root privilege).
  - baudaux 2y ago
    For this reason, I have added framebuffer support in https://exaequos.com https://exaequos.com.
  - seba_dos1 2y ago
    You could also implement a Wayland or X11 client by yourself. Those libraries are also implemented in C after all. No need for external libraries to write to some sockets. Whether it's worth doing is another matter.
    - jayshua 2y ago
      This is not actually that difficult if you just want the basics. I have a project that implements just the x11 key & mouse events, and the shared memory extension in 400 lines of Rust. Was worth it for me since it eliminated dependency on libx11 and libc, which removed a dependency on something like 800,000 lines of code across those two libraries. (Determined by a basic cloc on each library source. Actually compiled code for a specific architecture would probably be less than that, but still orders of magnitude more than 400.)
      - seba_dos1 2y ago
        I probably wouldn't bother with implementing X11 from scratch for a game as even simply fullscreening it would likely require some diverging code paths to actually work everywhere, but Wayland should be a breeze. Having worked on SDL's Wayland backend I'd say that most of the difficulty came from impedance mismatches with preexisting SDL APIs, so if you design your thing from scratch all you really need to deal with there are the protocol bits - which you could just mostly hardcode and automatically get rid of most of libwayland's complexity that deals with protocol extensions and their XML descriptions.
- Y_Y 2y ago
  > It's impossible to do graphics in pure C, so what are the alternatives Plenty of other comments have already disputed this. It's a reasonable mistake to make, especially if your experience is with more recent technologies and languages. All the same if reminds me of this perennial quote from a man who really couldn't just use C for everything; > On two occasions I have been asked, — "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" In one case a member of the Upper, and in the other a member of the Lower, House put this question. I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. - Passages from the Life of a Philosopher (1864), ch. 5 "Difference Engine No. 1" Although I don't start new projects in C very often, I'm acutely aware how it's not turtles all the way down (as the logophiles believe), but rather C. With some infrequent exceptions the whole tower of abstraction was written in C. SDL is written in C, the compiler? C, the Linux kernel is written in C, the graphics driver was written in C, the GPU firmware was C. It might be unfeasible for you to get by without writing these yourself, but with enough C and somewhere to sit you can move the earth. (Of course all projects have a smattering of other languages and with great effort you can bootstrap from Forth or handwrite assembly or whatever, but you can do it all in C, and very likely that's what happened.)
  - mjburgess 2y ago
    The idiot there is Babbage -- the politician, more well trained in general thinking, clearly observed that thinking-things can correct mistakes against a background of common understanding. eg., "Q. Who is the king of france?", "A. France has no king, did you mean who was the last king of france?"
    - Y_Y 2y ago
      But that's an input too (cf. contingent vs. necessary truth). If the Analytical Engine were controlled by an Orléaniste it would surely declare the balding[0] Count of Paris, Jean Carl Pierre Marie d'Orléans, to be king[1]. [0] https://files.osf.io/v1/resources/p4wqa/providers/osfstorage/5fbe2059ab6518013bb0f5cc?action=download&direct&version=1 https://files.osf.io/v1/resources/p4wqa/providers/osfstorage... [1] https://en.wikipedia.org/wiki/Succession_to_the_former_French_throne_(Orl%C3%A9anist) https://en.wikipedia.org/wiki/Succession_to_the_former_Frenc...
- ant6n 2y ago
  You can target the Game Boy Advance or Game Boy.
- amelius 2y ago
  Even if you can write directly to a framebuffer you are still using other people's VHDL code.
- cmovq 2y ago
  This is x86 assembly not C, but could be done just as easily in C. No kernel support either, since there isn’t one. https://github.com/stillwwater/raycaster https://github.com/stillwwater/raycaster
  - shric 2y ago
    Please show me how to do the equivalent of https://github.com/stillwwater/raycaster/blob/master/src/boot.asm#L48-L50 https://github.com/stillwwater/raycaster/blob/master/src/boo... in C. There are many examples that are impossible in C, I just picked an obvious one.
- seba_dos1 2y ago
  How do you think libwayland-client is implemented? Or even SDL?
- shric 2y ago
  Too many people have replied to my post saying I'm wrong in some way, so rather than replying the same thing to almost every single comment, I'm going to reply to myself. My original response was to the person claiming that it was basically cheating to use SDL. You need abstraction, so there is nothing wrong with having SDL in the way. Someone said that it's C all the way down. It's not. The Linux kernel is not 100% C and it cannot possibly be. There are no C facilities to: - Read a keystroke and/or mouse (required for Flappy Bird) directly. C only supports reading from the stdin and stdout streams. - Generate graphics (more on this below). As I mentioned in the original post, some operating systems let you write straight to graphics memory. While you can technically do this in C with a pointer to an address, you're still going to have to issue e.g. a BIOS call to set the mode to something other than the default text mode. But we can let that slide. There is absolutely no way to do "C all the way down" when reading and writing I/O ports, executing interrupts, etc. which is required for I/O beyond just the buffered stdout and stdin streams that C provides. Linux of course provides things in /dev, but they're also not C all the way down. If there was a hypothetical computer which supported all graphics and other I/O via reading and writing to/from streams, then sure, but I don't think that computer exists. I know very well what C can and cannot do, I've been using it for 40 years.
palsecam 2y ago
You might also like “Cramming Solitaire onto a Nintendo E-Reader card” https://mattgreer.dev/blog/cramming-solitaire-onto-a-nintendo-ereader-card/ https://mattgreer.dev/blog/cramming-solitaire-onto-a-nintend... Discussed lately on HN: https://news.ycombinator.com/item?id=42010136 https://news.ycombinator.com/item?id=42010136
flohofwoe 2y ago
AFAIK scene demos which compete for minimal size are allowed to use system libraries like D3D on Windows. From that perspective, using SDL is ok, since it can be considered a system library at least on Linux (to workaround a ton a little compatibility warts between Linux distros).

shric 2y ago

It's impossible to do graphics in pure C, so what are the alternatives? Whatever you do at whatever level of abstraction/portability (SDL, OpenGL, Metal, Vulkan, Unity, ...), you're leveraging zillions of lines of other people's code. The only way arguably you could do it in pure C (with undefined behavior) is in enviroments that let you write straight to graphics framebuffers without any abstraction layer and even when you can't do keyboard or mouse input in C without library and/or kernel support.

tmountain 2y ago
I wonder what the smallest assembly implementation would look like to provide the minimal graphics API necessary.
- flohofwoe 2y ago
  You can't directly access the GPU hardware on modern systems (at least without a massive re-engeneering effort like the Asahi Linux GPU driver for Apple hardware), so any 'minimal graphics API' still goes through a massive amount of wrapper code in the operating system and GPU driver. Also, on older home computer systems the hardware was essentially the rendering- and audio-engine. Those systems were designed from the ground up to be convenient to program by directly writing hardware registers from assembly code (e.g. you didn't have to draw a sprite yourself, you just wrote a hardware register with a pointer to the sprite's image data in memory, and then wrote another hardware register to update the current sprite position and the video hardware did the rest). On modern hardware, providing such an interface is the job of drivers.
pan69 2y ago
> It's impossible to do graphics in pure C, so what are the alternatives? Back in the days of DOS I used to do this all the time :)
- fgh 2y ago
  Yes, that brings back the memory of working through books by Andre LaMothe and implementing little games in DOS with C and a little bit of Assembler. I believe there was a very primitive graphics library included in Borland C, but it was not that useful for this task.
  - kevindamm 2y ago
    Andre LaMothe showed me the wonder of alternative graphics memory layout like Mode 13h and Mode Z. Though it confused teenage me at the time why you would have four memory segments each dealing with (offset %4) bytes in a line-oriented graphics buffer, it was magical when it worked and was one of the first times I had to let the code just work and move on. Double buffering was an understandable neat trick and one that would have taken me a bit longer to discover on my own. He also had a custom controller wired through the printer port and some C+ASM for interfacing with it. I had three of his books, I think the Black Art book was constantly on my desk in the 90s. https://archive.org/details/BlackArt3DEBook https://archive.org/details/BlackArt3DEBook
- oldsecondhand 2y ago
  Didn't you still rely on the DOS HAL (by using system libraries)? The C IDEs came with a lot of graphics util libraries too (e.g. Turbo C).
  - thpx86 2y ago
    You do call a routine stored in VGA ROM (interrupt 0x10) to set up the mode, then do some port I/O to configure VGA registers and then access VGA memory directly. No "system libraries" from DOS involved as such (they are needed for things like filesystem access, allocating memory and dealing with command-line arguments and returning to the system, though). Borland's dev tools came with "BGI" (Borlands Graphics Interface), but that's not necessary and wasn't really used for many games -- it provides abstract high-level drawing routines, like lines, circles, etc... that can be made to work on different graphics devices (CGA, VGA, ...). This was not necessary for direct graphics card access that most games used.
CodeArtisan 2y ago
On Linux, you may mmap /dev/fb0 to access the front buffer like you would have on old computers. Not all kernel configs and GPU devices allow that. You can test if fb0 is usable with cat /dev/random > /dev/fb0 to see if the screen is filled with garbage (you may also need root privilege).
- baudaux 2y ago
  For this reason, I have added framebuffer support in https://exaequos.com https://exaequos.com.
- seba_dos1 2y ago
  You could also implement a Wayland or X11 client by yourself. Those libraries are also implemented in C after all. No need for external libraries to write to some sockets. Whether it's worth doing is another matter.
  - jayshua 2y ago
    This is not actually that difficult if you just want the basics. I have a project that implements just the x11 key & mouse events, and the shared memory extension in 400 lines of Rust. Was worth it for me since it eliminated dependency on libx11 and libc, which removed a dependency on something like 800,000 lines of code across those two libraries. (Determined by a basic cloc on each library source. Actually compiled code for a specific architecture would probably be less than that, but still orders of magnitude more than 400.)
    - seba_dos1 2y ago
      I probably wouldn't bother with implementing X11 from scratch for a game as even simply fullscreening it would likely require some diverging code paths to actually work everywhere, but Wayland should be a breeze. Having worked on SDL's Wayland backend I'd say that most of the difficulty came from impedance mismatches with preexisting SDL APIs, so if you design your thing from scratch all you really need to deal with there are the protocol bits - which you could just mostly hardcode and automatically get rid of most of libwayland's complexity that deals with protocol extensions and their XML descriptions.
Y_Y 2y ago
> It's impossible to do graphics in pure C, so what are the alternatives Plenty of other comments have already disputed this. It's a reasonable mistake to make, especially if your experience is with more recent technologies and languages. All the same if reminds me of this perennial quote from a man who really couldn't just use C for everything; > On two occasions I have been asked, — "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" In one case a member of the Upper, and in the other a member of the Lower, House put this question. I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. - Passages from the Life of a Philosopher (1864), ch. 5 "Difference Engine No. 1" Although I don't start new projects in C very often, I'm acutely aware how it's not turtles all the way down (as the logophiles believe), but rather C. With some infrequent exceptions the whole tower of abstraction was written in C. SDL is written in C, the compiler? C, the Linux kernel is written in C, the graphics driver was written in C, the GPU firmware was C. It might be unfeasible for you to get by without writing these yourself, but with enough C and somewhere to sit you can move the earth. (Of course all projects have a smattering of other languages and with great effort you can bootstrap from Forth or handwrite assembly or whatever, but you can do it all in C, and very likely that's what happened.)
- mjburgess 2y ago
  The idiot there is Babbage -- the politician, more well trained in general thinking, clearly observed that thinking-things can correct mistakes against a background of common understanding. eg., "Q. Who is the king of france?", "A. France has no king, did you mean who was the last king of france?"
  - Y_Y 2y ago
    But that's an input too (cf. contingent vs. necessary truth). If the Analytical Engine were controlled by an Orléaniste it would surely declare the balding[0] Count of Paris, Jean Carl Pierre Marie d'Orléans, to be king[1]. [0] https://files.osf.io/v1/resources/p4wqa/providers/osfstorage/5fbe2059ab6518013bb0f5cc?action=download&direct&version=1 https://files.osf.io/v1/resources/p4wqa/providers/osfstorage... [1] https://en.wikipedia.org/wiki/Succession_to_the_former_French_throne_(Orl%C3%A9anist) https://en.wikipedia.org/wiki/Succession_to_the_former_Frenc...
ant6n 2y ago
You can target the Game Boy Advance or Game Boy.
amelius 2y ago
Even if you can write directly to a framebuffer you are still using other people's VHDL code.
cmovq 2y ago
This is x86 assembly not C, but could be done just as easily in C. No kernel support either, since there isn’t one. https://github.com/stillwwater/raycaster https://github.com/stillwwater/raycaster
- shric 2y ago
  Please show me how to do the equivalent of https://github.com/stillwwater/raycaster/blob/master/src/boot.asm#L48-L50 https://github.com/stillwwater/raycaster/blob/master/src/boo... in C. There are many examples that are impossible in C, I just picked an obvious one.
seba_dos1 2y ago
How do you think libwayland-client is implemented? Or even SDL?
shric 2y ago
Too many people have replied to my post saying I'm wrong in some way, so rather than replying the same thing to almost every single comment, I'm going to reply to myself. My original response was to the person claiming that it was basically cheating to use SDL. You need abstraction, so there is nothing wrong with having SDL in the way. Someone said that it's C all the way down. It's not. The Linux kernel is not 100% C and it cannot possibly be. There are no C facilities to: - Read a keystroke and/or mouse (required for Flappy Bird) directly. C only supports reading from the stdin and stdout streams. - Generate graphics (more on this below). As I mentioned in the original post, some operating systems let you write straight to graphics memory. While you can technically do this in C with a pointer to an address, you're still going to have to issue e.g. a BIOS call to set the mode to something other than the default text mode. But we can let that slide. There is absolutely no way to do "C all the way down" when reading and writing I/O ports, executing interrupts, etc. which is required for I/O beyond just the buffered stdout and stdin streams that C provides. Linux of course provides things in /dev, but they're also not C all the way down. If there was a hypothetical computer which supported all graphics and other I/O via reading and writing to/from streams, then sure, but I don't think that computer exists. I know very well what C can and cannot do, I've been using it for 40 years.

palsecam 2y ago

You might also like “Cramming Solitaire onto a Nintendo E-Reader card” https://mattgreer.dev/blog/cramming-solitaire-onto-a-nintendo-ereader-card/ https://mattgreer.dev/blog/cramming-solitaire-onto-a-nintend... Discussed lately on HN: https://news.ycombinator.com/item?id=42010136 https://news.ycombinator.com/item?id=42010136

flohofwoe 2y ago

AFAIK scene demos which compete for minimal size are allowed to use system libraries like D3D on Windows. From that perspective, using SDL is ok, since it can be considered a system library at least on Linux (to workaround a ton a little compatibility warts between Linux distros).