Messages

1

General discussions / Re: C#/C++ build comparison

« on: March 07, 2015, 08:16:35 pm »

It is not. I misread your code and removed my post when I realized (after about 20sec).

No worries, I have done the same.

2

General discussions / Re: C#/C++ build comparison

« on: March 07, 2015, 08:11:12 pm »

Without seeing the code it's all just random guessing.. And my crystal ball is not being helpful atm.
If you want to see where time is spent, try a profiler...

As per my last post, the hello world program.

Here's the adjusted C# version:

static void Main()
        {
                RenderWindow window = new RenderWindow(new VideoMode(200, 200), "SFML works!");
           
                CircleShape shape = new CircleShape(100);
                shape.FillColor = Color.Green;

                Stopwatch clock = new Stopwatch();
            clock.Start();
                long frames = 0;

                while (window.IsOpen())
                {
                        window.DispatchEvents();
                       
                        if (clock.Elapsed.Seconds >= 30)
                        {
                    Console.Write(frames.ToString() + " in " + clock.ElapsedMilliseconds.ToString() + "ms");
                                break;
                        }

                        frames++;

                        window.Clear();
                        window.Draw(shape);
                        window.Display();
                }
        }

3

General discussions / Re: C#/C++ build comparison

« on: March 07, 2015, 08:03:49 pm »

So you're comparing SFML to itself? What's the point? If it's to measure the overhead of the C# -> CSFML -> SFML bridge, I can tell you for sure, without any benchmark, that it is negligible compared to the overhead of the draw call (mostly spent in the OpenGL driver).

The point is exactly that, to see how much time is lost in the translation. I took the sample hello world program from the tutorial and got the same result. The C# build calls draw ~260K times in 30 seconds on my system. The C++ only manages ~250K (both X64 release builds). As you rightly say, there should be some, albeit negligible, overhead in the C# build, but I don't see it, and it's slightly baffling to me.

4

General discussions / Re: C#/C++ build comparison

« on: March 07, 2015, 07:07:17 pm »

As I see it, the test is flawed in that measuring frames per second is a bad metric. It probably has less to do with the programming language used than whether or not vsync (or some other frame rate limiting mechanism) is in play, and the quality/performance of your graphics drivers and their OpenGL implementation, than anything else.
And a measured 1% difference is not something I'd call significant regardless of what you measured - it's likely in the statistical noise and likely to fluctuate from run to run.

I'm not measuring frames per second, I'm measuring total frames generated over a time period, using the same system for each build's run (each built for x64 release), where most work done in the tight loop is in the SFML library (mostly draws). Also, the frames measured over my 30 second time frame is in the tens of thousands, so vsync is not in effect if I understand this correctly.

Would the above still mean the test is not effective as a measure of each environment's raw performance? If so, what is a more effective way to test perfomance of the library in each environment?

5

General discussions / Re: C#/C++ comparison

« on: March 07, 2015, 08:02:16 am »

But it looks like you're trying to say (even if this is not your intention): "Aha! I finally proved that C++ is not faster than C#!" ... without even posting the code of your benchmarks.

If anything, I express confusion at my results.

Then your title is severely misleading. Even if you claim to only be comparing builds, the test is still extremely flawed.

The content of my post clearly talks about build performance. I have changed the subject to hopefully encourage people to read the content more closely.

It might also be useful to explain in what way the test is extremely flawed.








I cannot share the code involved in my test. I will create a new test and see if I get similar results. If so, I'll happily post the code.

6

General discussions / Re: C#/C++ comparison

« on: March 06, 2015, 11:05:47 pm »

How about posting the code for both C# and C++ implementations before drawing conclusions?

I haven't drawn a conclusion, nor did I state one.

7

General discussions / Re: C#/C++ comparison

« on: March 06, 2015, 02:33:24 pm »

M.b. you are just bad C++ programmer? =)

That may be

Really? You are comparing two languages by how many frames they render in a set period of time? Just..... 

Does this kind of result make sense?

No, not at all because you can't even statistically compare languages this way.

I'm not comparing languages, I'm comparing the performance of builds.

