Hacker News Reader

Comment by invokestatic | Hacker News Reader

I'm sure many games can get away very well with an immediate mode GUI. I think the question is not can you, but rather should you. My last project used a custom immediate-mode GUI. At the absolute pinnacle of optimization, it was pushing 2,000+ FPS on my machine with something like 3-4k vertices, with heavy texture mapping and anti-aliasing. But the problem was that even with peak optimization, the CPU was spending 15-20% of its time every frame recreating the UI's vertex buffer. Now imagine if we had done a retained-mode GUI instead. That 15-20% overhead would be reduced to near 0% on a typical frame. For nearly any type of game, that kind of savings is really significant. Think of how many more vertices your artists can add, or cool gameplay elements you can add that you didn't have the CPU time available before, and how much better it will run on lower-end hardware.

Why settle for "good-enough" performance?

View on HN

Performance is not the only consideration, even in most demanding games. IM GUIs simplify UI code a lot, by not having to rely on message systems that make the code harder to follow and less predictable.

As most things in life, it's a matter of trade-offs.

> The CPU was spending 15-20% of its time every frame recreating the UI's vertex buffer.

Not saying it is easy, but it's possible to optimize and cache vertex buffers by using something similar to React's VDOM.

Doesn't your cache just become a limited retained mode with a somewhat hacky, opaque API?

Basically yes. If an immediate mode API is much easier to use, and a retained mode underlying implementation has much better performance, then putting a React-style VDOM layer in-between could get the best of both worlds, depending on how well the middle layer is implemented.

>Why settle for "good-enough" performance?

Because its good enough? Perfection is the enemy good.

I can't see 2000 FPS, 60 FPS is good enough for me. Similarly the 20% vertex buffer hit might not matter.

The catch is that games follow the law of "MOAR!": more details, more effects, more postprocessing, mpre abimation, more simulation... this means that the engine will almost always be pushed to max out the hardware long before the designers are happy with what they have.

Heck, I can think of pretty easy ways to improve sound and video quality of games in ways that are quite fundamental, but that would easily max out the best gaming rigs with either sound or graphics alone.

Bottom line: the need to optimize always comes sooner than you would expect.

Perhaps you're right. As you can probably tell from my prior comment, I don't really subscribe to the 'MOAR' philosophy.

I don't understand the problem. 2000Hz = 0.5ms/frame; 20% of this = 0.1ms. That sounds like a great result. Your target frame rate is presumably 60-100Hz, assuming it's a PC game, meaning your frame budget is 10-16ms. If your UI takes 0.1ms, you've got >99% of your budget left.

(Also: 3-4K vertices for UI was about what you could expect to budget for a PS2 or Xbox game! - max throughput for PS2 was something like 250,000 vertices/frame at 60Hz, and this is <2% of that. I struggle to believe this is any kind of an issue for anything modern.)

I should mention that 2000 Hz when only running the UI -- with the full game running at 150 FPS. So really the CPU time is 6.66ms*0.2 = 1.33 ms just for the UI!

Of course, that's on my beefy machine with a octo-core overclocked CPU and a couple 1080Tis. But what about the players who are trying to play on their mobile CPUs with integrated graphics? That margin could be the difference between 45 and 60 FPS.

This is wrong, just because it uses 20% CPU when rendering at 2000Hz doesn't mean it will consume 20% CPU when running the game too. Running the game alongside the UI is what makes it drop to 150FPS from 2000FPS. So if the UI consumes the 20% of the frame time at 2000FPS, that is indeed 0.1ms and this number will not magically increase when you add the game. So when you're running at 150FPS your frame time is 6.66ms and you're using 0.1 for the UI. That seems pretty good for me to be honest.

Reply on news.ycombinator.com