- ColorFilter is now in separate file
- Moved lerp function into global.h
- Bloodlust visuals mostly matches H3
- Petrify visual matches H3
- TODO: Adjust timing of all ColorFilter efects to match H3
- TODO: Petrify should pause stack animations
- TODO: ColorFilter-powered effects should be configurable in Spell system
- refactoring of CBattleStacksController.cpp
- moved EAlignment enum to Geometries.h from CIntObject
- renamed EAlignment to ETextAlignment, to avoid conflict with good/evil
alignemt
- ETextAlignment is now enum class
issues to solve:
- dynamic_cast error 2: One or more of the following type_info's has hidden visibility or is defined in more than one translation unit. They should all have public visibility. 13CPackForLobby, 20LobbyClientConnected, 20LobbyClientConnected.
- error setting socket option: set_option: No buffer space available
* Instead of [x][y][z] coordinates, map will be stored as [z][x][y].
* Nullkiller AI can get it too.
* Use boost::multi_array instead of nested vectors
* In MapHandler too
* Rotate foreach algorithms, too
* VCAI gets rotated, too
Disabled the following (for MSVC only) that couldn't (or shouldn't) be fixed.
4003: not enough actual parameters for macro 'identifier'
4250: 'class1' : inherits 'class2::member' via dominance
4251: 'type' : class 'type1' needs to have dll-interface to be used by clients of class 'type2'
4275: non dll-interface class 'type1' used as base for dll-interface class 'type2'
Defect:
After my previous change that enabled map layer (`CAdvMapInt`) to listen to all mouse move events via `strongInterest` bool, I noticed that there are a few scenario that start scrolling the map unexpectedly. The two that were the easiest to reproduce were using keyboard arrows to move the hero or dimissing a popup dialog.
I traced this down to unexpected mouse move event (`SDL_MouseMotionEvent`) that SDL seems to dispatch in this situation. The windowID that comes with the event in this scenario is 0 (so no window with mouse focus). I don't know why SDL dispatches this mysterious (to me) mouse move event in that case (note that there is no actual mouse movement in either repro case).
Fix:
Don't handle the mouse move event if the windowID of the mouse motion event is 0.
Notes:
Impacts scrolling of the game map. Did some play testing and didn't notice the scrolling not working when expected. The two specific cases where the map would scroll unexpectedly (move a hero with keyboard arrows or dismiss a popup dialog) no longer move the map.
In fullscreen mode, when the adventure window size does not fill the entire monitor (leaving black bars on each side), mouse movement is ignored in these areas. This results in difficulty scrolling the map in fullscreen mode, since you have to be exactly within [0,15] of the edge of the adventure window.
Fix:
Have the adventure map element, CAdvMapInt, subscribe to all mouse move events by setting the `strongInterest` bool to true. This will extend the scroll region to [min, 15], eliminating the dead mouse move space on the side of the window.
Notes:
Impacts adventure window mouse move event handling. Manually validated the scrolling the map now works without having to precisely aim for the edge of the window.
Added else condition that covers cases "ObjectAtTile that is not enemy nor is Town nor is current Hero". This should cover all cases of friendly dwellings/mines not having the correct cursor.
