Re: A83: TSE nearing completion

[Prev][Next][Index][Thread]

Re: A83: TSE nearing completion


In a message dated 05/03/00 23:56:41 GMT Standard Time, kaypictures@clara.net 
writes:

> _tseSmallSprite - A routine to draw variable height, 8 pixel wide
> sprites. I could get this by modifying the movax routine, is the movax
> routine the most optomised?
 
Depends what features you want. Do you want it clipped to the screen,
or a specific window ? Do you want collision testing at the pixel level ?
Do you want it optimised for space or speed ? Does it matter if it wraps
off the left or right ? Can you trust the programmer to put it in video 
memory and not (say) put a sprite on LCD line 63 ?

Personally I would optimise it by putting the sprite pixel data in HL
and using something like :-

 jr <x>     ; x modified to change shifts
 add hl,hl
 add hl,hl
 add hl,hl
 add hl,hl
 add hl,hl
 add hl,hl
 add hl,hl

i.e. shift it left not right.

> _tseRandom - Something like ionRandom. I could make this using rom calls
> to the system floating point rountines and the put it in a register with
> _convop1. However, that would be very slow and some games use this
> routine a lot! Does anyone know how ION does this?

Find a disassembler :) Use R and a 16 bt rotate, add sequencer, should be
good enough. FP ugh :)
 
> _tseFastcopy - This should be fairly easy to do. But ionFastcopy claims
> it's 'FAST!' (presumably in comparison to the equivilent rom call), so I
> was wondering if there was some kind of trick to it?

There are three ways of speeding it up. 

First is to flog the LCD controller to the limits of what it can do in 
terms of timing cycles (maybe test the status rather than using 
the TIOS "wait routine" on the grounds that the Data sheet timings
will have some spare space in them ?). 

The second is to only update the parts of the screen that need 
updating, rather like windows ; either checksum a line or have 
an InvalidateRegion(y1,y2) function. If you limit the developer
to your sprite functions, text functions etc. you can do this
transparently. i.e. if your game has the score and lives on the
top line, it only needs updating when that changes :)

Checksumming would be transparent but would occasionally
break down unless you used the whole line as the sum :)
 
The third is to interleave updates when you want fast screen
update ; update every alternate line every alternate refresh,
and hope the eye blurs it enough. Might look horrible.

Paul Robson.
Follow-Ups: