Messages

241

General discussions / Re: Multi monitor support

« on: September 09, 2015, 08:04:55 am »

I like it! Reminds me a bit of how GLFW does it.

I see 2 things I'd like to comment on:
1. I'd rename sf::Screen::frameRate to sf::Screen::refreshRate, to be a bit more semantically (is that the right usage? can never remember...) correct.

2. On that note, refresh rate is more of a video mode concept, not really a monitor concept. A monitor will define its max refresh rate, but a monitor can support more than 1 refresh rate. For instance, my monitors claim to support 60, 59, 50, 30, 29, and 25 (the last 3 being interlaced). But also support 75 Hz at 1280x1024 and below. So maybe refresh rate should be an addition to sf::VideoMode, ideally.

Now that I'm looking at it again...

3. I don't think sf::Screen should be a member/accessible through sf::VideoMode. I think you did for backwards compatibility, but that kind of feels backward. A video mode is dependent on a screen/monitor, not the other way around. That's my thoughts on it. I think it might make more sense to have sf::VideoMode through sf::Screen. For example:

std::size_t totalMonitors = sf::Screen::count();

for(std::size_t i = 0; i < totalMonitors; ++i)
{
    std::vector<sf::VideoMode> modes = sf::Screen::get(i).getFullscreenModes();
   
    for(auto& vm : modes)
    {
        std::cout << "Screen #" << i << ": " << mode.width << "x" << mode.height << " - " << mode.bitsPerPixel << " bpp @ " << mode.refreshRate << " Hz\n";
    }
}
 

That's my idea for an API at least. That would allow for less modification to sf::VideoMode as well. Minus the additional refreshRate member. sf::Screen having a "maxRefreshRate" or something might not be a bad thing. Maybe a bit redundant though.

I do think sf::VideoMode should still be accessible without sf::Screen though. That would keep things backwards compatible. Just use the primary monitor maybe?

Anyways, those are my (much more numerous than I initially thought!) thoughts as of now... I'm interested in what other people say!

If/when a final public API is decided on, I'd love to contribute, maybe with a Linux implementation?

EDIT: Downloading/compiling your fork now.

EDIT 2: Working great here! (Win 8.1, 3 monitors, GTX970, unfortunately quite similar to your config, haha.) Changed which monitor to open the window on and that works great as well.

242

General / Re: Slow down on re-sizing the window. Is it possible to cap the speed of the progra

« on: September 08, 2015, 03:41:19 am »

@dabbertorres, how does one test to see if the window is being resized?

http://www.sfml-dev.org/documentation/2.3/structsf_1_1Event_1_1SizeEvent.php
A resize event is generated on the first size change of the window iirc. If not, then handle a MouseLeft event. Different event, but same result generally. I know it's one of those, as I've done it before.

Though it looks like I completely misunderstood the question now that I've read it again, haha. I thought he was complaining about the game window lagging while resizing the window, my bad.

243

General / Re: display variables

« on: September 07, 2015, 08:40:20 pm »

Check the name of variable you're passing to setString.

244

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

« on: September 06, 2015, 08:12:42 pm »

Just to add other container types to the discussion, I've used Google's dense hash map (I exported from Google Code, I haven't found an official repository since it closed) and haven't noticed issues with it.

In addition, I've found and heard b-trees (not binary trees) can be a good choice as well.

245

General / Re: Slow down on re-sizing the window. Is it possible to cap the speed of the progra

« on: September 06, 2015, 08:05:31 pm »

One option I've seen some games do is simply pause the game while the window is being resized, until the user unpauses. Personally, I think that's a good option.

246

General / Re: Problem with constructors - game development

« on: September 06, 2015, 08:03:41 pm »

I completely recommend Herb Sutter out of Jesper's list (all of them are great!). I watched one of his talks, and I found him entertaining and interesting to listen to, which can be difficult to do sometimes in the computer world! So he may be a good start if you find one of the others difficult/boring to listen to (I haven't listened to talks by all in Jesper's list, I'm just adding my experience!).

247

Network / Re: Starting with Packet and Udp Socket

« on: September 03, 2015, 04:56:18 am »

What port are you specifying (if any)? I don't see you picking an actual port anywhere. It looks like you may have attempted to in your top post, but you created a bunch of local variables in your constructor, which isn't doing what I think you want to be doing.

248

Graphics / Re: Issues with drawing an sf::Text vector

« on: August 26, 2015, 11:53:28 pm »

You're copying the font in the constructor for texts, rather than referencing it. So, once the constructor is over, the new font you created is destroyed, so the textClass member no longer refers to a valid font. Not an SFML concept. C++ concept.

249

General / Re: Is it possible to use SFML just as an OpenAL wrapper?

« on: August 26, 2015, 01:45:53 am »

Actually, I'm looking at the tree for 2.3.x

https://github.com/SFML/SFML/blob/2.3.x/src/SFML/Audio/Listener.cpp
https://github.com/SFML/SFML/blob/2.3.x/src/SFML/Audio/AudioDevice.hpp
https://github.com/SFML/SFML/blob/2.3.x/src/SFML/Audio/AudioDevice.cpp

