0000853: Transition effects should be implemented

(0005508)
SXX (administrator)
2015-02-15 07:38

Assign it to @Fay so this can be closed eventually:
https://github.com/vcmi/vcmi/pull/84 [^]

Though not everything implemented in this pull request, but most.

(0005532)
Fay (developer)
2015-02-16 20:33

Window fading (town screen, battle, etc.) would need to be implemented as CIntObject fading in CGuiHandler. I might look into it later, but haven't tried to mess with it yet.

(0005545)
Fay (developer)
2015-02-18 22:13
edited on: 2015-02-18 22:22

Okaaay, fading CIntObjects will be tricky.
Normal open/close case is quite straightforward, but for example pressing another town when already in CCastleInterface view causes popInt and immediately after that another pushInt. Currently not sure how to handle it.

Edit ~ maybe this case will need new way to add int to gui handler -- to swap current view with given one, instead of removing one and adding another separately. I probably could crossfade between them.

(0005548)
Fay (developer)
2015-02-19 21:50

I made something that [probably] works correctly, but it feels very hacky and I'm not really sure I want to upload it. ;)

Crossfading castle interfaces is very tricky, because they have to be destroyed/recreated in exact order because of global changes in ctor/dtor. Which means I can't cache them for the duration of fade, nor start the "swap" in one method (because that would create the new interface before destroying previous one, and it breaks the game).

Additionally, it's not "fade to black" (as in report description), but alpha fading. I think that fading to black makes no sense for bigger resolutions, as windows don't take whole screen and it would look rather bad.

(0005549)
SXX (administrator)
2015-02-20 00:17

You can always upload it without pull request.

Though can't you like use "cached" bitmaps for fading when it's full screen windows so it's will be independent of how the code works in particular case?

(0005550)
SXX (administrator)
2015-02-20 00:29

And yeah I understand it's may not looks that good due to lack of animation, but may be it's won't be too bad for some screens.

(0005551)
Fay (developer)
2015-02-20 08:32

Yes, I've done this with a cache bitmap.
The logic would be pretty simple for normal fade-in/fade-out (e.g. battle screen). However when we switch between town views (pressing another town when castle interface is visible), there are simultaneous pop+push and it looks bad (especially on 800x600). That's why I've done this case differently and it looks better but is rather hacky.

I guess I can upload it today.

(0005557)
Fay (developer)
2015-02-21 10:18

I uploaded it here: https://github.com/Fayth/vcmi/tree/feature/fadingIntObjects [^]

(0005558)
SXX (administrator)
2015-02-21 13:56

Thanks. Hopefully will have time to test it today or tomorrow. :-)

(0005565)
SXX (administrator)
2015-02-22 10:03
edited on: 2015-02-22 10:03

Interesting. Screens changing looks good, but I notice there is some lag appear.
Though I'm not sure if it's not my fail (I test it with my pathfinding branch).

Can your code affect non-fullscreen modal windows?

(0005566)
Fay (developer)
2015-02-22 10:56

Yes, I noticed some lags during fades. Not really noticable at 800x600, but visible on higher resolutions. I'm not very proficient in SDL, so it's probably not optimal at the moment.
Simple fading push adds 2 fullscreen blits: clearing helper surface and blitting new window to it (showAll).
Crossfade (between CCastleInterfaces) has 5 (clearing helper surface, blitting old window to it, copying old window to screenbuffer and the 2 from normal push), but 1 less totalRedraw compared to normal pop+push.

I'm not sure what you mean by affecting windows.
Fading can be theoretically applied to any window (by passing true in pushInt call) if you mean that. But if a window has some strange logic, it might not look correctly.
I currently added it only to towns, battles and puzzle windows.

(0005567)
SXX (administrator)
2015-02-22 11:04
edited on: 2015-02-22 11:05

What I mean is: I noticed lags for windows that shouldn't use fading. :-)
But as I said it's may be fault in my own code even if I'm not really touch UI.

(0005569)
Fay (developer)
2015-02-22 13:24

Unless I did something wrong or something went wrong with the logic (e.g. flag got stuck, but I don't think it's possible) then my code shouldn't affect non-faded windows. The only additions in this case of normal window are several flag checks, definitely no extra drawing operations should be performed for these windows.

