scott@applix.UUCP (04/10/87)
I have yet to successfully use VSPRITES. I cannot seem to get rid of some occasional "streaking" below my sprites.. When I first tried these experiments, I got so frustrated, that I wrote a copper-list disassembler to see what was going on.. The problem I discovered, was that the vprites just didn't seem to all get sorted properly for the co-processor. I gave up, and stopped playing with VSPRITES. Today, I tried the recently posted Vprites demo from Peck (the S! sprite demo). If you watch this demo long enuf, you will see the "streaking" in the leftmost 1/4 of the screen (on MY screen, anyway). It looks as tho the hardware just isn't stopping, and instead continues to load sprite data words after it should have stopped. Is anyone else catching this?? Is my hardware flakey?? I have a Starboard II attached. -scott
jesup@steinmetz.steinmetz.UUCP (Randell Jesup) (04/12/87)
In article <8704100526.AA07605@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >>I have yet to successfully use VSPRITES. I cannot seem to get rid of >>some occasional "streaking" below my sprites.. When I first tried these > Are you using MOREROWS? If so, note that when you expand the >horizontal columns of the screen, fewer DMA slots are left to handle sprite >DMA. > -Matt One thing that many people don't realize is that if you position the screen-centering gadget in preferences very far to the left of the rightmost edge (the default), the last sprite or two (maybe more) will get trashed. The behavior I saw (which was not using VSprites) caused a garbage sprite from top to bottom of the screen. Randell Jesup jesup@steinmetz.uucp jesup@ge-crd.arpa
scott@applix.UUCP (Scott Evernden) (04/13/87)
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
keithd@cadovax.UUCP (Keith Doyle) (04/17/87)
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.. When I first tried these > >Is anyone else catching this?? Is my hardware flakey?? I have a >Starboard II attached. I don't know if it is a VSPRITES or a hardware problem, but I have noticed an odd anomaly related to sprites. If I run oing, the bouncing ball-sprites program by Leo, and then go into preferences and move my screen over to the left, one of the sprites will break up and spread out vertically all over the screen. I've never gotten around to trying it on other machines, so I don't know if it is specific to mine or not. Anyone else have any weird sprite experiences out there? Keith Doyle # {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd # cadovax!keithd@ucla-locus.arpa
keithd@cadovax.UUCP (Keith Doyle) (04/17/87)
Speaking of sprites and preferences...
How do you determine what 'correct' video centering is for video recording?
The Amiga Preferences centering control allows you to adjust for individual
monitors and TVs, but where is the right place for VCR's and television
broadcasting? (any gurus from Tektronix out there?) With a VCR you don't
want to adjust it for a specific TV, you want to put it where it is a best
fit for 'average' TVs, or wherever the spec says (if it says).
A week or so ago, we were feeding some Amiga video into a professional
U-Matic deck for a documentary for PBS, and I was wondering how you
determine what center is so I could adjust Preferences correctly. They
couldn't tell me, and we just used my 19 inch RCA tv and tweaked until
it looked good. Hardly a 'calibrated' method.
And with Preferences set to look good with my TV, I lose a sprite or two
(i.e. they break up vertically).
It would seem that one probably needs a monitor that has an 'underscan'
switch, and then center it based on some concept of how the average TV
overscans. Does the TV broadcast industry worry about this stuff? Or
does everyone do it differently, and just wing it like we did last week?
So gang, what's the definition of 'right' here?
Keith Doyle
# {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd
# cadovax!keithd@ucla-locus.arpajdg@elmgate.UUCP (Jeff Gortatowsky) (04/18/87)
Keywords:VSPRITES SPRITES HARDWARE GRAPHICS
I noticed that 'oing' did NOT like me pulling the screen down! One or
more of the sprites would become a semi-solid bar moveing back and
forth. It looked very similar to what the old Atari 800 did when you
turned on a Player but did not clear out the image memory. BTW simply
dragging the screen back to the top put everything back to normal.
I also noticed that you could pull the screen down alittle more than
half way before things got strange. Could this be a fall out of a
dma pointer being changed while sprite DMA is enabled?
--
Jeff Gortatowsky {seismo,allegra}!rochester!kodak!elmgate!jdg
Eastman Kodak Company
These comments are mine alone and not Eastman Kodak's. How's that for a
simple and complete disclaimer? fdi@arnav.UUCP (04/21/87)
In article <1484@cadovax.UUCP>, keithd@cadovax.UUCP (Keith Doyle) writes: > > If I run oing, the bouncing ball-sprites program by Leo, and then go > into preferences and move my screen over to the left, one of the sprites > will break up and spread out vertically all over the screen. I've never > gotten around to trying it on other machines, so I don't know if it > is specific to mine or not. > > Anyone else have any weird sprite experiences out there? > > Keith Doyle > # {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd > # cadovax!keithd@ucla-locus.arpa I haven't looked into whether or not moving the screen left or right has any effect but I too have seen a strange vertical streaking when running oing as well as other graphic hacks. Gary Albert Flight Dynamics, Inc. arnav!fdi
dave@onfcanim.UUCP (Dave Martindale) (04/27/87)
In article <1485@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: > >How do you determine what 'correct' video centering is for video recording? >The Amiga Preferences centering control allows you to adjust for individual >monitors and TVs, but where is the right place for VCR's and television >broadcasting? You check it with an oscilloscope. The best thing is to get a hold of a book on television engineering; it will tell you exactly where all the portions of the video signal should start and end, and correct voltage levels, for video that meets RS-170A (NTSC) specs. Briefly, the simplest method of centering the image is to draw a white box around the outside of the screen. Make the line 2 pixels wide so it appears in both fields of an interlaced raster. Then look at the resulting signal at the output of the NTSC encoder with an oscilloscope. With the timebase set up to view 1-2 horizontal lines, the first pixel of a line should appear at 9.4 microseconds after the beginning of horizontal sync, and the last pixel of the line should occur 1.5 microseconds before horizontal sync. All timing measurement are made relative to the point at which the negative-going (leading) edge of horizontal sync reaches its half-amplitude point, 140 mV below blanking level. If the "active" portion of one scanline does not take exactly 52.66 microseconds, you will have to either increase or decrease the figures above (9.4 and 1.5) by the same amount in order to maintain centering of the image within the area allocated for it. Then switch the oscilloscope to a slower sweep rate to display the vertical sync and blanking interval. There should be 17-21 (nominal 20) lines that are blanked between the last scanline at the bottom of one field and the first scanline at the top of the next field. There should be exactly three blanked lines between the last visible scanline and the leading edge of the vertical sync pulse (in one field this is 3 whole lines, in the other it is 2 whole and 2 va.Ue atE(Ri
gary@eddie.MIT.EDU (Gary Samad) (04/28/87)
In article <1485@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: >Speaking of sprites and preferences... > >How do you determine what 'correct' video centering is for video recording? >The Amiga Preferences centering control allows you to adjust for individual >monitors and TVs, but where is the right place for VCR's and television >broadcasting? (any gurus from Tektronix out there?) With a VCR you don't >want to adjust it for a specific TV, you want to put it where it is a best >fit for 'average' TVs, or wherever the spec says (if it says). > Well, I learned the hard way about centering of the Amiga's video. It turns out that I was preparing screen shots for use in my manual and magazine ads when I came across a company that had a Polaroid Palette set up for use with an Amiga. Great! Actual high quality color output! So, I went in carefully prepared and shot 20 slides over a couple of hours. I returned a week later to pick them up and found that every one was off center! Arggggg.... So we played around with Preferences and found that exactly centering the gadget in the rectangle exactly centered the image in the Palette. After shooting all 20 again, they came out fine. All was well in the end! Gary