Computer Graphics from Scratch (2017)

Similar story here, but on a ZX Spectrum :)

My thing was sprite-multiplexers. In theory it's very simple. You sort the sprites by y-position, then use raster interrupts to reprogram the sprite registers for "(spriteN++ & 7)".

The hardest part is sorting. It takes quite some time to sort data on a 6502. I "invented" my own sorting routine for this, but I later learned that most coders used bubblesort since most of the time sprites move just a little so it's mostly sorted already.

My routine used half the stack. I took ypos >> 2 and used that as an index to the bottom half of the stack. If the position was occupied I used the next pos etc. To collect I simply used a PLA(pop) instruction. There were holes of course, so you had to check for empty slots.

That routine took about the same time every frame.

32 sprites was not very hard to do, sorting-wise.

Google's comically bad at hiring for it though so I wouldn't count on them. When I interviewed there after having worked on graphics extensively at Apple and other places, they asked me how to load balance real time search suggestions and I failed, obviously.

Anyone else have info. on this?

I started by writing games and game engines as a teenager (now ~14 years ago), reading "Real-time Rendering" and the "OpenGL Superbible". I've done a lot more with computer graphics since, writing pixel shaders for fun, building a web-based domain specific CAD tool (for a client) etc. Also been doing some computational geometry stuff more recently.

I haven't had much luck finding positions for 'graphics programmers' though. I've found things like 'lead engine programmer' for game companies—which is a bit out of my league, IMO.

But I'd love to work on things like the VR youtube player that Google did (doesn't have to be VR; 3D UI design is interesting to me regardless). Don't how to find these sorts of positions at companies like Apple/FB/Google etc., where I would hope they pay quite well (comments on that also welcome!).

Visual effects industry as well.

> But once you do, you find that other subfields of CS are more interesting and useful. And you just get older. :)

It is true that some people, as they get older, claim to find games less interesting. In my opinion, some of them simply jaded a bit, and would be a good thing for them if they tried to find enjoyment again in the small things. I know, because I was there too. It depends a lot on the culture.

There are also others that start claiming games are useless, immature and that the world will end if youngsters keep playing them.

Entertainment has been useful even before civilization existed, and those that enjoy the time to entertain themselves, do; even if it is in the form of working on dream projects. Yes, that is playing too.

As for your other point, there are objectively very few (if any) topics as interesting as games for CS people, given the so many areas of CS (and non-CS) they encompass at the same time. Hardly any other area of work touches so many domains. Only operating systems, browsers and CAD apps (and maybe Emacs ;) are close as vast.

> But once you do, you find that other subfields of CS are more interesting and useful.

I feel like the exploitative nature and below-industry living-working standards are what pushes people away from the field in the first place.

The video gaming industry makes in the same order of magnitude in revenue as the global movie market. It certainly isn't a small industry.

I'm currently at a games studio. Graphics in general fascinate me, and I'd be happy at any job which allows for fast iterating and a visual interactive system to work on, where the underlying problems are difficult and performance sensitive.

A lot of the recent outcry over games industry being horrible is a bit exaggerated. I'm glad some of these issues are getting attention, but it's far from being like that everywhere.

It's really compelling work.

Maybe it was "Computer Graphics: Principles and Practice", most commonly known as "the Foley Van-Dam"?

http://www.opengl-tutorial.org/ is a pretty fantastic resource of learning this stuff.

Don't worry too much about opengl vs direct x vs vulkan. There are underlying principles that apply broadly to both.

Alternatively if you want a book that goes more in depth, but still allows you to take your first steps, opengl programming guide 8th+ edition is good.

Expect it to require some patience no matter what route you take. Graphics programming is finnicky.

Thanks for your kind words :)

No definite plan for a print version, but it could be fun, if nothing else to have a copy on my own shelf! There's a few sections I need to complete first, though.

I do have plans to add a few more chapters covering more advanced topics, but again, nothing definite.

Thanks for mentioning it.

Do you think that book is a good source to learn "traditional" OpenGL?

Not sure if this is related to errors loading resources, but all the "Source code and live demo" links go to pages that seem to render the demo in javascript but don't show any code. Maybe the reader is intended to view source to see it?

Thanks for your kind words, I'm glad you found it helpful :)

Maybe I'll write a book about Improbable some day - but more likely about the mythical origin story :) That said, at two different times I managed teams that made demos, tutorials and documentation, most recently https://twitter.com/gabrielgambetta/status/92135876311796121..., but there's people much more qualified than I am to write technical stuff about SpatialOS nowadays.

Region boundaries are a fascinating topic, see this for example: https://improbable.io/games/blog/distributed-physics-without...

But as Woody Harrelson would say, "let's keep it about Computer Graphics, people..." ;)

Hmmm, can't find it. Mind telling me what it is?

Glad to hear you've found it interesting :)

Copying the entire framebuffer over the PCI bus makes me sad, though it's obviously way faster than when you could memory-map the framebuffer. These days you can't map texture objects in memory because texture storage on GPUs is its own black magic and textures are not stored as simple linear framebuffers. It would be fun to restrict yourself to a well-documented architecture, e.g. give everyone a cheap intel-based notebook and write out commands directly for the graphics chip. I guess while fun that would teach more about doing low-level hardware access than graphics themselves.

And while on the topic of changing hardware forcing us to change our algorithms, I wonder if teaching scanline rendering is even worth it these days. Every CPU supports SIMD and a SIMD-optimised software rasteriser is a very different beast than the classic scanline triangle rasterisers of old.

Probably the fastest software rasteriser for modern CPUs is OpenSWR [0], written by Intel mostly to keep themselves relevant in the data visualisation space until GPUs eat HPCs (GPUs still can't help you when your dataset is measured in hundreds of gigabytes of graphics data), but it scales perfectly fine down to desktop CPUs. The code for it is in the Mesa tree [1]. I wish I could explain exactly how it works, but it's a pretty big beast and I haven't had the time to read and understand all of it. Intel gave a presentation on it at the HPC developers conference back in 2015 [2]

[0] http://openswr.org/index.html

[1] https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/driv...

[2] https://youtu.be/gpYd18E3TWc?t=1531

Here's the sample code I pass around for doing that. It's a minimal example using SDL. AFAICT, it's pretty much the fastest way to get graphics from the CPU RAM to the screen.

https://gist.github.com/CoryBloyd/6725bb78323bb1157ff8d4175d...

MOV AX, 13h; INT 10h :)