undefined | Better HN

0 pointstom_6y ago0 comments

I've written real-time game UIs too. I think you underestimate just how ludicrously fast CPUs and GPUs are, and overestimate the complexity of your average GUI. What does your average screen's-worth of GUI consist of, after all? How many widgets are there? I double dare you to tell me that a modern computer or games console can't handle 500 widgets per frame. And I now triple dare you to tell me that your UI designer has put that many damn widgets on one stupid screen in the first place.

(Every UI I worked on actually did redraw everything every frame anyway. It's really not a big deal. Your average GPU can draw a monstrous amount of stuff, something quite ridiculous, and any sensible game UI that's actually usable will struggle to get anywhere near that limit.)

0 comments

invokestatic6y ago

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?

brann06y ago

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.

revvx6y ago

> 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.

smallnamespace6y ago

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

2 more replies

benj1116y ago

>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.

gmueckl6y ago

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.

1 more reply

tom_OP6y ago

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.)

invokestatic6y ago

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.

1 more reply

j / k navigate · click thread line to collapse

0 comments

invokestatic6y ago

Why settle for "good-enough" performance?

brann06y ago

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

revvx6y ago

> 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.

smallnamespace6y ago

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

2 more replies

benj1116y ago

>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.

gmueckl6y ago

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

1 more reply

tom_OP6y ago

invokestatic6y ago

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!

1 more reply

j / k navigate · click thread line to collapse