Messages

1

Python / Re: Question about the Python binding

« on: November 09, 2013, 12:32:45 pm »

Hi,

Why are people so obsessed about performances :p You won't notice any difference. Just expect your program to run slightly slower but that's just because Python is interpreted while C++ is compiled. If you write stuff that takes time to compute, it will likely  run slow in both C++ and Python because SFML just sends stuff to the GPU which executes its tasks independently of the languages you use.

The official Python installers install a Python version compiled with these compilers so we need to use the same one. It's advised.. or you may encounter mysterious bugs/crashes.

Good luck

Thanks for the information and the reply.  As for why are people obsessed about performance.  I have an excuse I have been developing for micro controllers for the last 2 years as a hobby.    I would still not say I am obsessed I just know from experience that Python can really bog down computationally well before a solid C/C++ algorithm does.  I just wanted to make sure I was not going to run into any other potential slow downs.  I.E. Significant Python -> C call overhead.  I should have specified better in my post besides just saying I am unfamiliar with Cython.

Either way thanks for the reply I will continue to look into this.

2

Python / Question about the Python binding

« on: November 09, 2013, 12:03:49 am »

Hello Everyone,

I have not posted on these forums in years.  I am recently getting back into game development and I remembered SFML.  I was thinking about using the python version.  The only concern I have is performance as I am unfamiliar with cython.  When I use to drop to C in my python code I always have used ctypes as it was easy to do right from python itself.

How is the performance of pysfml using cython?  Also I notice you recommend using the VC++ compiler that python was built with?  Would I have a negative impact if I use MinGW instead? 

I like to try and stick to one compiler if possible for interfacing with C when I have to because it is a pain to chase around which VC++ compiler python is built with.

Sorry if my questions are horrid I have not touched python in quite a while I was on a Micro Electronics binge programming in C.

3

General discussions / debugging

« on: January 04, 2010, 03:46:07 am »

Yes to get proper debugging symbols you need to use the libs with -d after them.  Which means they are built for debugging.

4

General discussions / linux debug question

« on: January 01, 2010, 08:34:41 pm »

Ok thanks everything is working fine.

5

General discussions / linux debug question

« on: January 01, 2010, 06:11:22 pm »

under linux when you build why is there no libs with -d after them?

6

General discussions / Design and documentation

« on: December 31, 2009, 05:23:20 pm »

You should know even reset on the shared_ptr and clear on the container are not guaranteed to free the memory.  Because if the ref count is not 0 the memory will remain allocated when you call reset().

[edit]
The point being those calls are not 100% reliable.  Like I said shared_ptr's are great to use but they defiantly should not be over used.  They are not the end all be all.

The whole point of shared_ptr is for ... shared objects.  Not just memory management in general.

If you don't want to share the memory, then don't.  shared_ptr's don't just sneak in some references out of no where so you can't free the memory...

Correct if you don't share the memory.  But if you don't share the memory you should not be using shared pointers to begin with.  No point in having that extra overhead when you can just used a scoped pointer.

7

General discussions / Design and documentation

« on: December 31, 2009, 04:34:12 pm »

You should know even reset on the shared_ptr and clear on the container are not guaranteed to free the memory.  Because if the ref count is not 0 the memory will remain allocated when you call reset().

[edit]
The point being those calls are not 100% reliable.  Like I said shared_ptr's are great to use but they defiantly should not be over used.  They are not the end all be all.

8

General discussions / Design and documentation

« on: December 31, 2009, 04:26:26 pm »

shared_ptrs are excellent to use however, there are reasons why a lot of game devs including the pros avoid them.  No they don't care about the double heap allocations that boost does.  They care about that just typing #include<boost/shared_ptr.hpp> increases the compile time of a already 3 day long compiled application.  That is not even the main reason. A lot of game dev's avoid shared pointers because it does not allow them to explicitly control the life time of their heap allocated objects.

When you are creating resources and destroying resources at 60fps for say particle effects, maybe arrows that fire from a bow or bullets flying from a gun shared_ptrs are death to the code base because the objects linger longer then the should.

There is a whole article about it in general.  At the end they give some reflections on shared_ptr and games.

http://www.gamasutra.com/view/feature/4015/managing_data_relationships.php

On another note Laurent did you look at Intrusive Pointers?
http://www.boost.org/doc/libs/1_41_0/libs/smart_ptr/intrusive_ptr.html

9

General discussions / Visuel c++ 2010

« on: December 30, 2009, 01:14:13 am »

if you are in debug mode use -d.

I am stumped what is the full error the app is generating just Bad Init?

The more detail you give us the better our chances of supplying a solid answer.

10

General discussions / Visuel c++ 2010

« on: December 29, 2009, 03:38:23 am »

#include <SFML/Window.hpp>

Not sure if that is causing the problem or not but you should be including the window header as well as the Graphics.hpp

11

General discussions / Visuel c++ 2010

« on: December 29, 2009, 01:22:16 am »

Yea those are what he is asking for.  What definition of the main function are you using.  if you are using the standard...

int main() or int main(int argc char** argv) you need to also include the sfml-main.lib  or you will get unresolved externals.  Yours look like this might be the issue.

12

General discussions / Build From Source For 2010

« on: December 23, 2009, 01:43:38 am »

Yea I beleive if I read properly the express will launch at the same time as the main vs in march.  In all honesty there are some perks to 2010 but templates still can break the intellisense.  At this point I am so use to coding with it not working that the only real ide perk I have at this point is a nice debugging interface.

13

General discussions / Build From Source For 2010

« on: December 22, 2009, 01:39:46 am »

I did a successful conversion of the projects in Visual C++ Express 2010 Beta 2.  The main issue I see with putting it up in the svn is the fact it is still only a beta project and the majority of people are not using it yet.  Maybe as a branch?  If I get the go ahead I would be more then happy to put up the conversion.  Even better if allowed I can supply the C++ compiled binaries.  This way we don't have a extra unneeded branch.

I don't have the sample projects done because I really don't want to have to recompile the sample dependencies like wx and qt.

14

General discussions / SFML Release DLL Fails to build on VS2010

« on: December 13, 2009, 04:00:53 pm »

This must be a bug of some sort because I just got Debug DLL to build after switching back to the old settings.  But Release DLL Failed after I switched.  Gunna keep looking at this.


EDIT:  Problem Fixed  Turns Out on the Release DLL project in the linker options /INCREMENTAL flag was off.  Flick it on and it builds.

15

General discussions / SFML Release DLL Fails to build on VS2010

« on: December 13, 2009, 03:28:43 pm »

Yes it pushes the object files into the directory but for some reason if you don't the build fails on the Release DLL and Debug DLL.  On Release Static and Debug Static no changes need to be made.

It seems as if the linker is having issues finding the obj files.