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

Author Topic: Setup - Guide  (Read 6021 times)

0 Members and 1 Guest are viewing this topic.

NightCabbage

  • Newbie
  • *
  • Posts: 20
    • View Profile
    • Email
Setup - Guide
« on: December 04, 2012, 05:43:11 am »
Hi all

I come from a mainly C# background, and have been using XNA for the last few years. A lot of other developers, particularly new ones, will be in my position - ie. not a lot of c/c++ knowledge.

So my first goal is to learn (with your help) everything I need in order to get the latest version of SFML.Net fully compiled and operational. Then, when I understand everything - and you've confirmed I don't have any mistakes - I am going to write up a little guide/tutorial on how to do it, so other people will have an easier time getting up and running.

I haven't been able to find any good tutorials for getting set up yet (let me know if I've somehow missed one!).

So this thread is basically me asking you to answer some questions for me - simple! :D

After all this is done, I'm going to modify sfml to add in Pre-multiplied alpha (blend mode, and convert images on load). I'll make that a public release, too, of course.

Thanks!
« Last Edit: December 04, 2012, 05:53:29 am by NightCabbage »

NightCabbage

  • Newbie
  • *
  • Posts: 20
    • View Profile
    • Email
Re: Setup - Guide
« Reply #1 on: December 04, 2012, 05:49:55 am »
Ok, so first batch of questions.



a) Which version of SFML.Net to use?

I'm guessing I should be using the version of SFML.net located at github (https://github.com/SFML/SFML.Net) instead of the release candidate (http://www.sfml-dev.org/download/2.0-rc/SFML.Net-2.0-rc-windows.zip) as I would assume the release candidate is way out of date, and the github version is current?



b) Why the C version, and not the C++ version?

- SFML is primarily written in c++ (normal sfml)

- There's a binding in c (csfml)

- There's a binding in c# - and this uses the c binding?

So... why not use the normal c++ version?



c) Additional .dll files

So, as of SFML 2.0, I notice that 2 extra dll files are required:

libsndfile-1.dll and openal32.dll

Both for audio, right? And both are necessary for use of SFML 2.0?



d) For general use (ie. a game) I'm guessing I should be compiling the c# sfml dll files as Release x86?
(obviously don't want to compile them as Debug, and while it's nice that I can compile 64-bit versions, too, I imagine this would be dumb, as then people running 32-bit OS wouldn't be able to run them... lol)



e) As the .net version is just a binding, I need to include not only the .net sfml files, but also the normal sfml dll files, right? (8 dlls total, including libsndfile-1 and openal32)



Ok that'll do for now :P

Thanks for your time, effort and patience everyone!

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Re: Setup - Guide
« Reply #2 on: December 04, 2012, 09:02:50 am »
Quote
a) Which version of SFML.Net to use?

I'm guessing I should be using the version of SFML.net located at github (https://github.com/SFML/SFML.Net) instead of the release candidate (http://www.sfml-dev.org/download/2.0-rc/SFML.Net-2.0-rc-windows.zip) as I would assume the release candidate is way out of date, and the github version is current?
Right.

Quote
b) Why the C version, and not the C++ version?
For maximum compatibility. P/Invoke (ie. calling C functions from .Net) is standard and well supported on every platform. C++/CLI (ie. mixing C++ and .Net) is a strange beast designed by Microsoft and only supported by Visual C++ (as far as I know). So using C++ would be a problem on Mono, unless they recently decided to support it.
C has the other advantage of providing a standard ABI (application binary interface), while with C++, each compiled binary uses an ABI which is specific to every compiler and can only be understood by the same compiler. Even different versions of the same compiler are incompatible with each other.

Quote
c) Additional .dll files

So, as of SFML 2.0, I notice that 2 extra dll files are required:

libsndfile-1.dll and openal32.dll

Both for audio, right? And both are necessary for use of SFML 2.0?
They are the LGPL dependencies of sfml-audio, so you need them only if you use this module.

Quote
d) For general use (ie. a game) I'm guessing I should be compiling the c# sfml dll files as Release x86?
Yes, with Release x86 you can run on every system.

Quote
e) As the .net version is just a binding, I need to include not only the .net sfml files, but also the normal sfml dll files, right? (8 dlls total, including libsndfile-1 and openal32)
You need to include the CSFML DLLs. SFML is statically linked into CSFML, so there's no DLL for it.

I'd like to add something, for other people who may read this: recompiling the whole chain (SFML, CSFML, SFML.Net) is only needed if you need to modify something. If you just want the latest SFML.Net, up-to-date CSFML binaries are already provided in the repository.
« Last Edit: December 04, 2012, 11:20:59 am by Laurent »
Laurent Gomila - SFML developer

NightCabbage

  • Newbie
  • *
  • Posts: 20
    • View Profile
    • Email
