At 07:01 �� 28/3/2002, you wrote: >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?
True too see I didn't think about that as moving irregular areas was stuck in my mind for some reason... So yeah both you and Nasta must be right :-) > > 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) Oh one would, one would ;-) (Why not... it's fun to experiment!) >: > >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. Right but in any case, wouldn't a continuous access to a table in memory be cached (as you say elsewhere?) thus increasing access significantly? In any case this whole question was mainly to see which method would be more efficient speed wise. As many of you told me calculating without accessing memory would be the same if not faster than accessing a pointer table in memory... However in the S*Basic case (that you dread ;-) it probably would be faster don't you think? > >>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. Oh no... Mode 4 as far as I am concerned is non-existent... After I got QPC i used Modes 4 and 8 only once each! (I was messing around with SSG 4.0) Phoebus
