[4.3.5.X/3.2.X] Black beam traces have returned

[Eizzoux]

Somewhere around 4.3.4.X versions one certain bug was sorta fixed - black traces which beam leave on some objects like grids and mirrors, these tiny black pixels that chop out some parts of game graphics until the elements themselves are forced to update. But in both 4.3.5.0 and 4.3.5.1, that bug is back and leaves these traces once again. I'll assume some bug fixes forced that bug back into the game, or rather some kind of bug was sort of retrieved as a sacrifice to fix some other bug, I don't know. But it is back.

ksfkhskdhksdhs.png (49.74 KiB) Viewed 6058 times

Again, you can try that out in Reflektor for especially visible effect because of MM grid replacements (even though vanilla game pretty much has these tiny visual cutoffs with DF mirrors... actually, we already mentioned that years ago, yeah...)

[Holger]

Indeed, you're right. :-/

In version 4.3.4.0 (more or less by accident), every single tile on the playfield gets redrawn in each and every frame (which was very noticeable when mass-replaying tapes using "autotest", even though this mode operates in headless state and does not redraw anything at all, but still has to walk through all the drawing code, even if the final bitmap blitting is skipped).

So this fixed the existing graphical glitches you have noticed -- but this only really affected the one-pixel corners like it can be seen for the DF style mirrors as shown in your screenshot. However, the DF style grid is another story -- the game engine (unfortunately?) knowns exactly how that grid looks like, and does not treat it like a rectangular block! That's why the laser is able to enter such a diagonal grid (that can only fully be passed in an 45° angle) also from 90° corners -- but only for a few pixels, until it hits the grid. For graphically redesigned grids (like in your case), the laser just behaves the same, and does not redraw what it "thinks" it hasn't even touched.

But this has to be fixed, of course (also the cut corners are not really acceptable).

I will modify the code so that every tile that was touched by the laser by at least one pixel (be it black or not in the original artwork set) will be redrawn when the laser is removed again.

[Eizzoux]

In version 4.3.4.0 (more or less by accident), every single tile on the playfield gets redrawn in each and every frame (which was very noticeable when mass-replaying tapes using "autotest", even though this mode operates in headless state and does not redraw anything at all, but still has to walk through all the drawing code, even if the final bitmap blitting is skipped).

So this fixed the existing graphical glitches you have noticed -- but this only really affected the one-pixel corners like it can be seen for the DF style mirrors as shown in your screenshot. However, the DF style grid is another story -- the game engine (unfortunately?) knowns exactly how that grid looks like, and does not treat it like a rectangular block! That's why the laser is able to enter such a diagonal grid (that can only fully be passed in an 45° angle) also from 90° corners -- but only for a few pixels, until it hits the grid. For graphically redesigned grids (like in your case), the laser just behaves the same, and does not redraw what it "thinks" it hasn't even touched.

I think that also explains the envelope border graphic staying on the screen after closing. Before that, game was updating elements every frame, so envelope's graphic gets overwritten as soon as the gameplay continues. But afterwards, closing the envelope causes the game to not update graphics in that area, so, of course, the little border in the middle just stays before getting erased by the beam or forcing the elements underneath to update.

[Holger]

I think that also explains the envelope border graphic staying on the screen after closing. Before that, game was updating elements every frame, so envelope's graphic gets overwritten as soon as the gameplay continues. But afterwards, closing the envelope causes the game to not update graphics in that area, so, of course, the little border in the middle just stays before getting erased by the beam or forcing the elements underneath to update.

I really wondered why I could have overseen this problem (graphical artifacts of closing envelope), but this is the exact explanation! Thanks!

If I could only create unit tests for such things, but apparently this is not really (at least not easily) possible.

BTW: The "black beam artifacts" have been fixed now, too!

[Eizzoux]

Funnily enough, I actually found out a funny manual workaround for myself.
Since the animated elements are updating the entire tile, then I can animate all static elements by adding two lines:
".frames: 2" and ".offset: 0"
For example:

Code: Select all

mm_wooden_grid_fixed_2:		file.png
mm_wooden_grid_fixed_2.xpos:	0
mm_wooden_grid_fixed_2.ypos:	0
mm_wooden_grid_fixed_2.frames:	2
mm_wooden_grid_fixed_2.offset:	0
# Two frames to force the game to animate element between two frames.
# The offset between these elements is 0, which means these frames will be identical, but yet still updating every frame.

The exception is that the animation isn't working for some things like mini tile walls, they just don't animate at all.

[Holger]

That's really a nasty kludge that works, but should not be used at all!

The problem should be fixed with the next patch release coming soon.

[Holger]

All fixed now!