HN Books @HNBooksMonth

The book you want is called within the graphics industry "Foley Van Dam", after the original authors, but the actual title is "Computer Graphics: Principles and Practice". https://www.amazon.com/Computer-Graphics-Principles-Practice...

You may also be interested in "ACM: Transactions on Graphics", the Association of Computing Machinery's publication of computer graphics research papers. I suggest going to a University technical/research library, where you should be able to access the collection of issues from the 80's, where the original scan line, ray tracing, CSG, and pretty much every single advanced graphics technique (minus the deep learning) used today is documented by the original innovators.

At that same University research library they might have the collected set of course text books (mimeographs and photocopies) used for the 3-day long courses taught at SIGGRAPH every year.

These items are invaluable, and I reference them multiple times a year.

⬐ jb1991

This is incredibly useful, thank you so much!

⬐ dahart

I only have 2nd edition of Foley & vanDam’s GCPP, which predates sRGB, I assume the 3rd edition has been modernized? I wouldn’t have thought of this book as the first place to learn color & compositing specifically, but it’s probably decent. I haven’t referred to CGPP much lately, but maybe it has something to do with the time Andy van Dam loaned me one of his swimsuits and it was slightly too small for me. :P

Way back in the day I read either the 1st or 2nd edition of this book: https://www.amazon.com/Computer-Graphics-Principles-Practice...

It's a classic in the computer graphics field, like Knuth is for algorithms. I'd recommend it alongside the OP's new book.

EDIT: But for anyone who is reading this wanting to learn about practical computer graphics, CG:P&P is NOT the resource to use! Learning the low-level rasterization algorithms used in computer graphics is an important thing to learn at some point, just like learning assembly language provides valuable insights even if you never touch a line of assembler again. But if you actually want to write graphics code on modern hardware with GPUs, I'd highly recommend Real Time Rendering instead: https://www.amazon.com/Real-Time-Rendering-Fourth-Tomas-Aken...

⬐ 2pEXgD0fZ5cF

Thanks a lot for the recommendation!

What would you say are the prerequisites for this one?

Also from the description it sounds as if it also goes a bit more into 2D graphics too, is that correct?

⬐ garmaine

Again, I read an ancient edition which predated the existence of consumer GPUs. But the edition I read was more than half on the topic of 2D graphics and what you might consider to be mundane things like font rasterization.

You might think this has nothing to do with 3D graphics, but in fact there is a big overlap. The graphics driver + GPU takes a description of a 3D scene and projects it into 2D primitives whichs are rasterized onto a bitmap (the display) just as one might render a font glyph.

So IIRC the book begins with the basic theory and techniques of 2D graphics, and then shows how projective geometry can be used to render 3D scenes onto 2D displays, and progressively adds various corrections which we take for granted, such as perspective-correct interpolation of texture values, which these days is done automatically by the hardware.

I don't think there's any pre-requisites other than a basic understanding of beginner computer science, coding, and algorithms. If you can read Knuth, you can read CG:P&P.

Also, see my edit to the grandparent comment.

Computer Graphics:

[1a, 1b, 1c] Computer Graphics, Principles and Practice Series [2] Physically Based Rendering [3] Real Time Rendering

---

[1a] https://www.amazon.com/Computer-Graphics-Principles-James-Fo... [1b] https://www.amazon.com/Computer-Graphics-Principles-Practice... [1c] https://www.amazon.com/Computer-Graphics-Principles-Practice... [2] https://www.amazon.com/Physically-Based-Rendering-Theory-Imp... [3] https://www.amazon.com/Real-Time-Rendering-Third-Tomas-Akeni...

⬐ kendallpark

Any resources you'd recommend for learning about 3D volumetric rendering via voxels (not polygons)?

⬐ GaryNumanVevo

NVIDIA has some good papers on Sparse Voxel Oct-trees (GPU backed of course). Typically voxel rendering is done via raytracing.

⬐ kendallpark

Thanks!

Do you have any opinion of voxel cone tracing vs raytracing?

⬐ __exit__

