Messages

151

General / VS2010 C#/.NET and SFML 2.0

« on: February 13, 2011, 07:40:55 am »

A Google search gave this command:

Code: [Select]

%comspec% /k ""C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"" x86

152

Graphics / Draw seems to be not correct.(sprites)

« on: February 13, 2011, 12:36:06 am »

Try with Image.SetSmooth(false)? Otherwise it's probably a bug in your code in my opinion.

153

General / Help - lag

« on: February 09, 2011, 06:47:37 pm »

Are you on Windows actually? :? Just make sure your drivers are up to date then, but it shouldn't be a problem.

154

General / Help - lag

« on: February 09, 2011, 06:14:49 pm »

My bet is that your graphic driver has poor acceleration. Are you using ATI or Intel's free driver?

Sadly, software solutions like SDL seem much faster than OpenGL with these drivers.

Edit: it's still strange that such a simple program is slow. Maybe there's something wrong in it, but the snake program is probably slow just because of drivers.

155

Python / Python binding generation tools

« on: February 08, 2011, 09:15:41 am »

I started working on this project again and just cleaned up some code. My memory is a bit blurry about what was going on so I'd like to get your input about the development.

This is just a test for SFML 1.6. Personally I don't plan to learn SFML 2 before an official release, but at the same time this is just a basic proof of concept so it probably won't be too much of a hassle to port it.
Also I guess some people will disagree with the conventions I use (e.g. with properties instead of get/set methods). Personally I just started this as a personal project so I don't bother about it too much, but if the official binding is ever written with Cython we'll need to agree on the convention.

The source is here: https://bitbucket.org/bastienleonard/pysfml-cython
The current generated documentation can be found here: http://bastien-leonard.alwaysdata.net/doc/index.html

As I said earlier, I don't have any former experience for writing native modules, so it's possible that the way I'm doing things is totally crappy.  :roll:

In the most simple case, I just write a class with a p_this attribute which points to the C++ instance. __cinit__() creates the C++ object, __dealloc__() (destructor) deletes it.

If I need to wrap C++ objects into Python objects arbitrarily, I add a boolean delete_this attribute in the class, which tells __dealloc__() whether or not it should delete the C++ object.
For example, RenderWindow.GetDefaultView() returns a view that doesn't need to be freed, so delete_this must be set to False.
I also need to bypass the default contructor, so I call View.__new__(View) instead.
Previously I did this sort of stuff anywhere needed in the code, but it was error-prone, so now I write wrap_Xxx_instance() functions that do this kind of work. They automatically set delete_this to False, which means that at least we won't get a segmentation fault or similar, but maybe the C++ object won't be freed because SFML didn't free it either. Looking at the code right now I can't tell if it's a problem or not.

For the events union, there's a single attribute in Event containing the “detailed” event (e.g. KeyEvent). It's never used directly by the user, instead he uses properties like key or mouse_move that check that the event parameter is of the right type and raise an exception otherwise. It's probably a bit slower but it will save some bugs (Python programmers won't necessarily directly realize the implications of the C++ attribute being a union).

I guess the next step is to write class/static methods e.g. for loading images instead of creating dummy objects just to initialize them with another method.

156

Python / Python binding generation tools

« on: February 08, 2011, 08:38:40 am »

Also, what about renaming the module to pysfml ? I never liked the ugly PySFML.sf import, ans as we have import aliases in python, there's no need to abbreviate it's name to sf.

I don't like this way of importing either, but I thought sf.so could simply be dropped in site-libs/ so that you just need to type “import sf”.

I just use the sf namespace so that it's the same as SFML, and because it's three times shorter to type. Someone who's used to to PySFML can easily rename it with “import sf as pysfml” anyway.

157

Python / Subclassing Drawable

« on: February 08, 2011, 08:33:00 am »

There's no need to inherit Drawable, actually I believe that Laurent didn't intend end-users to do it at all.

158

General / how to Program object oriented???!!!

« on: November 15, 2010, 03:11:09 pm »

Quick Tutorial

Code: [Select]


sf::Image* pImage = new sf::Image();
sf::Sprite* pSprite = new sf::Sprite();

pImage->LoadFromFile("MyImage.png");

pSprite->SetImage( (*pImage) ); // - Remember to include Pointer in brackets, prefixed with an asterix.

pMyRenderWindow->Draw( (*pSprite) );


The easy way to object-orientate SFML.

(Hope this helps!)

Beside the fact that you use dynamic allocation and parenthesis for no reason, I don't see anything special here.
I think pretty much everyone agrees on the fact that good object-oriented programming mainly comes from how you design the relationships between your objects for a specific problem; it's not just applying a generic pattern.

Personally I think there's nothing wrong about starting with the most simple implementation (which is often procedural), then tailor it as needed when the project grows, especially when it's a personal project and no OOP zealot will harass you.

By the way, “pure OOP” in languages such as C++ and Java is just bullshit. When a zealot talks about such things just ignore him. Any worthy design practice has straightforward advantages which should be easily explained; if someone instead keeps talking about how the gods of object-oriented programming don't like your design, then he doesn't know what he's talking about.

159

General discussions / SFML 2.0

« on: November 13, 2010, 10:06:14 am »

I don't care about other back-ends, OpenGL is widely implemented and every new hardware supports an OpenGL variant by default. And SFML is an OpenGL library by definition, its interface is made to mix nicely with native OpenGL calls.

As a side note, crappy drivers make 2D programs terribly slow, on GNU/Linux at least.
My laptop has Intel's driver, but it can just display like 100 sprites at 60 FPS. The LinCity game runs fine with the SDL backend, but the OpenGL one is terrible. Generally speaking, I can't imagine that games like Wesnoth would run fine on it if they used OpenGL since I already have trouble displaying 200 sprites with SFML.
My desktop computer has the same problem, but it uses a WIP open source driver, so it's somewhat normal.

