spillerrec wrote:About the frame rate, I would say it really depends on the situation. In a FPS game, you can easily see the difference between 45 and 60 fps. (At least I can.) While in a racing game I often let the fps drop as low as 20 fps without caring much. 12 fps is way to slow for many applications though.
For a NXT display I would say 12 fps is just fine in most cases. It is better to have a stable slow frame rate than to have a fast choppy frame rate imo. (Btw, in NXT RPG I use 6.67 fps as frame rate, even though it is more than twice as fast as that.)
About the FPS framerate: I originally thought "people who think they can distinguish between framerate > 40 fps are imagining things", but it's true. I've got my own theory why this might be the case: It's not only display update rate that is faster with 60 fps (compared to lets say 45), it's also the sensor input update rate -- i.e. the whole game loop (at least on games of the Half-life 1 era) runs faster. And I believe this is what gamers sense: The faster reaction time, the smoother movement of ther characters.
So when making games and having a limited display update performance, it might as well be worth it to update user input more frequently in a separate thread. Ideally you would also calculate user and enemy positions more often, but this might again lead to performance problems.
What I mean is, that not only update rate, but also latency is important: How long does it take for my user input to get on the screen (as opposed to how often does it get onto the screen).
So, to get back to the NXC game: Maybe maybe try seperating "game logic", "user input" and "display thread", and don't let the interactive part get delayed by the slow drawing routines...