It's cool and all, but this also seems excessively complicated. Moosh and I have a similar system running in 2.5 that seems a lot simpler (only 1/3 the side of your code) and, to me at least, infinitely more readable. I'm not even entirely sure what your method is doing. Creating several bitmaps and storing combo data, cset, and solidity in one each? It seems like a rather roundabout way of doing things. What's the purpose? I'm sure it allows for some added flexibility somewhere, but I'm not immediately seeing the benefit.
There are a few advantages here. The most immediately obvious, is lightweight ASM.
Don't count the size of the script itself--that's window dressing. Look at the ASM output from the script and count the instructions per frame, amd how heavy each of those instructions is to execute. ou are welcome to try to make a comparison, by taking he same map from this quest, making it scroll in all four directions and checking combo solidity when scrolling/panning, and comparing the size of the ASM output.
I'm running this single demo quest, faster than 1st.st runs right now. Granted, I have no sprites for ZC to track, but I would certainly expect old methods using stuff like DrawCombo() to be far, far slower. Also, count your loops, and how frequently ou need them. For the most part, I only have loops running on DMap init.
Because I am pregenerating all of that data, my mandatory per-frame instryctions are a few blits (memory block copy), and some pixel reads for pixel-precise solidity and collision.
A less obvious feature, is that, because I am using bitmap masks for type/solidity checking, I can distort each bitmap using the same calcs, and end up able to have the same level of precision in my checks.
Redarding readabilirty: If you mean from the perspective of someone used only to old, stock and common ZScreipt, sure, because you are not accustomned to seeing these types of statements and expressions; but not from a programming sense. It is no more or less readable than older scripts, if you understand the syntax. In fact, coming from most programming languages, it is probably more readable, and more logical.
No-one normally manipulates tile draws individially, en masse in any modern game engine. This is more or less hor ZC behaves internally, for example, when performing a screen transition.
The most critical implication though, is from the perspective of designing a toolkit for anyone to pick up and use. Wityh careful design, selection of script types, and integration into the UI, I can use this in a way that is portable, and thus, in a way that requires no programming/scripting knowledge on the part of the user. The end-user need only set the dmap script to 'Scrolling', and enter in some D arg values, to use it.
Thus, game construction is entirely via the ZQ UI, and the user need never even look at how it works, nor need to comprehend it, to make use of it. If you look at my latest commits, you will see that, for the stats menu, I'm using the string table to generate menus.
On another note, I can use various effects, such as transparency, anchoring, pivot and rotation to make all sorts of mad visual effects on the primary game screen, with only a few instructions, that take very little extra power to execute. In the DQ example, I make the menu display part of the game screen bitmap, and I make it translucent while not needed.
Look at levels in games such as the 16b Akamajou Dracula titles, for examples of using this kind of effect.
If you wanted to, e.g.) make a dungeon that slowly rotated, imaginge how much work you'd need to do to manually rotate and reposition individual combos--and the ASM generated by such a task. Instead of that, I can pivot the bitmap with rotational anchors, and move it on any desired axis, and do the same with its solidity mask, and its type/flag checking.
Further, I can use the entire screen area with this method, without clunky hacks. Because my master map is pre-rendered, I am just drawing a slice of it onto the full screen at all times. This is less of an issue in my implementation, as I do not need to blit enemy/weapon sprites above it, but I can see adding an option into ZQ to draw the subsceen before sprites, so that it is always possible to blit to the entire screen size, on layers 0 or 1.
Thus, i save screen real-estate that is normally wasted by the subscreen for something more useful.
Last, if I want a full horizontal scrolling, sideview level, I can arrange my bitmap to be any size to fit my need. if \i want it to be two screens high, by 64 screens wide, I have that luxury without any fancy combo pos and screen pos reading functions. e.g., i do not need to align multiple maps, in order to get 64 screens of width.
P.S. I could equally use mapdata->isSolid(x,y), and mapdata->Combo*[] here, if I don't need distortions or visual effeccts. I already installed *mapInfo.curscreen and *mapInfo.curmap, so that I can determien the actual map and screen for the current player position at any given time, on the 'real' ZQ game map. Thus if I want to cut down a tree, I could use that data location, modify the mapdata, and act accordingly (e.g.), write a different ComboD[] to that mapdata, and reblit only that screen slice to the master bitmap, which is then redrawn to the virtual screen.
I need only set that event oe time, if I want it to be static; or I could instead write new data to its combo location on my bimaps, including solidity, type, and flag values, without ever touching mapdata, in which case, it reloads from the original mapdata when the player re-visits the area (i.e., the tree will be still be gone or will be back, respectively).
That is one simple 16x16 pixel block copy to (from) two to five locations, depending on how many calues I need up update. It's a total of 45 ASM instructions IIRC (this includes popping the dunction params), on average, to completely modify a specific position data in all five places, so that part may be heavier, but I need to do it far less frequently than shifting screen combos to create a scrolling environment