Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Game Loop

gameprogrammingpatterns.com

Post reply on HN
Print view View original

51–58 of 58 posts

Re: Game Loop

#51

Post by khaledh »

munificent wrote: post #45
khaledh wrote: post #11

While this book seems to get a lot of praise (as it deserves, obviously), I wish the style of teaching complex programming topics walked me through the pain of making something work, exploring a few alternative solutions, showing the tradeoffs, and then after the pain has been experienced by the learner, a proper solution is finally introduced and recommended. IMO it's a much more powerful technique for teaching if y…

Author here. This, I think, one of the fundamental challenges of teaching software architecture or other higher-level engineering topics. A lot of architecture boils down to: 1. Here's an obvious simple way to solve a problem, X. 2. If you do X at scale, much later, you will run into pain. 3. So here's Y, which seems weird and non-obvious but solves the same problem as X without the pain. It's really hard to teach pe…

Thanks Bob, I appreciate your response. To be honest, I haven't read the entire book. However, I looked at the table of contents, and it appeared to be a run-down of well known game design patterns. For someone who wants to get educated on those patterns, that's probably fine. For someone new to the topic of game programming, they're probably going to benefit from the style I described, e.g. hand-holding them in creating a game from scratch, progressively going from simple to complex after understanding the pains along the way, introducing new concepts as needed and just-in-time. So this may have been just an issue of understanding who's the audience of the book.

That being said, the point about doing X at scale wasn't my issue. Take for example programming language books and/or documentation. The typical approach in almost every book/guide is teaching you about syntax, data types, control structures, etc. While this is valuable information, it's not usually what a person new to the language is looking for. What they're looking for is (most probably) what is unique about this language in solving specific domains of problems. New to Erlang? You probably should be introduced to a problem that deals with concurrency and reliability, and get walked through an example of how Erlang can solve it elegantly. New to Python? You should probably be introduced to a problem that deals with manipulating data, and get walked through an example of how Python can help you wrangle data easily. Etc.

> For many of the chapters of the book, I try to walk readers through the problems of simpler approaches as well as I can, but it's a continuing challenge.

Please continue to do so. I'm sure the praise you get for your book is well deserved, and part of the reason is your approach to teaching the patterns.

> There really is no substitute for experience.

Agreed. And part of the teaching style I'm advocating for is making the learner "earn" the skill by showing them the way, not the destination.

Re: Game Loop

#52

Post by cpeterso »

Animats wrote: post #42

Game loop based systems have trouble using more than one CPU effectively. This is a big problem, since we can now get more CPUs, but not faster ones. The audio guys are happy - they can finally get their own CPU, or a big piece of one, and get out of the game loop. (Audio guys liked the Cell. Nobody else did.) The AI guys are usually running on a much slower schedule than the frame rate, so they're OK with this. The…

"Multithreading the Entire Destiny Engine" is a 2015 GDC talk by Bungie's Barry Genova explaining how Bungie turned almost every part of Destiny's engine into a job graph that can be processed in parallel.

https://youtu.be/v2Q_zHG3vqg

Re: Game Loop

#53

Post by bencollier49 »

Back in the days of CRT monitors, you'd wait for a display refresh loop interrupt to fire, and as you knew that the screen refreshed at a particular number of cycles per second, you knew how fast your game would run.

Re: Game Loop

#54

Post by mreome »

munificent wrote: post #47
mreome wrote: post #3

Earlier quoted context omitted.

I love this book as well. I think part of what makes it so good is that the patterns are discussed in a very domain-specific context and their usage is not overly abstracted. I often find it hard to see why a particular "widget" or "foo/bar" pattern or structure is used/useful, but when you put the examples in a very specific context like this, it's much easier to understand their value and remember why/when/how to u…

The secret subtext of my book is that almost all of the patterns are perfectly useful outside of games too. Very few patterns here are specific to games (though "Game Loop" is one of them). Maybe it's just me, but if I'm going to read a few thousand words about some piece of software architecture, I'd rather be reading about trolls and magic than employee record databases.

Thank you very much for all your work on "Game Programming Patterns." It's an amazing resource. I was not aware of "Crafting Interpreters" before now. I can't wait to start digging into it.

I've come across very few Design Patterns, and Software Engineering topics in general, that couldn't be taught/explained from the perspective of game development. I'm surprised that it isn't used as a teaching-tool more often then it is. It's an inherently complex domain that most audiences are already quite familiar with; the "why" behind things is either immediately obvious or easily explained. If someone doesn't know what the requirements are for something like an employee record databases, and how such a system might be used, using that as a context for teaching is not much more useful then "class Widget" and "Foo.Bar()".

Re: Game Loop

#55

Post by munificent »

dullin wrote: post #50
munificent wrote: post #48

Earlier quoted context omitted.

Yes! This article was one of my main inspirations for the chapter.

Speaking of inspirations, looking at the sample PDF on your site, I'm getting some pretty intense Edward Tufte style vibe. Was that intentional?

Oh, yes. <3 Tufte.

Re: Game Loop

#56

Post by rasz »

bencollier49 wrote: post #53

Back in the days of CRT monitors, you'd wait for a display refresh loop interrupt to fire, and as you knew that the screen refreshed at a particular number of cycles per second, you knew how fast your game would run.

Back in the days of CRT monitors and DOS, graphic hardware didnt generate vsync interrupts.

Re: Game Loop

#57

Post by bencollier49 »

rasz wrote: post #56
bencollier49 wrote: post #53

Back in the days of CRT monitors, you'd wait for a display refresh loop interrupt to fire, and as you knew that the screen refreshed at a particular number of cycles per second, you knew how fast your game would run.

Back in the days of CRT monitors and DOS, graphic hardware didnt generate vsync interrupts.

Yes it did. I used to use them to keep my games at the right speed.

Re: Game Loop

#58

Post by rasz »

bencollier49 wrote: post #57
rasz wrote: post #56

Earlier quoted context omitted.

Back in the days of CRT monitors and DOS, graphic hardware didnt generate vsync interrupts.

Yes it did. I used to use them to keep my games at the right speed.

I should of narrowed my statement to VGA under DOS. You had to either manually poll 3dAh, or best case scenario politely ask VESA (SetDisplayStart) to page flip during vsync for you, but even that wasnt always working (for example Quake had a manual switch and treated it as something experimental). Interrupt was a remnant from CGA/EGA standard support, crapshoot on VGA cards.

https://www.vogons.org/viewtopic.php?f=63&t=58445

https://books.google.pl/books?id=gZ5SDTpMR-MC&pg=PA386&lpg=P...

Post reply on HN