8

General discussions / C#/C++ build comparison

« on: March 06, 2015, 01:57:18 pm »

I wrote a 500 line game in C#, simple space shooter, one player, one AI opponent, scrolling backgrounds, text on screen.

I then ported it to C++ and setup both builds to run a series of programmed sequences for 30 seconds and report the amount of frames produced.

The C++ build produced on average 1% fewer frames than the C# build.

Does this kind of result make sense? I would have assumed (clearly wrongly) that C++ would outperform C# given the library is natively C++.

9

General / Re: Few loose ends compiling custom static SFML VS2012

« on: June 04, 2013, 11:03:32 pm »

Damn the license issue slipped my mind totally.

Looks like compiling openal and libsnd for static linking (and in windows) is a real pain in the ass. Don't suppose anyone has experience with this?

10

General / Re: Few loose ends compiling custom static SFML VS2012

« on: June 04, 2013, 01:03:27 pm »

Well to just update, I followed your advise on the previous posts and everything compiles and links fine now, so thanks for that.

The benefit was suppose to be that I only required one .lib file to use SFML (+get the PDBs, +the libs for all configs and platforms would adhere to a common naming scheme, allowing use of VS macros when building against it), but it seems that given the way SFML uses OpenAL and SND, you will still require at least these 2 dlls.

Am I to understand from this that using a static linking version of these libs was not possible/practical?

11

General / Re: Few loose ends compiling custom static SFML VS2012

« on: June 04, 2013, 12:21:27 pm »

Thanks for the help.

I'm interested in your comment on this not being a good idea. My understanding is that the linker would be able to include (into a project using this single .lib) only the parts it needs.

This seems to be case (with some simple tests I did), I'm guessing I've missed some other glaring reason not to do this?

12

General / Re: Few loose ends compiling custom static SFML VS2012

« on: June 04, 2013, 12:13:08 pm »

VS2012 allows you to archive the deps into your output so that you link your project to the one .lib file.

If I do not specify any of the deps in the extlib\libs-msvc during my compilation of SFML then my app, using sfml,  is required to provide the .libs during it's link, but if I tell the "librarian" about your deps during the compilation of SFML then my app no longer needs to provide them.

That is, all except the ones in my original post, which I'm unsure how to resolve.

In contrast, when I link to your static .libs (sfml-xxxxx-s.lib) then everything is fine, I presume because everything required is provided in that .lib

I'm simply trying to create a single .lib containing everything, and so that I can get a PDB.

13

General / Few loose ends compiling custom static SFML VS2012

« on: June 04, 2013, 11:55:37 am »

Hi,

I've setup my own VS2012 project for compiling a static linking SFML 2.0. I instruct the linker to include the additional .lib deps (in the extlibs/libs-msvc folder).

The resulting .lib file then, when used in another project had some unresolved symbols involving GL, so I included opengl32.lib in the SFML .lib project and retried, but now I am left with a number of unresolved symbols referring to GLEW. Since GLEW is one of the deps in the provided extlibs folder, I'm a little confused about what I'm missing out in the link.

Apart from the 5 libs provided by the SFML 2.0 source (and opengl32.lib), what other lib deps need to be included?

Here is the linking errors when using this SFML in a project:

1>sfml.lib(RenderTarget.obj) : error LNK2001: unresolved external symbol __imp____glewBlendFuncSeparateEXT
1>sfml.lib(RenderTarget.obj) : error LNK2001: unresolved external symbol __imp____GLEW_EXT_blend_func_separate
1>sfml.lib(Shader.obj) : error LNK2001: unresolved external symbol __imp____glewActiveTextureARB
1>sfml.lib(Shader.obj) : error LNK2001: unresolved external symbol __imp____glewAttachObjectARB
1>sfml.lib(Shader.obj) : error LNK2001: unresolved external symbol __imp____glewCompileShaderARB
1>sfml.lib(Shader.obj) : error LNK2001: unresolved external symbol __imp____glewCreateProgramObjectARB
1>sfml.lib(Shader.obj) : error LNK2001: unresolved external symbol __imp____glewCreateShaderObjectARB
1>sfml.lib(Shader.obj) : error LNK2001: unresolved external symbol __imp____glewDeleteObjectARB
1>sfml.lib(Shader.obj) : error LNK2001: unresolved external symbol __imp____glewGetHandleARB
1>sfml.lib(Shader.obj) : error LNK2001: unresolved external symbol __imp____glewGetInfoLogARB
1>sfml.lib(Shader.obj) : error LNK2001: unresolved external symbol __imp____glewGetObjectParameterivARB
1>sfml.lib(Shader.obj) : error LNK2001: unresolved external symbol __imp____glewGetUniformLocationARB
1>sfml.lib(Shader.obj) : error LNK2001: unresolved external symbol __imp____glewLinkProgramARB
1>sfml.lib(Shader.obj) : error LNK2001: unresolved external symbol __imp____glewShaderSourceARB
1>sfml.lib(Shader.obj) : error LNK2001: unresolved external symbol __imp____glewUniform1fARB
1>sfml.lib(Shader.obj) : error LNK2001: unresolved external symbol __imp____glewUniform1iARB
1>sfml.lib(Shader.obj) : error LNK2001: unresolved external symbol __imp____glewUniform2fARB
1>sfml.lib(Shader.obj) : error LNK2001: unresolved external symbol __imp____glewUniform3fARB
1>sfml.lib(Shader.obj) : error LNK2001: unresolved external symbol __imp____glewUniform4fARB
1>sfml.lib(Shader.obj) : error LNK2001: unresolved external symbol __imp____glewUniformMatrix4fvARB
1>sfml.lib(Shader.obj) : error LNK2001: unresolved external symbol __imp____glewUseProgramObjectARB
1>sfml.lib(Shader.obj) : error LNK2001: unresolved external symbol __imp____GLEW_ARB_fragment_shader
1>sfml.lib(Shader.obj) : error LNK2001: unresolved external symbol __imp____GLEW_ARB_shader_objects
1>sfml.lib(Shader.obj) : error LNK2001: unresolved external symbol __imp____GLEW_ARB_shading_language_100
1>sfml.lib(Shader.obj) : error LNK2001: unresolved external symbol __imp____GLEW_ARB_vertex_shader
1>sfml.lib(Texture.obj) : error LNK2001: unresolved external symbol __imp____GLEW_ARB_texture_non_power_of_two
1>sfml.lib(GLCheck.obj) : error LNK2019: unresolved external symbol __imp__glewInit referenced in function "void __cdecl sf::priv::ensureGlewInit(void)" (?ensureGlewInit@priv@sf@@YAXXZ)
1>sfml.lib(GLCheck.obj) : error LNK2019: unresolved external symbol __imp__glewGetErrorString referenced in function "void __cdecl sf::priv::ensureGlewInit(void)" (?ensureGlewInit@priv@sf@@YAXXZ)
1>sfml.lib(JoystickImpl.obj) : error LNK2019: unresolved external symbol __imp__joyGetPosEx@8 referenced in function "public: static bool __cdecl sf::priv::JoystickImpl::isConnected(unsigned int)" (?isConnected@JoystickImpl@priv@sf@@SA_NI@Z)
1>sfml.lib(JoystickImpl.obj) : error LNK2019: unresolved external symbol __imp__joyGetDevCapsW@12 referenced in function "public: bool __thiscall sf::priv::JoystickImpl::open(unsigned int)" (?open@JoystickImpl@priv@sf@@QAE_NI@Z)
1>..\..\..\..\Main\Libraries\Debug\x86\OasisMain.dll : fatal error LNK1120: 30 unresolved externals

14

General / Re: Linking errors with VS2012

« on: May 31, 2013, 12:37:02 pm »

Apologies, it seems it was in fact the wrong library.

15

Graphics / OpenGL 4.x with SFML

« on: May 31, 2013, 10:49:07 am »

Hi, new here and been trying to find a clear answer to whether you can mix in your own openGL stuff into a SFML window.

Essentially can you bring 3D to SFML?