Archived from groups: rec.games.vectrex (
More info?)
Clay Cowgill wrote:
>Now then, take something simple like an Atmel ATMEGA16 microcontroller.
>$4.71/ea in qty 100. It has 16K of internal flash memory, and is 16MHz.
>It's average clocks/instruction is closer to 1, but let's call it 1.5 to be
>safe. It'll push maybe 10.5MIPS, or roughly 27 times the processing power
>of the Vectrex. It has a hardware multiplier that can do an 8x8 multiply in
>2 cycles too, so from a multiplication performance standpoint it's about 55
>times faster than the Vectrex.
I'm hate to say it, but I think you're playing lances vs windmills...
1.5Mhz at 20 fps = 75,000 cycles per frame
Assuming 140 cycles per vector drawn at scale 127 ($7f) which includes
the 127 cycles actually spent drawing as well as any loop/index
overhead and the actual code needed to start/stop drawing - Which is
probably conservative.
If 100% CPU time is spent just drawing vectors, this yeilds a scene
with a maximum of 535 vectors. This would occur if your copro did all
calculation and just returned at display list for the Vectrex to draw.
As far as scenes go, the best case is a scene which can be drawn as a
single sequence of vectors, without ever having to turn the pen off or
reposition the pen. In this case you would actually be able to get 535
visible vectors.
This is the equivalent of 133 4-sided polygons, 107 5-sided polygons,
etc.
This case will never happen, if only because of drift. It also implys
a scene with only one, highly complex, object. Or a scene where all
objects overlap. The former is of limited pracical use. The later
can't be counted on all the time.
The worst case scenario is one where the pen must be positioned to
strat drawing a vector, draw the vector, reset0ref, and then be
repositioned for the next vector. That is, none of the lines are
touching each other.
This too will never happen, however, it results in 267 visible lines
in a scene.
So, if the 6809 is tasked only to drawing vectors, the theoretical
limits 535 visible lines and 267 visible lines.
But what of practical limits?
Assume a scene composed entirely of n-sided polygons. Each polygon
will take 140+n*140 cycles to draw.
So, for a scene composed of:
4-sided polygons (700 cycles), results in 107 polygons which is 428
visible lines.
5-sided polygons (840 cycles), results in 89 polygons which is 445
visible lines.
6-sided polygons (980 cycles), results in 76 polygons which is 456
visible lines.
etc.
Obviously this is going to depend upon how your scene is composed,
what kind of polys your objects are made up of. It's also going to
depend upon your copro's software and it's ability to optimise the
sequencing of vectors to be drawn. Hidden line removal will help this,
has will eliminating drawing vectors more than once - For examples, a
cube is six 4-sided polys. However, if you draw all six of those
polys, you wind up drawing all the lines twice, all of which count
towards your totals. If your code can eliminate most of that
duplication you're looking at a big performance boost. In addition, if
any objects overlap you may be able to gain some more by drawing more
complex shapes all in one go. As limited by drift.
I think it's safe to say you're looking at a maxamium 450-460 visible
lines.
Now, on the other hand. What if there's no copro and we just deal with
the Vectrex's limitations as is?
What's a reasonable number of cycles to budget to our video driver vs
the game engine?
Well take the Atari 2600, which is the only system I'm really familiar
with that has the same relationship with the video hardware as the
Vectrex. Namely that the display must be serviced in real time. You
don't get to just write to some registers whenever you have a chance
and let the video hardware take care of things. And more importantly,
the video hardware doesn't stay "live" until you change it, in the
2600 and Vectrex if you don't service the hardware on time your
display is pooched. (you know all this, I'm including this kind of too
much information for everyone else who's reading)
The 2600 runs at 1.19Mhz. Each frame, 14592 (76*192) cycles are spent
drawing the video while 5320 (76*70) cycles are available (in the
overscan and vertical blank) to run program code.
If we assume that same ratio (73% video) on the Vectrex, then we have
54961 cycles for drawing and 20039 cycles for game code.
Using the previous metrics, our theoretical best case is 392 visible
lines and a worst case of 196 visible lines.
And a scene composed of:
4-sided polygons (700 cycles), results in 78 polygons which is 312
visible lines.
5-sided polygons (840 cycles), results in 65 polygons which is 325
visible lines.
6-sided polygons (980 cycles), results in 56 polygons which is 336
visible lines.
etc.
So you're likely looking at 330-340 visible lines.
Comparing the two, you're looking at at 36% performance boost with the
copro.
Okay, okay, I can hear the objections already - 2600 games tend to be
far simpler than a real 3D engine so that ratio is not realistic. True
enough, however because of the different framerates, we actually have
almost four times as many cycles available per frame. And we have a
much more powerful CPU. And we have a lot more RAM. So I think those
specs are, in fact, realistic. I've also been a little loose with my
numbers, essentially assuming "zero friction" like a high school
physics problem, with no overhead from a main loop, joystick input,
&etc. Whatever, we're in the right ballpark.
Assume our scene has 65 5-sided polys (some polys will be 4-sided,
some will be 6-sided, some more, for the sake of argument figure an
average of 5).
We have 20039 cycles to deal with everything. That's 308 cycles per
poly. That's 61 cycles per point or vector (depending upon how we
express them).
Simple left/right/up/down/foreward/back movement is no big deal, the
tricky stuff is of course rotation and:
y' = (cos(theta) * y) - (sin(theta) * z)
z' = (sin(theta) * y) + (cos(theta) * z)
Is looking pretty tight! But, if we only update 1/2 the polygons every
second frame, we have 616 cyles per poly and 122 cycles per
point/vector. Worst case if we move 1/4 of polys every 4 frames we
have 1232 cycles per poly and 244 cycles per point/vector.
Hidden line removal is a big, big problem. We don't have near enough
RAM to do a nice, simple z-buffer. So we're looking at more maths -
intersection of a line and a plane. But on the other hand, hidden line
removal could simplify the scene which needs to be drawn and may "pay
for itself". Though the only hidden line removal we can cound on is
the back faces of objects. We can't always cound on two objects being
in front of each other (unless we fix it that way, or course). But of
course we can simply our hidden line removal if we just remove hidden
faces. Umm, anyway...
So, IMHO, it's doable (true hidden line removal may or may not be).
I've long wanted to do a Torque for the Vectrex. It's just a matter of
doing it. I've been easing back into Vectrex, but time is a serious
concern right now so I dunno if I'm going to be up for it any time
soon. And I still have several 2600 projects that really need
finishing up.
The big problem with UTG is it cheats too much. The maths are 8 bit
which leads quickly to rounding errors. The tanks are not 3D objects,
they're precalculated flat sprites and the Vectrex scale property is
used, which is inherantly flawed and not linear so the tanks don't
really rescale right which leads to more visual problems.
Chris...
Facebook
Twitter
Instagram