So I'm all for OpenGL, but it's sad to see SDL has much better performance on the computers I use.

160

General / How to share SFML games 'correctly' (DLLs issue)?

« on: November 13, 2010, 09:55:50 am »

If you want the application to crash because something went wrong then assertions is much faster to implement and easier to use. Also you can get them ignored when compiled to release code much easier so they aren't even added to the source for compilation.

Well exceptions are not about making the app crash when an error occurs, it's about handling errors or throwing them back to the caller.

What if you for instance allocated anything on the heap memory in one of those functions?

It gets deallocated if you use RAII. I'm not saying it's easy, I personally avoid C++ as I find it overly complicated for most uses. But you can say the same with, say, templates, “it's complicated so I don't want to use them, I'm used to void pointers”, or polymorphism, or operator overloading, ...

Also if we use the exception functionality often it might reduce performance, not sure, never tested just what I've heard.

It's supposed to be possible to avoid exceptions overhead when your code path doesn't raise any exception, but I couldn't find much information when I researched it. Now a quick search shows this: http://stackoverflow.com/questions/43253/measuring-exception-handling-overhead-in-c

Anyway, performance reduction must be measured and you should make a choice based on your specific needs. Many programs spend most of their time waiting for I/O, computing long algorithms or whatever. It often just doesn't make sense to choose a technology just because it might make your application a few microseconds faster.

Strictly speaking polymorphism is slow as well, but it doesn't mean you shouldn't use it. The lack of templates in C also causes some code to be slower than in C++, it doesn't mean all C programs are slower and C should be avoided.

Haven't you wondered why SFML doesn't implement any exceptions?

Laurent answered that. He said that exceptions make writing bindings more difficult, and maybe something else I forgot (I can't find the post). Anyway, even if Laurent hates exceptions, it doesn't mean they shouldn't be used.

161

General / How to share SFML games 'correctly' (DLLs issue)?

« on: November 12, 2010, 07:31:51 pm »

Though optimizing size on PC's is just wasted work. Especially on Windows as Windows isn't capable of managing several different versions of a DLL file at the same time like Linux can. If you want to keep your mental sanity on Windows then I REALLY REALLY recommend that you just keep the DLL files in the same folder as the executable. Or else you'll probably just destroy the system stability.

With .NET there's a new scheme for system-wide libs which is supposed to solve the problems, and if I remember correctly Microsoft's C and C++ runtimes are distributed in this way. (It's stored in a weird directory name, like Winsxs or something).
I have no experience with that, but supposedly Windows is able to manage multiple versions of system-wide libraries now.

Well you should avoid using exceptions any way in C++.

Huh, why?

162

General / Redistributing SFML games for Linux

« on: November 08, 2010, 11:52:47 am »

If you make the source code available, people will install the program in whatever way is the standard on their distribution.
There are various formats of packages which contain your program, its data and its dependencies. When the user installs the package, the package automatically ensure that the dependencies are installed as well.
You just give people the source code, the data and the installation instructions, and if your program gets somewhat popular, some people will create the packages for their distribution.

If you don't distribute your source code, you can create an installer (can be as simple as a script or can be like a Windows installer) which will attempt to install the program à la Windows. That's pretty ugly though.

Also, what says you can't take the shared libraries of Linux and put them in the same folder just as Windows? Works there too. If you are having trouble finding your SFML library files then they should be placed under /usr/lib and just search after "sfml".

If I remember correctly, you can't do that because of security issues. I just tried it and it didn't seem to work, but it's been a while since I made a so so I might have done something wrong.

163

Python / Python binding generation tools

« on: November 06, 2010, 07:56:55 pm »

OK, I just realized Cython supports references creation. I added some more classes and methods, here is what the example looks like currently:

Code: [Select]

import sf


def main():
    window = sf.RenderWindow(sf.VideoMode(640, 480), 'Example')
    window.framerate_limit = 10
    image = sf.Image()
    image.load_from_file('python-logo.png')
    sprite = sf.Sprite()
    sprite.image = image
    running = True

    while running:
        for event in window.iter_events():
            if event.type == sf.EVT_CLOSED:
                running = False

        window.clear(sf.Color(255, 255, 255))
        window.draw(sprite)
        window.display()

    window.close()

if __name__ == '__main__':
    main()

You can get a view of the current API here: http://bastien-leonard.alwaysdata.net/doc/index.html
(A lot is missing and there are probably still bugs)
Do you you think I should keep constants this way or place them in namespaces like SFML does?

164

Python / Python binding generation tools

« on: November 06, 2010, 06:48:09 pm »

I think I just found the solution to a bug I've been looking into for hours.
It boils down to the fact that this code prints two different addresses:

Code: [Select]

sf::View view = window.GetDefaultView();
std::cout << &view << ", " << &window.GetDefaultView() << '\n';

Is this a C++ feature or it's a custom behavior?

165

Python / Python binding generation tools

« on: November 06, 2010, 06:03:28 am »

I have a question about managing C++ instances returned by SFML methods.

For example, I wrap the C++ View returned by RenderWindow.GetDefaultView() in Python instance.
At first I deleted systematically the C++ instance in the Python destructor. But I got runtime errors, presumably because SFML deletes the default view as well.
So I added a “delete_this“ flag which tells whether the C++ instance should be deleted in the Python wrapper code or not, and when I wrap the default view I set this flag to False.

I would like to know if I can safely use this pattern every time SFML returns an object? When I played around with SFML in C++ I didn't really bother about memory management. :roll: