sorry i didn't notice this "VDPCmd HMMM-IMP (88,560)->
200,16),0 [4,16] -- tile copies for diagonal scroll"
So those are!
VDP continues to surprise me in it's slowness. i think the overhead is bigger because of the small width x "larger" height format...
it is moving a byte every 20 z80 T-states. z80 can do better with unrolled OUTI :-(
If the mask is 16 pixels wide I would still need to do sixteen 16x16 copies within one frame. A mask of 32 would give me sufficient buffer to do a single copy per pixel scrolled, but that would be a bit too much horizontal screen space sacrificed 
. For that one should just use the 2-page horizontal scroll mode, at the cost of VRAM. So my use of 4x16 copies is due to my choice not to use the 2-page scroll mode.
But I’m not too bothered by the copy speed currently. It’s nice at least that it executes in parallel, and the CPU isn’t waiting for it excessively much, just a bit. If I had to move all that data with the CPU (which I did consider earlier) I would’ve been in a lot more trouble with my frame time!
Cool, I tried it, looks like it saves 2% CPU time (0.67 ms, 2400 cycles) when scrolling diagonally. Good info.
I happened to implemented a custom ISR with IM2 two days ago, for screensplits… 
Pre-selecting status register 1 may be needed to get them tight, but let’s see.
Playtime is over, as my long Easter weekend has come to an end and real-life games programming/optimizing is back on the table
Good luck with your project; it has real potential (my own attempt at such engine a long, long time ago was trying to do a two layer approach, so the sprites could move behind trees/walls, etc. This engine would update sprite pattern tables depending on what was in the foreground. Also layer drawing was made cheaper by allowing certain tiles to be simple LINE,BF type of VDP commands, but that's something that has to fit the art-style of the game.)
My final results (43+% free CPU time when scrolling diagonally):
Idle:
The boost to idle mode is because you have a minor bug in your code: you still do tile collision testing when the player doesn't move and I fixed it in my local version.
Move diagonally:
Move vertically:
Move horizontallly:
Playtime is over, as my long Easter weekend has come to an end and real-life games programming/optimizing is back on the table
Haha, cool though that you checked it out .
Good luck with your project; it has real potential (my own attempt at such engine a long, long time ago was trying to do a two layer approach, so the sprites could move behind trees/walls, etc. This engine would update sprite pattern tables depending on what was in the foreground. Also layer drawing was made cheaper by allowing certain tiles to be simple LINE,BF type of VDP commands, but that's something that has to fit the art-style of the game.)
Thanks. I’ve thought about that, but it seems a bit complicated to do with sprites. One approach would be to store bitmasks for the terrain and manually mask out the every frame. Seems expensive though since it needs to process 256 bytes of pattern data on the 60 fps loop.
For now my plan is to simply disallow the player from moving behind objects. If I want to have some narrow overhang in specific places (like an archway over a 1-tile wide passage) I can put a static sprite object there. Up to four sprites per line remain for those kind of things.
My final results (43+% free CPU time when scrolling diagonally):
Nice . So let’s see if I got it right how you got there...
3% frame time from inlining stuff. Esp. in the sprite attribute update it seems there’s over a whole percent gained. I think it might be a good idea to start using macros for my getter functions.
2% frame time from copy wait loops defaulting to status register 2.
2% frame time from... other general optimisations. I especially see 1% gain in the player move update / collision handling. More inlining?
The boost to idle mode is because you have a minor bug in your code: you still do tile collision testing when the player doesn't move and I fixed it in my local version.
Actually that’s intentional... I don’t optimise for those cases and just always run it, because it reduces the amount of variation in code paths, and I need to optimise for the worst case anyway. I prefer things to just always run so that I have a constant budget and the meters don’t jump so much. I might even start doing all the scrolling copies when idling!
Maybe at some point if I want to do some framerate-dependent things (like doing more tile animations if you’re idle) I would optimise those things, but for now I think it’s more beneficial to have the frame budget allocation be constant, so I can be sure there will be no frame drops.
One thing that can be optimised though is that collision only needs to be checked every other frame, because player input is sampled on the "slow tick", so as far as the game is concerned the player sprite only moves in steps of 4 pixels per frame. Should halve the time spent there, saving about 3%.