Recent Posts

Pages: [1] 2 3 ... 10
1
General Discussion / Re: Development on PC environment possible?
« Last post by Towlebooth on May 16, 2017, 08:54:28 AM »
Thank you for the patience in answering these questions (and so many more to come I'm sure).  I had the same ones.  I'm looking forward to jumping in!

Chad
2
News and Updates / More Vectrex32s available, now with "no-buzz" support!
« Last post by Vectrex32 on May 12, 2017, 01:36:06 PM »
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
3
News and Updates / Version 1.15 Released
« Last post by Vectrex32 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.
4
No, controller 2 doesn't exhibit the same behavior.

- Bob
5
Now that you've fixed reading controller 2 Y axis, does it exhibit the same behaviour?
If not, could it be some kind of memory conflict?
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
Awesome!

Any luck with the weird Controller 1 Y axis behaviour?
8
I have found these bugs and fixed them for version 1.15.

- Bob
9
General Discussion / Re: Adjusting the Frame Rate on Lunar Lander
« Last post by Vectrex32 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
10
General Discussion / Re: Adjusting the Frame Rate on Lunar Lander
« Last post by Astrosynthesist on April 24, 2017, 10:33:57 PM »
I hadn't considered that possibility but yes the problem occurs with all instances of text being drawn, including the vector font.

I'm a bit confused as to how this whole frame thing works - is it possible that the time it takes to draw one frame is longer than whatever the frame rate would allow, say it's set to 60 fps and the frame takes 1/50th of a second to draw? Is there any way for the Vectrex32 to figure it out and fall back to the highest available framerate?

I could run some timing tests on how long it takes to draw one frame with text to see if my first theory works out, but I don't have any experience in programming the Vectrex in its native assembly (I don't have a flash cart yet!) so as to my second question I'd need to do some "manual digging" if you can't think of anything off hand. (Rereading this I see it's unclear... I mean if there is no way for the Vectrex32 to figure out the max framerate on its own, potentially the Vectrex might have some method for figuring this out) It seems to me that in the original software it doesn't have a fixed frame rate, it changes on the fly based on how many lines are being drawn (however that's completely anecdotal, I have no proof whether it's true or not). If we programmed for the Vectrex32 such that all timing calculations weren't frame-based, would it be possible to compensate for the frame rate issues by not setting a fixed frame rate to begin with?
Pages: [1] 2 3 ... 10