I acquired Pbrt in order to learn the basics of computer graphics rendering in a practical way. However, I struggle even with the most basic things (math mostly).

Do you happen to know of any resource that provides a good mathematical foundation directed at computer graphics?

I'd go with these two instead:

Michael Abrash’s Graphics Programming Black Book http://www.jagregory.com/abrash-black-book/

Computer Graphics: Principles and Practice: Principles and Practices https://www.amazon.co.uk/Computer-Graphics-Principles-Practi...

This is a solid list, but its a shame that no computer graphics resources are even mentioned. Although the reason for the omission is mentioned in the FAQ, I'd argue that computer graphics basics (images, basic rasterization, color spaces, etc.) are as fundamental as networking or databases. A link to Computer Graphics Principles and Practice (https://www.amazon.com/Computer-Graphics-Principles-Practice...) would have been nice.

I understand that most graphics resources out there focus on real-time 3D rendering for games or writing raytracers, which I agree are currently industry specific topics. Your average developer isn't going to write a vector graphics library as part of their day job, but the browser abstracts computer graphics in the same way it abstracts networking or compilers, so if the goal is to understand the underlying principles of software platforms you'll be working on every day I think computer graphics is a strange, biased, omission.

⬐ snowcrshd

How does that book compares to Peter Shirley's Fundamentals of computer graphics [1]

I'm interested in CG but don't really know where to start.

[1] https://www.amazon.com/Fundamentals-Computer-Graphics-Fourth...

⬐ malayandi

cs184.org

⬐ jacobolus

The video links there are broken. Any idea if they have the videos available anywhere?

⬐ malayandi

I don't think so :( UC Berkeley were forced to take down lecture videos as a result of some slight violation of the ADA. There are a couple links about that further down this page.

⬐ eriknstr

I don't know what ADA is in this context (misspelling of NDA maybe?), but hopefully this means that the next time they run the course -- in 2018 -- they will avoid those violations and be able to distribute video recordings.

⬐ shard

ADA is the American Disabilities Act, which require equal access for those with hearing, visual or manual disabilities. The videos in question most likely lacked captions for the hearing impaired, which would have been prohibitively expensive for Berkeley to add to the thousands of videos that they offered. Therefore to comply with the letter of the law, Berkeley removed access to the videos.

⬐ nickpsecurity

It's the acronym for American Disabilities Act or something. I get ADA-related results every time I look for updates on what people are doing with the Ada programming language. It gets more unfortunate when one realizes how much words like safety, formal policies, and so on are used by web sites dedicated to both. I almost got fooled a few times thinking I was reading a result about the language but it was some ADA safety initiative. (rolls eyes) Have to work the filters carefully.

I will say you don't want to screw around with ADA requirements. I've seen plenty of news reports of companies taking hits in court over it. Best for business owners to see what they need to do and do it whenever they can afford.

⬐ af16090

It's the Americans with Disabilities Act: https://en.wikipedia.org/wiki/Americans_with_Disabilities_Ac...

⬐ neivin

Americans with Disabilities Act.

UC Berkeley was hit with a lawsuit saying that their videos were inaccessible because they had no subtitles. So they're just taking them all down to avoid it.

Some people just don't want others to have nice things.

⬐ Tushon

>Some people just don't want others to have nice things.

I don't know you or your situation, but it's easy to think that while not really being how this works. ADA lawsuits are filed for a variety of reasons and at least some are intended solely to be the stick that gets a company to do the right thing for a group of people who have protection under the law. Often, these lawsuits are accompanied by timelines for implementation that are pretty reasonable (months or longer). I can't speak to this particular one, but that was an experience at my company. Some companies/organizations choose to provide the benefit in one way or another, and others choose to behave in the manner of UC-Berkeley (and, presumably, they know why they are choosing to take down videos instead of captioning). It isn't fair to single out people w/ that empty platitude. Sucks that the content is being taken down, but I bet UC-Berkeley had a choice.

⬐ nickpsecurity

The stuff costs money, too. Money that might have gone on other things even more important. Just one class of disability combined with sidewalks might cost LA over a billion dollars:

