Recent Posts

Pages: 1 [2] 3 4 ... 10
11
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
12
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?
13
Feature Requests and Bug Reports / Re: Crashing in live shell
« Last post by Astrosynthesist on April 24, 2017, 09:42:53 PM »
Awesome, and it's a lot of fun so no worries!
14
Feature Requests and Bug Reports / Re: Crashing in live shell
« Last post by Vectrex32 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
15
General Discussion / Re: Adjusting the Frame Rate on Lunar Lander
« Last post by Vectrex32 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
16
General Discussion / Re: Adjusting the Frame Rate on Lunar Lander
« Last post by Astrosynthesist on April 24, 2017, 06:40:34 PM »
Okay, I'm back with further insight.

Try the version of lunar.bas but with the included diff applied to it (or just lunarmod2.bas, which is just that).

Now I'm hitting the frame rate limit you were speaking of before. Specifically, it is 96 fps. (that's the setting from my diff). In my previous post I was testing at 120 fps and that was why the timing was all wrong.
The game now runs perfectly well at 60fps and I recommend playing it at that speed. But pushing it to its limits at 96fps reveals something interesting - a flicker appears on my Vectrex every once in a while, where it misses a frame or two. I'm not sure why.
So by cutting out the TextListSprite references I boosted the maximum possible frame rate from 35 to 96.
I'm wondering if there's another function being called in the program which is another limiting factor. When I adjust the frame rate you can actually hear the scans slow down when changing between 96 and 97 fps. This one will be a bit harder to isolate (at least on my end, only playing with the basic side) but as it stands I think 96 fps is more than adequate for most applications.
Also be aware that all of the data omitted from the screen is now printed to terminal (and the stats appear once per second, mostly as a cheat so I could visually "tick" every second and check that one second for the vectrex is one second in real life. You can change it to frame by frame prints by removing the if statement at the end of the main while loop (exposing the print statement).
17
General Discussion / Re: Adjusting the Frame Rate on Lunar Lander
« Last post by Astrosynthesist on April 24, 2017, 03:05:23 PM »
This post should probably be moved to bug reports...

A few notes:
In lunar.bas, after breaking, you can increase frame rate to 35 and the frame rate will increase. Once you hit 36, it slows down again (and increases from there such that setting to 60 is equal to setting to 30).
This is strange but it gets stranger.
I've narrowed part of the problem to the TextListSprite function.
If you comment all references to those sprites (instructions, stats, msg) out the vectrex is able to boost the frame rate to 120 no problem.
The next weird thing I'm noticing after that is that the timing gets all screwed up. I add the line "call setFrameRate(120)" to the beginning of the code, and the framerate indeed stays at 120, (and the frameRate variable depends on the getFrameRate() call later so that's all fine) and yet the game runs super sluggish. I'm not sure what is calculating the timing that is causing this but I will continue to investigate this a bit later.

Anyways, I'm almost positive the frame rate barrier is not a hardware issue but just a bug as stated above. I believe this because I can stop what's running, create a simple text sprite, and adjust the frame rate as high or low as I please without problems.
18
Feature Requests and Bug Reports / Crashing in live shell
« Last post by Astrosynthesist on April 24, 2017, 02:16:31 PM »
v1.14
Boot Vectrex32, hit ^C to enter live shell
I noted that if I'm in the middle of creating a while loop in the live shell, such as:
Code: [Select]
move = 122
while 1
call MoveSprite(-50,0)
call TextSprite(move
And then I realize I forgot something so I break to get out of it:
Code: [Select]
move = 122
while 1
call MoveSprite(-50,0)
call TextSprite(move^C
I usually have to hit enter for the break to register.
Then the very next command I enter soft crashes the Vectrex 32.
(The two I've tried are print(move), print(), and call MoveSprite(50,0), all of which crash the Vectrex32.
It then reboots to the standard menu (no errors output on terminal)
Then I once had it crash again and reboot without even connecting to the shell.

From the testing I've done, this happens in these circumstances but it's hard to make happen using any general commands. It might involve function calls as this also works:
Code: [Select]
while 1
call MoveSprite(0,50)
call MoveSprite(1,50)^C
19
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
20
Easy to replicate technique for vectrex32 crash in Demo3d:

Hold Button 3
Hold stick left

The first tie fighter should whizz off to the left and in a matter of a few seconds the vectrex32 will crash (I get ejected from my terminal session), then the vectrex/vectrex32 will reboot with the typical vectrex32 title screen (but interestingly with a highscore of 0 appearing as well), and it functions as normal again.
Pages: 1 [2] 3 4 ... 10