And I'm not seeing anything creating a new AudioDevice, except for isExtensionSupported and getFormatFromChannelCount. The rest of the functions aren't creating one if needed. Unless I'm missing something?

250

SFML projects / Re: I'm working on an open source character controller class in C++

« on: August 25, 2015, 01:05:33 am »

I doubt there is an accuracy difference (unless an implementation of std::chrono does something different). But std::chrono does do more. That would be because std::chrono is actually a namespace, not a class. The std:: comparable type would be std::chrono::duration, which, depending how you use it, may or may not be more accurate than sf::Time.

But at this point, I'm just arguing semantics. Since you're using SFML, and presumably sf::Clock, sf::Time would be preferred (though not required).

251

Graphics / Re: [SOLVED]SFML Access violation

« on: August 25, 2015, 12:59:45 am »

All member variables are only declared once, in the class declaration (header file), unless they are static members. In which case, they must also be defined (also initialized here too) (source file).

If this double declaring thing has worked for you before, it's mostly due to luck, and not using more than one instance of a class, would be my guess.

252

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

« on: August 24, 2015, 10:30:55 pm »

Argument type naming

Hmm.

The boolean typedef is easily resolved if needed, though sf::Vector2<bool> isn't a big deal I think.

4D vectors and matrices... You've got a point there. I'm not sure how I feel about this as much anymore. I'm starting to lean in the direction you went. Though I find Vec2f, Vec3b, Vec4i, etc a bit more readable. Also, it's at least a little more consistent with the sf::Vector2<T> naming scheme. Putting them in a sf::glsl namespace is a good idea too.

SFML3 with C++11 might allow for some nice ways to work with this.

template<typename T>
using Vec4<T> = std::array<T, 4>;

using Vec4f = Vec4<float>;
 

It does look slightly nicer. Though, if it's using C++11 (and 14?), hopefully uniform buffer objects could be used and then something like:

template<typename... Uniforms>
class Shader
{
    ...
    set(Uniforms... uniforms);
}
 

could be plausible. And would be nice to use. I think.

generics/overloads

True. I just find the setUniform<float>(5.3f) syntax a bit nicer than several different function names.
As well though, just because templates allow for generic programming doesn't mean you have to strictly adhere to generic programming.

Error stuff

Yeah. Though static_assert is C++11, isn't it? And yes, I know SFINAE would work as well, but, with all my experience with templates, the error messages produced are often... large. And difficult for someone not used to them. Since SFML doesn't make use of a large amount of templates, I figured it might be nice to send a bit nicer of an error message to the user.

253

Java / Re: Collision Detection

« on: August 24, 2015, 07:43:26 pm »

It looks right to me from here. Could you create a minimal example?

254

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

« on: August 24, 2015, 07:19:38 pm »

Number of overloads

I like getting rid of the vector component overloads (x, y, z) and just kept vector overloads.

I agree that the argument naming should be sf::Vector2*, sf::Vector3*, and etc. I see where the Vec# abbreviations come from, but this is a part of SFML, I think the naming for Vector types should be consistent across all of SFML. If someone is going to be using shaders/glsl, they'll know that glsl Vec# types correlate just fine with SFML Vector# types.

Also:

void setUniformVec2Array(const std::string& name, const Vector2f* vectorArray, std::size_t length);
void setUniformVec3Array(const std::string& name, const Vector3f* vectorArray, std::size_t length);

if you stick with *vec# naming, you may want to change the vectorArray type to reflect that.

GLSL arrays

I need to think about this some more, but I think a template/generic function could work quite well here.
Declare a generic version, and specialize it for each supported type. This wouldn't require indirection, and it would satisfy OpenGL remaining in the .cpp.
If desired, then the generic version could #error out to let the user know they picked an incorrect type (if the default error is deemed not clear enough).

// .hpp
template<typename T>
void setUniform(const std::string& name, const T& value)
{
    #error "Invalid type in sf::Shader::setUniform..." etc
}

// .cpp
template<>
void setUniform<float>(const std::string& name, float value)
{
    ...
}

... and so on
 

This was supported in C++03, right? I forget which template stuff was added in C++11 sometimes. If it isn't, maybe that would have to be done in SFML 3.

255

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: August 21, 2015, 09:58:17 pm »

Why? You could create that on first use. Problem solved

Well yeah, I guess that would work. This would be why multiple brains on a problem are good, haha.

It doesn't make sense to argue from a user/API perspective and talk about stuff happening in the background.

Well, the user-facing API is dependent on the background, correct? So would it not then be relevant?
Besides that, I like knowing what's going in the background. Regardless of the chosen API/background/etc, I'll be happy with having it, I'm just curious and want to know about the different options, that's all.

How would providing two APIs for the same help, just so that users with a bad feeling in the stomach are happy too?

I don't see how an overload/whatever is two different APIs. I meant function overloads (or another method of doing this). Just something like:

someClipboardFunction(someArg)
{
    someClipboardFunction(someArg, globalClipboardWindow);
}

someClipboardFunction(someArg, window)
{
    stuff
}

Maybe I'm misunderstanding what you meant, though.