Messages

61

Graphics / Re: Fragment shader issue [possible bug]

« on: October 29, 2015, 07:41:20 am »

I just had a very quick look.  But my first guess is that gl_FragCoord is in a different range in your project than it is for the glslsandbox example you linked to.

If you're using a sf::Sprite, gl_FragCoord x and y will be in the range of 0 to 1.

Your shader is comparing this to the "resolution" value.  I don't know what you've got that set to, but I'm guessing screen resolution, or the size of the sprite (or both).

If this is the case, you're comparing stuff in screen space (resolution) to stuff in texture space (gl_FragCoord), and that's kinda apples and oranges.  You'll need to convert both values to use the same coordinate space to have any meaningful comparison between them.

62

General / Re: High FPS unstable frametimes?

« on: October 21, 2015, 01:19:17 am »

while I was doing this, I noticed that these strange irregularities (the very noticeable stuttering of my game was always a factor, but the concrete frametime measurements were not) were still present, even though my code was drastically more stable and adaptable.

Regarding stuttering, if you're using an nvidia graphics card, this is worth a read:
http://en.sfml-dev.org/forums/index.php?topic=16449.0

63

General discussions / Re: Experimental internal-context-less branch

« on: October 11, 2015, 09:27:02 pm »

Cool.
I recall being bit once by some SFML context-related surprises.  Whether or not this change fixes that particular problem, I'm all for this change.  Especially if it makes the library more useful to advanced users, as suggested on this thread.  Even more impressive if it doesn't affect current users or the API at all.

64

General discussions / Re: aMessage_To_Laurent

« on: September 05, 2015, 06:43:42 am »

Yep, this can't be said enough.  SFML is a fantastic library.  I'm both much appreciative of it and the dedication you folks have towards continually making it better.

tl;dr  You guys rock! 

65

General discussions / Re: Shader uniform API -- part II

« on: August 30, 2015, 08:52:33 pm »

I'd also be interested in further opinions on this.

+1 vote for const char*

Any potential confusion can be solved by a short comment like:  "a const char* argument is used rather than a const std::string& to avoid the extra constructor cost for the common use case where a string literal is provided as an argument".  Give an example if necessary.

But it's a minor detail, so I'm not too worried either way.  If you do go with a const std::string reference, anyone concerned with the optimization can always just declare some std::string constants somewhere in their program to hold their parameter names in.

66

Graphics / Re: Sfml multi-textured tile map

« on: August 17, 2015, 05:49:01 pm »

Yep, totally possible.
I've done something very similar before with no problem.

I did it with 4 different textures, but there's absolutely no reason you couldn't do it using a texture atlas with 4 different offsets passed in as uniform params.

67

General / Re: Too much screen tearing

« on: August 11, 2015, 08:16:20 am »

Thanks for the post, binary1248.  Good stuff as always.

Also, there is no universal way to probe for the VSync interval, so there's that...

Would it be possible to do a really low tech measurement of the VSync interval?  Something like a simple draw operation, then a swap buffer followed by a glFinish, with a timer to measure?  You could maybe run it a few frames if this would help ensure an accurate result?

Also, you should really unlearn the habit of referring to what you are witnessing as "input lag".

Out of curiosity, how would you refer to this?  "OpenGL command queue overflow due to a mismatch of game execution speed vs. GPU speed which imposes a visible latency between user input and the rendered results commonly perceived and referred to as 'input lag' by gamers and the input media" seems like a bit of a mouthful. 

68

General discussions / Re: SFML 2.3.1 released!

« on: July 14, 2015, 11:02:06 am »

Congrats guys, and thanks.

69

Graphics / Re: sf::Texture::checkMaximumTextureSize() creates a new gl context

« on: June 18, 2015, 01:16:43 pm »

Cool, appreciate the informative and thoughtful response binary.

70

Graphics / sf::Texture::checkMaximumTextureSize() creates a new gl context

« on: June 18, 2015, 05:13:35 am »

Hiya,

I just thought I'd share a problem I encountered incorporating a 3rd party opengl-based UI library into my game.

There were some SFML functions which, if called, would cause problems with the UI library, such as corrupt or missing graphics.  It turns out the problem was that these SFML functions create a new sf::Context.  Example:

Texture.cpp

    unsigned int checkMaximumTextureSize()
    {
        // Create a temporary context in case the user queries
        // the size before a GlResource is created, thus
        // initializing the shared context
        sf::Context context;

        GLint size;
        glCheck(glGetIntegerv(GL_MAX_TEXTURE_SIZE, &size));

        return static_cast<unsigned int>(size);
    }
 

The code comments make it obvious why this is done.  And that makes sense.  However, in my case this led to quite a bit of debugging while incorporating the UI library.  Granted, I am quite clueless about low level OpenGL code, and I'm sure an expert may have discovered the problem more quickly.  And the solution is simple, once you understand the problem - just ensure to call setActive again on the RenderWindow (or whatever target you're rendering to).

