Messages

1

DotNet / Re: Pushing everything to a VertexArray each frame

« on: June 14, 2014, 10:17:15 pm »

So, apparently VSync doesn't work the same way SetFramerateLimit does. If I set the framerate limit to 60, I get normal CPU usage. If I set VSync to true, I still get crazy framerate issues because all gets drawn so many times?

@zsbzsb: the problem is with the infrastructure though, so the minimal example would still need quite a few files and such. Is that ok?


EDIT: So yeah, setFramerateLimit seems to fix the issue (while VSync just does... nothing? wtf?). Now it's much better, wastes a lot less CPU and the computer fans don't make so much noise.

I think I'll keep the current method I'm using, while testing it further and improving it a bit (such as rendering tilemaps directly instead of batching them with the rest, only rendering the stuff on screen, etc.).

Thank you guys!

2

DotNet / Re: Pushing everything to a VertexArray each frame

« on: June 14, 2014, 09:53:05 pm »

Mhm... I see...

Actually I need to use layers using a SortedDictionary because of the way it works. Layers are an array that contain the entities.

I just don't understand why the bottleneck is just accessing the property itself (http://puu.sh/9tw2z/eac5d9b62d.png).


EDIT: I just tested a simple project that only clears the window and displays it each frame. 13% CPU. The additional RenderTexture is the other 13% that builds up to the 26%.

What the fuck? Why just calling RenderTexture's Clear method so performance intensive?


EDIT2: Ok, further testing done. The problem was I wasn't limiting the framerate. That's why it was so intensive, it just cleared the screen a lot. Will continue testing.

3

DotNet / Re: Pushing everything to a VertexArray each frame

« on: June 14, 2014, 09:16:18 pm »

I ran Visual Studio 2013's profiler on my code.

The bottleneck seems to be a call to RenderTexture.clear(), that's done once per frame (and the one that clears the screen too). Weird. Is that usual?

The second bottleneck is accessing the SortedDictionary where I store the layers. Why is accessing a property so expensive? I don't understand...

Also, apparently it gives out no information about gpu performance. Sorry, I'm really new to profiling. What should I do?

4

DotNet / Re: Pushing everything to a VertexArray each frame

« on: June 14, 2014, 08:30:04 pm »

I know it's a performance hit because the game uses quite a bit of CPU power.

The spike happens when opening the game. It goes from 1% to 20~30%: http://puu.sh/9tp7B/745a34a0b5.png

What kind of tests would you write to measure how much processing power it requires, and compared to what?

I know using just SFML's sprites would improve CPU performance, but how do I measure the GPU hit?

I was just asking in case someone faced a similar issue, or if someone had some tips on how to better handle sprite batching and such.

I'm new to programming for both the GPU and the CPU, as I mainly used AS3 before and I only had to worry about the CPU. I don't know what best practises are there for graphics programming that are easy both on the CPU vs. the GPU.

Not sure how to balance draw calls vs cpu power and such.

I have some ideas already (such as just draw the tilemaps directly instead of copying the huge vertexarray to another one each frame), but I just wanted to know if any of you had some ideas...

5

DotNet / Pushing everything to a VertexArray each frame

« on: June 14, 2014, 07:46:19 pm »

So the method I'm using for rendering, is I have all these Images and Tilemaps and stuff I've written. Most of them work using vertices, and I have a BatchManager that will batch everything batchable into the same VertexArray (that is, everything that has the same texture, blendmode, shader, etc.)

Thing is, I've noticed this is a bit cpu-expensive. Clearing all the VertexArrays and pushing everything to them each frame seems to be a bit of a performance issue.

This is written using C# by the way, just to clarify.

Am I doing it terribly wrong? Should I just stick to using SFML's sprites and stuff that simply don't use batching (and just batch Tilemap or Particles)? Any tips on how to improve performance?

6

SFML projects / Re: NetEXT - SFML.NET Extension Library based on Thor

« on: May 28, 2014, 12:52:21 pm »

