Messages

The way to handle sprites leaving the screen is to either 1) have your BASIC code remove it from the drawing list (or disable it), or 2) set up clipping so that it gets clipped out and not drawn.

Option 1 is preferable since clipping takes a lot of time. But it's also more complicated to write the code for, and I didn't do that in the 3D demo. Ideally, clipping should only be used to handle the case where an object is partly within the field of view and partly outside. Clipping makes sure the part that's visible is drawn properly.

- Bob

https://youtu.be/wfow8xKGZZ0
Skip to 11:19
It appears as though I have the expansion/contraction directions backward - up = shrink to left as seen in the video

Wow, that's stunning. I never noticed that before but if I look for it on my Vectrex, I can see it. I  have no clue why it would be happening.

- Bob

I've reproduced these crashes.

1. When trying to go into lunar orbit, the Vectrex32 does not crash but the Vectrex does. If you have a terminal open, you can Ctrl+C the V32 and get a response. But clearly, the Vectrex is not happy about something. Probably, something in the drawing list is getting compiled to bad Vectrex BIOS command arguments.

2 & 3. If you have a terminal window up when adding tie fighters or moving them too far off screen, you'll see an error message: "At line 57, column 16: Not enough Dual Port RAM memory for all the Vectrex commands". So the BASIC program crashed, but V32 did not. If you enter the commands 'stop' and 'run', Demo3D runs again. However, I'm not sure the dual port RAM has been fully cleaned up.

- Bob

As we're all aware lunar lander has a scaling issue - the terrain widens and shrinks in accordance to Joystick 1 Y position.

We are? It does? I was not aware that LL has a scaling issue. Who else is aware of this? No one told me.

When you get close to the ground, the scale changes so you can see the ground more clearly. The original arcade game did this too. Is that what you're referring to?

- Bob

[a lot]

You can run V32 programs on the Vectrex without having it connected to a PC. Just copy a BASIC program to the V32's flash. If its name is autorun.bas, it will run when the Vectrex is turned on, regardless of whether a PC is connected. Alternatively, you can use the autorun.bas program that comes with V32; it displays a menu of all the BASIC programs on the V32 and lets you select one and run it.

Having the V32 send 6809 code over the USB to the PC is problematic, not just because of USB's speed but because Windows is not a real-time operating system; there's no guarantee that Windows will read the USB 30 times per second. In any case, it would be simpler to port the V32 code to Windows and have it interact with a Vectrex emulator.

"Simpler" is a relative term, though. It would still be a lot of work.

- Bob

I actually don't think it would be too hard to build a nice graphical environment for the Vectrex32 to combine both terminals into one. If I have time after these blasted exams are done I'll write it in Java and post the source to Git. I may even be able to put it into Eclipse, haha.

Check out VIDE first to make sure it isn't already doing what you want. If it does not do what you want, one possible approach is to work with Malban to add the features.

Allow the thing to run off of USB power! That way 90% of testing can be done with the Vectrex off

I've thought about this, and I've even experimented with it. But how useful would it really be? You could run the program, but you wouldn't see any of the shapes or any of the motion, you wouldn't hear any sound, you couldn't feed it any input. All it would really do is check your program's syntax.

- Bob

I have ten Vectrex32s available for purchase. If you'd like one, you can buy it here.

- Bob

Oh cool, but if it can go behind the camera and look right surely there must be more to it than just doing the perspective and then clipping in 2D? Plus there's the risk of division by zero if a point has the exact same z coordinate as the camera?

Right. It's a different chunk of code doing the behind-the-camera clipping.

Please keep us up to date on your Vectrex32 work. It sounds interesting.

- Bob

Malban can address this better than I can, but I believe it offers a text editor that you can use for writing the program, a file explorer for viewing the files on the Vectrex32, and a terminal emulator for typing commands to the Vectrex32.

You would not use VIDE's Vectrex emulator while developing V32 games.

- Bob

I was thinking of writing a Tail Gunner game which would have enemy spaceships flying towards and then behind the camera. So I wrote the Vectrex32 code to do the necessary clipping of a line that goes behind the camera. Don't write your own frustum clipping until you test the built-in capabilities.

- Bob

Vectrex32 has a clipping feature for 2D sprites. The way to do 3D fustrum clipping is to apply the 2D clipping feature to the view, after the perspective transform has been done (since, after the perspective transform, 3D sprites have been flattened to 2D). In the Vectrex32 manual, see sections 7.9.5 and 7.6.2.4.

- Bob

Version 1.14 has been released, with new features, a new game, and a new video. If you already own Vectrex 1.10 or newer, you can download the firmware here. If you still have version 1.00, please read this.

Hi Pic,

I've fixed the problem and released a firmware upgrade, version 1.13. I'm now able to load and run your program, even with that large, memory consuming test function you added. You can download the firmware from http://vectrex32.com/version-1-13-upgrade/ and follow the instructions to install it.

Keep in mind that Vectrex32 compiles your BASIC program into an intermediate form that consumes a lot more memory than the BASIC code itself does. Still, I was able to find several opportunities for reducing memory usage.

I'm a little puzzled by the way you make Lines sprites. You create arrays with "M" and "D" values, then copy them into new arrays, replacing the strings with MoveTo and DrawTo. MoveTo and DrawTo are just built-in constants that are the integers 0 and 1; they consume a lot less memory than the strings "M" and "D". Creating new arrays and copying the values over also uses memory, time, and complicates your code. Why not just define the original arrays with MoveTo and DrawTo?

My only guess is that you were trying to reduce the amount of typing. But if this is the case, you could create global variables M = MoveTo and D = DrawTo, and use those when creating the arrays.

BTW, when I ran your game, it looked very intriguing. I'm looking forward to seeing the finished product.

I hope this helps.

- Bob

Version 1.13 has been released. There are no new features, but memory usage has been improved to allow larger programs.

You can read more about it here and download it from here.

I am able to reproduce the problem. I'm looking into it.

- Bob