10 ms·

> The first thing that jumped out at me in this story was the part about sending machine code over the network to be executed by the game. It had never occurred

> The first thing that jumped out at me in this story was the part about sending machine code over the network to be executed by the game. It had never occurred to me that this was possible, despite it being obvious in hindsight. This is a good reminder that us software devs generally live in bubbles, not really thinking about or (sometimes intentionally) ignoring things that are not immediately relevant to our work. The author appears to mostly work in game development, specifically shading, 3D, and engine development. Generally you think very little about writing secure code in those fields. You can actually see him going down the "low-level rabbit-hole" if have a look at his posts: http://kylehalladay.com/archive.html http://kylehalladay.com/archive.html

BrianOnHN 6y ago
What's the low-level rabbit-hole?
- danmur 6y ago
  There's a surface rabbit hole for regular rabbits, but if you follow it down, sometimes low-level rabbits have made another rabbit hole at the bottom which leads into their warrens. That's all though there's no third level.
  - Lvl999Noob 6y ago
    Why not? A rabbit could feel like the hardware still too mysterious and go even deeper, making their own chips from their self sourced silicon.
    - caseysoftware 6y ago
      Yes but getting mining helmets that are compatible with rabbit physiology but still meet OSHA guidelines is a pain. I'd recommend outsourcing to other deeper-delving creatures. Some abstractions are useful.
    - temp0826 6y ago
      The only rabbit I know of that dares to go that deep is Åkesson (see Parallelogram [0]) [0] http://www.linusakesson.net/scene/parallelogram/index.php http://www.linusakesson.net/scene/parallelogram/index.php
deadbytes 6y ago
I would encourage all developers to download a Commodore 64 emulator and spend some time learning 6502 assembly. There is no memory protection and no software abstractions. You display graphics on the screen by writing directly to video memory. Programming for the C64 made me have innumerable lightbulb moments and significantly changed my perspective on what a computer really is.
- br2 6y ago
  Any recommendations for books/tutorials/videos or other starting points? I don't know any assembly but wanted to learn 6502 assembly because of how ubiquitous it was in lots of older systems (2600, NES, Apple II, and of course C64 among others). That SMB 3 speed run [1] really blew my mind and made me want to learn more. [1] https://news.ycombinator.com/item?id=24456247 https://news.ycombinator.com/item?id=24456247
