Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!mit-eddie!bu-cs!halleys!applix!scott
From: scott@applix.UUCP (Scott Evernden)
Newsgroups: comp.sys.amiga
Subject: Re: Vsprite stuff
Message-ID: <432@applix.UUCP>
Date: Mon, 13-Apr-87 00:26:56 EST
Article-I.D.: applix.432
Posted: Mon Apr 13 00:26:56 1987
Date-Received: Sat, 18-Apr-87 17:45:10 EST
References: <283@mcdsun.UUCP> <431@applix.UUCP> <16542@sun.uucp>
Reply-To: scott@applix.UUCP (Scott Evernden)
Organization: APPLiX Inc., Westboro MA
Lines: 76

In article <16542@sun.uucp> cmcmanis@sun.uucp (Chuck McManis) writes:
>In article <431@applix.UUCP>, scott@applix.UUCP (Scott Evernden) writes:
>> I have yet to successfully use VSPRITES.  I cannot seem to get rid of
>> some occasional "streaking" below my sprites...
> ...
>A couple of points and cautions here, first VSPRITES only work under
>1.2 reliably. Second, if you use the MoreRows program to expand the
>display area of the screen, that takes cycles away from the sprite
> ...
>(a few) Amigas out there that have bad/broken sprite hardware.

I am not running morerows.  I am running V1.2.  I don't think I have
bad sprite hardware.

I understand how some sprites are lost when there are many on a scan
line, but that isn't the behaviour I described.  What I see (and I
would suggest readers actually LOOK at Rob Peck's VSPRITE demo) is
that some sprites "streak" (I don't have a better word - they just
don't seem to stop vertically properly).

. As I write this, I have the demo program halted from inside of "db".
. There is one sprite in the right 1/4 of the screen that is "streaked".
. I just ran my copper list disassembler on the screen.
. I then "grepped" the output of the disassembler for the "WAIT"
    instructions (used to reprogram the sprites).
. You will clearly note that the list IS NOT SORTED properly, as I
    described in the original posting.
. The WAIT instructions you see here preceed copper instructions to
    set up the sprites for next reuse.  For example, an excerpt:

00025104	WAIT	(00,6d)		; wait til scan line 0x6d
00025108	MOVE	0000,sprpt[3]	; and then..
0002510c	MOVE	18b8,sprpt[3]+2	; ..init a sprites data pointer
00025110	MOVE	9347,spr[3].pos	; ..position, etc.
00025114	MOVE	9c00,spr[3].ctl

. Grepping for WAIT instructions in the copper list yields:

00024ec8	WAIT	(00,2a)
00024f98	WAIT	(00,2b)
00024fd8	WAIT	(00,2c)
00024ff8	WAIT	(00,37)
0002500c	WAIT	(00,49)
0002501c	WAIT	(00,55)
00025030	WAIT	(00,2b)	<== What is THIS doing here??
00025044	WAIT	(00,38)	<== and this
00025058	WAIT	(00,2b)	<== and this.....
0002506c	WAIT	(00,5c)
0002507c	WAIT	(00,61)
0002508c	WAIT	(00,66)
000250a8	WAIT	(00,68)
000250bc	WAIT	(00,72)
000250d0	WAIT	(00,80)
000250e0	WAIT	(00,8b)
000250f0	WAIT	(00,8c)
00025104	WAIT	(00,6d)	<===
00025118	WAIT	(00,38)	<===
0002512c	WAIT	(00,91)
0002513c	WAIT	(00,92)
00025158	WAIT	(00,97)
0002516c	WAIT	(00,9a)
0002517c	WAIT	(00,9d)
00025190	WAIT	(00,a6)
000251a4	WAIT	(00,72)	<===
000251b8	WAIT	(00,9e)	<===
000251cc	WAIT	(00,ab)

	etc, etc, etc.

so...

I am considering disassembling the SortGList() function next...

(p.s. I also believe I know of a bug in propgadgets introduced in V1.2)

- scott