Re: Setup - Guide
« Reply #3 on: December 04, 2012, 11:02:05 am »
Excellent response, thank you Laurent - answered all my questions nicely.

Yes, I have gotten everything up and running using just what's located in the SFML.Net folder.

First step was to compile the 3 packages, then just create a new .net project and put all of the .dll files in there (referencing the 3 .net ones in the project).

Now my next step is the hard part - get the c version to compile so I can modify SFML to add in pre-multiplied alpha :)

Might start on that part tomorrow. Am doing some performance testing now - to compare SFML with XNA. So far it's interesting to see the differences between SpriteBatch (which uses shaders) and SFML (which I'm not actually sure how it renders sprites... anywhere I can read to find out?)

So far XNA / SpriteBatch wins by a massive margin at rendering the same sprite 10,000 times (XNA 700 fps vs SFML at 100 fps). Why is this so? I'm guessing it's to do with SFML doing some extra set up for each draw call, whereas XNA skips the setup if it knows the same sprite is being drawn?

But XNA & SFML are even at rendering 2 different sprites 5,000 times (80 fps each).
« Last Edit: December 04, 2012, 11:04:42 am by NightCabbage »

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Re: Setup - Guide
« Reply #4 on: December 04, 2012, 11:25:34 am »
Quote
SFML (which I'm not actually sure how it renders sprites... anywhere I can read to find out?)
You can read the source code, it's really easy to follow.

Quote
So far XNA / SpriteBatch wins by a massive margin at rendering the same sprite 10,000 times (XNA 700 fps vs SFML at 100 fps). Why is this so?
It's simple: SFML doesn't batch implicitely, so you're comparing batched drawing to unbatched drawing. Since batching is one of the most important optimization in a graphics application, the performance difference can be huge.

There's no high-level batching interface in SFML (ie. grouping multiple sf::Sprites together directly), but you can use vertex arrays to group static/similar geometries into a single entity and draw it with a single call.
Laurent Gomila - SFML developer

NightCabbage

  • Newbie
  • *
  • Posts: 20
    • View Profile
    • Email
Re: Setup - Guide
« Reply #5 on: December 04, 2012, 11:30:14 am »
Cool, that was going to be one of my next questions - about using VertexArray to batch multiple static sprites together. So this is indeed how it's done? Good to know :)

So am I correct in saying that a sprite can be batched if:

a) it doesn't move (so the vertices don't change)

b) the texture is the same

(or is there a case where you can batch even if one of those is not true? or perhaps another condition is required?)

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Re: Setup - Guide
« Reply #6 on: December 04, 2012, 11:39:14 am »
The texture must be the same, because you can pass only one texture per draw call, but the vertices don't need to be static. Since the vertex array is just an array of vertices in RAM, its contents can be changed freely. So the cost of changing the vertices depends on what you do, but it has no impact on the draw call.

PS: this is a little out of the scope of a "Setup guide" ;)
Laurent Gomila - SFML developer

NightCabbage

  • Newbie
  • *
  • Posts: 20
    • View Profile
    • Email
Re: Setup - Guide
« Reply #7 on: December 04, 2012, 11:50:34 am »
PS: this is a little out of the scope of a "Setup guide" ;)

LOL probably true :)

But I want to make sure I at least know how things work before I try to tell other people :P

Will probably end up writing a guide on sprite batching, too :D

Since the vertex array is just an array of vertices in RAM
Ah, this is what I did not know - so you're not loading the vertices into the gfx card like a normal mesh, I see.

Thanks Laurent!

Back on topic...

So for input, I can't seem to find any normal IsKeyPressed methods - only Events... does the .net version of sfml only have events for input? Or am I just not seeing it?

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Re: Setup - Guide
« Reply #8 on: December 04, 2012, 11:58:09 am »
Quote
so you're not loading the vertices into the gfx card like a normal mesh, I see.
The vertex array is transfered to the graphics card every time it is drawn. I could store it directly to the graphics card, but then it would impose too many constraints and make the API more complicated. I think performances are good enough with the current API.

Quote
So for input, I can't seem to find any normal IsKeyPressed methods - only Events... does the .net version of sfml only have events for input? Or am I just not seeing it?
You're just not seeing it :P
It's exactly the same as in the C++ API (Keyboard.IsKeyPressed).
Laurent Gomila - SFML developer

NightCabbage

  • Newbie
  • *
  • Posts: 20
    • View Profile
    • Email
Re: Setup - Guide
« Reply #9 on: December 04, 2012, 12:02:30 pm »
It's exactly the same as in the C++ API (Keyboard.IsKeyPressed).
Ahahaha, I see. My problem was that I was looking at the "Displaying a sprite" tutorial and it was for version 1.6, and version 2.0 is different :)

Ok, so if the mesh is stored in RAM, then moving sprites is a "free action" :)
(so long as the sprites don't change their texture)