!Now, we are still grid based (no freeform collision system) and this has implications for the type of scrolling. It is still scrolling from square to square, so the player cannot change direction or stop inbetween two squares or move at wild angles. Nonetheless, having new squares (and evertyhing else, minus ui and party in dead center of screen) smoothly sail in and old ones elegantly glide out makes a lot of difference for the way that movement feels. Holding a move button down and soaring across the map feels much better this way, imho. Generally, all movement - even a single step - feels much more fluid. We have not gained any fps by this particular change (it costs ressources actually), but it feels like we had a huge fps gain. Tricks of the mind and eye, I guess
. This is one of the changes with the most bug portential so far. I hunted down alot of them already. By now, the new/standard useAllTile system for drawing maps seems to work without - visible - glitches, so far (well, the light map around the party is a tiny bit out of synch due to the binary way it works, but this is only noticable at extreme move speeds/taps of the move button or very low scroll speed settings). But I still have work to do for the old way of drawing the map (eg used by Hearkenwold). It already works quite well in Hearkenwold, too, but there's eg still some flickering and strange draw omissions going on with the outer rows. I will have to bend my mind around very old code again. Ah, we will get there
.In the end, there will be a new property in the toolset to turn scrolling on/off. I will also add a setting for scrolling speed, so authors can adjust this to their own preferences. Later down the line, I might try to get in optional move animations for the party (so an author could use two or maybe more frame walk animations that are palyed during the scrolling phase).
. It doesn't help either that the whole draw hierarchy has grown organcially over time and due to me being me quite chaotically, too, hehe 
.