[RESOLVED] Tile cursor renders over global animations

[TheOnyxGuy]

Intentional or not, but the 'global.tile_cursor' graphic seems to be drawn over even the pointer global anims.

asdkasbdjasd.png (37.97 KiB) Viewed 71122 times

[amirnatsheh7]

red_orb_by_kayosa_stock_d9c80hn.png (427 Bytes) Viewed 71024 times

hmmmm interesting levelsets, but they tile laser goes like that from animations on rnd?

[TheOnyxGuy]

I'm sorry but I even after reading your message ten times I don't understand what you mean. Could you explain, somehow?

[amirnatsheh7]

maybe

[Holger]

Intentional or not, but the 'global.tile_cursor' graphic seems to be drawn over even the pointer global anims.

It's definitely not intentional!

In fact, the tile cursor is drawn above all other global animations, and as the pointer is just a special type of global animation, the tile cursor (which is handled differently and somehow "special") is drawn also above the pointer.

But this does not look right, of course. Maybe the easiest solution is to just draw the tile cursor first, then draw all other global animations (including the tile cursor, which is only used for the MirrorMagic game engine anyway).

I have thought about this a little bit, and the case seems to be clear for the global animation marked as being a "pointer" (that is, draw it above everything else), but is maybe not as clear for the tile cursor: Draw it (directly) over the playfield (of course), but under all other global animations? This may depend somehow on how those global animations are used. If they have a more or less decorative character on the screen (like the notorious "toons"), tile curser at lowest drawing level probably makes sense.If some global animations are used to look like being some static part of the playfield, the tile cursor propably should be drawn above these global anims.

So, maybe I will have to extend the tile cursor to properly support the "draw_order" attribute some day...

Update: Fixing this issue was easier than I thought it would be.

Global animations are now drawn in the following order:
- draw all global animations below screen border (class "playfield", "door_1" or "door_2")
- draw screen border
- draw all global animations above screen border (class "window" or "border", which is the same)
- draw tile selection cursor
- draw mouse pointer global animation (class "pointer")

That should do it!

[TheOnyxGuy]

That also reminds me, this one probably can't really be prevented because of cursor's "global anim" kind of nature, but cursor also can render over request and envelopes.

ssghdasgdsfdsd.png (115.91 KiB) Viewed 70539 times

[amirnatsheh7]

oh you working in your WIP?, Very nice

[Holger]

That also reminds me, this one probably can't really be prevented because of cursor's "global anim" kind of nature, but cursor also can render over request and envelopes.

This can be prevented by using the line "request.draw_order: 1" in your "graphicsinfo.conf" file, causing the request dialog to be drawn over global animations (and therefore also over the tile cursor).

As this really does not work well at all (as it does not respect any global animation's draw order besides the above special case, that is, it does not allow for drawing some global animations below the request and some above), I decided to remove this graphics configuration directive and always draw the request dialog on top of all global animations, which is probably the expected result in most cases anyway.

[TheOnyxGuy]

As this really does not work well at all (as it does not respect any global animation's draw order besides the above special case, that is, it does not allow for drawing some global animations below the request and some above), I decided to remove this graphics configuration directive and always draw the request dialog on top of all global animations, which is probably the expected result in most cases anyway.

Yeah, the request on top of animations seems like overall a better idea. But there's still one tiny problem which I sorta currently have (although it's not really that major). Request window still passes the global anim clicks through itself. In my case, I have custom anims acting like menu buttons, and they have the usual 'stand by' anim which awaits for inputs (part_1) and the one after you click (.part_2), which redirects you to respective screen on '.anim_delay_action: main.button.(whatever)'. And when I click on request buttons or just overall on the window itself, I see the animation below changing and trying to move to another screen with no success.

And also that reminds me, there's a little nish thing with the timing of global anim behavior which you can see, for example, in this levelset. If you have a global anim located in playfield (or in window but above the playfield) and has '.anim_event_action: XK_Escape' specifically on click in editor or another sub-screen, clicking on the anim will also buffer the click for the next screen and will most likely click on whatever button is on the same spot as the global anim click.

In short, just try entering the editor in levelset I mentioned and try clicking on the spots where the menu buttons are usually located (because the entire editor is just covered with one large anim which presses Esc on click), and the anim will most likely 'double-click' for you.

[TheOnyxGuy]

Speaking of request window, I got another bug which might be possibly result of you changing render priorities of it over global anims and tile cursor. In short, I recently realized that my request window in RF is not masked because I forgot to add 'background.request.draw_masked: true' line. But now because I added the mask for the request window, it just doesn't render. At least it seems like it's not rendering until you try to feel your way over to the request buttons, because they do render, except they're hidden until you click on them. I assume the issue is that the game rather doesn't really know how to properly render masked request window making it invisible or maybe renders it below everything else including the playfield.
I don't really have to send you any kind of testing levelsets for that, you can just try that out in most recent RF demo, since I haven't changed anything in it for a while (let alone upload any demos, oops).

[Holger]

Thanks for reporting this bug which I was easily able to reproduce. In fact, this bug must be quite old, as I could not find an older version where this worked. Apparently this does not work anymore since I introduced using textures to display the request dialog, which apparently was quite some time ago.

I have already fixed this bug, so transparent (masked) request dialogs should work now just using the config line in the example you mentioned (that is, using "background.request.draw_masked: true"). The new version containing this patch should be released very soon!

As an additional bonus, the next version will also contain simple alpha value support for global animations, and also for the request dialog. That is, when using "background.request.alpha: 192", the request dialog will have some transparency now (using "0" for full transparency and "255" for full opaqueness).

When doing these changes, I also added a few more fixes for the envelope style request dialog for the "Play again?" dialog after losing a game: The game engine now does not stop while opening or closing the request, and game actions will also be visible through the transparent or masked request window. Just try it out with the next version.

Regarding the "buffered" (or wrongly passed) click events, I still have to investigate this...

[TheOnyxGuy]

As an additional bonus, the next version will also contain simple alpha value support for global animations, and also for the request dialog. That is, when using "background.request.alpha: 192", the request dialog will have some transparency now (using "0" for full transparency and "255" for full opaqueness).

Oh neat! That's one of ideas I as well had in mind.
Just out of curiosity, how well does it work with both '.draw_masked:' parameters?

[Holger]

Just out of curiosity, how well does it work with both '.draw_masked:' parameters?

You mean, using both ".draw_masked" and ".alpha"? Works just as expected!

[TheOnyxGuy]

Well, kinda, I meant with both '.draw_masked: false' and 'draw_masked: true'.

[Holger]

Well, kinda, I meant with both '.draw_masked: false' and 'draw_masked: true'.

Yes, works with both settings.