Re: 137179 replacements (again)

Clay Cowgill wrote:
> Now that I've used it for a while, the AVG system is really pretty cool.
> You can mix and match "shapes" (pre-defined sprites or whatever) with
> free-form line instructions at will. (Something that would be a real
> rat-bastard to pull off with the Sega G-80 system for example.)
>
> The only thing I *don't* like is that the hardware doesn't do rotation of
> sprites for you (like the Sega G-80 does). If it had that it would just be
> too cool. And separate X and Y scaling would be neat too. ;-)
>

yeah, I figure that since they were storing every individual rotation of
every object (don't forget the handy mirroring bits tho, MH only) they
were really counting on using large amounts of vector ROM. On major
havoc the Vector ROM space was rather small so they ended up paging it,
I suppose just about everything was paged on MH tho!

> One thing that's a little odd (but makes sense when you think about how it
> works) is that your scale factor applies to everything once you set it. So
> your "absolute" screen coordinates are only absolute if the scale is right.
>
> Atari seemed to generate the vector-list on the fly (adding objects to it
> sort of like a big linked list). I took a slightly lower-tech approach and
> put objects in specific locations of VRAM and *didn't* allow them to move
> around. That made it a lot easier to do the bricks in V-Breakout, and some
> of the "automatic" animation the ISR handles. The downside is that if you
> need to add something all your offsets move. :-( That's bad because VRAM
> addresses don't equate to vector generator addresses 1:1, so all the
> defines/equates change.
>
On Major Havoc, there is 2K of Vector RAM. They did the same sort of thing (If
Im understanding you correctly).
They actually then made JSR's to sections of the vector RAM so that each object
had an area to grow and shrink in.
   Sorta like...

     2000 set some scaling and color
             center beam
             JSR StarBuffer (VGRAM)
             set colors and scaling
             center beam
             JSR ScoringBuffer (VGRAM)
             colors and scale
             center beam
             JSR MazeBuffer (in VGRAM)
             etc...
             HALT

StarBuffer
     2200 position beam
             JSR to Star Object (VGROM)
             center beam
             position beam
             JSR to Star Object (VGROM)
             ... as many stars as you want as long as it doesn't go into the 2300 area of
the VGRAM.
             RTS

MazeBuffer
     2300 position beam
             JSR to Mazesection (VGROM)
             center beam
             position beam
             JSR to MazeSection (VGROM)
             etc..
             RTS

You get the idea. You would think that they would somehow calculate the current beams
position and
then just reposition from the last vector but I guess that since like you mentioned, the
scale effects
beam positioning too. So, they sort of always have to start from the center reference. It
seems to
make up about 30% of vector code tho.

> Knowing the absolute location of the objects in VRAM also makes easy for
> easy color-cycling where you *don't* want to modify the palette. (So on
> V-Breakout, the "BREAKOUT" title cycles through red and yellow a letter at a
> time. Changing the palette entries would change everything at once
> (including the bricks), but just writing to the color instruction (h'xx,
> h'68) from the main loop solves that.)
>

Yep, if you know where your vector data is going to be, you can use the power of
the main CPU (fast) to save a lot of vector state machine (slow) time.
Received on Tue Jun 8 14:59:47 1999