|
|
Post by D-Type on Jun 8, 2021 15:20:16 GMT -5
If you set Scale Factor to $7f and move to -$7f, -$7f (corner of the screen, sort of), you can easily draw a big square around much of the border of the screen (using a new SF of $ff and a line length of line $7f). Thus, Vectrex "pixels" can be understood to be pretty much "square", which is nicer than having 4x3 shaped pixels! That gives you a nice big play area and a display "resolution" of 256x256...but actually that's wasting quite a lot of the screen, because the screen isn't square, it's 4x3. So given SF of $7f for big positioning seems quite handy, how do people manage their positioning for the top and bottom of the screen? - Only use the middle square and ignore the top/bottom bars?
- Start all your vectors inside the middle square and push those vector lists outwards?
- Make two moves to get from the middle box to move in the top/bottom bars?
- Use a SF >$7f?
- ...or something else?
I'm assuming that everyone's obsessed with speed and thus using SF $7f maximum as a default for big positioning...but maybe I'm wrong? I've never really had to think about this too much with my toy test programs, but now I have a project where I do, so I'm interested in the strategy of others. |
|
|
|
Post by Peer on Jun 8, 2021 15:46:03 GMT -5
If you set Scale Factor to $7f and move to -$40, -$40 (corner of the screen, sort of), ... I'm assuming that everyone's obsessed with speed and thus using SF $7f maximum as a default for big positioning...but maybe I'm wrong? Maybe I misunderstood what you wrote, but if you want speed, you better use a small SF and max the coordinates (length of the vector): e.g. SF $40, and (-$80, -$80) for the move to the corner. SF is time!
Many Cheers, Peer
|
|
|
|
Post by D-Type on Jun 8, 2021 18:03:50 GMT -5
Hmm...I tried SF $40, -$80, -$80 and it doesn't work, it only goes about 2/3 of the way to the corner before it starts drawing.
Maybe I'm making some assumptions about what Wait_Recal actually does?
I shall investigate further!
UPDATE: So it appears that Wait_Recal runs Recalibrate, which uses Moveto_ix_FF and that sets the SF to $ff - I didn't know that!
Recalibrate: LDX #Recal_Points ;$7F7F
BSR Moveto_ix_FF
So that means I'm not using SF = $7f and -$40, -$40 to get to the corner, I'm actually using $ff and -$40, -$40.
So straight away, I can optimise that to SF = $7f and -$7f, -$7f, I tried it and it worked.
I will adjust my original post!
|
|
|
|
Post by D-Type on Jun 9, 2021 17:49:58 GMT -5
Tonight I calibrated my workbench Vectrex display and discovered that the test grid overlay is actually /not/ square, you're calibrating against a rectangle of 13cm x 15cm. This is all alchemy...
|
|
|
|
Post by Peer on Jun 10, 2021 1:39:48 GMT -5
Tonight I calibrated my workbench Vectrex display and discovered that the test grid overlay is actually /not/ square, you're calibrating against a rectangle of 13cm x 15cm. This is all alchemy... Na, rather analog wizardry  According to the numbers, your program draws a square. But when you measure what appears on the physical Vectrex screen with a ruler, it turns out to be a rectangle, and not a proper square. Is that what happens? Or what exactly is meant by "test grid overlay"? Did you calibrate the displayed image by modifying the numbers in your program, or did you calibrate the cathode ray tube by using the internal potentiometers? There are, if I remember correctly, two potentiometers on the internal boards, one for horizontal stretch, and one for vertical stretch. In theory, you can calibrate the tube to produce a perfect square image from square-vector-list in your program. But most other consoles out there won't be calibrated in the same way, and will show the same square-vector-list slightly differently stretched along the y or x axis on the physical screen. That is why it is always a bit delicate to outsource screen elements to the game overlay, as there will likely be other consoles where things will not properly align. Or did I misunderstand your post? Many Cheers, Peer |
|
|
|
Post by D-Type on Jun 10, 2021 3:54:03 GMT -5
 Picture above is for illustration purposes only, it's not my Vectrex. I performed a full screen calibration, looking straight-on, using one eye only and moving my head position up down left right to negate parallax errors: 1. Selected the grid pattern on the test cart 2. Set the DAC zero offset 3. Centred the image using the tube neck magnet tabs 4. Adjusted the height and width pots 5. Steps 2 3 4 again to be sure 6. Adjusted the text slant and height pots Picture now looks great with the test cart grid, there's a slight barrel shaped bulge in the middle, but only a few mm. I calibrated so that the perimeter of the drawn grid aligns with the middle of the three perimeter lines on the test overlay. The centre point of the drawn grid is exactly in the middle of the overlay cross-hair. The top and bottom extra horizontal drawn lines almost align with the middle of their three overlay alignment lines, maybe off by 1 or 2 mm. There is no official instruction in the manual that says this is correct, but it seems logical to me. The middle of the three test overlay perimeter lines form a rectangle that measures 13cm X 15cm exactly and so the test grid on my display is now 13x15, give or take one or two mm. And here's the key point...if I draw a 'big square' myself using SF 7f and four lines of 7f length, I also get a rectangle of 13x15, it's the same size of the grid drawn by the test cart. So I will now test my calibrated Vectrex against all the GCE overlays I have - about 10 of them - and see if it all lines up nicely. If it does, then I will conclude that my Vectrex is correctly calibrated and that everyone is the world should calibrate their Vectrex in the same way.  Assuming this calibration is correct, then the fact that a drawn 7f 7f "square" actually produces a 13:15 rectangle is a bit of an issue when you're drawing something that should be a square. Peer's chess board for example, the screen dumps he posted, which are from an emulator, are square - I measured them (albeit with a physical ruler, let's hope my monitor has correct x:y scaling). If I run the binary on my actual Vectrex, the board display is about 6 X 6.5cm, i.e. not square. If someone had the idea to scale a chess board up to the full 13x15, it would look decidedly rectangular, which, IMHO, just would not do  I'm still interested in what other people (esp. developers) think and have done about screen calibration. |
|
|
|
Post by Peer on Jun 10, 2021 5:27:54 GMT -5
... I'm still interested in what other people (esp. developers) think and have done about screen calibration. Ah, thanks for the explanation, I had indeed misunderstood this. Now to answer your question above:
I have honestly never cared for this. I have more or less always taken it for granted that things on the Vectrex display appear slightly stretched along the y-axis, and I have never bothered with a perfect vector-list-square not being shown as truly 100% square. I also never tried to calibrate my consoles this way.
I would also be interested to learn if other developers have tried to adjust their program computations to compensate for the y-axis stretching.
My guess is that maybe the y-axis stretching was deliberately preset by the console designers in order to better make use of the complete area of the rectangular shaped cathod ray tube.
|
|
|
|
Post by D-Type on Jun 10, 2021 6:19:49 GMT -5
Emulator authors have probably considered it, if they have included overlay functionality.
Really, for a system that was promoted with overlays as a key part of the user experience, I think it's kind of important!
|
|
|
|
Post by Peer on Jun 10, 2021 6:53:01 GMT -5
I guess again that the original overlays were probably designed to fit a console which was, in that sense, perfectly calibrated in exactly the same way as you did with yours.
I think it was accepted that calculations by the programmers were done based on a 1:1 aspect ratio, while the display itself showed a slightly distorted 13:15 aspect ratio. An indication for that could be the fact, that the BIOS routines for vector (list) rotation compute 1:1 aspect ratio rotated vectors, and do not do any adaptions along the y-axis.
|
|
|
|
Post by D-Type on Jun 10, 2021 16:02:17 GMT -5
I tried out all my overlays, they all work well now that the Vectrex is calibrated From the ten or so originals I have, the interesting ones are shown below: Space War The star vector fits perfectly into the middle of the overlay. Clean Sweep The vertical rectangle in the centre lines up well. Spinball The drop-targets all get highlighted in white. These look good, but the overlay could also accommodate a larger "big square", perhaps the outermost perimeter of the test card. Star Hawk The playfield "notch" in the centre of the drawn vectors and the topmost "horizon" vector line of the planet get drawn in blue, the rest of the planet landscape in orange. This contrasting effect works really very nicely, giving lots of colour pop. Berzerk The top print of the overlay extends quite far downwards, but the "big square" playfield fits nicely inside. [Comment: Whilst the game plays quite well, albeit a bit slow compared to the arcade version, Berserk's 5x3 grid doesn't really work on a portrait monitor, the diagonal bullets look way too steep. Malban should make a landscape version!] I think it was accepted that calculations by the programmers were done based on a 1:1 aspect ratio, while the display itself showed a slightly distorted 13:15 aspect ratio. An indication for that could be the fact, that the BIOS routines for vector (list) rotation compute 1:1 aspect ratio rotated vectors, and do not do any adaptions along the y-axis. Yes, that's an interesting point regarding the rotation code...given the distortion is ~15% and it could be quite confusing to work with ellipses, I can see why they left it as is. Apart from Star Hawk, Spinball & Space War in my collection, the rest look quite tolerant of monitor misalignment, especially in the vertical plane, so I guess it wasn't much of a problem overall. That said, I guess Armor Attack would look awful out of alignment! I took a look in the VIDE Vecxi config and there are some parameters in there called "emulated vectrex integrator max (w/h)" with defaults of 43000 and 48000. 43/48 = 0.8958. 13/15= 0.8666, which is not so different. |
|
|
|
Post by minsoft on Jun 21, 2021 3:39:00 GMT -5
So given SF of $7f for big positioning seems quite handy, how do people manage their positioning for the top and bottom of the screen? - Only use the middle square and ignore the top/bottom bars?
- Start all your vectors inside the middle square and push those vector lists outwards?
- Make two moves to get from the middle box to move in the top/bottom bars?
- Use a SF >$7f?
- ...or something else?
In my current game I use a scale factor of $80 for moving to display the main gameplay area, but use $94 as the move factor for displaying score & lives indicators...which are higher/lower than the main gameplay area. This works well enough for my game as I am happy with the gameplay area not reaching the full top/bottom extents of the screen. Note that I use much smaller scale factors for drawing objects, most of the time, as they are relatively small objects.
I did wonder about this myself and it seems like a lot of the original games don't use the full height of the screen.
It doesn't bother me too much about the vertical image being 'stretched', but I can see why that might be a problem in some circumstances. I usually design my graphics (in 1:1, I use a vector graphics package), test on vectrex and make sure it looks ok...if not then adjust accordingly.
|
|
|
|
Post by D-Type on Jun 21, 2021 6:58:07 GMT -5
Thanks for your feedback on this topic, it might sound like a no brainer to a seasoned Vectrex coder, but to the newbie like me, it's a useful confirmation.
|
|
|
|
Post by minsoft on Jun 22, 2021 5:29:01 GMT -5
Thanks for your feedback on this topic, it might sound like a no brainer to a seasoned Vectrex coder, but to the newbie like me, it's a useful confirmation. No problem, I am a novice and largely came to my own conclusions, and for the game I am working on it isn't a big problem.
I haven't had to tackle the issue of drawing full screen or very long lines but I can see that would create some challenges. I suspect you are right and often the screen real estate is sacrificed for the sake of speed.
Also the original game overlays often cover some of the top/bottom portions of the screen, especially the logo at the bottom. I suspect the programmer left those areas unused out of necessity rather than purposely leaving it for the overlay designer to fill!
|
|
|
|
Post by minsoft on Jun 22, 2021 5:40:34 GMT -5
I'm still interested in what other people (esp. developers) think and have done about screen calibration. I did something similar to you. See this thread which includes some pictures from the manual:
I think the key is that the bold lines at the top/bottom/left/right should be fully visible but as close to the edge of the screen as possible (as per the grid image from the manual). Obviously while being as well centered as possible.
The grid on mine is also ~13x15cm.
Once I had done that I configured Vide to look as similar as possible so I could try out overlay ideas.
|
|
|
|
Post by gtoal on Jun 25, 2021 17:31:47 GMT -5
I asked a related question on FB: "On a properly adjusted Vectrex, which of these three options represents the boundaries of the notional coordinate space at maximum scale? I.e. from -128,-128 to 127,127? If the top to bottom is 127:-128, does the left to right of -128:127 go from offscreen to offscreen (A), or screen edge to screen edge (C)? Or should that range represent a square that is entirely on-screen with the top and bottom inaccessible (B)? Options A and B preserve a 1:1 aspect ratio, but clip. Option A lets you draw a square as a square, but allows you to draw off-screen. Option C uses all the coordinate space and the full screen area but requires software to understand a 4:3 aspect ratio when drawing, i.e. to draw what looks like a square you would need to draw lines of length 3X vertically and 4X horizontally. This is not just a software question, it's relevant for how you physically tune the display pots. I ask because I have a suspicion that not all vectrex games make the same assumptions about the hardware. So which *should* it be?" This was accompanied by this image: gtoal.com/vectrex/screens.jpg- the consensus opinion was (C) - fill the screen with -128:127 on both axes, and adjust the coordinates in the source code to correct the aspect ratio so that a 3x4 rectangle looks square. PS The 13x15 ratio determined above looks to me like a half-hearted compromise between 1:1 and 3:4 aspect ratio by the original designers on the fence about the issue. Btw I worked on an early 512x512 raster display around '77 and we opted for 4:3 pixels and specifically handled drawing circles as ellipses etc. (There's an interesting aside about drawing raster ellipses that came out of that early display that I'll tell you about some day.) |
|
