Messages

I'm working on a fix for the crashes: the final MoveTo in a sprite will be discarded if the next sprite is a ReturnToOrigin. Would you be willing to beta test it?

Since this means coming out with a new version, are there any other features (or bug fixes) you'd like to see?

- Bob

Would this workaround slow the process down at all, Bob?

You mean putting interrupt handling code in the 6809's RAM? No, that shouldn't slow things down appreciably. Copying the code is a one-time thing at the beginning of the BASIC program - just remember to remove the CodeSprite after it runs once. Then there's the usual caveats about keeping your interrupt handler short and fast.

- Bob

If the built-in 3D transforms aren't meeting your needs, the solution is for me to upgrade them, not for you to implement your own 3D code in BASIC.

I see that Demo3D also crashes when objects are behind the camera. I think I need to work on this.

- Bob

Well, you want the floor to go to the bottom of the Vectrex screen, but that doesn't mean it has to have a Z offset of zero relative to the camera. Fiddling with the zoom or the tilt of the camera might accomplish the same effect.

- Bob

Why not just move the scene further away from the camera? Having it end right at the camera is like putting your eyeball right up to something. The player wouldn't expect to be that close to the lightcycles or playing surface.

- Bob

Hi Jaymz,

I wasn't able to reproduce the crash until I switched to "call ScaleSprite(64, 324 / 0.097)". To be honest, I didn't try very hard; this game goes really fast!

Anyway, when I changed the ScaleSprite, it crashed immediately, as you said it would. So first I called DumpSprites() to get a list of all the sprites. Comparing the error message to the sprites in the dump, I saw that the offending sprite was number 7 in the list.

So I got a handle to the 7th sprite with "s = DrawingListSprite(7)". Then I got the details with "call SpritePrintVectors(s)". That shows the coordinates for each phase of the calculations. I saw this:

Code Select Expand

Raw data (meters):
mode = MoveTo, x = -32, y = 0, z = -32
mode = DrawTo, x = -32, y = 0, z = 32
mode = DrawTo, x = 32, y = 0, z = 32
mode = DrawTo, x = 32, y = 0, z = -32
mode = DrawTo, x = -32, y = 0, z = -32
View coordinates: (meters)
mode = MoveTo, x = -32.1293, y = -4, z = 7.53032
mode = DrawTo, x = -17.5251, y = -4, z = 69.8418
mode = DrawTo, x = 44.7864, y = -4, z = 55.2375
mode = DrawTo, x = 30.1821, y = -4, z = -7.07393
mode = DrawTo, x = -32.1293, y = -4, z = 7.53032
z-clipped coordinates (meters):
mode = MoveTo, x = -32.1293, y = -4, z = 7.53032
mode = DrawTo, x = -17.5251, y = -4, z = 69.8418
mode = DrawTo, x = 44.7864, y = -4, z = 55.2375
mode = DrawTo, x = 31.8401, y = -4, z = 0
mode = MoveTo, x = 0, y = -4, z = 0
mode = DrawTo, x = -32.1293, y = -4, z = 7.53032
Projected coordinates: (units)
mode = MoveTo, x = -6682.09, y = -831.899
mode = DrawTo, x = -416.093, y = -94.9708
mode = DrawTo, x = 1341.97, y = -119.855
mode = DrawTo, x = 106352, y = -13360.8
mode = MoveTo, x = 0, y = -13360.8
mode = DrawTo, x = -6682.09, y = -831.899
Clipped coordinates (units):
mode = MoveTo, x = -255, y = -97.2509
mode = DrawTo, x = 255, y = -104.47
mode = MoveTo, x = -6682.09, y = -831.899


So when the sprite gets projected from 3D to 2D, the coordinates get huge. That last MoveTo is what's causing the crash. What happened was that the clipping code realized that the last DrawTo in the projected coordinates was completely outside of the clipping rectangle, so it changed the DrawTo to a MoveTo (the line is clipped, so nothing should be drawn, but the pen still needs to be moved to the endpoint so it's in position to draw the next sprite, and that's why the MoveTo isn't eliminated).

The real question, though, is why the coordinates get so big. It's because the object is so close to the camera.  The Z coordinates in the raw data go from -32 to +32. The camera is at {1, 4, -32}, so the object is right up against the camera and it looks "infinitely" large. Thus, the huge X and Y coordinates.

Hope this helps.

- Bob

No, you can't point an IRQ at a CodeSprite. But at startup, you could have a CodeSprite copy a block of code into the 6809's RAM and set the IRQ to point at that.

- Bob

Sounds like I was over-engineering it.

- Bob

I suspect it's harder than that. The light pen probably triggers a 6809 interrupt when it detects light. Perhaps the interrupt routine sets a flag. Meanwhile, after each line the 6809 draws, it can check the flag to see if that line was selected by the light pen.

But that would only tell you what line was selected. If you wanted to know what point in the line the light pen was at, you would need to know the precise moment the interrupt occurred. Instead of just setting a flag, the interrupt routine would probably read a timer and store its value. Then you'd need to calculate where the pen was at that instant.

It requires a fair amount of code to pull this off. The V32's limited dual port RAM might not be up to it. You could copy some code into the 6809's RAM, but there's not a whole lot of that either.

So at the very minimum, this is difficult. It might be impossible. :-(

- Bob

Welcome Jamel!

There's currently nothing in the Vectrex32 that supports reading a light pen. It's conceivable that you could rig something up using the CodeSprite, which allows you to write machine language into the 6809's memory space. But that would be a challenging project.

I've thought about adding support for the 3D imager and the light pen but I haven't figured out how I would do it. Part of the problem is my lack of understanding of how Vectrex games normally handle those devices. So I'm sorry to say, it's not going to happen anytime soon.

(If anyone does manage to control an imager or light pen with a Code Sprite, I promise I will incorporate it in a new version of Vectrex32 quickly!)

- Bob

Well, the two manuals add up to 120 pages, so if some part of it slipped your mind, we'll allow it. This time.



- Bob

Right. And so is translating a sprite.

- Bob

For the first sprite, you move to (0, 0) and draw to (5,5). At this point, the pen is at (5,5). The second sprite is translated relative from there, i.e. translated from (5, 5) not from (0, 0).

If your sprite were a closed object, i.e. the last line ended at the same point the first line started, you would not have noticed a problem.

Hope this helps.

- Bob

Awesome tool! Thank you for posting this.

- Bob

There's a new version of the Vectrex32 firmware available, version 1.20. This adds several new features as well as dramatically speeding up BASIC execution:

• Add C-like structs
• Add matrix arithmetic: +, -, * (dot product) and / (by a scalar)
• Add matrix functions: norm(), transpose(), cross() (for cross product)
• Add ByRef keyword to specify when arguments should be passed to subroutines and functions by reference instead of by value.
• Add atan2() function.
• Add DeepCopy() function for copying arrays and structs

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.