If I use string as the Key for a TextureCache, it randomly gets freed? How can I use resources properly?

7

C / Re: CSFML cmake broken?

« on: May 27, 2014, 03:36:12 pm »

Haha nope, I'm referring to compiling dotnet in order to use SFML.NET with iOS / Android

8

C / Re: CSFML cmake broken?

« on: May 27, 2014, 01:02:23 pm »

I'm following these. Please inform us when you get it to work!

9

DotNet / Future Xamarin support?

« on: May 25, 2014, 01:38:06 am »

Is there any chance we could see some kind of Xamarin support for SFML.NET to be able to publish SFML.NET projects to iOS / Android using SFML's iOS/Android implementations?

10

General discussions / Re: SFML 3 - What is your vision?

« on: April 24, 2014, 07:57:41 pm »

A way to make sprite batching easier to use and more integrated with SFML.

11

General discussions / Re: Class for extremely big, or small, numbers

« on: February 09, 2014, 12:30:07 pm »

Well, they are small now, but I plan to allow the particle to gather up and squeeze a group of smaller particles into bigger particles. Eventually there will be really big particles that will be making numbers that are much bigger.

And you still would be able to have bigger numbers without using larger data types.

12

General discussions / Re: Mutual following on Twitter!

« on: January 31, 2014, 07:55:43 pm »

Hallo.

Sometimes I'm active, sometimes I'm not. Either way: @Abel_Toy

13

General discussions / Re: SFML: C# or C++?

« on: January 30, 2014, 06:51:16 pm »

I would have to port the libraries (or make bindings, but I've got no idea about that).

Depending on what you are after I have ported Thor to SFML.NET (see NetEXT in my signature), and you can PM for more information on making bindings if you are interested in that route. 

Oooooh. Shiny! Cool, one less thing to worry about

Could I also use the SFML.net mobile version once finished with my C# code?

There is currently a test version of SFML for andriod/ios, but it is unfinished and as for coming to SFML.NET I doubt it will happen. 

Damn. Ok. I guess I'll have to make a port for mobile. Not a problem.

You should be aware that C++ is an extremely complex language. Even when you already know a language like C#, it will take months until you have properly learned the basics, and possibly years until you know how to write clean, idiomatic code (although this can be accelerated if you read the right books from the beginning). Never underestimate C++

If you already know C#, I would recommend the SFML.NET binding. zsbzsb even ported my C++ library Thor to C# as NetEXT

Yeah, I know C++ is extremely complex. That's why I want to check I can use C#. I want to eventually learn C++, but I need to do this project now, and I was checking if there's any possibility I can avoid using C++ at the moment. I know how it is learning how to properly write for a language.

Thank you guys for the quick responses!

14

General discussions / SFML: C# or C++?

« on: January 30, 2014, 06:27:14 pm »

Hello everyone,

I'm an experienced AS3 programmer (one of the main guys at FlashPunk), and have also worked quite a bit with C#, Python, Ruby, the web languages, etc.

I'm undecided between choosing the .NET version of SFML or the C++ one, and I was wondering if you guys could help me a bit.

The pros of using the C++ version would be that most of the libraries for SFML are only available in C++. Also, it's faster. But I have never used C++, and I would have to learn the language first. (and the C++11 techniques).

The pros of using the C# version is I already know the language, and I love the additional features it has to offer compared to C++. The disadvantage would be less speed and much less library support. I would have to port the libraries (or make bindings, but I've got no idea about that).

My questions are: is SFML.Net as portable as SFML C++? With that I mean, can I use the C# version to make Mac and Linux versions of my game that would run well? Is Mono fast and good? Could I also use the SFML.net mobile version once finished with my C# code?

Would I be able to easily integrate the Steam API into a C# game? I know the official Steam API is only C++, but I've seen a paid library that brings C# to the API and it's very easy and fun.

What problems would I run into using the C# version instead of the C++ version?

Also, as an aside question... does Java really work for games? I've heard about the cool libgdx library... but I've always seen Java apps perform poorly, and they all have some sort of Java feeling.