ZDoom

In this case the defined animation sequence goes one frame further than the defined sprites. Without the hack you'd see the empty sprite being drawn.

Graf Zahl wrote:What we have here is a classic case of sloppy design. The lackluster syntax of actor animations in CON apparently led to some errors which this hack was supposed to patch over.
And my refactoring of the texture code just revealed its existence. The hack is still there but it now does a check for texture validity that is compatible with the backend.

So if I get that right, the underlying problem is otherwise not fixable then, without reworking some things in CON itself maybe?

What we have here is a classic case of sloppy design. The lackluster syntax of actor animations in CON apparently led to some errors which this hack was supposed to patch over.
And my refactoring of the texture code just revealed its existence. The hack is still there but it now does a check for texture validity that is compatible with the backend.

I like how it's so neatly advertised as a hack though , for some reason it's hilarious, though I've seen similar instances in plenty of code. Reminds me of some old commits by nuke in NBlood which were directly advertised as "ugly hacks" when they got tossed in.

The good thing here is that the migration also managed to reveal some bad design choices that can now be finally rectified, and I'm quite happy with how nicely things are looking now after the migration, with this issue and the few others that came with it, notably the screen spasm and the drawing of 2D elements fixed, I am quite pleased with what we've managed to achieve <3. But a few still remain - the palette needs to be reintroduced, and the screenshots in Blood still don't show the sprites.

But it also, somehow, made some issues less pronounced. Like I said, so far I've not managed to see the wallsprites flicker in Blood in spots where they used to flicker like crazy before. Makes me wonder why.

And regarding this issue with the actors, would there be some other underlying problems that need to be corrected here as well, or was that all? I wonder if this was not a workaround that was added as a measure against a bigger problem that never saw a proper fix, and now something else got exposed as a result?

It does try to render a non-existent sprite for the Coot - but I have no idea why the old code did not flicker.

EDIT: Behold this little piece of beauty:
The only problem here: Testing for zero size as hint for an invalid texture does not work with GZDoom's texture code. But this clearly hints at very dumb game design that such a hack was added to the engine to patch over some actor definition errors.

mjr4077au wrote:I've genuinely never noticed it before but if it happens, it happens. I've only recently moved to a 144Hz monitor at home (last 4 weeks), so maybe I'll notice it when I am home on the weekend (on the work laptop until then). If that commit isn't causing it, it's definitely exasperating it.

Can second this. Prior to the backend changes, if it was there, it was a lot more subtle and I never managed to truly notice it as a result, so I am fairly convinced that well, if the changes didn't cause, they've definitely made it a lot worse to the point it's now impossible not to observe.

I've genuinely never noticed it before but if it happens, it happens. I've only recently moved to a 144Hz monitor at home (last 4 weeks), so maybe I'll notice it when I am home on the weekend (on the work laptop until then). If that commit isn't causing it, it's definitely exasperating it.

The Coot has been flickering for me long before that commit, it has basically been there right from the start. I won't rule out that it may have gotten worse, but it's definitely older.

c4017de12ff6dc8eac11d1abc3a2e95d454e83c9 is the one that breaks the coot. Not sure about other enemies that lowskill has noticed.

Annoyingly, it's another monster commit...

Graf Zahl wrote:The medikit is more likely some failed visibility checks and unrelated to the Coot. With Coot it looks like some frames are simply missing.

I haven't noticed it before though. I'll do some investigating this week with some of the other reported issues I wanted to bisect such as the Powerslave sparkle not working anymore, etc.

Graf Zahl wrote:The medikit is more likely some failed visibility checks and unrelated to the Coot. With Coot it looks like some frames are simply missing.

Perhaps, I tried to trigger it with pickups/powerups but didn't manage to do it again. Your theory sounds more reasonable though since this is a lot more frequent - and plain different.

I've investigated the enemies further in Duke in the meantime, to see who exactly is addicted to flickering, and I can say that, apart from the bosses and by the looks of it, Slimers and Sentry Drones, it happens with virtually all enemies. Commanders, Assault Commanders, Pig Cops, Enforcers, Pig Cops driving tanks, Octobrains, Protector Drones, etc. But with the bosses (even the mini Battlelords) it either doesn't happen at all, or it's a lot more difficult to trigger, as I've had no such luck with them. I've not seen it happen on Mickey Mouse and the babes either, though those aren't enemies, of course.

The medikit is more likely some failed visibility checks and unrelated to the Coot. With Coot it looks like some frames are simply missing.

Graf Zahl wrote:The coot seems to be a bit broken - this is something I've been noticing ever since I started working on this code. To me it looks like it references undefined animation frames - no idea if this is a bug in the game data or something in the game logic.
Which other enemies have this problem?

Can't say 100% sure, potentially more than just 2 for sure.

But, for now I've seen it primarily happening with Pig Cops and Commanders in Duke since it's more difficult to trigger with other enemies. It's also not just enemies, when the flickering occurs I think I spotted some Medikits temporarily disappearing on E1L2 in the blue key room as well.

The coot seems to be a bit broken - this is something I've been noticing ever since I started working on this code. To me it looks like it references undefined animation frames - no idea if this is a bug in the game data or something in the game logic.
Which other enemies have this problem?

mjr4077au wrote:Confirming lowskill is not just seeing things . Noticed this in Redneck Rampage with the skinny old coot across the road from the spawn point while circle strafing him.

In which case, this also confirms the fact that it's probably some EDuke32 brokenness.

Tried to reproduce this real hard in Blood and SW as well, and I get nothing there. Can't be a coincidence that it happens only in these 2 games .