Regardless, to save others the trouble in the future, perhaps it might be worth it to check for an existing context first, before creating a new one?  And only create a new context if none is already present.

If there's good reasons not to do this, no problem.  I'm just sharing a user experience with SFML here.  It's one of the few times it's caused me some trouble.

71

SFML projects / Re:creation - a top down action rpg about undeads

« on: June 12, 2015, 04:03:38 am »

Definitely a nifty game mechanic you've got going on, Elias.  Thanks for the updates.

72

General / Re: What about memory leaks?

« on: June 07, 2015, 12:42:07 pm »

That's a nice bit of reductio ad absurdum there.

I think your reductio ad absurdum is a strawman. 
Heh, actually I get why you're saying that, but it's really this simple.

Rosme said this:

I can't do anything but wait until you have an issue with your pointers.

...obviously implying issues was either likely or practically inevitable.

My response refuted this - that it is neither likely nor practically inevitable.

I'm pretty sure that's all either of us meant.

Waiting until someone makes mistakes by not using smart pointers doesn't mean that everyone who didn't use them made mistakes. It means it is possible and therefore you might make a mistake by not using them.

You can't write a line of C++ code without possibly making a mistake.  Of course mistakes can be made.  All C++ programmers have a toolbox and mental process to address this.  Mine is different than yours.  That doesn't make me incorrect.

shadowmouse, the rest of your post mostly repeats arguments that have already been made, and already responded to.  (I don't blame you for that, it's getting to be a long thread.)  We did give some reasons for not using smart pointers - there's more to it than disliking change.  We did give some reasons why those exception/memory leak examples are not a real issue.  But you'll have to critique that stuff if you want to cover some new ground here, instead of just talking in circles.

Either way, thanks for chiming in!

73

General / Re: What about memory leaks?

« on: June 07, 2015, 12:03:48 am »

Thanks for that, Mörkö.

Actually, I think you wrote your objections more eloquently than I did.

You clearly didn't read correctly all we said.

That isn't clear to me at all from Mörkö's post.  In fact, everything he said is technically correct, as far as I understand.

The proof have been made by a lot of very experimented programmers(not only on this forum but across the internet) why smart pointers in general are good.

I am a very experienced programmer.
Jonathan Blow is a very experienced programmer.
A simple google search lists many who critique them.
Obviously it's not as unanimous as you say.

But if you really believe that full manual memory management(because even with smart pointer, there is manual memory management) is really better, than I can't do anything but wait until you have an issue with your pointers.

Now, here is another small example of memory leak if you want:

There are other ways to find memory leaks in your program that do not involve permanent changes to your code at all.
Examples:
- valgrind
- this for visual studio

I can't do anything but wait until you have an issue with your pointers.

In my case, I'm afraid you're going to be waiting a long time.  Unless you honestly believe that every C++ program in existence before C++11 was a buggy piece of memory leaking crap (which is obviously not true), your statement doesn't hold.  I'll certainly agree with you if you say smart pointers can make the job of memory management easier for some programmers.  But it's blatantly incorrect to say they are necessary for a proper functioning program.

I do however very much appreciate hearing from folks who use smart pointers.  Maybe someday I'll change, or have to work on a project where they are code standard. 

74

General / Re: What about memory leaks?

« on: June 06, 2015, 08:17:12 pm »

Cool, so we're on the same page.

75

General / Re: What about memory leaks?

« on: June 06, 2015, 06:56:16 pm »

I don't understand what you mean with raw pointer to another unique pointer, could you make an example for me please?

class SkillDirectory
{
public:
   // ... constructors, etc...
   const Skill* LookupSkill(const std::string& i_skillName) const;

private:
   // maps a skill name to a skill class.
   std::map<std::string, std::unique_ptr<Skill*>> m_mapSkill;
};

const Skill* SkillDirectory::LookupSkill(const std::string& i_skillName) const
{
   // my syntax here is probably wrong because I don't use smart pointers, but...
   std::map<std::string, std::unique_ptr<Skill*>>::const_iterator it = m_mapSkill.find(i_skillName);

   if (it != m_mapSkill.end())
   {
      // return a raw pointer to the std::unique_ptr
      return (*it)->get();
   }
   return 0;
}
 

And some other gamesystem code stores this raw Skill* pointer like so:

bool PlayerSkills::AddSkill(const std::string& i_skillName)
{
   const Skill* pSkill = GetSkillDirectory()->Lookup(i_skillName);
   if (!pSkill)
   {
       // handle error..
       return false;
   }

   // Track this RAW SKILL POINTER in my "known skills" data.
   m_setKnownSkill.insert(pSkill);
   // So now the SkillDirectory has a unique_ptr to pSkill, and I have a raw pointer to pSkill.
}