Ghosting Images [split from Action function appears broken]

[CeeJay]

The Action keys work now and the previous issue, with them constantly going on and off, appears to have been fixed when I re-bound the keyboard keys. Really weird.

I am experiencing some graphical glitches:

A phantom or ghost copy appears above the real one, in this case the explosion which is PNG-based.

Lastly, the sliding issue is better but it's still there. They don't seem to bounce at all now, they hit the floor and slide for a brief moment.

[ChillyWilly]

The ghost problem is (edit - not due) due to a fix for existing mods in this commit: https://github.com/3dfxdev/hyper3DGE/co ... 760a1cef06

The problem is that modders have a tendancy to make animated sprite frames different sizes when they SHOULD always be the same height. I added code to go through and find the max height of loaded sprite frames and to pad smaller sprites to that size. If it doesn't get caught by that code, any smaller sprites will wind up being wrapped to the full height, which causes the ghost. It could also possibly be that the sprite doesn't scale the actual height to match the stated height. In that case, it would also wrap. In general, make all sprite animations the same dimensions, and make sure that if the actual height is not the same as the stated height (in the ddf) that you set the scale properly to make it match.


The only change to the bounce code was to comment out the random angle generated if a bounce would be inside a wall and make it perpendicular instead. It shouldn't affect bouncing on the floor at all. If this is casings, those are done as corpses, and were modified by this commit: https://github.com/3dfxdev/hyper3DGE/co ... 190b831785

That makes corpses not climb stairs and always have friction. It make be that which is making them not bounce as much.


As to rebinding the keys, I've seen so many Let's Play videos with crazy keys due to things like automap key utilities. It doesn't surprise me that is was some key problem.


EDIT: Here's the commit for what's causing your ghost problem: https://github.com/3dfxdev/hyper3DGE/co ... 3aa8f0e424

The way the rendering system works, images MUST tile! So if the image is not as big as the ddf says it should be, I manually tile the image to the size of the thing so that it tiles properly (that was the bug-fix for animated walls that didn't tile correctly). The solution is make the png as tall as the thing is supposed to be, no matter how little of the png that fills. That will be empty space and compress really well, anyway, so it doesn't matter. Hope that clears up the issue.

[CeeJay]

So you're saying the problem is because the individiual sprites/images in the animation are of different sizes? That is not exactly an uncommon practise.

[Corbachu]

This looks to be an issue with the grAb struct:

From Debug.txt:

W_OpenLump: 4853(BARLA0)
Image_PNG: Got grAb struct: 44/67
W_OpenLump: 4854(BARLB0)
Image_PNG: Got grAb struct: 44/67
W_OpenLump: 4855(BARLC0)
Image_PNG: Got grAb struct: 44/67

Those BARL* sprites correspond with the PNGs in the WAD
that indeed have grab structs.

So, something is not right and we might need additional fudging to
deal with the grab struct support.

[ChillyWilly]

The grAb offset is based on the origin of the sprite being the top left corner. The edge renderer uses the center of the bottom line as the origin so that a default DDF offset of 0,0 renders in the correct position for most sprites. I adjusted the grAb code to adjust for the edge origin, which fixed the Duke It Out barrels. So if you were using PNG+grAb and saw something funny, try again.

Note: Duke It Out also has a logo PNG with a grAb of 0,0, and expects it to render the same as if there was no offset specified. So the code I put in currently assumes that a grAb offset of 0 is assumed to be no offset and isn't adjusted.

[Corbachu]

CeeJay: please test this with one of the latest devbuilds and let me know if anything is still ghosting, but it
should be fixed now!