(it might explain why things work one direction but not the other)I was working on a nice little puzzle/rubik/tetris type game and have hit a brick wall ....the scan line!
I'm guessing (correct me if I'm wrong Holger) that the screen is drawn and each CE is processed using a Left-Right Top-Bottom scan line?
The problem I'm having is CEs getting ignored/wiped and always if it's going with the scan line, right or down. (swimming against the tide works, surfing to the beach doesn't
)Say we have CE1
It is moved by pressing it (not actual movement just replacement), here's its change pages for pressing it up,down,left and right:-
up
down
left
right
As you can see this wipes and recreates itself one step ahead, and as soon as you press one of these all it's neighbours move as well.
The problem is, it works going against the scan line (left or up), but fails when it's going with it (right or down).
Say I have a line of CE1s
I push left:-
You get:-
Since the scan line is left-right the far left
is processed first. It moves left and leaves a space like this:-...until the whole line has moved (in one draw cycle), OK so far so good.
Now the problem is, moving right:-
This gives you:-
Again, since the scan line is L-R, the first CE to be effected is the one by the player. This is wiped and reconstructed to the right, then the scan line moves right (to the newly made CE), which is then wiped. Gives the effect of a dotted line.
I have tried every possible way under the sun to try and trick the scan line and move them all right in one (or two) screen draw cycles.
Having the element wait until a free space is on the right works, but that means you can only move elements on the end of a line once per screen draw, all the rest have to wait for the next cycle, the longer the line the more waiting they do (and the more errors can occur). So if you push a line of 20 CE1s, it will take 20 screen draw cycles to move the whole thing.... which is slooooooow!
Other methods where to construct secondary movers, like:-
change page right:
Using
to check/add/delete neighbours using timers, it either works the same as the simple method, or came crashing down like a horribly complected house of cards. :-\I had all these problems with snakebite, but what I'm doing now is a bit more technical.
I have ran into this kind of problem lots of times (since day one I suppose) and have either settled or abandoned the idea/game.
Anyone got any ideas?
Holger: How hard would it be to reprogram the screen draw routine so it could not only draw the screen L-R and T-B, but also R-L as well as B-T (8 combinations in all )
You could then add an option to override the next scan with the draw direction of your choice!
So if I moved a vertical line of CE1s down and set the "scan line mode" to B-T and L-R (which starts drawing the screen at the bottom first)
Now all elements at the bottom of a line will be effected first, and all of them would move down correctly (the scan line mode could go back to it's default after a force call)
This would end all block movement limitations (all of snakebite works like that), plus it would have a 1001 uses.
)
ZOMIS! FIX IT!! 
uumm... wait a second... I'm Zomis... ah... yes... Linux Shellbot hit the system... 
I hope it will be up again in the beginning of next week though..
I have done something like this (but a bit different)
I think from now on, if the example CE is in range of 0-9 then we should use 
-
(just kidding...).