Code Monkey home page Code Monkey logo

Comments (8)

GoogleCodeExporter avatar GoogleCodeExporter commented on September 15, 2024
The SDL2 branch should try to use the desktop video mode on whatever monitor 
you tell it to fullscreen in. Does it work properly if you manually set the 
video mode to 70Hz?

I'm also curious, why is it worse running without X11 than with? You say both 
aren't being vsync-ed, so I don't see what would be the difference.

Decoupling the game speed from frame rate isn't something that's going to 
happen. It's too ingrained into the game logic.

Original comment by [email protected] on 5 Oct 2013 at 9:34

from opentyrian.

GoogleCodeExporter avatar GoogleCodeExporter commented on September 15, 2024
In the first place, there's no vsync in X11 enviroments: you simply got 
asynchronous screen updates, so you get tearing but "smooth" scrolling, even if 
pretty ugly.

Also, in the Raspberry Pi, X11 is unaccelerated: any SDL1.2.x or SDL2 program 
using the X11 backend is slideshow slow.

On the Arm boards running Linux I've seen, it's impossible to change to a 70Hz 
video mode once booted: video mode is established on boot.
So, without a 60FPS mode, we're going to have jerky scroll on most common video 
modes used today.

Original comment by [email protected] on 5 Oct 2013 at 10:40

from opentyrian.

GoogleCodeExporter avatar GoogleCodeExporter commented on September 15, 2024
I know. In windows instead you have compositing and get jumpy scrolling instead 
of tearing. (Which is IMO worse.)

Since changing the internal game tick rate is infeasible (at least to my 
knowledge, Mindless might want to comment if he disagrees) I'm gonna mark this 
as WontFix.

You could try hacking the source so that is simply runs at a 60Hz tick rate. 
That will change the game speed, but at least it will be smooth. (Not a big 
deal anyways, since you can already adjust the in-game speed via the menu...)

Original comment by [email protected] on 5 Oct 2013 at 11:14

  • Changed state: WontFix

from opentyrian.

GoogleCodeExporter avatar GoogleCodeExporter commented on September 15, 2024
I've been fiddling with the sources, desperately trying to hack the game and 
make it running at a 60Hz tick rate, precissely!

Can you help me on how to do it?
Where's the value? How's it derived?

I found a 70Hz rate in src/lds_play.h:#define REFRESH 70.0f, but that's all. 
It's only for the music player, and I need to change the game speed to 60Hz.

Original comment by [email protected] on 5 Oct 2013 at 11:20

from opentyrian.

GoogleCodeExporter avatar GoogleCodeExporter commented on September 15, 2024
The timer routines are in nortsong.[ch]. The game speed is calculated in a 
routine in config.[ch], iirc. It consists of a timer update rate and number of 
ticks to wait between frames.

Original comment by [email protected] on 6 Oct 2013 at 7:27

from opentyrian.

GoogleCodeExporter avatar GoogleCodeExporter commented on September 15, 2024
Ok, Yuri, I got it to refresh screen with a 60.0000Hz refresh rate (60.0017 is 
the exact value in my monitor) by setting float jasondelay = 16.661946f.

But the game is still slightly jerky, showing a desync every few seconds, when 
it should be totally smooth as it's now supposed to be running at the monitor 
refresh rate.

So, in order to fix this final problem, I went and made wait_delay() and 
service_wait_delay() return immediately without blocking on SDL_Delay() calls, 
hoping for the game to run "wild", only blocked by the SDL_RenderPresent() 
function, wich DOES wait for vsync before swapping buffers, thus controlling 
the game speed.
To my surprise, disabling wait_delay() and service_wait_delay() makes the game 
run as fast as the CPU allows: that's wrong, imho. The game should sync to 
monitor refresh rate, something you can rely on if you use SDL2.0. I can 
understand monitor refresh rate is ususally different from 70Hz, so the game 
would run at a reduced speed even if perfectly smooth, but even so, an option 
to run at "monitor refresh rate speed" would be very nice.

Even if you don't want to do that, can you tell me how is it possible that game 
runs "as fast as possible" when the delay functions are disbled if the 
functions SDL_RenderPresent() or SDL_Flip() in old SDL1.2 are supposed to be 
synchronous?
Are the game logic and the video speed control routines running in separated 
threads?

Please, if you're not the person to help me with those questions, I'd be more 
than happy to contact with the adequate developer... I really want to 
understand how all this stuff works and there seem to be some details I'm 
missing here. 

Original comment by [email protected] on 7 Oct 2013 at 2:38

from opentyrian.

GoogleCodeExporter avatar GoogleCodeExporter commented on September 15, 2024
[deleted comment]

from opentyrian.

GoogleCodeExporter avatar GoogleCodeExporter commented on September 15, 2024
As yuriks mentioned, the game logic and frame rate are tightly coupled.  As you 
are no doubt realizing, the mechanism for determining the gameplay speed in 
Tyrian is not simple and, unfortunately, not particularly easy to refactor 
since it is also tied to values in level scripts (level scripts can affect 
gameplay speed).

At Normal speed, the game is supposed to wait 2 70-ish-Hz (1193180 / 0x4300) 
ticks per frame of gameplay, so it's not surprising that the game would run 
fast if you change it to wait for 1 60-ish-Hz tick per frame of gameplay.

Original comment by [email protected] on 7 Oct 2013 at 4:40

from opentyrian.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.