http://www.scpr.org/news/2015/04/01/50727/l-a-to-pay-1-4-bil...

⬐ af16090

The videos will be taken down starting March 15th: http://news.berkeley.edu/2017/02/24/faq-on-legacy-public-cou...

So you still have a day to run youtube-dl on whatever you want from their channel. Recordings from a 2014 CS 184 course can be found here: https://www.youtube.com/playlist?list=PL-XXv-cvA_iBifi0GQVF1...

⬐ jacobolus

Those seem like a different set of videos though than the ones from the linked page about this year’s course.

⬐ bogomipz

Does anyone know if there is any project that will archive these? This is a shame. I'm not even clear why the DOJ got involved here.

⬐ ozanonay

Hi! It was hard to draw the line. And then, it was an omission to not even make a suggestion in the FAQ. Now fixed, thanks :)

⬐ niuzeta

Heh, heh, draw the line.

...Sorry.

⬐ smnplk

best pun of today :P

Few things consistently blow my mind as insane graphics demos

https://www.shadertoy.com/view/4dfGzS (or basically anything on that site)

How is that 400 lines of code.

Or this one which even generates the sound on the GPU

https://www.shadertoy.com/view/4ts3z2

With the wide adoption of WebGL, it's a good time to get involved in graphics. Furthermore, GPUs are taking over esp. with the advent of machine learning (nvidia stock grew ~3x, amd ~5x last year). The stuff nvidia has been recently doing is kinda crazy. I wouldn't be surprised if in 15 years, instead of AWS, we are using geforce cloud or smth, just because nvidia will have an easier time building a cloud offering than amazon will have building a gpu.

These are some good resources to get started with graphics/games

# WebGL Programming Guide: Interactive 3D Graphics Programming with WebGL

https://www.amazon.com/WebGL-Programming-Guide-Interactive-G...

Historically, C++ has definitely been THE language for doing graphics but if you are starting these these, you would have to have really compelling reasons to start with C++ and not JavaScript and WebGL. And that's coming from someone who actually likes C++ and used to write it professionally.

# Book of Shaders

https://thebookofshaders.com/

# Game Programming Patterns

http://gameprogrammingpatterns.com/contents.html

https://www.amazon.com/Game-Programming-Patterns-Robert-Nyst...

HN's own @munificent wrote a book discussing the most important design patterns in game design. Good book applicable beyond games.

# Game engine architecture

https://www.amazon.com/Engine-Architecture-Second-Jason-Greg...

# Computer graphics: Principles and Practice

https://www.amazon.com/Computer-Graphics-Principles-Practice...

This is more of college textbook if you'd prefer that but the WebGL one is more accessible and less dry.

# Physically Based Rendering & Real-Time Rendering

These discuss some state of the art techniques in computer graphics. I'm not going to claim to have really read them but from what I've seen they are very solid.

https://www.amazon.com/Computer-Graphics-Principles-Practice...

https://www.amazon.com/Physically-Based-Rendering-Third-Impl...

⬐ kickscondor

That first shader is sampling from three textures, so the image is not entirely generated by an algorithm - see iChannel0, iChannel1 and iChannel2 at the bottom of the page. (With iChannel3 being the music.)

The shaders on ShaderToy aren't quite the same as straight OpenGL fragment shaders - there is quite a bit of boilerplate code built into the site that allows ShaderToy shaders to have access to stuff like mouse coordinates and audio signal info. (Expand the 'Shader inputs' area above the code block - none of those are available in OpenGL.)

But OpenGL also has its own library[1] of functions: `texture2D`, `smoothstep`, `mix` and all the built-in vector math - and you can see all of these in action in the shader you linked. The ShaderToy boilerplate - in partnership with these libraries - is the reason the code is so concise.

[1] http://www.shaderific.com/glsl-functions/

⬐ adamnemecek

You are right, I didn't pick the best example. But I believe everything is procedurally generated on the GPU in this demo https://www.youtube.com/watch?v=pnn6QC8a5g8. Note that all of this had to be fit into a binary of 4k or smaller.

