Messages

16

Window / How to achieve high framerate with Vertical Sync?

« on: November 20, 2011, 02:31:22 pm »

Hi Laurent. I tried doing this with threads but I found it too complicated.

Instead I created an IF inside the main loop which omits the display method until it is very close to Vsync. Thanks to this trick the main loop runs 6000 times per second instead of 60.

Code: [Select]

def main():
   window = sf.RenderWindow(sf.VideoMode(800, 600), 'Window', sf.Style.DEFAULT)
   window.vertical_sync_enabled = True

   last_display = time.clock()
   while window.opened:      
      for event in window.iter_events():
         #handle events

      if time.clock() - last_display > 0.016:
         window.clear(sf.Color(200,   0,   0))
         window.display()
         last_display = time.clock()

The problem is, I set the value 0.016 to just under 1/60 of a second, which is suitable for a refresh rate of 60 Hz. With a different refresh rate it would be a disaster as the display would miss every second frame and wait twice as long.

So I have a few questions:
1. Is it possible to get the screen's refresh rate with SFML? The one that is used when Vsync is on.
2. If not, would it be difficult to implement a renderwindow.GetFramerate?
3. Do SetFramerateLimit and EnableVerticalSync override each other?
4. When initializing a window in full screen, is it possible to select a refresh rate? For example my display can work in 60 Hz or 75Hz for certain resolutions.
4. Should not screen refresh rate be a part of VideoMode?

A perfect solution for me would be:
- get list of video modes, together with refresh rate
- initialize a window e.g. (800,600,fullscreen,refresh_rate=60)
- enable vertical sync

Then I would know the refresh rate and could set my code based on that.

17

Python / How to display window in a separate thread/process?

« on: November 20, 2011, 02:13:39 pm »

You see, the problem is that I would not like to tell the app to sleep, I would not like to waste the computational power, I would prefer to handle window events in the meantime. The window.display with vsync enabled goes to sleep and waits until it is safe to write the buffer.

I actually figured out a workaround that looks like this:

Code: [Select]

import time
import sf

def main():
window = sf.RenderWindow(sf.VideoMode(800, 600), 'Window', sf.Style.DEFAULT)
window.vertical_sync_enabled = True

last_display = time.clock()
while window.opened:
for event in window.iter_events():
#handle events

if time.clock() - last_display > 0.016:
window.clear(sf.Color(200,   0,   0))
window.display()
last_display = time.clock()

if __name__ == '__main__':
main()

The crucial part is if time.clock() - last_display > 0.016:. Without it I get 60 FPS. With it I get 6000 FPS! That's because This little if triggers the display just before the Vsync window get opened, which makes the display wait time minimal.

However, the 0.016 value will only work for 60 Hz. For different refresh rates bad things will happen. Btw, is there a way to retrieve screen refresh rate in SFML?

18

Python / What version of Python for Windows 7 64 bit?

« on: November 18, 2011, 10:33:19 pm »

Don't forget that I uploaded a compiled module for 32 bits Windows (should also work on 64 bits) that contains SFML and dependent DLLs: https://github.com/bastienleonard/pysfml2-cython/downloads
But nobody commented about it, so all I can say is that it works on my XP machine where SFML is already installed.

Oh yes I was going to test this, so I did. It does not work for me. The error happens on import sf: Cannot find module. I pasted all SFML libs, ext libs and sf.pyd along with the py file. When I replaced them with my libs, it worked.

Here are my libs:

http://grebocin.com/upload/pysfml2.zip

These libs were compiled for Windows 32bit Python 2.7.2 using VC++ 2008. This means that to run it you need to install the VC++ 2008 redistributable. The redistributable contains common libraries for all programs compiled in VC++.

19

Python / How to display window in a separate thread/process?

« on: November 18, 2011, 07:36:03 pm »

Threading IS the right way to do it, as Laurent told me himself. I want to depend my calculations on time as well, I just do not want to be limited to 60 frames per second. I would prefer 600 frames, or as much frames as the machine can handle. Differences between machines won't occur because all movement will be based on frame time.

So I'm asking if you know how to do implement it in python?

The design of my app:

thread 1: (done e.g. 600 times per second)
- get window events (keyboard input)
- send/receive network packets
- do physics calculations
- move sprites

thread 2: (done e.g. 60 times per second)
- a loop that draws sprites and displays them on screen

I just don't know how to share the window object and the sprites between two threads. Man, I don't even know how to share an object between two functions. Should I use global / static or keep passing the object by reference somehow?

20

Python / pysfml2-cython

« on: November 18, 2011, 02:17:38 pm »

