How to increase refresh-rate of my programs?

[8bitpapaya]

Dear programmers,

some time ago I started some simple vectrex programming. However, I noticed that my refresh rate gets low quickly with an increasing number of lines - no surprise in general. But when it comes to professional games like solarquest or e.g., vectrexians I realize that they achieve a stable picture even for rather complex scenes.

For the scaling factor I set $90 and $7F for the intensity. In addition I recalibrate in the beginning of the refresh loop calling Wait_Recal followed by Moveto_d for each line.

Some games draw pixel-graphics for text in a line-by-line fashion. They seem to produce an even larger number of lines without taking too much time.

My question is: What measures can I take to increase the speed of the line-drawing?

Thanks in advance,

Thomas

[kokovec]

This might be helpful to you.
www.playvectrex.com/designit/chrissalo/vectordisplay.htm

[christophertumber]

Intensity makes no difference in frame rate.

Scale is a timer. Since you're using a scale of $90, every vector takes $90 (140) cycles plus any overhead from pushing values into registers.

So ideally, you want to always use the lowest scale possible. Consistency of scale is important if you want things to line up exactly (ie; if you're drawing a large static logo or title screen in multiple parts - too many vectors at once will lead to drift) but otherwise is not. Especially when there's any motion which will act to disguise any inexactness.

For initial positioning of objects on screen, most people use a scale of $7f or $80. This is large enough to go from the center of the screen to anywhere on the visible (note: visible size of the screen can vary from machine to machine depending on calibration) screen.

For drawing any "sprite" itself, the lowest possible scale is used. Generally something between $04 and $10. Things like long walls &etc may require larger scales.

Say you're drawing a sprite composed of 8 vectors + the invisible positioning vector.
The time to draw this would be 9*140=1260 cycles.

If instead you used a positioning scale of $7f and a scale of $06 for the object itself:
The time to draw this would be 127+8*6=175 cycles.

(That's a bit of a simplification - I'm skipping the overhead I mentioned but it should about constant for both).

As you can see, you can draw 7 sprites at more optimized scales for every single sprite you're drawing now.

[8bitpapaya]

Thanks for your hints. I allowed myself to create a little vectrex-greeting.

For scenes which span across the entire area things are not that easy. I did a small 3D model that can be rotated but the edges that should meet at the same vertices don't coincide very well. Guess that's the limitation of the technology.

Nevertheless, very tempting to program the vectrex. Hardly anything has every been designed to produce such beautiful analog-looking line drawings.

[christophertumber]

Glad you've had some success!

Nov 18, 2015 9:52:59 GMT -5 8bitpapaya said:

I did a small 3D model that can be rotated but the edges that should meet at the same vertices don't coincide very well.

This could be a couple things:

- Depending on your rotation routines there could be considerable rounding error. 8bit math vs floating point is a big concern. In particular, how are you determining sine and cosine? FWIW, I generally use precalculated look-up tables.

- You need to periodically zero out the integrators with reset0ref. If you just keep drawing vector after vector your drawing will gradually drift out of alignment - the movements are not infinitely precise so you get a gradual accumulation of error. And this drift will vary from machine to machine based on tuning. Horizontal and vertical lines tend to drift a little less than lines drawn at an angle. Drift will become noticeable in longer lines/larger shapes faster than smaller ones. For small sprites (ie; space ships) somewhere around 14-16 is generally pretty ok.

- If you have a finite number of possible rotations (ie; 2D rotations of an Asteroids style player ship) consider using precalculated sprites for each possible rotation. ie; if you have 16 possible angles, use 16 sprites. This is much faster than calculating on the fly and more precise since you can use anything you like to do the rotation (ie; my DOS tool V-Model or mountaingoat's Java tool)

[mountaingoat]

All very good points from Christopher.

One easy recommendation I would add is do NOT use the string printing routines, they are exceptionally slow.

In Sub Wars I had the energy and hull strength levels displayed with strings (Print_Str) and it took 14-15 fps off the game. Replaced them with vectors - they still show exactly what I needed to show - and performance improved a lot.

[garryg]

Nov 18, 2015 11:58:32 GMT -5 christophertumber said:

Glad you've had some success!

Nov 18, 2015 9:52:59 GMT -5 8bitpapaya said:

I did a small 3D model that can be rotated but the edges that should meet at the same vertices don't coincide very well.

- If you have a finite number of possible rotations (ie; 2D rotations of an Asteroids style player ship) consider using precalculated sprites for each possible rotation. ie; if you have 16 possible angles, use 16 sprites. This is much faster than calculating on the fly and more precise since you can use anything you like to do the rotation (ie; my DOS tool V-Model or mountaingoat's Java tool)

That's all better advice than I could give, the only obvious thing I would point out is remember that the more pre-calculated sprites you have the more memory you are using.
For rotation, if it's quick enough, people probably wouldn't notice more than 8 positions for a small ship graphic, and 2 or 4 may be enough in some cases, if simple X/Y flips are all that is needed.