07-20-2011, 08:14 PM
That did it!
Turns into:
Now it works "without" the limitation of the random number generator. Less division and now the routine can use a 8bit division so thanks a lot.
I think it would be better to use something like RandByte and such instead of adding to the size of the compiler with "nice" features, unless there is a cheap way to do it.
But I have another question.
Here it has to use an extra instruction to transfer between 16bit and 8bit and I do notice that there are many such instructions in my code and sometimes there is a accompanying statement like "ld h,0" and
thinks like that. On that level, minus the calculation routines, isn't then the 8bit data type slower than the 16 bit data type even though there is twice as much data to transfer? The Z80 has to fetch and process all the extra instructions.
Code:
rn=(RandByte()/86)+1
Code:
call _RandByte
ld h, 86
call __DIVU8_FAST
inc a
ld (_rn), a
I think it would be better to use something like RandByte and such instead of adding to the size of the compiler with "nice" features, unless there is a cheap way to do it.
But I have another question.
Code:
__LABEL__DrawTriangles:
call _randint
ld de, 21846
call __DIVU16
inc hl
ld a, l ; Transfer
ld (_rn), a
Here it has to use an extra instruction to transfer between 16bit and 8bit and I do notice that there are many such instructions in my code and sometimes there is a accompanying statement like "ld h,0" and
thinks like that. On that level, minus the calculation routines, isn't then the 8bit data type slower than the 16 bit data type even though there is twice as much data to transfer? The Z80 has to fetch and process all the extra instructions.