screen clipping - necessary?

[zackc]

Hi guys,

I'm new to Vectrex development. My current project involves bidirectional scrolling, and since I don't yet have the ability to test on actual Vectrex hardware, I'm wondering what happens when an attempt is made to draw a line whose starting point is on-screen but whose ending point is off-screen. Mainly, I'm trying to determine whether clipping lines at the screen edge is necessary.

I created a simple demo with a bouncing '>' that moves off-screen, and it draws fine on both VIDE's emulator and ParaJVE, even for lines starting off-screen. The only adverse effect I can see is a faint bright spot on the screen edge in VIDE. If this is the worst I can expect, I can live with it, but I'm not sure what an actual Vectrex would do. If anyone
has knowledge to share on the subject or is willing to run the demo on an actual Vectrex and report back, I would be extremely grateful!

The demo is written in C with VIDE 2.0:

#include <vectrex.h>
int main(void) {
int x = 0;
int y = 60;
int xInc = 1;
int yInc = 1;

while(1) {
Wait_Recal();
Intensity_a(127);
VIA_t1_cnt_lo = 127;   // scale

Moveto_d(y, x);
Draw_Line_d(20, 110);
Draw_Line_d(20, -110);

x += xInc;
y += yInc;

if (y <= 0 || y >= 127) {
yInc *= -1;
}
if (x <= 0 || x >= 127) {
xInc *= -1;
}
};

return 0;
}
You can download the binary here:
www.filedropper.com/cliptest

Thanks!

[Malban]

Hi,

all Vectrex have "different" outer boundaries - so it is in general  hard to say when/where to start clipping if you want to do it exactly at the screen edge.

That said, if you do not exaggerate to much it is not per se "bad" to draw a little bit out of bounds.
The further out of bounds you go the more pronounced the "halo"-effect Vide tries to emulate will be.

If you go out of bound to much a second effect will occur - namely that integration will not be linear anymore.
Example:
(for easyness for the example I take fixed coordinates)
Say you are position 0,0 you add 100 to your x - coordinate than you will be at coordinate 0,100.

Exaggerated:
- if you add another 100 to your x position you will be at location 0, 180
- if you than subtract 100 from x position you might end up at location 0, 70

Mind - this will not happen untill you are way out of bounds...


Speaking in generals again...
- most games do not do a "fine" clipping
- look e.g. at scramble - the "cave" scrolls in very "unsmooth"
- some games scroll in from out of bounds (background VPatrol)

It mostly is a matter of taste. And it is always good to have a "few" Vectrex handy to see if it looks alright on different hardware.

Malban

PS
I wouldn't start lines "off screen".

PPS
I am not at home right now - can't run it on an actual Vectrex atm.

[D-Type]

If you look at Rockaroids Remix, the rocks appear/disappear at the sides of the screen without any overscan - it's not smooth. If you look at the recent Rocks 'n' Saucers/Rocks Deluxe (YouTube, perhaps?), you can define the screen boundaries and the rocks appear/disappear when mostly over the boundary, it looks much smoother. The game also allows you to calibrate the boundary.

Given no-one's doing exact overscan clipping, the question then is will overscan break the monitor? Doesn't part of the story go that vector monitors were never very reliable in arcade games and what finally killed them off with operators was Tempest having major off-screen vector drawing (jump between levels where the screen comes towards you?) that managed to kill a lot of monitors?

Best stay with gentle overscan!

[zackc]

Awesome, thanks for the info and quick responses.

When experimenting earlier I had observed in Vide the non-linear behavior you described, Malban, but I wasn't sure what the cause was at the time. Good to know Vide's emulation is so thorough!

D-Type, I hadn't heard about vector display damage from overscanning, but this site appears to support it:

Tempest placed no limits on the amount of overscanning, whereas by limiting overscanning to 1.23", the ZVG achieves the same visual effects without generating the possibly monitor damaging voltages that Tempest is known for.

My current design would potentially allow for quite a bit of overscan, so I may need to reign that in, but that'll still be far better than having to do precise clipping.

[garryg]

On a real Vectrex drawing off screen can produce a LOT of flare, which can be very distracting to a fast-paced game.

[vectrexmad]

Apr 4, 2018 3:22:10 GMT -5 D-Type said:

If you look at Rockaroids Remix, the rocks appear/disappear at the sides of the screen without any overscan - it's not smooth. If you look at the recent Rocks 'n' Saucers/Rocks Deluxe (YouTube, perhaps?), you can define the screen boundaries and the rocks appear/disappear when mostly over the boundary, it looks much smoother. The game also allows you to calibrate the boundary.

Given no-one's doing exact overscan clipping, the question then is will overscan break the monitor? Doesn't part of the story go that vector monitors were never very reliable in arcade games and what finally killed them off with operators was Tempest having major off-screen vector drawing (jump between levels where the screen comes towards you?) that managed to kill a lot of monitors?

Best stay with gentle overscan!

I think Pole Position does over scan. When I look at the same image with a 19" monitor connected in parallel with the Vectrex I see "extra" land scape not visible on the Vectrex display.