There is no need to move anything less than a pixel as pixel is a smallest amount you can move, so that you can see the difference. Solution is simple: Just don't move it! To demonstrate this on BASIC:
10 SCREEN 2 20 SPRITE$(0)=STRING$(8,255) 30 ' Main loop 40 TIME=0:FOR I=0 TO 1:I=TIME:NEXT I 'Wait for screen refresh 50 R=R+1:IF R<5 THEN 80 ELSE R=0 60 ' Next line is executed not executed every time 70 PUT SPRITE 0,(X,0),8,0:X=(X+1)AND255 80 ' Next line is executed each time 90 PUT SPRITE 1,(X2,10),10,0:X2=(X2+1)AND255 100 GOTO 30
that is other trick... less complicate to programming but a bit difficult then if you want to use the decimal part to calculate trayectory or to do sinusoide jumps... etc
So, it can be done. Just slightly slower.
To clear things up, any kind of compiler what so ever makes Machine Language programs (ML) Assembler is just a more readable format of ML. This means, that compiled BASIC program is ALWAYS slower than program made on assembler because computers can't understand what you want to do, but people can. By that I mean, that compiler or ROM format is not a miracle maker, that will make it possible to make Space Manbow on BASIC.
If you want for example to multiply a value by 2, the compiler will most propably end up to solution something like this:
; ;Multiply 16-bit values (with 32-bit result) ;In: Multiply BC with DE ;Out: BCHL = result ; Mult32: ld a,c ld c,b ld hl,0 ld b,16 Mult32_Loop: sla l rl h rla rl c jr nc,Mult32_NoAdd add hl,de adc a,0 jp nc,Mult32_NoAdd inc c Mult32_NoAdd: djnz,Mult32_Loop ld b,c ld c,a ret
... when in real life:
ADD A,A
would have been enough...
well that example is for stupids compilers
a smarth one will check if the value is fixed or is a variable
so
A = x * 2
will be
add a,a
but
y=2
A = x * y
it will takes like you posted.
The problem of a basic programming converted to assembler is the following
10 A=10 :b=20: A = A + B
all variables will be saved in memory
so a, reasonably good converter will do
ld a,10
ld (poke adress for A) , a ; saves the value 10 in variable A
ld a,20
ld (poke adress for B), a ; saves the value 20 in variable B
ld a,(poke adress for B) ; load content of the variable B
ld b,a ; move value to register b
ld a,(poke adress for A) ; load content of the variable A
add a,b ; a=a+b (registers)
ld (poke adress for A),a ; saves the result in the variable A
that is the problem , a programmer just will to write
ld a,10
ld b,10
add a,b
ld (adress for variable A),a
ld a,b
ld (adress for variable B),a
because the programer understand how to mix the three commands in that LINE
( A=10 :b=20: A = A + B ) in few commands....
that is one of a lot of problem that a compilers need to understand to be good
Nyyrikki, I am aware of that also... I do not want a 100% machine code speed compiler. But if it's about 50% of pure machine code speed, that'd be really suitable for most games.
However, games such as Space Manbow would not need much multiplies or divides in-game. And even that could be optimized by the programmer (just create a look-up table at the beginning of the program), or simply use a bit-shift-left or right operation in case of powers of 2.
Scroll is done by memory blocks transfer (add and subtract). Enemy and ships movement would be simple too (add and subtract). Such a Dreamcompiler (TM) would be less effective for more mathmathical demanding programs, such as Elite or Return of Jelda. Or not, if some look-up tables were calculated at the beginning of the game...
Actually, for 2D games, you only need decent block transfers and sprites. The MSX can do that!
And by the way, the thing I most like about computers is that is always possible to do something claimed as impossible.
By the way, a BASIC game in pure machine code would run at about how many times its original speed?
coding manually?
since 30- 50 or 100 times faster, but that depends of the code..... and what you want to do
in assembler to do little thinks is 1000 times faster than basic
but in general a game - anymation routine will go 50 time faster.... an average
And a decent compiler could compile a BASIC program to run at, let me say, 50% of a manually machine-coded game?
less... i saw 20 times faster TURBO basic, it supports only INTEGER variables, it comes as accesory on my MSX2....
well there is also kun basic iirc
but they convers to assembler on the fly.... irrc
PD: that means, when you do _RUN it first is converted , then it runs... but you never can to save the converted version. And that will only works with the compiler in memory....
large basic program are a problems because you needs in memory the original basic code, plus the converted, and left little memory for variable....