[voltagex_]

Every now and then I get interested in demoscene programming. I've never even been able to get a triangle to render on the screen - except with something like XNA.

Do you think there's any value in going back to say, DOS based VGA programming? People in #osdev thought I was a bit strange for wanting to write a bootable kernel that only put pixels on the screen, but I really enjoy the idea of starting with plotting pixels, then moving on to more complex effects.

[khedoros]

Are you more interested in actually writing to PC VGA registers, or just the idea of writing a pixel-by-pixel renderer? There are bindings for SDL and SFML in a lot of languages, and the web technology option mentioned by the sibling comment.

If you like the idea of "DOS-based VGA programming" (taken literally), you could also find a DOS compiler or assembler and run it in DosBox. All of IBM's hardware-level documentation can still be found online: http://www.mcamafia.de/pdf/pdfref.htm

[chrisseaton]

You can write raw pixels to the screen with a HTML canvas and JS - no need to do it with low level code and making your own OS.

[corysama]

I bet you could go from main() to displayBufferOnScreen(unsigned char *buffer) in a couple dozen lines of C using SDL.

[voltagex_]

This is a good idea, as is the Javascript one above.

[vram22]

Or with different desktop GUI toolkits for different languages: C++ w/Qt, C++ w/ wxWidgets, wxPython, Perl/Tk, Python +Tkinter, Delphi, Lazarus, or many other lang/toolkit combos. Even many BASICs have that ability built-in (from the early days of personal computers).

[nice_byte]

You could skip writing a bootable kernel, and try that with microcontrollers :) It's possible to hook up a tiny lcd screen to an arduino

[errozero]

You can even wire up an arduino into a vga monitor. There are a few vids on youtube showing simple games displayed this way.

[kragen]

The value of DOS based VGA programming is that, although hard things are damn near impossible, easy things are easy. https://www.mail-archive.com/[e-mail]/msg0... is a 64-byte .COM file I wrote in assembly that draws circles on the screen; you can get to mode 13h with two instructions, and then you have a linear framebuffer with 64000 bytes, one byte per pixel, at your disposal located at A0000h.

So there are some awesome things about this:

- It's really easy to get started. You can literally take the code on that page, assemble it, verify that you get the right hexadecimal output, and run it in dosbox.

- Just about anything you do in the segment you point at the framebuffer will make something appear on the screen and not crash your program. So your bugs will be harder to debug, but they will also be cool.

- For example, running a pointer off the bottom of the screen puts you back on top of the screen instead of in the middle of your stack or heap or something. There are 4 lines of pixels that aren't shown, but often you don't care.

- The pixels are more or less square.

- Since each pixel is one byte, pixels correspond nicely to addressable memory locations.

- The first few colors in the default VGA palette are primary colors.

- Once you draw something, you can get awesome effects by changing the palette. Color-cycling, for example. This was really cool when actually redrawing the screen sixty times a second was computationally infeasible.

There are also a lot of shitty things about it:

- 320×200 is not very much resolution. Nothing will look sharp, except possibly the corners of your pixels.

- Palettes make it easy to draw something, and they even provide a kind of high-level interface that lets you kind of search and replace colors, in a way. (It's really more like macro-expanding your colors I guess.) But they make gradients and alpha-blending really hard to achieve, unless you stick to grayscale or sepia or something. TrueColor video modes are much better for those.

As for triangles, I'm sure you can figure out how to do them, but keep in mind that geometric algorithms easily turn into a rat's-nest of special cases. I've written polygon-filling routines a few times, and they can easily have the same algorithmic complexity as an entire ray tracer, which looks a hell of a lot cooler.