arx/ArxLibertatis — comment on commit 727cac0a8ecc21e929b4ce0b9a0bf65eafa9e33b
File:  line 0
By adejr:

this change should be harmless - the memset on the struct/class though is extremely dangerous as it can zero out vtables and destroy constructor-initialized members.

in this particular case i've tested it and it appears "ok". this must be changed in the future though - i believe i'll implement a "zero()" member in the particle-params object.

there is much room for optimization. i believe some spell effects create and initialize particleparams objects on the stack every frame. while that isn't too expensive in isolation, it can add up to being worth a few fps quite easily with many spells/particles. i want to look through the spells in spells_cleanup and optimize them as much as possible.

one possible solution is to create static members. rather than a generic particleparams object, sub-classes could be created with specific init states produced by their constructors. there are two issues. the first issue is that some of the data is not static - positions, vectors, etc. the second issue is that by using static constructors, extra memory will be allocated globally and constructors will be called on application init. this may result in increasing the size of the binaries as well as increased init load.

a practical solution may require redesign - elimination of the generic all-encompassing particleparams object in preference to smaller component parts.