Phoebus Dokos wrote:
> In my case where you use aligned blocks on the screen (ie Pixel column
> stays the same while the row changes (In essence therefore moving around a
> block (not contiguous physical memory block but rather a "virtual block"),
> the calculations can take a lot of time, especially as numbers increase.
Shouldn't take much time. No matter in what direction you go, X or Y,
it's basically always one single add instruction (in case of X and in
assembler it can be done with no additional instruction at all, in
fact).
> 1. feed the pixel values to your routine (lets assume Mode 32 or 33)
> 2. Get the SCR_BASE (You HAVE to get it every single time as from what
> Marcel tells me the screen base can change esp. on QPC - I have no info on
> Qx0's and the Aurora is not the case here)
As Jochaim said, such a move operation should be done as an atomic
operation (iow.xtop), so that you only have to get the screen base
once at the beginning (which you have to do anyway). Outside of
iow.xtop it can move, yes.
> 3. Calculate The start address, then length, then recalculate the start for
> the next line etc... (Not very slow when starting at the beginning but can
> get painfully slow (esp. in S*Basic when having an offset)
Why not just add an offset to the already calculated address?
> It's one calculation instead of at least 4. (Don't forget you have to make
> at least 3 multiplications whereas with the second method only one subtraction)
No. You just do your first example much too complicated. A quick guide
for moving memory (16 bit mode, SBASIC just as an example, OF COURSE
one wouldn't do this in basic):
X1, Y1 = offset of source
X2, Y2 = offset of destination
XS, YS = size of region to move
Ofs1 = SCR_BASE + Y1 * SCR_LLEN + X1 + X1
Ofs2 = SCR_BASE + Y2 * SCR_LLEN + X2 + X2
Gap = SCR_LLEN - XS - XS
FOR Y = 1 TO YS
FOR X = 1 to XS STEP 2
POKE_L Ofs2, PEEK_L(Ofs1)
Ofs1 = Ofs1 + 4: REMark Simply postincrement access in assembler
Ofs2 = Ofs2 + 4
END FOR
IF XS && 1 THEN
POKE_W Ofs2, PEEK_W(Ofs2)
Ofs1 = Ofs1 + 2
Ofs2 = Ofs2 + 2
END FOR
Ofs1 = Ofs1 + Gap
Ofs2 = Ofs2 + Gap
END FOR
> Yes but for my specifications (partial areas where a lot of moves are
> needed will be calculated) so the resulting tables would be significantly
> less and in any case the alternate address can be made with one addition (a
> lot faster than multiplying three times adding and then adding the result
> to get the new address).
Wrong premise -> wrong conclusion. You only see 2 multiplication in my
whole code above.
>>This is about the same understatement as saying you are slightly hot
>>standing in the middle of a bonfire
> Depends where you come from ;-) (Hehe)- Seriously look above as I refer to
> partial areas and in any case for QPC and Qx0 memory is not the issue :-)
What else? You don't want to program such a move routine for mode 4,
believe me.
Marcel