⬐ kickscondor

Oh it's a fine example - I'm sorry - it didn't occur to me that my reply would sound critical! I just wanted to add some explanation, for anyone who was curious. The original post was good!

⬐ fla

for the maximum wow effect, I suggest one of the latest shader by iq : https://www.shadertoy.com/view/4ttSWf

This is almost Pixar level graphics running realtime in your browser.

⬐ greggman

I don't want to dis shaders on shadertoy, they are amazing toys (which is why it's called shadertoy). And, that shader you linked to is amazing as well. But, for example on my 2015 MBP it runs at 8fps in a tiny sub portion of a window. If I go fullscreen in runs in 0.3fps. Yet this same machine can run The Witness at 60fps or GTA5 at 30fps and see the entire world.

My point is the shaders on shadertoy are exercises in doing something for fun with limits (one shader and a few inputs) and not about speed or optimization or the anything to do with the way any game engine would go about to get performance.

⬐ scoopr

I'd like to just point out that iq used to work for Pixar[0] :)

[0] http://www.iquilezles.org/personal/curri/curri.htm

⬐ userbinator

iq has a ton more examples of these on his site (including tiny executables which generate such images and animations):

http://www.iquilezles.org/www/articles/raymarchingdf/raymarc...

http://www.iquilezles.org/prods/index.htm

⬐ adamnemecek

That guy's whole production is insane https://shadertoy.com/user/iq

⬐ optionalparens

> you would have to have really compelling reasons to start with C++ and not JavaScript and WebGL. And that's coming from someone who actually likes C++ and used to write it professionally.

As someone working in game programming a long time and now also spending more time in machine learning, I must disagree. I suppose I can see your implied point about getting started quickly or something like that, but there's really few compelling reasons to do graphics programming in JavaScript professionally. As a hobby or for a web-based project like a tutorial site, sure, JavaScript and WebGL make perfect sense. For most professional uses though, I can't agree.

Writing a decent performing and well-architected graphics engine is much more than just using an API like OpenGL, WebGL, or any of the successors or predecessors. Further, writing a graphics engine is not about creating an efficient island, but rather a piece of a larger eco-system. Consider that quite often some of the biggest hinderances to graphics performance are creating the data to actually be rendered (ex: via the game update), sending the data to the GPU efficiently, and still getting all kinds of other program logic to run before you even have a frame or want to display a frame. It would be a long post to go into all the details, so forgive me for oversimplifying. Among many things vital to graphics programming that C and C++ provide that JavaScript doesn't or either fails to do well:

- Control of memory allocations and memory shape/characteristics

- Maximizing cache lines (due to architecture, memory footprint, etc.)

- Multi-threading, concurrency, parallel processing

- Data pipelining

- Predictable execution

- Fast, efficient, correct math (or possibility thereof)

- Compilation tweaking/assembler output tweaking

- Efficient IO

- Fast compression/decompression algorithms

- Integration with existing toolchains for graphics including middleware, apps, and shader languages

JavaScript has made great strides in some of these areas and certainly things like web asm help. Nevertheless, most JavaScript runtimes people are using are wholly unsuitable for professional graphics programming. This is akin to people who used to say that you can write a professional game in BASIC or later, Visual Basic. Yes, it's true you can, but should you do it or start there? Probably not if your goal is to learn professional graphics programming. Have people taken such routes and become awesome programmers? Sure, but there are just as many people who never learn, grow, and develop nasty habits that are harder to unlearn than learning the difficult stuff.

If your goal is having fun and learning a few things before moving on to C++, dabble in some JS graphics programming, but since you called our professional programming as no longer being compelling to start, I have to point out that this is both wrong and bad advice to someone new. If you are struggling with the concepts, you will struggle in any language. If you personally need instant gratification and a self-esteem boost, from this point of view JS might not be bad for learning, but it won't teach you a lot of vital things and will encourage some horrific practices. The presence of GC and the lack of a proper parallel and concurrent programming model poison the experience quite a bit.

