search

adventuregamestudio / ags

AGS editor and engine source code
Other
701 stars 160 forks source link

Small 'flashes' on scene startup on ogl driver #779

Closed i30817 closed 5 years ago

i30817 commented 5 years ago

Basically (this is A tale of Two Kingdoms Deluxe new game, although it happens on other games too, often when restoring a game, not always though - afaict): output

On software the screen stays black until the text displays here. Those objects are objects from the prologue scene that will display 'soon' after that text overlay. This is not really a big deal but it may push some game authors to go with the software driver for something that may end being a minor issue in the end.

ghost commented 5 years ago

At the first guess, looks like it's displaying something during fade out stage.

sonneveld commented 5 years ago

I've seen this with some 256 colour games, it expects the fade out to set the palette to all zeros. But maybe we're accidentally resetting the palette somewhere?

ghost commented 5 years ago

A tale of Two Kingdoms is probably a 32-bit game.

UPD: old one is 16-bit, but I don't have the deluxe version to try.

i30817 commented 5 years ago

I've seen it also on Guard duty when restoring the game on the scene where the knight is down with the worm in the sinkhole. Restoring the game there will flash the horse on the top-left always, even if the ego is on the top-right by then, or the camera down with the knight.

i30817 commented 5 years ago

Here: output

edit: confirmed that on this game on load there is a fadeout in software too, so yes, it's a fadeout bug.

ghost commented 5 years ago

Above issue in Guard's Duty is this bug: #775

i30817 commented 5 years ago

Because the camera doesn't start in the right place right? So isn't it a combination of both bugs (Camera and fadeout not operating correctly)?

Now that i think about it, the author might have been depending on the fadeout to mask the camera bug.

ghost commented 5 years ago

Because the camera doesn't start in the right place right? So isn't it a combination of both bugs (Camera and fadeout not operating correctly)?

The second issue may be only camera bug. I am not sure about ATOTK bug. I dont have that game to test yet, but it could be that they utilize a scrolling room there for intro sequence.

Now that i think about it, the author might have been depending on the fadeout to mask the camera bug.

Cameras were not implemented when these games were made (3.4.1 and earlier), and this bug was added only recently.

ghost commented 5 years ago

@i30817 I've made a pr #804, could you please test both games you mentioned above? I am certain only about second one though.

i30817 commented 5 years ago

They're different bugs then. It fixes guard duty but not ATOTK deluxe

ghost commented 5 years ago

Alright I found what causes the glitch in ATOTK: fb7d8abe8c55cbf0a89bf9aba0c170731aded6f4

Guess there is a moment when the engine thinks that game is faded-out completely and skips rendering GUI or some object that covers the whole screen in their intro. What I don't understand yet, what are these visible objects in such case and why they are being rendered under same conditions. (or vice versa, something is not drawn when the rest is)

ghost commented 5 years ago

So, it seems to me that this is another one case of a mistake in engine's logic that just did not cause any trouble until something else barely related was changed. (Although I am not certain whether this is an ancient or newer mistake, but it has to be introduced before fb7d8ab)

These objects you see in the short blink are "walk-behinds" cut out from the room's background. What I suspect though is that they are not from this exactly room, but remains from some other room that were once cached but not reset yet. Following code is updating these walk-behinds as next game frame is prepared for render, and is relevant to this issue: https://github.com/adventuregamestudio/ags/blob/release-3.5.0/Engine/ac/draw.cpp#L1987

As you may see, there are two branches depending on if (roomBackgroundBmp == nullptr). When in the new room roomBackgroundBmp is null, but tricky thing is that walkBehindsCachedForBgNum == play.bg_frame at the same time. For this latter reason the walk-behinds are not correctly updated during first pass through this function. At least this is what I suspect. When this function is run for the second time it goes into second branch and reupdates them.

Before commit fb7d8ab it seems there was at least 1 preceding rendering pass when play.screen_is_faded_out == 1, and then second one that gathered sprite lists for the fade-in transition (fade-in works with same lists, redrawing them in a loop). After that commit the preceding pass is cancelled early and never gets into this function.

This is as much as I got so far. I think these assumptions may be proven by two methods: 1) call prepare_room_sprites(); twice in a row; 2) make update_walk_behind_images(); be called unconditionally under first branch in prepare_room_sprites.

Either hack seem to fix this issue.

Neither ofcourse is a proper fix, so I will continue investigating.

ghost commented 5 years ago

Sorry for delay, finally pushed a fix: 8b965d794dc717322464400b43e49e8eccf9cfa8

Again, spent more time investigating than fixing, but I really wanted to understand what's going on.

Basically, what is going on there:

This was never noticed before because, it seems, the first frame was always matching "complete fade out" state when whole screen is covered with black surface, so no one could see what's going on.

i30817 commented 5 years ago

It's fixed (i don't consider the mouse cursor showing for a frame a problem i guess).

ghost commented 5 years ago

i don't consider the mouse cursor showing for a frame a problem i guess

Hmm, maybe it's also an oversight, I will check this out.

ghost commented 5 years ago

@i30817 ok, I gave up eventually. Unless I misunderstand what you mean, the only time I was able to see a flashing mouse cursor was when I ran original executable, and it never repeated (I think I ran it for 4-5 times).

Guess that's something different...

i30817 commented 5 years ago

Now that i'm trying it again, i can't reproduce. Super weird.