Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - bastien

Pages: 1 ... 4 5 [6] 7 8 ... 13
76
Python / How to display window in a separate thread/process?
« on: November 20, 2011, 11:42:38 pm »
Quote from: "kolofsson"
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.


Unless you have very specific needs, there's no reason why you would want more than, say, 60 FPS. Your application can run for an extended period of time, and it will waste a lot of resource if you try to avoid sleeping after each iteration of the main loop.

Quote
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()


That's kind of scary. :)

Quote from: "kolofsson"
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.


To be clear, the window only gets opened at the start. window.opened simply returns True if the window is currently opened, until you call window.close().

Quote from: "kolofsson"
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?


Not that I know of. You can probably get it with OpenGL, but you can't do OpenGL calls with this binding currently.

77
Python / What version of Python for Windows 7 64 bit?
« on: November 20, 2011, 11:01:28 pm »
Thanks. I'll try to compile the standard library statically.
I guess the other errors are due to this:

Quote
Missing delay-load dependencies are not a problem as long as the calling DLL is prepared to handle the missing module. Dependency Walker flags all potential problems as it cannot detect if an application intends to handle the issue.


http://www.dependencywalker.com/faq.html

78
Python / pysfml2-cython
« on: November 20, 2011, 10:55:34 pm »

79
Python / How to display window in a separate thread/process?
« on: November 19, 2011, 12:23:29 am »
Quote from: "kolofsson"
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?


Global variables need to be used sparingly, and I would recommend to avoid them because they can be misused easily in Python:

Code: [Select]
global_var = 0

class Thread(threading.Thread):
    def run(self):
        global_var = 1


This code doesn't modify the global object, it creates local object named global_var. You need to write “global global_var” to let Python know you want to use a global variable.

If you pass a reference to the thread, you need to be careful too, because some basic types are immutable. If you pass a bool to a function, the function can't modify the bool object itself (the one referenced from the caller), so all it can do is create a new bool object and store it in a local reference.

If you just create a class containing the thread data, you won't have these problems:

Code: [Select]
import threading

class ThreadData(object):
    def __init__(self, window):
        self.window = window


class Thread(threading.Thread):
    def __init__(self, data):
        threading.Thread.__init__(self)
        self.data = data

    def run(self):
        for event in self.window.iter_events():
            pass


In your thread's loop, you can use a clock to retrieve the elapsed time since the last loop iteration, decide if you need to go idle, and if so call time.sleep().
I'm not familiar with multithreading with SFML, but I don't remember reading that you need to be especially careful about the window object when handling its events in one thread and displaying stuff on it in another thread. But maybe I've just missed/forgotten some information.

Now, the thing with Python is, only one thread will run at once. What I can do in the binding is allow another thread to run while waiting for a function to finish, like window.display(). But I haven't done this kind of optimization yet because I'd like to have some real world example of the performance benefit it gives.
An easy to have true parallelism is to use processes instead of threads, but processes don't share memory by default, so if you want to share e.g. sprites it's easier with threads.
If you have some performance heavy code, you can also write it in C or in Cython and then nothing the threads from running at the same time (as long as you release the global interpreter lock).

80
Python / What version of Python for Windows 7 64 bit?
« on: November 18, 2011, 10:55:05 pm »
Can you use this tool to see which libraries fail to load?
http://www.dependencywalker.com/

81
Python / pysfml2-cython
« on: November 18, 2011, 05:36:14 pm »
Pygame is nice, I've used it for some time but it's based on SDL and it doesn't totally solve its problems.
Generally speaking, SDL's API gives you access to the screen as an array of pixels where you do every effect with the CPU, which doesn't really make sense nowadays. You used to have to implement scrolling and zooming manually.

With SFML, you can use effects like zoom or rotation on any drawable, or use views to apply effects to the entire scene, and it will use 3D acceleration behind the scenes. You can also use shaders easily.
With Pygame, as far as I know, the closest thing is a limited module. It's not well integrated in the API.

The upside for Pygame is that SDL is very stable and portable, and if you really don't need the features of SFML, you know your program will run everywhere. Personally, my open source driver on GNU/Linux became able to handle even basic 2D stuff only fairly recently with OpenGL/SFML. Somewhat paradoxically, SDL's software rendering seems to work a lot better with crappy driver support.

82
Python / How to display window in a separate thread/process?
« on: November 18, 2011, 05:15:15 pm »
Usually, this happens because you have some state growing with every frame instead of, say, every second. You want to avoid making your code dependent on frame rate, otherwise the game will progress differently based on the machine's performance and the game configuration (if the user can tweak frame rate or vertical synchronization). If you look at the pong example, the balls move in proportion with window.frame_time rather than in with every frame.
I don't know what you're trying to do exactly, so I can't really help you.
I don't think multithreading is the right way to solve this.

83
Python / What version of Python for Windows 7 64 bit?
« on: November 18, 2011, 05:12:38 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.