Hey Bastien. I've been looking into Pygame and it looks nice so I'm wondering if you could tell me why did you decide to make PySFML. Was it speed, ease of use, more capabilities or SFML? If you ever used Pygame, what are the pros and cons in relation to PySFML?

Also, if you could look at my multithreading question post, I would be greatful.

21

Python / What version of Python for Windows 7 64 bit?

« on: November 18, 2011, 12:30:10 pm »

Hi ingwik

If your students have VS2010 on their PC's, then in makes no sense at all to uninstall it on all their machines. Remember that the only reason you need Visual Studio is to compile the SFML libs and the PySFML binding. You can do that at home and then just distribute the libs to the kids. Also, I can give you my compiled libs and save you some work. I'm at work now and don't have these files on me and I keep forgetting about it when I'm back home.

Regarding the 32bit-64bit. You can run and compile 32bit apps on Windows 7 x64, because it supports 32bit natively (it does not support 16bit app though). There are two differences between 32bit and 64bit: speed and compatibility. 64bit is faster but 32bit will run everywhere. I should mention that most computer games and applications are made in 32bit (it's logical since majority of people still have 32bit systems installed, so bigger customer base).

Python 2.7 vs Python 3: If you don't want to distribute your python apps, use python 3, but if you want to make EXE files, I suggest Python 2.7.

So for the list of steps, I suggest:
1. Tell your students to install Python 2.7.2 32bit.
2. Get PySFML libs from me.
3. You may need to install MSVC++ 2008 Redistributable package
4. Either use IDLE that comes with Python or install one of these editors.

22

Python / How to display window in a separate thread/process?

« on: November 17, 2011, 08:30:02 pm »

Hi. I'm practicing with PySFML. I made a simple app that measures user response with a timer. To avoid mad refresh rate I enabled vertical sync. This is where the problems start. Without Vsync the results were accurate, but with Vsync on they are rounded according to the refresh rate of the screen. For example on my PC i keep getting results like 0,2333 second (14 / 60). This is because the window.display() function waits for the vertical sync and pauses the whole app. For me, this is unacceptable.

So there goes my question: How to move the display code to a separate thread or process? I read some tutorials on thread, threading and multiprocessing libraries, but they all seem to have a problem in accessing shared objects. I want to handle input and drawing in separate threads, and both reside in the same sf.window object. Is there a way to solve this?

Big thanks up front for help!

23

Python / What version of Python for Windows 7 64 bit?

« on: November 17, 2011, 04:37:48 pm »

So, in short:
*I should use Python 2.7.2.
*I should use SFML 2.0 - but I have to compile it myself with VC++ 2010 express since it is intended for 64 bit system.

Then I assume python 2.7.2 will work with SFML 2.0 compiled for a 64 bit system, or do I have to compile SFML for a 32 bit system?

No no no no no.

What you're saying creeps me out so much I want to shout .

I'm a python noob and I went through all shit myself recently.

I installed both python 2 and 3 and what I can say is that Python 3 works fine, but it fails when I want to make a redistibutable exe file of my app to share with other users. PyInstaller which is the best app that packages all dll files in one EXE does not support Python 3. That is why I went back to Python 2.

About compiling SFML: You do need to compile it yourself, but why 64bit version? If you compile SFML in 64bits then it will not work on ANY 32bit windows (including windows 7). If you compline SFML in 32bits, you get library that will work on both 32bit and 64bit systems.

This is the most important advice: DO NOT COMPILE SFML USING VS2010. Python was built using VS2008 (MSVC 9.0) and all Python-based software wants to build other libraries using this IDE. If you have VS2010 you will go though a lot of errors, starting with installing Cython. Solution: Install Visual Studio 2008 and compile SFML and PySFML with it.

Also, don't install Pyhton 3 if you're using MinGW, i think it does not support Unicode, right?

To finish off, I can upload my own compiled SFML and PySFML, along with a working Pong example if you wish, this will save you a lot of the hassle.

24

General / Sprite moving speed same on all computers

« on: November 14, 2011, 11:07:35 am »

Yes, you are definitely overdoing it, even theoretically, with the seconds-per-frame .

By the way, I think the variable that you named "speed" should be called "velocity". Velocity is a vector, it has direction AND value, speed has just a value. Of course, I'm aware you may already know that and use the name "speed" for convenience.

I'm sure you know this equation:

Code: [Select]

average velocity = position change / time change

Since we are looking for position change, we can transform this equation into:

Code: [Select]

position change = velocity * time change
[m] = [m/s] * [s]

To calculate time change, I suggest measuring gaps between each frame.

Code: [Select]

sf::Clock clock;
Uint32 last_frame = clock.GetElapsedTime();

while (game_running)
{
time_diff = clock.GetElapsedTime() - last_frame;
sprite.Move(velocity * time_diff);
}


Remember that time_diff is in milliseconds, so if your velocity is in meters per SECOND, divide time_diff by 1000 so it's in seconds as well.

25

Window / How to achieve high framerate with Vertical Sync?

« on: November 07, 2011, 12:24:19 pm »

Guys, thanks for the feedback, I appreciate it .

What if I don't lock the rendering thread and it will get interrupted in the middle of executing window.display() and switch to the calculation thread? What if the graphics card decides to render the buffer to the screen in that particular moment? Will it result in display tearing, thus negating the effect of Vsync for that frame? Or maybe the window.display() method contains some mutex inside it that prevents interruption while filling the screen?

26

Window / How to achieve high framerate with Vertical Sync?

« on: November 07, 2011, 09:59:39 am »

Would multi-threading be an option?

The only one.

OK, so if threading it is, then let me ask once more:
Would Vsync work if I did not lock the thread while calling window.display()? Clearly, locking the thread would be missing the point, since the delay is caused by window.display(). On the other hand, I'm not sure what would happen if I interrupted while it was running. Would it not be like jumping out of a train? . I wonder how big is the gap that the graphics card leaves between each frame for apps to fill the buffer, compared to the time that takes to fill the buffer.

I think some kind of boolean would be useful, like Is_Buffer_Being_Used or Is_It_Safe_To_Fill_The_Buffer_Now . Then, after checking one of these, I could safely lock the thread until window.display() finishes it's work.

27

Window / How to achieve high framerate with Vertical Sync?

« on: November 06, 2011, 11:09:06 pm »

Hi. If I am correct, enabling vertical sync pauses the app each time window.display() is called, so that the buffer is not overwritten while the graphics card renders it. This means that the main game loop will be repeated the number of times equal to the refresh rate (e.g. 60).

What if I wanted to achieve more calculation frames per second (e.g. I'm making an F1 game and I want to count lap times in milliseconds, or I make a multiplayer game and I want to process the data from sockets the moment they arrive)?

Would multi-threading be an option? 1 thread for physics calculations, other thread for rendering stuff? Would vsync even work if I did not lock the window.display() method?

Also, what happens if Vsync is enabled to 60 FPS (new frame is rendered every 17 milliseconds) but my main game loop lasts a constant 20 ms? Will SFML "miss the train" and wait to catch the next one (34 ms), thus reducing the effective framerate to 30 FPS?

28

Python / pysfml2-cython

« on: November 06, 2011, 10:35:47 pm »

Hey Bastien I've got a question. When I run PySFML apps I have 2 windows - the black console window and the proper app window. Is there a way to get rid of the console window? In SFML there was a special library for that, it would initialize the main function so that the console window does not appear.

Also, I can't find the implementation of sf::Window::EnableVerticalSync. Is it possible to enable vertical sync in PySFML? I see it's only possible to limit the framerate to a fixed value, but how should I know the refresh rate of a given display mode? If I set it to 60, it will be incorrect for those who have 75 of 100 Hz.

29

General discussions / Switched times to Uint32 milliseconds in SFML 2

« on: November 05, 2011, 03:44:10 pm »

milliseconds  are too unprecise for some measurements, and very cumbersome for everyday work (seconds are usually easier to imagine and to work with)

Exactly! If I'm using the standard SI physical units and want to calculate car/ball movement in a single frame, I have to multiply velocity (meters/second) * delta time (milliseconds) and divide it by 1000. This is really neither fast nor elegant.

EDIT: Since I'm using Python (and still learning it), I found a neat function in Python called time.clock(). The description from the docs: a floating point number, based on the Win32 function QueryPerformanceCounter(). The resolution is typically better than one microsecond.


I guess, bye bye sf::timer

30

General discussions / Switched times to Uint32 milliseconds in SFML 2

« on: November 05, 2011, 01:42:12 pm »

This is most likely what is happening with my game, specially during window drag/resize when display is ignored, truncations make my game run a little bit faster . Any suggestion?
I see two different uses of clocks: longterm and precision measurements, sometimes I wish there were one clock for each.

Yes we could have a float precision clock, what's the problem, what's the harm?

Gsaurus, I guess a global timer would help you. Then, each frame you could store the timestamp in an array:

Code: [Select]

timestamp[frame_number] = gettime()

And then, to get the time elapsed:

Code: [Select]

time_elapsed = timestamp[current_frame] - timestamp[current_frame - 1]

if time_elapsed equals 0, skip this iteration of the loop.