Ironically, other languages that are more friendly to parallelism and concurrency tend to be better than C, C++, and JS. A lot of the realities of graphics programming are simply caused by historical reasons, market dominance of things like x86 and companies such as nVidia, and existing knowledge, code, and toolchains. Functional languages for instance in many ways have the potential to be better suited to take advantage of the direction we're headed in with regard to numbers of cores, Moore's Law (or diminishing of), GPU design, memory architecture, and so on, but this is just hypothetical mostly. Given JavaScript is hardly known for its ability to deal with concurrency and parallelism in most contexts (no, nodejs doesn't count), again I have to find the above dubious considering you mention the future WRT nVidia.

Of course in the end, you can use things like transpiling, engines that may or might compile to JS as a runtime target, and so on and getting a running product that might be decent in the eye of the beholder. Personally, I've dabbled in JS enough to write a high-performance Voxel engine many years ago when I thought about making a game in JS as well as a skeleton of a 3D adventure game engine for a contract. I was productive enough but ran up against walls that weren't worth working around or just made things feel so kneecapped that I wondered why I was even using JS at all in its current state. The old adage holds that in the end, you can write anything in any language, but there is indeed value of selecting the best tool for the job. Even just making something run and at a reduced frame rate typically is something fundamentally different than being THE language for graphics programming.

In truth, when I first saw JS in the 90s, I thought there was no way it would reasonably do anything in 3D. Things are getting better, but I think you are dramatically underselling what people use and exists today in a professional environment. Your comment about 400 lines of code being that impressive and small seems to also hint you haven't dabbled that much in the area professionally. While your links are just fine and the above shader toy link is indeed impressive in the context of now, personally I was much more blown away when I dabbled in the demo scene and saw what people were doing with an Atari ST, Amiga, and PCs with no GPUs and on systems with less power than today's fitness trackers.

Anyway, I can't think of many compelling reasons to start in JS when IMO, it's better to learn to do things the proper way even if they can be a bit rough and punishing. JS will surely be more productive at the beginning, but also skip teaching you vital things you need to know as well as some of the fundamental primitives of graphics programming. This is the real world and no one in a professional environment cares if you are awesome in JS but don't understand the tools and best practices people actually use industry-wide. Moreover, you won't get far if you can't be productive from your first day because you tried to take the easy way out. If anything, just comparing the amount of resources for JS vs. C/C++, especially from professional vendors like nVidia, Microsoft, AMD, and so on makes me think at best, JS as a starting language for graphics programming only holds for web programmers. If anything this seems to makes things an extra layer of difficult.

⬐ adamnemecek

Oh yeah I totally meant to get started. There's no way we'll see AAA games written in JS anytime soon. I just remember how long it takes me to setup my environment when I want to do some graphics programming.

However WebGL will outlive JS, when webassembly is introduced.

⬐ optionalparens

Fair enough. Definitely there need to be better resources for getting started in 3D programming, particularly in C/C++, but the barriers to entry are also related to what makes things powerful at a AAA level.

In some ways, just grabbing an engine like Unreal or Unity is a decent alternative to something like JS to learn (some even let you use JS or use other languages that also have traps). Big game engines leave a lot to be desired and at times abstracts too much or makes things like handling shader code annoying. Still, most larger game engines like these two are the closest thing to having LOGO for 3D games programming.

You can at least get stuff on the screen relatively quickly, learn a few things, and then start replacing it from there. I personally learned quite a bit way back when just decompiling or reverse engineering stuff from people much smarter than me.

Sometimes I feel like there's a lack of things like what the C64 provided for younger kids and adults today. I suppose as expectations have risen, so has complexity of getting going.

⬐ brokenmachine

> Sometimes I feel like there's a lack of things like what the C64 provided for younger kids and adults today. I suppose as expectations have risen, so has complexity of getting going.

Although I understand the gist of this statement, I wish I had all the amazing (and cheap!) powerful stuff we have around now to play with when I was young. Also the effect of easy access to information on the internet now cannot be overstated. You can just pull up a youtube video on any subject you might be interested in immediately. It's amazing.

I remember manually typing out pages of C64 code from a magazine to generate a fractal. After typing for literally hours, the actual single fractal picture took hours to generate... Still satisfying in the end to witness it being generated pixel by pixel, but it was surely a lot of work and needed a lot of patience for a kid. Plus if I had mistyped any of that code, it would have been a big disappointment for sure. Kids nowadays have no idea how tough using computers was back then.

⬐ optionalparens

Yes, very true, obviously I just mean conceptually poking around. In many ways we definitely have it better now. I am infinitely more productive today. Simultaneously have gone further from teaching the low-level stuff properly.

I spent hours, days, and weeks of my life on things related to graphics/games programming such as:

- Building mouse drivers from scratch or implementing them from alternative vendors

- Implementing/Working with DOS protected mode

- Manually compressing memory/implementing swapping

- Implementing blitting from scratch

- Implementing z-buffers from scratch

- Reverse engineering consoles to steal processing power from idiotic sources just to render a tiny bit more data or later, a few more polygons

- Spending a huge chunk of cash to throw in a math co-processor into my machine at home

- Debugging code for hours only to realize things like the problems are caused by seemingly unrelated problems such as tape media is at fault, the floppy is corrupt, or the file system doesn't work the way the vendor said it does in the specs

- Rendering a scene and then going home, only to come in the next day and see it is still not done

- Converting from 72 billion formats and interpreting, finding, and/or correcting corrupt data from each one

- Rewriting entire pieces of code bases to squeeze out several more bytes of EMS and XMS

- Implementing 2 or more graphics APIs for the same game. Thank you 3dfx, S3, and many others that pained me, not to mention at a higher-level, OpenGL, DirectX, and so on.

- Doing all my work on 1 platform, then loading it on another. Thank you SGI for taking years off my life.

- Writing matrix operations in pure assembler for the simplest of operations

- Having multiple workstations for reasons such as "this one has the Matrox card in it."

The list goes on. Yeah, I don't miss those days. But I learned a lot, we all did. And the barriers to entry definitely reduced the signal to noise IMO.

⬐ gspetr

You sound like you've had some interesting experiences in the trenches, do you have a blog or something where you share your thoughts about the craft?

⬐ prefect42

Funny that, I've used that exact expression before, with Matrox framegrabbers ;-)

⬐ brokenmachine

There always has been and always will be problems, there are just different problems now...

We can't even imagine what kinds of crazy stuff the next generation will come up with, with all the resources they have available now. The barriers to entry are still there, but the goalposts have moved significantly.

⬐ elcapitan

> # Game Programming Patterns

This is also available on the authors website: http://gameprogrammingpatterns.com/contents.html

⬐ adamnemecek

Added.

⬐ Asooka

Another one that blows my mind, for a completely different reason, is https://www.shadertoy.com/view/MddGzf . That's a simple breakout clone that stores all game data in a separate render buffer. I love that the author managed to implement a game loop in a system that was never designed to support it.

⬐ greggman

I'm going to shamelessly push

http://webglfundamentals.org

⬐ cr0sh

> ...I wouldn't be surprised if in 15 years, instead of AWS, we are using geforce cloud...

NVidia's already there with the hardware:

http://www.nvidia.com/object/nvidia-grid.html

⬐ adamnemecek

And they are building that thing that will let you game in the cloud and stream it to your computer (is there a name for this type of product). There were startups that tried that before that generally failed but fundamentally if you manufacture the platform, sky is the limit. This will let them build out an infrastructure while still selling to the other cloud providers but eventually, they can just start keeping the secret sauce for themselves and their products.

⬐ girvo

LiquidSky is doing it now, and I'm using it as my sole gaming PC. It's amazing.

⬐ prefect42

Thanks for the mention of this, I'm quite interested, looking at their FAQ right now, curious to see how they handle latency. Do you notice any lag? Also, what FPS do you achieve?

⬐ girvo

My ping in Overwatch is 1ms, with 40ms latency to the server from my computer at home. Your bandwidth will determine what your FPS will be, of course!

⬐ prefect42

OK thanks again for the info, now very much worth a serious look.

⬐ ddingus

Marking this for later. I did some graphics in the 00s.

Your JS plus WebGL comments are compelling.

Thanks for a golden comment.

⬐ andrewmcwatters

I would say C more than C++, with the latter only emerging into popularity due to major game engines within the last couple of decades.

⬐ shuntress

"I would say Latin more than English, with the latter only emerging into popularity due to major nations within the last couple of centuries"

⬐ coherentpony

Hmmm. The first official C++ standard was published in 1998, so 'the last couple of decades' covers pretty much the entirety of languages standardised life.

⬐ optionalparens

Now mostly retired, but I've been doing game dev for a couple of decades. I would say based on my career and that of my peers, it is more correct to say C or even assembler is the traditional graphics programming language with regard to games. It just depends on your definition. For that matter, if we consider things like CAD, 3D modeling/animation (using APIs/scripting), movie production, etc. to be graphics programming, again there are some differing results as to which language you use.

It also really depends on what time period we're counting as the "start" and if we value older games or periods of higher but simpler productions vs. now. For instance, I wrote quite a lot of code against NES, SNES, Genesis, Atari, Arcade machines, C64, and so on in assembler. 68000-based systems alone are such a huge chunk of sheer volume of games and most of us wrote quite a bit in pure assembler with regard to graphics.

On other systems that were faster or for different game requirements, we definitely used a ton of C, only moving to C++ later. In the case of C++, it's almost hard to even call things C++ at times. To be honest, most decent game engines I've worked on essentially use C++ to practically rewrite the language and go to great lengths to avoid some of the primary selling points of C++. It's sort of pick and choose some good things about C++ or at least powerful things while avoiding some of the burdens of C with regard to games. Obviously general C++ programming is different, so keep in mind I'm only referring to professional games programming. As things have progressed, people are indeed using more of what the newer C++ standards offer, but most of the same things still hold true. Where one has a tough argument with regard to graphics is the fact that so much now happens on the GPU, which one can argue is its own thing given stuff like shader languages.

⬐ treehau5

Pardon me asking, Is there a way to save comments for later? This is gold, and thank you for the resources. I have been very interested in graphics since I took Computer Graphics in College (It felt like an applied linear algebra course, but I loved it. It was subsequently the only course I felt like I was challenged beyond my abilities -- I had to take the course twice to get the credit, but I loved that class)

Also just kind of asking for curiosity, do you think a language like go or rust will become popular for developing game engines? I realize game programmers are anti-GC but what if GC technology advances that the performance drop is negligible I wonder.

⬐ dang

> Is there a way to save comments for later?

Click on its timestamp to go to its page, then click 'favorite'. Favorite stories and comments are visible from your profile page. Note that these are public, so users can browse each others' favorites.

⬐ groby_b

> do you think a language like go or rust will become popular for developing game engines?

That depends on the type of engine :)

Many games will be perfectly fine in a GC language. (People do write JS games all the time :). But as you approach the limits o

f a devices performance, GC has an overhead that is visible.

You can work around it - there are patterns that essentially work around the collector by recycling objects - but it's quite a bit of engineering effort, and it's a very different style.

But the big issue in GC'ed environments is that you give up control over heap growth. Working with fixed memory budgets becomes a very difficult thing to achieve. And there are few things game developers hate more than unpredictability :)

If you want to look at ongoing efforts, Amethyst is trying in Rust: https://github.com/amethyst/amethyst

⬐ kartD

Tap the time (x mins/hours ago) of the comment you want to favourite. That should take you to a page where you can favourite it

⬐ None

None

⬐ brokenmachine

> Is there a way to save comments for later?

I usually just upvote. You can view your list of upvoted posts/comments in your profile page.

⬐ adamnemecek

Lol, I'm flattered that you think it's worthy of saving. If you upvote it will show up in your profile in upvoted comments. Also, if you click on the date in the header of the comment, a favorite button should appear. When you favorite a comment it will show up in your profile in favorite comments.

> Also just kind of asking for curiosity, do you think a language like go or rust will become popular for developing game engines? I realize game programmers are anti-GC but what if GC technology advances that the performance drop is negligible I wonder.

