k8vavoom: no good thing ever dies! (2023, Dec 22 build)

that's not exactly what the code wants i'm afraid. here, for once, they really meant to have a different local, because this is the counter of old threads, it should not overwite a counter passed by user. so i changed it a litte. yet thanks a lot, commited!

tbh, i completely stopped upgrading anything several years ago. because… why? my system works perfectly, i have no new hardware which may require upgrading… so i simply see no reason in doing that.

besides, nvidia stopped releasing 32-bit drivers, and i'm afraid that old drivers will refuse to work with a new kernel.

also, my system is not really Slackware, it is a mishmash, with a lot of things built manually, and many others rebuilt with different configure options. it may be seen as "Slackware derivative" at its current state. ;-) so it's not as simple as upgrade all the packages and call it a day. and i am too lazy. "if it works… DON'T TOUCH IT!" ;-)

we're simply talking about different levels here. ;-)

you're mostly talking about definition, and i am talking about implementation.

in the implementation, models are completely separate from everything other. nowhere in the engine (except the low-level renderer, of course) nothing knows about model existance at all. basically, the renderer simply "intercepts" sprite drawing calls, and replaces sprites with models.

but actor frame is the whole different story. we cannot simply replace sprite frame image at the very last moment, because the engine also uses actor frames to check for various things, including (but not limited to) image translucency, for example. and it does this assuming that frame name always corresponds to the texture, avoid passing the actor pointer around. (at least that is what i remember about the code; the beast is HUGE. ;-) the engine also using frame names to batch actors, so it can use less render calls; there is experimental (not commited) code for dynamic actor texture atlases (which is partially done in BSP traversal), and so on. this will break horribly if i try to replace frame images somewhere along the way.

that was exactly what i thought about: in DECORATE, you can set base texture path for each actor, and the engine will read textures from there, not from SPRITES subdir. yes, frame names will stay the same, but frame images will be different. and that is THE problem: we need 1:1 correspondence between frame name and frame image.

on startup, for example, the engine scans all available sprite frames to build various tables (rotations, etc.). at this stage, no actors are loaded yet, so the scanner doesn't know about frame overrides. and even if it will know that, rotation info may be wrong due to conflicts (override has more than 8 rotations defined, but base textures defines only 8, for exampe). and rotation table is global for all actors (we need it to be that way).

there are other places where the engine doesn't except sprite frame images to suddenly change too.

so it's not only about substituring one texture with another on rendering (which works for models). properly implementing such feature will require several major redesigns of various engine parts. that's why this proposal was rejected in GZDoom, for example: they faced the same set of problems.

so i have to think hard about new designs for this feature. because i don't want to sacrifice engine performance (and it heavily depends on some immutable info pregenerated on startup), and don't want to turn the code into unmaintainable mess too.