Quakespasm 0.85.1 vs. 0.85.8

[Baker]

[Baker]

Just want to say, this is so entirely cleaned-up in source code. I don't mean "looks nice". I mean, function prototypes where they should go. All the network files have been made "right". Almost every proper cleanup angle you could think of (gcc warnings, no externs except for the headers almost entirely, string safety, const char* where that should be, #define XYZ type definitions gone in favor of "sizeof(blah)/sizeof(blah[0])", everything "filed" in the right header) and it actually changes no functionality in doing so. Unloved source files fixed up and modernized. Uses the right way to multiplatform everything.

And the functionality is unchanged, a true cleanup.

This had to be about 1000 hours of cleanups. And the quality and expertise of the cleanups are astonishing and almost robotically correct in precision and full understanding of all the C and platforms "rules".

[szo]

[Baker]

[Spike]

the issue with dynamic lightmap updates is that you end up with something like:
1 draw surface
2 update lightmap
3 draw surface
4 update lightmap
etc.

if the update lightmap step is implemented as:
1 wait for texture to no longer be in use
2 replace the subregion
3 return to caller
then you're waiting for each and every draw call individually.
note that if the driver ignores order coherancy (3dfx...) then there's no massive issue here. but drivers that do things properly either need to wait as above, or copy the entire updated subregion to some thread in order to update in sync with the graphics card. if the card has no support for that then there's no choice but to wait. alternatively, the driver can orphan the existing texture such that the hardware sees a completely new texture allowing it to destroy the orphaned texture when its finally no longer active. but that's the sort of optimisations nvidia would do, and not anyone else.
you have the same issues in opengles, except more extreeme.

so animating your lightstyles and updating them in bulk at the start of the frame avoids the excess memcpys or waits, and you get significantly higher framerates in such situations.

[Baker]

[szo]

[Baker]

[Baker]

[Baker]