Issue History
Date Modified	Username	Field	Change
2012-01-23 02:05	Darko	New Issue
2012-01-23 06:44	Warmonger	Relationship added	duplicate of 0000119
2012-01-23 06:44	Warmonger	Relationship deleted	0000119
2012-01-23 06:44	Warmonger	Relationship added	has duplicate 0000199
2012-07-07 14:11	Ivan	Relationship added	related to 0001028
2012-07-07 14:14	Ivan	Description Updated	View Revisions
2015-02-15 07:36	SXX	Assigned To	=> Fay
2015-02-15 07:36	SXX	Status	new => assigned
2015-02-15 07:38	SXX	Note Added: 0005508
2015-02-16 20:33	Fay	Note Added: 0005532
2015-02-18 22:13	Fay	Note Added: 0005545
2015-02-18 22:22	Fay	Note Edited: 0005545	View Revisions
2015-02-19 21:50	Fay	Note Added: 0005548
2015-02-20 00:17	SXX	Note Added: 0005549
2015-02-20 00:29	SXX	Note Added: 0005550
2015-02-20 08:32	Fay	Note Added: 0005551
2015-02-21 10:18	Fay	Note Added: 0005557
2015-02-21 13:56	SXX	Note Added: 0005558
2015-02-22 10:03	SXX	Note Added: 0005565
2015-02-22 10:03	SXX	Note Edited: 0005565	View Revisions
2015-02-22 10:56	Fay	Note Added: 0005566
2015-02-22 11:04	SXX	Note Added: 0005567
2015-02-22 11:05	SXX	Note Edited: 0005567	View Revisions
2015-02-22 13:24	Fay	Note Added: 0005569

Notes
(0005508) SXX (administrator) 2015-02-15 07:38	Assign it to @Fay so this can be closed eventually: https://github.com/vcmi/vcmi/pull/84 [^] Though not everything implemented in this pull request, but most.

(0005532) Fay (developer) 2015-02-16 20:33	Window fading (town screen, battle, etc.) would need to be implemented as CIntObject fading in CGuiHandler. I might look into it later, but haven't tried to mess with it yet.

(0005545) Fay (developer) 2015-02-18 22:13 edited on: 2015-02-18 22:22	Okaaay, fading CIntObjects will be tricky. Normal open/close case is quite straightforward, but for example pressing another town when already in CCastleInterface view causes popInt and immediately after that another pushInt. Currently not sure how to handle it. Edit ~ maybe this case will need new way to add int to gui handler -- to swap current view with given one, instead of removing one and adding another separately. I probably could crossfade between them.

(0005548) Fay (developer) 2015-02-19 21:50	I made something that [probably] works correctly, but it feels very hacky and I'm not really sure I want to upload it. ;) Crossfading castle interfaces is very tricky, because they have to be destroyed/recreated in exact order because of global changes in ctor/dtor. Which means I can't cache them for the duration of fade, nor start the "swap" in one method (because that would create the new interface before destroying previous one, and it breaks the game). Additionally, it's not "fade to black" (as in report description), but alpha fading. I think that fading to black makes no sense for bigger resolutions, as windows don't take whole screen and it would look rather bad.

(0005549) SXX (administrator) 2015-02-20 00:17	You can always upload it without pull request. Though can't you like use "cached" bitmaps for fading when it's full screen windows so it's will be independent of how the code works in particular case?

(0005550) SXX (administrator) 2015-02-20 00:29	And yeah I understand it's may not looks that good due to lack of animation, but may be it's won't be too bad for some screens.

(0005551) Fay (developer) 2015-02-20 08:32	Yes, I've done this with a cache bitmap. The logic would be pretty simple for normal fade-in/fade-out (e.g. battle screen). However when we switch between town views (pressing another town when castle interface is visible), there are simultaneous pop+push and it looks bad (especially on 800x600). That's why I've done this case differently and it looks better but is rather hacky. I guess I can upload it today.

(0005557) Fay (developer) 2015-02-21 10:18	I uploaded it here: https://github.com/Fayth/vcmi/tree/feature/fadingIntObjects [^]

(0005558) SXX (administrator) 2015-02-21 13:56	Thanks. Hopefully will have time to test it today or tomorrow. :-)

(0005565) SXX (administrator) 2015-02-22 10:03 edited on: 2015-02-22 10:03	Interesting. Screens changing looks good, but I notice there is some lag appear. Though I'm not sure if it's not my fail (I test it with my pathfinding branch). Can your code affect non-fullscreen modal windows?

(0005566) Fay (developer) 2015-02-22 10:56	Yes, I noticed some lags during fades. Not really noticable at 800x600, but visible on higher resolutions. I'm not very proficient in SDL, so it's probably not optimal at the moment. Simple fading push adds 2 fullscreen blits: clearing helper surface and blitting new window to it (showAll). Crossfade (between CCastleInterfaces) has 5 (clearing helper surface, blitting old window to it, copying old window to screenbuffer and the 2 from normal push), but 1 less totalRedraw compared to normal pop+push. I'm not sure what you mean by affecting windows. Fading can be theoretically applied to any window (by passing true in pushInt call) if you mean that. But if a window has some strange logic, it might not look correctly. I currently added it only to towns, battles and puzzle windows.

(0005567) SXX (administrator) 2015-02-22 11:04 edited on: 2015-02-22 11:05	What I mean is: I noticed lags for windows that shouldn't use fading. :-) But as I said it's may be fault in my own code even if I'm not really touch UI.

(0005569) Fay (developer) 2015-02-22 13:24	Unless I did something wrong or something went wrong with the logic (e.g. flag got stuck, but I don't think it's possible) then my code shouldn't affect non-faded windows. The only additions in this case of normal window are several flag checks, definitely no extra drawing operations should be performed for these windows.