NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/sys/atari/st/tech/4488

Internet Message Format | 1992-08-19 | 3.5 KB

Path: sparky!uunet!charon.amdahl.com!pacbell.com!mips!mips!munnari.oz.au!bunyip.cc.uq.oz.au!uqcspe!cs.uq.oz.au!warwick
From: [e-mail] (Warwick Allison)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Sprite code (Re: Second&last time: Hacking Contest)
Message-ID: <[e-mail]>
Date: 20 Aug 92 01:48:51 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]
Sender: [e-mail]
Reply-To: [e-mail]
Lines: 74

[e-mail] (Steven Eker) writes:
>[e-mail] (Warwick Allison) writes:

>This is fine. but is a previous post you mentioned that sprites could
>be updated at different speeds which made me think you were using some
>arbitrary interleaving of draws & wipes.

Oops, poor qualification by me.  Obviously, it is DAMNED HARD to give
arbitrary sprite priorities, AND arbitrary update rates.  (Although
possible - using full-screen masks, which are also useful for clipping,
moving "behind" playfield objects, etc.)  If I even need such Sprite
classes, I'll have my head examined.

>Maybe, maybe not - it depends on your sprite drawing method. The code
>I originally posted only read the screen implicity with
>       or.w    d0,(a0)+

Hardly useful for anything but UNMASKED single-bitplane graphics, which
is next-to-useless (at he very least, you usually want to have black
and white sprites (like the ST mouse pointer), rather than just black
sprites (like the Sun SunView mouse pointer)).  Of course, in the
interests of competition, anything is "useful" :-).

>BTW the code I posted is (slightly) faster than the 32x32 sprite code in
>your GNUchess port even under the most pessimistic assumptions (you did a great
>job on the port though...).

<delight> if you can mail me code-for-code patches, I'll put them into
my library (which will be free-to-all one of these days).

>|> Which reminds me - was this a competition?  I wrote some VERY fast
>|> sprite routines in a furious discussion with Dave B. - 60 or so
>|> single-bitplane 16x16 sprites at arbitrary positions on an arbitrary
>|> background was I believe my limit...

>No, it was just a sugestion for a better competition goal than the
>rather pointless TOS hacking in Nat!'s competion.  60 sprites at 50Hz
>is quite amazing on a non-blitter ST. At 25Hz rather less so.

Actually, I think it was more like 50 at 72Hz (ie. mono).

>Still I can't resist the challenge...

You didn't post performance stats!  How well does it BURN?


Let's make some categories:

    1. Preshifted / Unshifted
    2. 16x16 / 32x32
    3. Masked / Unmasked       (ie. black&white / black)

>Come to think of it, if the sprites are only one pixel deep why not preshift
>the blighters???

Yep.  One better:  with unmasked sprite, why even HAVE sprite data?
it uses only 100% more RAM to have the sprite data be the CODE ITSELF,
ie. automatically generate the

    orl   #....,(a0)     (3 words)
    addl  d0,a0          (1 word)

instructions from the 2-word sprite-data!

(Of course, this is only acceptable for HACK CONTESTS.  Anyone who seriously
considers this a "programming technique" is a beauxault)

--
Warwick
--
  _-_|\      [e-mail]            /Disclaimer:
 /     * <-- Computer Science Department,  /
 \_.-._/     University of Queensland,    /      void (if removed)
      v      Brisbane, Australia.        /