Adjusting the Frame Rate on Lunar Lander

[Astrosynthesist]

Has anyone successfully adjusted the frame rate for LL?

I tried calling setFrameRate(120) at the beginning of the code, which did speed up the text and stop the text from flickering, but then when the game starts everything runs very slowly (as in the timing seems to be wrong: rotations are slow, gravity is slow, etc, but the unit itself is running at the correct speed) and the flicker is still present. I'm wondering if I'm missing something.

Thanks

[Vectrex32]

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

[Astrosynthesist]

In your docs you mentioned that heavy computation might slow down the frame rate... next time I play around with it I'll start removing blocks of code here and there until I find whether or not the limiting factor is one particular call or a combination of everything that's causing the slowdown. I'll probably be playing with it again on Saturday or Sunday.

[Astrosynthesist]

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.

[Astrosynthesist]

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).

[Vectrex32]

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

[Astrosynthesist]

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?

[Vectrex32]

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