cgame/cg_marks: process all impact marks at once

[illwieckz]

For now, it doesn't bring performance improvement, but the loop calling trap_CM_MarkFragments for every impact mark can be rewritten to only process data that would be fetched in a single call by a future trap_CM_MarkFragmentsArray before entering the loop.

This patch is what I talked about in #846:

• Optimizing trap calls and giving extra 200 fps to anyone DaemonEngine/Daemon#846 (comment)

The next performance glutton is trap_CM_MarkFragments, and then after that, trap_R_AddPolyToScene. They're both called by CG_ImpactMark. The cgame calls CG_ImpactMark each time it want's to add a mark. I have a patch that turns CG_ImpactMark into CG_RegisterImpactMark (it just stores the data to be processed later), then at the end of CG_DrawActiveFrame I call a new CG_ProcessImpactMarks function that processes all those registered impact marks. For now this can't bring any performance improvement since it just iterates the registered impact marks and calls trap_CM_MarkFragments the same way as before, but this will allow us to rewrite trap_CM_MarkFragments to send a whole array of impact marks at once. This last part (sending and receiving arrays of such data) isn't an easy task unfortunately, so I make a pause in my development for now.

This is a preparatory work, as the trap_CM_MarkFragmentsArray function is not implemented yet, but this code is required to be able to use trap_CM_MarkFragmentsArray once implemented.

Unlike any implementation of trap_CM_MarkFragmentsArray, this code doesn't break engine compatibility.

The purpose of this code is to defer the calling of CG_ProcessImpactMarks to a place where all impact marks are processed at once (this is implemented), allowing us to also fetch all mark fragments at once (this is not implemented yet).

I'm not available to implement trap_CM_MarkFragmentsArray and I have not been since May, but if we merge this it becomes possible to others to implement it instead of waiting on me.

[illwieckz]

@DolceTriade, can you investigate an implementation of trap_CM_MarkFragmentsArray? I tried once but I lack knowledge about some C++ wizardry and I don't know how to implement a trap call that would request such array of data.

There are people in the team I believe are much more skilled than me to do this and who already possess the required knowledge and experience to do this task, including you and @slipher. I believe @slipher is already busy on many other things so if you can help on that part that would be a precious help. I assume the time required for you to implement this function would be incredibly fast compared to me.

One may say it would be the opportunity for me to learn new things, but I don't want to delay this more and I don't want to make “illwieckz should learn how to do that” a blocking condition for implementing this. Also, all the time spent on that task would remove me from other tasks I would be more efficient and productive at doing.

As reported in #2663:

• Creep performance cost #2663 (comment)

Disabling marks on some alien base scene (like default plat23 alien base) increases my framerate from 470 fps to 780 fps. I expect the same performance boost would happen once trap_CM_MarkFragmentsArray is implemented, but without disabling marks. One can say 400 fps is far from enough, but let's imagine what that could bring to a low-end machine struggling to achieve 30 fps to get the framerate multiplied by 1.7? This would reach a comfortable 50 fps.

[slipher]

The most ideal would be to just implement MarkFragments in the cgame (or in the CM lib which is in the Daemon repo but linked into the gamelogic). The CM data structures ought to have all the things that are needed.

[illwieckz]

The most ideal would be to just implement MarkFragments in the cgame (or in the CM lib which is in the Daemon repo but linked into the gamelogic). The CM data structures ought to have all the things that are needed.

If that's possible that would be perfect. We better want to avoid all those costly traps! I have no idea about how to implement that anyway…