84
Python / What version of Python for Windows 7 64 bit?
« on: November 17, 2011, 12:59:42 pm »
I think you should use SFML 2, for the reasons mentioned here: http://pysfml2-cython.readthedocs.org/en/latest/introduction.html#why-sfml-2

Python 2.x and Python 3.x are not compatible. It's explained here: http://wiki.python.org/moin/Python2orPython3
Once you've chosen the major version, you should get the latest version available (e.g. 2.7).
 
Strictly speaking, Python 3 is better, but a lot of libraries still haven't been ported and the changes aren't really huge anyway, so a lot of people stick with Python 2, including myself.

I haven't tested pySFML 2 on Windows 64 bits, but normally, 32 bits applications run fine on 64 bits systems.

85
Python / pysfml2-cython
« on: November 07, 2011, 12:00:57 am »
Quote from: "kolofsson"
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.


Using pythonw.exe instead of python.exe as the interpreter should fix it. The simplest way is to rename your entry point file to .pyw (for example, main.pyw). The Windows installer associates .pyw files to launched with pythonw.exe. This problem doesn't happen on Unix.

Quote from: "kolofsson"
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.


You're right, I just added it in the Git repo: http://pysfml2-cython.readthedocs.org/en/latest/graphics.html#sf.RenderWindow.vertical_sync_enabled

I'm not really happy with these boolean attributes that you can set but not get, I guess I'm going to add getters myself. But it would be simpler if SFML had methods to do that directly.

86
Python / pysfml2-cython
« on: November 06, 2011, 11:47:46 am »
Finally I built it from scratch in a virtual machine, here is a ZIP that should contain everything you need: https://github.com/downloads/bastienleonard/pysfml2-cython/python2-sfml2-cython-win32.zip

I'm especially interested to know if it works on machines that don't have SFML installed.

87
Feature requests / SFML should use only types of defined size
« on: October 29, 2011, 05:21:03 pm »
Quote from: "deadalnix"
Well nothing more than 32 -> 64 bits arch can sometime lead to funcky linking error in klingon (native language of the linker). And people rusually don't have both architectures ready to test.


Quote from: "deadalnix"
gsaurus > I didn't mesure that, so this is speculation, but I don't thnink working on a 32 bit value is slower than on a 64bit one on recent intel's or AMD's CPU.


The “default” integer size on x86-64 is still 32 bits. The rationale is that most of the time you don't need 64 bits integers, and if I remember correctly, using 64 bits all the time would make the code larger because immediate values are coded on 64 bits (I wouldn't be surprised if it requires a prefix too). They could probably have made the 64 bits instructions smaller, but as I said you don't need them most of the time and the instruction set needs to be backwards-compatible, so staying with 32 bits integers by default is fine.
In the end, I believe that all the PC C compilers have 32 bits ints on 64 bits operating systems. The main difference is that Microsoft decided to stick with 32 bits long ints on Windows 64 (!): http://msdn.microsoft.com/en-us/library/3b2e7499.aspx.

Personally, I wrote a Python binding for SFML 2 and I don't remember having problems working with integers with non-specific size. You can assume that the C++ int is at least 32 bits wide, and in practice almost all the platforms that run SFML probably have 32 bits ints, although you shouldn't rely on it.

88
Python / pysfml2-cython
« on: October 28, 2011, 12:02:55 am »
I forgot you're using Visual Studio. :/
SFML uses floats, pure Python only has the equivalent of double (although they are called floats in Python). So in the end there's no way to prevent the user to use double precision, but I don't think that's a real problem. The warnings come from the code generated by Cython, I can't control them directly.

By the way, normally you can create an installer with “python setup.py bdist_wininst”.

89
Python / pysfml2-cython
« on: October 27, 2011, 09:27:54 pm »
When I try your Pong example with my sf.pyd, I get this:

Code: [Select]
err:module:import_dll Library libgcc_s_sjlj-1.dll (which is needed by L"Z:\\home\\bastien\\Desktop\\pong\\sf.pyd") not found
err:module:import_dll Library libstdc++-6.dll (which is needed by L"Z:\\home\\bastien\\Desktop\\pong\\sf.pyd") not found
Traceback (most recent call last):
  File "main.py", line 9, in <module>
    import sf


Could you copy-paste here the command-lines that are issued when you build the binding? I guess I missed something to include the standard libraries.
Also, for some reason the SFML libs I cross-compiled aren't even detected by Wine.

90
Python / pysfml2-cython
« on: October 26, 2011, 11:00:14 pm »
I just compiled something that looks like a Win32 module, but I can't get it to work with Wine (it tells it can't find dependent DLLs, even when they are in the current directory).
Can someone test it on Windows and tell me if it works? Here is the direct link: https://github.com/downloads/bastienleonard/pysfml2-cython/sf.pyd

Pages: 1 ... 4 5 [6] 7 8 ... 13