I think it will but on some level, the needs of a game engine are different from the needs of say a DNS server. Jonathan Blow, the developer behind Braid (http://braid-game.com/) and Witness (http://store.steampowered.com/app/210970/) has been working on a language called Jai https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md even though he's aware of Rust and Go. He talks about some of his reasons in this video https://www.youtube.com/watch?v=TH9VCN6UkyQ

One of the things he mentions is that the game industry doesn't care about security that much (which I didn't realize until then but it makes sense) compared with a DNS server or something so his ideal language might have different design considerations than Rust.

Maybe my expectations are too high, but that's just a collection of random comments loosely related to graphics. It's a terrible introduction, and it doesn't give any concrete information on how to get started.

My advice for people interested in graphics would be to jump in and get started with a tutorial on the web and then get a book or two to learn more. My recommendations would be:

Introduction To Ray Tracing - It focuses on ray tracing, but many of the topics (vectors, matrices, shading, view transforms, etc.) are applicable regardless of the actual rendering method, and it does a good job explaining all of it.

https://www.amazon.com/Introduction-Tracing-Kaufmann-Compute...

Real Time Rendering - This also covers all the math, but focuses on rendering at a higher level and covers more ground.

https://www.amazon.com/Real-Time-Rendering-Third-Tomas-Akeni...

