Sangman, on 10 February 2020 - 06:44 AM, said:
Is it possible to detect if the player has a given tilenumber in view? The way I was thinking of doing it was to do a hitscan check from every pixel covering the player's view, but that sounds entirely ridiculous.Still, we have some functions like ifcansee that work against actors. I probably need that but for textures.edit:Apparently this is exposed via the gotpic array in CON.ife gotpic[tilenum] 1 => means that tilenum is currently visibleThe array doesn't reset on its own (there is an EVENT_RESETGOTPICS but from what I can tell from the source code, this only gets called when handling mirrors), but you can do so manually inside your code bock:setarray gotpic[tilenum] 0So far performance seems okCredit to Mblackwell for letting me know
I'm working on a few performance related things and just want to corroborate this behavior, and I'm not sure if this is a bug in the implementation of EVENT_RESETGOTPICS or if this event is explicitly meant to function only with mirrors. Based on the description and comments in the source code, I assumed it would fire every frame after EVENT_DISPLAYROOMS, but it only seems to be fired when mirror rendering logic is happening. So if you want to reset the gotpic array independent of mirror logic, it seems to be safest to do in a DISPLAYROOMS event after all other DISPLAYROOMS events have been executed, or in any other event that runs after DISPLAYROOMS.
Danukem, on 10 February 2020 - 09:44 AM, said:
Interesting. So what exactly causes the elements to get set? For example, if a certain enemy dies in a place where no players are around, is its dead body tile "in view"? Or does it require that the tile is actually rendered on a screen?
Based on a quick test using the above info, sprites are rendered (or at least, inserted into the gotpic array) even if they are not explicitly on screen, based on A.) if the sprite's sector is being rendered
AND B.) if the sprite is within the player's field of vision. Using the example image below, if the player were in the top left of each U, the sprite on the left room would always be rendered no matter where the player is located, as long as the player is facing in its direction, even though the walls block it from being seen. But the sprite in the right room would never be rendered until the player gets in the bottom left corner sector, at which point the sprite's sector begins to be rendered and it begins to follow those rules.
Basically, if you understand how sector rendering is performed, any sprite in a rendered sector will always be drawn if the sprite's location is within the player's field of vision, even if walls block it from being seen. One-way mask walls would presumably prevent this as they function as white walls during rendering, although I didn't test this here.