- ajuc 6y ago
  > There is no memory protection and no software abstractions. You display graphics on the screen by writing directly to video memory You can have similar experience with a little more power by writing code in mode 13h for dos. Want to light a pixel with specific color? Change byte of memory at A000 + y*320+x :). You have 256 colors, every pixel is a byte, and you have another place in memory where it says what each color number maps to in rgb values. So you can do palette animations trivially. There is no easier way to program graphic IMHO. You can use any language - my favorite was Turbo Pascal 7 (but the compiler has a bug that breaks on cpus with over 200 MHz clock - you need to download turbo pascal and a patch that fixes this issue for example https://www.trsek.com/download/T7tplfix.zip https://www.trsek.com/download/T7tplfix.zip ).
  - kragen 6y ago
    > There is no easier way to program graphic IMHO. You might enjoy https://github.com/kragen/bubbleos/blob/master/yeso https://github.com/kragen/bubbleos/blob/master/yeso. /* Munching squares, generalized to TrueColor. */ #include <yeso.h> int main() { ywin w = yw_open("munching squares", yp_p(1024, 1024), ""); for (int t = 0;; t++) { ypic fb = yw_frame(w); for (int y = 0; y < fb.size.y; y++) { ypix *p = yp_line(fb, y); for (int x = 0; x < fb.size.x; x++) p[x] = (t & 1023) - ((x ^ y) & 1023); } yw_flip(w); } } I think that, in terms of accessibility, these 14 lines of C compare favorably to the 15 instructions (and one assembler directive) in the 31-byte mode-X demo Klappquadrat, for example. Yeso also has Lua and Python bindings, which are somewhat incomplete. I haven't written Pascal bindings for it yet, but feel free. On the other hand, that won't give you the same kind of satori experience as the bare-metal C64 experience, because Yeso is running on top of some arbitrary stack of software you don't understand, and the C64 VIC (or VGA mode 13h, at least if you're using a real VGA) is really just circuits. Using Yeso won't stop you from feeling that what's behind the library calls is magic.
mbrodersen 6y ago
> Generally you think very little about writing secure code in those fields. That sounds incredibly patronising. Most software in any field is insecure. It is not unique to games development. SQL injection and buffer overruns is still a thing. Even today.

BrianOnHN 6y ago

What's the low-level rabbit-hole?

danmur 6y ago
There's a surface rabbit hole for regular rabbits, but if you follow it down, sometimes low-level rabbits have made another rabbit hole at the bottom which leads into their warrens. That's all though there's no third level.
- Lvl999Noob 6y ago
  Why not? A rabbit could feel like the hardware still too mysterious and go even deeper, making their own chips from their self sourced silicon.
  - caseysoftware 6y ago
    Yes but getting mining helmets that are compatible with rabbit physiology but still meet OSHA guidelines is a pain. I'd recommend outsourcing to other deeper-delving creatures. Some abstractions are useful.
  - temp0826 6y ago
    The only rabbit I know of that dares to go that deep is Åkesson (see Parallelogram [0]) [0] http://www.linusakesson.net/scene/parallelogram/index.php http://www.linusakesson.net/scene/parallelogram/index.php

deadbytes 6y ago

I would encourage all developers to download a Commodore 64 emulator and spend some time learning 6502 assembly. There is no memory protection and no software abstractions. You display graphics on the screen by writing directly to video memory. Programming for the C64 made me have innumerable lightbulb moments and significantly changed my perspective on what a computer really is.

br2 6y ago
Any recommendations for books/tutorials/videos or other starting points? I don't know any assembly but wanted to learn 6502 assembly because of how ubiquitous it was in lots of older systems (2600, NES, Apple II, and of course C64 among others). That SMB 3 speed run [1] really blew my mind and made me want to learn more. [1] https://news.ycombinator.com/item?id=24456247 https://news.ycombinator.com/item?id=24456247
ajuc 6y ago
> There is no memory protection and no software abstractions. You display graphics on the screen by writing directly to video memory You can have similar experience with a little more power by writing code in mode 13h for dos. Want to light a pixel with specific color? Change byte of memory at A000 + y*320+x :). You have 256 colors, every pixel is a byte, and you have another place in memory where it says what each color number maps to in rgb values. So you can do palette animations trivially. There is no easier way to program graphic IMHO. You can use any language - my favorite was Turbo Pascal 7 (but the compiler has a bug that breaks on cpus with over 200 MHz clock - you need to download turbo pascal and a patch that fixes this issue for example https://www.trsek.com/download/T7tplfix.zip https://www.trsek.com/download/T7tplfix.zip ).
- kragen 6y ago
  > There is no easier way to program graphic IMHO. You might enjoy https://github.com/kragen/bubbleos/blob/master/yeso https://github.com/kragen/bubbleos/blob/master/yeso. /* Munching squares, generalized to TrueColor. */ #include <yeso.h> int main() { ywin w = yw_open("munching squares", yp_p(1024, 1024), ""); for (int t = 0;; t++) { ypic fb = yw_frame(w); for (int y = 0; y < fb.size.y; y++) { ypix *p = yp_line(fb, y); for (int x = 0; x < fb.size.x; x++) p[x] = (t & 1023) - ((x ^ y) & 1023); } yw_flip(w); } } I think that, in terms of accessibility, these 14 lines of C compare favorably to the 15 instructions (and one assembler directive) in the 31-byte mode-X demo Klappquadrat, for example. Yeso also has Lua and Python bindings, which are somewhat incomplete. I haven't written Pascal bindings for it yet, but feel free. On the other hand, that won't give you the same kind of satori experience as the bare-metal C64 experience, because Yeso is running on top of some arbitrary stack of software you don't understand, and the C64 VIC (or VGA mode 13h, at least if you're using a real VGA) is really just circuits. Using Yeso won't stop you from feeling that what's behind the library calls is magic.

mbrodersen 6y ago

> Generally you think very little about writing secure code in those fields. That sounds incredibly patronising. Most software in any field is insecure. It is not unique to games development. SQL injection and buffer overruns is still a thing. Even today.