Finally, Computer Graphics: Principles and Practice - This is a great general reference for more specific topics. It's like Real Time Rendering expanded to cover more topics and going into more depth. Not a beginner reference, but great to have when you need more information on something.

https://www.amazon.com/Computer-Graphics-Principles-Practice...

I don't think there's anything quite like Abrash's tome in breadth or all the other intangibles he eloquently wrote about (I mean the best optimizer is between your ears is worth a book in itself!)

Bur for graphics programming, Foley and Van Damm is probably the canonical text - now in 3rd edition. http://www.amazon.com/Computer-Graphics-Principles-Practice-...

⬐ doty

While F&VD does a great job covering many different aspects of image generation, for this kind of work Real-Time Rending[1] is probably more useful. It is firmly grounded in a world of programmable GPUs (shaders & the like), and wastes little time talking about rendering techniques that are not relevant to modern graphics hardware.

[1] http://www.amazon.com/Real-Time-Rendering-Third-Tomas-Akenin...

⬐ benched

Second for Real-Time Rendering. As far as I am aware, it's the closest thing to a foundational book on GPU programming for realtime 3D.

⬐ shadowfox

I have to say that Foley, while a good book, is more of textbook compared to something like the black book.

In any case some of the "GPU Gems" [1] books are worth a read.

[1] Available for free on nvidia' website these days: http://http.developer.nvidia.com/GPUGems/gpugems_part01.html https://developer.nvidia.com/content/gpu-gems-2 https://developer.nvidia.com/content/gpu-gems-3

Hey, glad I was able to give you some useful information! If you ever find yourself in Toronto, say, for an indie game jam (http://www.tojam.ca/home/default.asp hint hint), you can buy me a beer ;)

If you're looking for something lower level, the book you probably want is the white book - Computer Graphics: Principles and Practice. I have the 2nd edition from 1992, which is the still the standard intro graphics textbook for many CS departments. Though Amazon says there will be a 3rd edition coming out at the end of this year!

http://www.amazon.com/Computer-Graphics-Principles-Practice-...

Another highly recommended book (also recommended in another comment here) is Real-Time Rendering, but I've only used bits and pieces from this one, so I don't know how good it is for folks just starting out. Still probably one you'll want to add to your shelf if you continue on in the field.

http://www.amazon.com/Real-Time-Rendering-Tomas-MOller/dp/15...

Oh, and also also, head over to YouTube with some snacks and a drink, sit down, and watch the weekly Overgrowth game developer videos from Wolfire Games. It's both inspirational to see what other people are doing, and a great demo of concepts that you'll read about in GEA, such as animation blending: http://www.youtube.com/playlist?list=PLA17B3FAA1DA374F3&...