On Wed, 14 Jan 2004 11:57:53 -0700, Jess Askey <jess@askey.org> wrote:
>So would slightly overclocking the hardware be an option do you think?
>If the analog XY outputs are fast enough to deal with the actual
>drawing, then I can take care of the side effects of the game being
>faster by changing the game code a bit. :-) It would be interesting to
>see the effects of stepping up the crystal frequency a bit as far as
>extra heat, RAM flakiness and vector drawing quality.
The problem is going to be the AVG itself, and how Atari is driving it, not just
the CPU speed.
To zoom or shrink the vectors Atari included a variable gain amplifier on the
output of the VG. This also allowed you to draw faster vectors by giving up
resolution.
The time it takes to draw a vector remains constant, but by increasing the gain,
shorter vectors now cover the full screen. If it takes x number of microseconds
to draw a 1024 point vector from one side of the screen to the other, then by
increasing the gain so that you zoom in until a 512 point vector fits across the
whole screen, you can draw that vector essentially twice as fast (since it's
only half as long). You give up the number of starting and ending points you
can have on the screen (512x384 as opposed to 1024x768) but since the vectors
are analog, they are still drawn with the same resolution between the points.
That was a great way to get more vectors in Star Wars, that game moves fast
enough that there is no jerkiness because of the smaller number of starting
points. Even if you had a full resolution screen, you'd be moving your vector's
endpoints more that one point per frame anyway.
I haven't looked at any MH disassembled code, but I'm under the impression, from
talking to Owen, that on MH, they took the opposite approach. They lowered the
gain of the X/Y outputs so that the whole screen fit in the small map area. So
now they have a very high endpoint resolution display, but the vectors are now
being drawn much slower. The time it takes to draw the small map is the same
amount of time it would take to draw the full screen if fully zoomed out. So
it's similar to drawing two full screens per refresh. They kind of ran out of
time.
The CPU sits and waits for the AVG to finish before starting the next refresh
screen, so speeding up the CPU alone would not help with the drawing. It would
have to be either a combination of speeding up the CPU and AVG, or possibly just
speeding up the AVG. A problem could be that when you speed the AVG up enough
to allow the small map to be drawn at a decent speed, the monitor might not be
able to keep up with the vectors being drawn at full speeds when the screen is
zoomed in for the normal play field.
The ZVG draws all vectors at a constant speed, which you set (through jumpers)
to be within the spec's of the monitor you're using. It also maintains a fixed
resolution. It has the advantage of a very powerful CPU (a PC running in the
Ghz range as a opposed to a 6809 running in the Mhz range) to recalculate the
position and size of the vectors based on the emulated AVG's gain setting, each
vector is re-sized and placed in the proper position on the screen, and then
drawn at full speed, regardless of MH's zoom level. So the ZVG draws the map's
vectors at the same constant speed as it draws the playing field vectors, which
gives the ZVG the advantage of allowing more vectors per refresh, on the same
speed monitor, than MH was able to do with its hardware zooming. If the 6809
had had enough power to do zooming calculations in software, the AVG could have
been driven the same way. So this was more of a CPU speed issue than running
into AVG hardware limitations.
-Zonn
>Tom McClintock wrote:
>
>>Forgot to add, when speaking with Owen Rubin at last year's California
>>Extreme, he said the MH hardware was *almost* fast enough and *almost*
>>accurate enough to draw all the lines correctly. If/when you do your BIP
>>adjustments, as Chris noted, you may still end up with lines that don't
>>touch.
>>
>>The slow hardware speed can is particularly evident in the 'map' at the
>>top of the screen. Effectively it is a complete second redrawing of the
>>main playfield. Works flawlessly on the ZVG... :)
>>
>>
>>tm
>>
>>"Christopher X. Candreva" wrote:
>>
>>
>>>>One more question. Is it normal for the maze to have gaps in the vertical
>>>>lines? I can't remember if this is normal - sorry for the moving pic, but you
>>>>should be able to see the gap just to the right of Rex' head, and another to the
>>>>left of the "3 lives" text:
>>>>
>>>>http://www.members.aol.com:/mkdud/mhconv/mhmaze.jpg
>>>>
>>>>
>>>I think that's a BIP / Liniarity problem. I was able to close the gaps, but
>>>there are still noticeable doscontinuities on mine where they do not look
>>>like complete lines.
>>>
>>>
>>
>>---------------------------------------------------------------------------
>>** Unsubscribe, subscribe, or view the archives at http://www.vectorlist.org
>>** Please direct other questions, comments, or problems to chris@westnet.com
>>
>>
>
>
>
>---------------------------------------------------------------------------
>** Unsubscribe, subscribe, or view the archives at http://www.vectorlist.org
>** Please direct other questions, comments, or problems to chris@westnet.com
---------------------------------------------------------------------------
** Unsubscribe, subscribe, or view the archives at http://www.vectorlist.org
** Please direct other questions, comments, or problems to chris@westnet.com
Received on Wed Jan 14 18:03:55 2004
This archive was generated by hypermail 2.1.8 : Thu Jan 15 2004 - 00:50:01 EST
