Polygon GFX capabilities - evaluation?

[marquisor]

hello C128 fellas and coding enthusiasts

for a game, vector racing idea like on vectrex, i just want to know how YOU experienced coders estimate the speed of polygon display on the VIC.
i consider about drawing 60-90 hires singlecolor lines per frame (if that's enough and possible?), including pageflipping, player and "enemies" should be sprites.
and how many cycles do i have per frame to calculate? 283 rasterlines on PAL = cycles??! is that right?
got a concept for the "problem" in basic yet, just to get into 3D and "vectorization". the angles and stuff, anchors of objects could be precalced and stored as values in RAM.

thx'n'regards
maq

[Hydrophilic]

You get 312 rasters or 19656 cycles per frame on PAL.  You get 263 raster or 17095 cycles per frame on NTSC (of course you get more frames with NTSC).  This works out to 982,800 cycles/second PAL or 1,025,700 cycles/second NTSC.

This assumes the CPU is running constantly at 1MHz.  If you switch to 2MHz during the VIC-II border, you get more cycles.  In fact, PAL overtakes NTSC with this method.

Polygon calculation is extremely variable, depending mainly on the size.  Even line calculations are extremely variable, depending on both the length and the "type".  Horizontal lines can be really fast.  Diagonal lines that are "mostly" horizontal can be reasonably fast.  Perfectly vertical lines can also be reasonably fast.  But most diaganol lines (i.e., most lines in general) take 4+ times longer.

All I can say for sure is I was able to get about 14 to 18 frames per second rendering 10 to 20 "medium to long" lines, including frame clearing and flipping on a reduced VIC-II bitmap of 32x14 chars (256 x 112 pixels).  This was pure 1MHz on an NTSC machine.  These were 3d vector calculations; pure 2d should show some improvement.  Screen clearing was done with Page0 relocation... actually it was really background rendering (a horizon of ground and sky)... a simple screen clear would show improvement as well.  The vectors were calculated using the fast multiply routines that you can find on 6502.org

Hopefully that'll give you an idea of VIC-II rendering.  I have no idea about VDC bitmap speed.  I don't know what you're up to, but look forward to the results!

P.S. Sprites will steal about 2 cycles per raster, each.  A normal (not Y-expaned) sprite is 21 rasters, so figure about 42 cycle loss per sprite per frame.

[marquisor]

hello hydrophilic!

many thanks for the detailed and constructive information. really appreciated. it now rings a bell again, 63x312 = 19656 for PAL x50 = 982.800... etc.

well, the vic-ii e speedup is roughly 30% overall (it's said so). i guess because of some $D030 switching and invisible rasterlines after and before possible blank in 2MHz make in overall 30%. but that i'd see as a reserve. but that's not a problem (yet).

good point you make about the framerate AND the concept you used. i can deduce, that my project i have in mind is not completely lost or senseless

my calculations are in basic yet, just to get a decent fast overview, what perspective i should choose and what all has to be (pre)calculated.
and that's my answer: it will all stay 2D, (pseudo-3D effect), no Z-calculation. the angles etc. i want to precalculate with some kind of a factor for the precalculated angle function value tables to stay in RAM as integer values (if possible). so there shouldn't be much complex calculations anymore, "just" line-drawing and pageflipping and other stuff (sprite movement, sound, score, AI, collision detection).

i will later write some "naked" line drawing routines in ASM to evaluate the cycles "eaten" by each. to estimate the cycles i would have till next frame display refresh. roughly i guess for a 300 pixel line in angle of 30° will need 1000 cycles in total. 90°, 180°, 45° could be much more speed. but that won't happen that often, unless i plan to build objects that way a bit. plus 6-8 sprites x 42 each + movement and checks dunno (20-30 each) will make a total of ~ 600-800 cycles cut each frame.
i'm going to write parts of the program and then draw cycles needed timelines in a bar graph diagram to have it visually and more "moveable" in mind, what's possible, and what's not.

the VDC comes in mind if using charset block gfx. which i might do as alternative (with custom charset), but maybe in another project. (if this fails and IF VDC would be fast enough, which i doubt...)

i did some screenshots of my early just testing purposes. i might add them if wanted.

regards so far
maq

[Hydrophilic]

...roughly i guess for a 300 pixel line in angle of 30° will need 1000 cycles in total. 90°, 180°, 45° could be much more speed

300 pixel line?  So you're doing hi-res graphics?  My quoted speed was in multi-color, by the way.  It shouldn't make much difference in terms of speed (just fatter pixels). 

But 1000 cycles for 300 pixels is amazing for a 30° line.  That's about 3.3 cycles/pixel.  The only time I beat that was with a horizontal line (approx. 1.5 cycles/pixel), and general lines took much longer... more like 20 cycles / pixel... which would be 6000 cycles for a line of 300 pixels.

Of course optimizing for horizontal and vertical lines is a good idea.  I tried optimizing for 45°, and it gave only a modest improvement over the general case, but added about 25~33% more code!  And since a perfect 45° line rarely occurred, I dropped the optimization.  Of course this was 3d vectors with all kinds of angles, so you might get better use in your case.

Anyway, have fun!

[marquisor]

well 6.000.... at 20.000 "spare" per frame (50 fps) in PAL, 78.600 at 12,5fps. i should drop the project.
or reduce the screen to 256x200 screen and using multicolor 128x200... but well if i use multicolor or hires two bits is same for me...
i will see, writing some routines at first and "benchmark" that all... maybe i get some another ideas.

what about precalculated tiles? but sorting this out might take longer to calculate a tile manually, i first have to get into the technic of line drawing... (just loud thinking)

[marquisor]

BTW some impressions so far

[Hydrophilic]

Awesome!

It looks like you CAN make good use of 45° angles!

I'm sure you know that going multi-color will reduce the pixel count 50%.  2MHz in the border helps a lot, and if you can live with less than 200 rasters, then you can get even more 2MHz boost.

Keep us posted 

[airship]

Would it help to limit the image to the left 256 pixels? That way you'd keep it all to 8 bits.