4 ms·
Games typically need to redraw the entire screen anyways. Imagine a sidescroller where even a 1px movement requires the entire background and every object on to
by Rotten194 7y ago
Games typically need to redraw the entire screen anyways. Imagine a sidescroller where even a 1px movement requires the entire background and every object on top to be redrawn, or in 3D even a tiny camera move shifts the position of every triangle on the screen. Even very simple games without a lot of movement often have animations, where you then have to worry about transparency so you may have to redraw the region under the animated element anyways even of it doesn't move, etc. You could do a diff hoping for the happy occasion of a mostly-static frame, but a) that gives a performance penalty to the majority of frames that would need a total or near-total redraw anyways, and b) would lead to either unstable FPS or pointlessly hitting the FPS cap.
There are exceptions to this, for example a visual novel or a turn-based strategy game, but those are often satisfied to just eat the performance penalty for the ability to use standard tooling, or can use engines or standard UI toolkits like React that can do a temporal diff. For example, I've written several text-based games [1] that just use the DOM because using canvas or WebGL wasn't necessary. I've written other games that use a hybrid approach of absolutely-positioning temporally diffed DOM over a frame-by-frame redrawn canvas, to get the best of both worlds [2]. And I've also written games in e.g. Unity where it's easier and performant enough to use ImGui and redraw it every frame. Ultimately it cones down to what's practical and what's performant enough.
[1] https://vgel.itch.io/themengi https://vgel.itch.io/themengi , https://vgel.itch.io/the-sacred-text https://vgel.itch.io/the-sacred-text
[2] https://vgel.me/hoverator https://vgel.me/hoverator
- aliswe 7y agoBut 2D sidescrollers have traditionally just "paned" the already drawn/rendered (buffer?) and only redraws the new bits. In some cases this caused artifacts to stick to the screen. Specifically thos was not unheard of regarding games made with KnP, TGF and MMF. I guess this was before HWA, though.
- victorNicollet 7y agoThere used to be a time when the game would render to a buffer slightly larger than the screen, then blit the right portion of that buffer to the screen. This meant that scrolling just consisted in blitting from a different offset. Composing the background image, then, would only require changing the bits behind animated sprites (so you would usually intersect the old and new position of each sprite with the background tile grid to find which tiles to draw again). All of this changed with the advent of 3d hardware acceleration, but I remember doing it up until 2005 to get significant performance gains (on bad hardware).
- elif 7y agoI guess my understanding of an HTML canvas is that it takes less work to "translate these 1000 objects 5 pixels left" than "draw these 1000 objects" e.g. mozilla's tips for canvas performance state: "Avoid unnecessary canvas state changes." And: "Render screen differences only, not the whole new state." https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Tutorial/Optimizing_canvas https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/...