Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Vectrex32

Pages: [1] 2 3 ... 7
1
News and Updates / The V Prize: A bounty for new games
« on: September 05, 2017, 10:14:44 AM »
I am offering US$500 bounties for games to be written for the Vectrex32. See the details at http://vectrex32.com/the-v-prize.

- Bob

2
News and Updates / Yet more Vectrex32s
« on: June 26, 2017, 04:22:03 PM »
Vectrex32s are back in stock. I have 19 available (I had 20 made, but one was DOA). You can order one here.

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

The is a new revision of the hardware that supports all Vectrexes, both the original and the late model "no-buzz" Vectrexes! BASIC programs written on the older Vectrex32s will run on this new hardware and vice-versa (assuming the old Vectrex32s have been upgraded to firmware version 1.15).

- Bob

4
News and Updates / Version 1.15 Released
« on: May 12, 2017, 01:22:31 PM »
Version 1.15 has been released. It consists of bug fixes and a very minor new feature. 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.

Many thanks to "Astrosynthesist" who found and reported many of the bugs.

5
No, controller 2 doesn't exhibit the same behavior.

- Bob

6
Any luck with the weird Controller 1 Y axis behaviour?

You mean where the terrain shrinks? The short answer is "beats me".

I played with it a little.  If I draw the same LEM regardless of the joystick (i.e. the same amount of thrust coming out the rocket bell), the problem still occurs, so it's not that the LEM drawing is affecting the terrain drawing. If I read the joystick as digital instead of analog, the terrain problem doesn't happen.

There's only one digital-to-analog converter in the Vectrex and it's shared between the joystick and the vector drawing. So my hypothesis is that reading an analog joystick affects the D/A converter which affects the screen. I asked Malban about it and he didn't have any experience with it. He said he'd look into it, but he might not be able to get to it immediately.

- Bob

7
I have found these bugs and fixed them for version 1.15.

- Bob

8
General Discussion / Re: Adjusting the Frame Rate on Lunar Lander
« on: April 25, 2017, 09:20:13 AM »
There are other people who know more about this stuff than I do. But I think you want a fixed frame rate throughout the game. Otherwise, the brightness of the lines on the screen will vary and, in the case of the Vectrex, the rhythm and the volume of the buzzing would change!

- Bob

9
Feature Requests and Bug Reports / Re: Crashing in live shell
« on: April 24, 2017, 08:50:07 PM »
I've found and fixed these problems (having to hit Enter after Ctrl+C, and crashing when trying to execute a command). The fixes will be in version 1.15.

Thank you, Astrosynthesist, for all the great work you're doing!

- Bob

10
General Discussion / Re: Adjusting the Frame Rate on Lunar Lander
« on: April 24, 2017, 07:29:26 PM »
I've been told that drawing text takes a long time on the Vectrex. That may be why it decreases the maximum frame rate so much.

- Bob

11
I found the bug in my code that prevented the V32 from reading the Y axis of controller 2's joystick. It will be fixed in the next firmware release.

- Bob

12
General Discussion / Re: Adjusting the Frame Rate on Lunar Lander
« on: April 20, 2017, 09:05:52 PM »
I've seen that too, and investigated it a fair amount. What's happening is that the Vectrex/V32 system seems to have a maximum frame rate somewhere around 60 or 80. I don't know if the limiting factor is the Vectrex or the Vectrex32. When you jack the frame rate up to 120, the screen refreshes at around 60 to 80 fps, but since the V32 is using 120 as its time base, the timing of the game is thrown off.

- Bob

13
I'm wondering that too. I don't have an answer yet; I'll have to investigate.

- Bob

14
I can confirm that Controller 2 doesn't seem to be working right.

15
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

Pages: [1] 2 3 ... 7