Messages

16

General / Re: Can someone please help me understand what goes into allowing the use of "new"?

« on: September 04, 2016, 07:22:56 am »

New in C++ is not the same as new from C# or Java or the like. In C++ new allocates memory for your type and returns a pointer to the allocated memory which you must later deallocate or you will get memory leaks. Given that you don't know this already I would strongly advise against using new at all and instead look at using unique_ptr in c++11 and up.

17

General / Re: Tile map help

« on: September 04, 2016, 07:20:04 am »

Are you calling your draw method anywhere? Additionally if you intend to draw anything with sfml you should consider deriving sf::Drawable.

18

SFML development / Re: How should SFML handle non-legacy shaders?

« on: August 27, 2016, 07:12:58 pm »

Personally I would be an advocate for moving to the modern pipeline however I would put it at the same priority as moving sfml to modern c++. Both changes will make sfml non backwards compatible as soon as they are implemented.

If I'm not mistaken, glsl offers the use of layout specifiers for variables (in, out and uniform)  which would mean that internally sfml shaders can be named whatever you want to name them and when users want to alter uniforms and in variables they can use the layout position specified in the shader as opposed to doing a name lookup.

That aside, I would consider myself an expert on the topic by any means, however I'm curious as to how a user would go about using their own shaders in conjunction with sfml ones. For example, say I want to draw a sprite but maybe I want some wavy effect going on. Sfml provides the absolute minimal shaders required to render the sprite to the screen so I don't want to write my own, instead I want to use the sfml one us my own.

I believe shader programs accept multiple shaders of the same type which could come in handy but would that mean that I would have to create a shader program every time I wanted to use my own shaders?

19

Feature requests / Re: Vulkan Support

« on: July 03, 2016, 01:31:38 pm »

You arent bursting anyone's bubble. This was pretty much shot down the moment it was brought up and the lack of support for legacy cards and such was also noted. Vulkan is too new and, again, doesnt have enough support to warrant using it. SFML wouldnt even begin to use its benefits over OpenGL anyway considering it doesnt even use OpenGL 1 to its fullest.

20

Window / Re: Text not drawing

« on: July 01, 2016, 04:37:21 am »

Firstly I would like to point out that the repo you have linked has absolutely nothing useful to us in it. Where is the rest of your code?

Secondly, http://sscce.org/.

21

Network / Re: [PROBLEM] Expression is_block_type_valid(header->_block_use)

« on: June 24, 2016, 08:34:08 pm »

For starters I can see a lot of memory leaks happening in your code. If you have access to smart pointers (A compiler that can compiler C++11/+code), use them.

Aside from that, you never remove ClientCommunications for clients that have disconnected.

22

General / Re: RAM dedicated to video for my SFML app seems it's not enough

« on: June 13, 2016, 07:04:23 am »

Can you please post the source and not the binaries? For those of us who do not have unlimited/decent internet, the download is almost 40MB.

As for the problem, I would suspect a memory leak is to blame but I (And noone else) can be sure unless you post the source.

23

Network / Re: Advice for TCP sending?

« on: June 09, 2016, 03:45:40 am »

What you want is called a "ping" or "heartbeat" and its what a lot of (If not all) games implement as a rough detection for when a socket is timing out. You send a packet every n seconds and if you havent received one in n2 seconds, you are timing out. Personally I would recommend TCP for this considering that TCP guarantees the packet will be received where as UDP is connectionless and its kind of important that a ping packet get received.

As for wait, it takes a time out (In sf::Time) where it will block for that amount of time before unblocking. I would advise that you use that with about a 200ms wait time which is more than enough time per frame to allocate for networking.

24

General / Re: Window is drawing Background of whatever is behind the window/Window draw ERROR

« on: May 20, 2016, 03:19:09 pm »

Where is the rest of your code?

25

Feature requests / Re: Vulkan Support

« on: May 20, 2016, 03:18:07 pm »

As it was noted before, SFML is nowhere near complex enough to even begin utilizing any benefits of Vulkan. It doesnt even utilize OpenGL 1 fully because it doesnt need to. That being said, support is not a false issue at all. If graphics cards dont support Vulkan and your application does, how do you intend on getting people to use it? For SFML's purpose, OpenGL 1 is .. Adequate. It could stand to be updated but it works now so why change it? There is nothing stopping you from using Vulkan or OpenGL 4 in your application.

26

General / Re: Problem loading font from file

« on: October 27, 2015, 04:36:09 am »

I'm not familiar with assert/fail, but this wouldn't be a fix so much as a better way to catch the failure, right? 

Sort of. It wont fix your problem but it will stop your code from breaking in unknown areas. Is anything printed to the console when you try to load the font? I'm thinking its possible that your font might be corrupted or unsupported?

27

General / Re: Problem loading font from file

« on: October 26, 2015, 11:39:08 pm »

The font should be in the same directory as your project (i.e C:/Users/{you}/Documents/Visual Studio 2010/Projects/{your project}/).

Your code should also assert/fail when the font is loaded. Currently, you are still using the font even though it might not be loading.

28

General / Re: Crash on Exit Passing RenderWindow to Class

« on: October 26, 2015, 11:40:22 am »

Tell that to the makers of Valve's Source Engine. Tons of globals there, that's kind of where I was getting some inspiration from. I've been programming under the Source Engine for quite a while now. But there's tons of global variables, externs all over the place, and whatnot.

The programmers at Valve know what they are doing so I'd say its safe to give them a bit of an exception here 

Typical fallacy: argument from authority

The fact that one big company does something may be the result of various reasons, including historical or political ones -- in short, you don't know the backgrounds. Assuming that it's purely because of better design is risky, and applying the same reasoning to your own code, which has completely different preconditions, is a mistake.

This from a purely logical standpoint. There are objective arguments why global variables are problematic if used too often, see for example here. Please inform yourself carefully and be skeptic what you hear, instead of just thinking "ah, the big guys do it, so it must be right". Most progress in C++ during the decade of C++98 has been made by guys who questioned the common old ways of doing things -- and that was a huge step forward, considering that the language hasn't changed at all until 2011.

Tip: in C++, it's usually better to look at how people don't do things ;)sion can go on uninterrupted. Don't open a thread now -- but thanks for reproducing the issue

While I agree with you whole heartedly I'd still like to make the point that global variables are strongly discourages BUT that doesnt mean you cant/shouldnt use them ever, just use them with caution.

29

General / Re: Crash on Exit Passing RenderWindow to Class

« on: October 26, 2015, 04:23:21 am »

The rule-of-thumb isnt "Dont ever use global variables", its more along the lines of "Be wary about the consequences of using them". Order of initialization isnt defined for global objects, even constants, so problems arise with certain types (Pretty much only user defined types) when declared globally.

The programmers at Valve know what they are doing so I'd say its safe to give them a bit of an exception here 

30

General / Re: Crash on Exit Passing RenderWindow to Class

« on: October 25, 2015, 07:45:56 am »

CSFML is not the official SFML library. It is a port/bind which may or may not do things the same way as the official SFML library (Ports/bindings usually introduce their own bugs, quirks and anomalies on top of the official code).

As for the problem: If I recall, SFML has problems when you close it .. I'm going to say incorrectly but thats not the right word.

I'm not sure if this is still an issue but I remember reading a while back (On here) that closing an SFML application by closing the console (For console apps), closes the application in a pretty ugly way.

I noticed you are pushing/poping GL states which CAN cause this problem if you close the application before your draw calls have been executed.