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

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - eXpl0it3r

Pages: 1 2 3 [4] 5 6
46
General discussions / Conditional C++11 Support
« on: July 05, 2014, 01:05:11 pm »
To not further spam this one issue - I already cleaned it up a bit - I thought, I open a thread here.

The subject at hand is, whether we should rewrite some things in SFML to place in conditional support for C++11, way before we most likely fully move to C++11 with SFML 3. And if we do so, what should be included as conditional support.

Points that should not be discussed here:
  • How much of C++11 which compiler supports. - We are aware that not all compilers support everything, but that's the reason why it would be conditional.
  • Detailed discussion on how something could be implemented. - This thread isn't here to discuss how the implementation should look like in detail.

Point that should be discussed here:
  • Should SFML implement conditional C++11 support?
  • Should SFML move to unconditional C++11 support at one point?
  • What feature should be considered for the conditional C++11 support?

Important point that have already been made:
Supporting C++11 will allow nice additions, but it won't replace many things. After this change, I think you'll still be able to write a program that uses mostly C++98, if you want to.

Regarding backward compatibility and maintenance of older versions, it's true that we'll move forward and focus on improving the latest versions, but I think it would be wise to spend some time back-porting bug fixes to the latest revision of the previous major version (i.e. 2.x after 3.0 is out). If we want SFML to be used in the real world, and not only for short-term small projects, we have to care a minimum about backward compatibility, and not abandon users who would not stick to the latest version. So where should the limit be? I don't know, but this should definitely be discussed.

Quote from: Laurent on GitHub
After a bit of research, it seems that I won't be able to make a single build of SFML that both supports C++03 and C++11. Mixing both can lead to binary incompatibilities.

In this case, C++11 cannot be added conditionnally, we'd have to wait until SFML completely switches to C++11 (not before SFML 3).

Quote from: GitHub
  • initializer lists
  • r-value references (move semantics)
  • some of the constructors can be made constexpr really easily (for example, sf::Color, sf::VectorN, sf::Rect).
  • sf::String could support the new Unicode character/string types.

47
General discussions / SFML 3 - What is your vision?
« on: April 24, 2014, 01:37:42 pm »
As promised we as the new team, would like to be more open towards the community especially regarding the current development. We're currently discussing on how to approach things after SFML 2.2 and as such, we need to figure out what SFML 3.0 should actually be about.

Keep in mind this shouldn't really be about simple feature requests, for that we have dedicated forum, this should be more about what SFML 3 should offer besides a few new feature. For example: How the graphics API should be changed/opened/advanced, or whether C++11 should be non-optional, or should we change the way window states are handled, or etc...
We won't make any decisions here, we simply want to hear the ideas from all community members.

What is your vision of SFML 3?

48
General discussions / Rethinking the definition of "Simple"
« on: April 19, 2014, 06:45:06 pm »
Given my post count, it should be quite obvious that I'm an SFML enthusiast and as such, I've been following many discussions here on the forum but also on IRC. What I've noticed with many discussions regarding API adjustments or feature request, is the argument of keeping things "Simple" as the library's name says: "Simple and Fast Multimedia Library". This is in general good, because it will prevent unnessecary API blow-ups and a like. Unfortunately I've also seen many make use of that argument, but interpreting the word "simple" differently and the longer the more it seems that the general definition is something along the lines of:

"Someone with nearly no C++ experience should be able to use it."

Sure it never gets spelled out like that, but if a discussion only arises around how to make the magic happen by only calling a function and not bother with anything else, it's in my opinion the wrong definition of "simple".

This all kind of leads to the question: Who's the target audience of SFML?
Should SFML be a library with the simplicity for the ones that have learned some C++ in a week and then maybe manage to create a pong game OR should SFML be a library that allows more advanced C++ programmers to create fully featured 2D games, while providing an power full, yet simple and well documented API?

If we're amiing just for the first group ("newbies"), then I strongly believe SFML is not worth anyone's time, because if it's just easy to start with, even the newbies will once advance and notice that SFML doesn't have to offer enough complexity for bigger projects. SFML would then only be a gateway library to game programming.

So what's my point here? When discussing API changes or feature requests, we shouldn't ask ourselves whether newbies can use it easily, but instead ask whether the change would simplify the developer's life, whether it would allow the developer to focus more on the game itself. The focus of newbie-friendly features should shift to "scaleable" features, meaning an API that is more flexible, something that doesn't just work for the simple/newbie use-case but also for complex games and advanced C++ programmers.

Let's forget about "too complicated" and focus on "how do we make it simple"! :)

49
General / Type conversion warnings
« on: April 11, 2014, 09:03:47 am »
When I was building SFML for the Nightly Builds, I ran into the following warnings. I think most of the are only related to x64 builds and I'm not sure if we change the stb_image code, but here we go:

SFML\src\SFML\Network\Packet.cpp(408) : warning C4267: 'Initialisierung': possible loss of data 'size_t' to 'sf::Uint32', possible loss of data
SFML\src\SFML\Network\Packet.cpp(437) : warning C4267: 'Initialisierung': possible loss of data 'size_t' to 'sf::Uint32', possible loss of data
SFML\src\SFML/Graphics/stb_image/stb_image.h(760) : warning C4244: 'Initialisierung': possible loss of data '__int64' to 'int', possible loss of data
SFML\src\SFML/Graphics/stb_image/stb_image.h(773) : warning C4244: 'Initialisierung': possible loss of data '__int64' to 'int', possible loss of data
SFML\src\SFML/Graphics/stb_image/stb_image_write.h(321) : warning C4244: 'Initialisierung': possible loss of data '__int64' to 'int', possible loss of data

50
General / Doxygen Warnings
« on: April 09, 2014, 09:53:37 pm »
While going over warnings and errors with the 3DEE version, I noticed that some of the warnings from Doxygen were from the original SFML version, so I thought it might be useful to provide them here. Not sure if they should all get fixed.

Warning: Tag `SYMBOL_CACHE_SIZE' at line 299 of file doc/doxyfile has become obsolete.
To avoid this warning please remove this line from your configuration file or upgrade it using "doxygen -u"

Warning: Tag `SHOW_DIRECTORIES' at line 483 of file doc/doxyfile has become obsolete.
To avoid this warning please remove this line from your configuration file or upgrade it using "doxygen -u"

Warning: Tag `HTML_ALIGN_MEMBERS' at line 808 of file doc/doxyfile has become obsolete.
To avoid this warning please remove this line from your configuration file or upgrade it using "doxygen -u"

Warning: doxygen no longer ships with the FreeSans font.
You may want to clear or change DOT_FONTNAME.
Otherwise you run the risk that the wrong font is being used for dot generated graphs.

include/SFML/Graphics/Rect.hpp:187: warning: include file SFML/Graphics/Rect.inl not found, perhaps you forgot to add its directory to INCLUDE_PATH?
include/SFML/System/String.hpp:613: warning: include file SFML/System/String.inl not found, perhaps you forgot to add its directory to INCLUDE_PATH?
include/SFML/System/Thread.hpp:193: warning: include file SFML/System/Thread.inl not found, perhaps you forgot to add its directory to INCLUDE_PATH?
include/SFML/System/Utf.hpp:731: warning: include file SFML/System/Utf.inl not found, perhaps you forgot to add its directory to INCLUDE_PATH?
include/SFML/System/Vector2.hpp:250: warning: include file SFML/System/Vector2.inl not found, perhaps you forgot to add its directory to INCLUDE_PATH?
include/SFML/System/Vector3.hpp:252: warning: include file SFML/System/Vector3.inl not found, perhaps you forgot to add its directory to INCLUDE_PATH?

include/SFML/Network/Packet.hpp:178: warning: Member operator>>(Int8 &data) (function) of class sf::Packet is not documented.
include/SFML/Network/Packet.hpp:179: warning: Member operator>>(Uint8 &data) (function) of class sf::Packet is not documented.
include/SFML/Network/Packet.hpp:180: warning: Member operator>>(Int16 &data) (function) of class sf::Packet is not documented.
include/SFML/Network/Packet.hpp:181: warning: Member operator>>(Uint16 &data) (function) of class sf::Packet is not documented.
include/SFML/Network/Packet.hpp:182: warning: Member operator>>(Int32 &data) (function) of class sf::Packet is not documented.
include/SFML/Network/Packet.hpp:183: warning: Member operator>>(Uint32 &data) (function) of class sf::Packet is not documented.
include/SFML/Network/Packet.hpp:184: warning: Member operator>>(float &data) (function) of class sf::Packet is not documented.
include/SFML/Network/Packet.hpp:185: warning: Member operator>>(double &data) (function) of class sf::Packet is not documented.
include/SFML/Network/Packet.hpp:186: warning: Member operator>>(char *data) (function) of class sf::Packet is not documented.
include/SFML/Network/Packet.hpp:187: warning: Member operator>>(std::string &data) (function) of class sf::Packet is not documented.
include/SFML/Network/Packet.hpp:188: warning: Member operator>>(wchar_t *data) (function) of class sf::Packet is not documented.
include/SFML/Network/Packet.hpp:189: warning: Member operator>>(std::wstring &data) (function) of class sf::Packet is not documented.
include/SFML/Network/Packet.hpp:190: warning: Member operator>>(String &data) (function) of class sf::Packet is not documented.
include/SFML/Network/Packet.hpp:197: warning: Member operator<<(Int8 data) (function) of class sf::Packet is not documented.
include/SFML/Network/Packet.hpp:198: warning: Member operator<<(Uint8 data) (function) of class sf::Packet is not documented.
include/SFML/Network/Packet.hpp:199: warning: Member operator<<(Int16 data) (function) of class sf::Packet is not documented.
include/SFML/Network/Packet.hpp:200: warning: Member operator<<(Uint16 data) (function) of class sf::Packet is not documented.
include/SFML/Network/Packet.hpp:201: warning: Member operator<<(Int32 data) (function) of class sf::Packet is not documented.
include/SFML/Network/Packet.hpp:202: warning: Member operator<<(Uint32 data) (function) of class sf::Packet is not documented.
include/SFML/Network/Packet.hpp:203: warning: Member operator<<(float data) (function) of class sf::Packet is not documented.
include/SFML/Network/Packet.hpp:204: warning: Member operator<<(double data) (function) of class sf::Packet is not documented.
include/SFML/Network/Packet.hpp:205: warning: Member operator<<(const char *data) (function) of class sf::Packet is not documented.
include/SFML/Network/Packet.hpp:206: warning: Member operator<<(const std::string &data) (function) of class sf::Packet is not documented.
include/SFML/Network/Packet.hpp:207: warning: Member operator<<(const wchar_t *data) (function) of class sf::Packet is not documented.
include/SFML/Network/Packet.hpp:208: warning: Member operator<<(const std::wstring &data) (function) of class sf::Packet is not documented.
include/SFML/Network/Packet.hpp:209: warning: Member operator<<(const String &data) (function) of class sf::Packet is not documented.
include/SFML/Network/Packet.hpp:192: warning: parameters of member sf::Packet::operator<< are not (all) documented
include/SFML/Network/Packet.hpp:192: warning: return type of member sf::Packet::operator<< is not documented
include/SFML/Network/Packet.hpp:173: warning: parameters of member sf::Packet::operator>> are not (all) documented
include/SFML/Network/Packet.hpp:173: warning: return type of member sf::Packet::operator>> is not documented
<@3>:1: warning: parameters of member sf::UdpSocket::@3 are not (all) documented

51
Graphics / Clarify sf::Shape.getPoints() returns untransformed points
« on: April 02, 2014, 11:58:06 am »
Someone on IRC just asked why the rotation doesn't affect the point list of the CircleShape and upon looking closer, I realized that the points are essentially untransformed points in local space, which makes totally sense, but isn't documented clearly, neither in the documentation nor in the tutorial.

Sure it's kind of obvious and logical, but I think a comment doesn't hurt either, right?

52
SFML website / Clickable link for tutorial titles
« on: March 10, 2014, 11:10:11 am »
It's nice that the tutorials have ids for each title, but they are a bit useless, since you'll have to view the source code to ever get the name of the idea.
It would be great if there was some (hidden) link that one can just copy and paste. ;)

53
SFML game jam / SFML Game Jam 2 - Post Mortem
« on: February 03, 2014, 11:43:59 pm »
It's been a tough weekend for some of the SFML community and I feel it would be a shame if all the projects just sat over there on the SFML Game Jam website and nobody was really talking about them (except maybe on IRC). To get your attention and inspiration I'll post all the screenshots with names here.

The theme was: Time Travel

A Temporary Outbreak - Nexus & eXpl0it3r




Chronix - Therocode




LexThree - Iteem




No name ;) - AlexAUT




Shielding 114 - thomas9459




ShotWarp - zsbzsb & Elijah Brown




The Loop - 1man2kinds




Time paradox - vip-ak47




time shooting thing - kimspindel





Right now I have to go over the game myself and will hopefully finally manage to add something to my SFML News...
To everyone that created something: Congrats! You're really awesome for getting something together in such  a short period of time! :)

Let the discussions begin! ;D

54
General discussions / One Game A Month
« on: January 13, 2014, 09:05:08 pm »
Hey SFML Community!

I know there are many talented people here and mostly all are interested in developing some games, thus I thought some might be interested in hearing of One Game A Month. As the name says the idea is to create one game a month, so essentially twelve games in a year. There aren't really any rules to it, it's really just for fun and for the sake of making games. See the FAQ for more information.

I found the page last year, but didn't participate, this year however I'll try to get those twelve games out. As soon as the first one is finished, I'll create a "megathread" for all games.

And here's the 1GAM 2014 Keynote:


55
SFML website / Mistake in the 'Text and fonts' tutorial
« on: November 19, 2013, 02:36:03 pm »
I just ran into a small mistake in the 'Text and fonts' tutorial, which seems to be indicating that the font class has afunction called getLineHeight.

Quote from: Text and fonts - Tutorial
Finally, you can get some other metrics of the font, such as the line height or the kerning (always for a certain character size):

int lineHeight = font.getLineHeight(characterSize);

int kerning = font.getKerning(character1, character2, characterSize);

Looking at the documentation and the header file, I can't seem to find such a function. :)

56
General / CMake static & TDM
« on: October 09, 2013, 08:20:00 pm »
So I've been meaning to implement a way to recognize TDM builds, so that SFML actually builds correctly and not static for shared & static (yeah I assume the official builds are built wrong as well). ;)

The critical part would involve changing the following lines (Macros.cmake:101):
    # for gcc >= 4.0 on Windows, apply the SFML_USE_STATIC_STD_LIBS option if it is enabled
    if(SFML_OS_WINDOWS AND SFML_COMPILER_GCC AND SFML_USE_STATIC_STD_LIBS)
        if(NOT SFML_GCC_VERSION VERSION_LESS "4")
            set_target_properties(${target} PROPERTIES LINK_FLAGS "-static-libgcc -static-libstdc++")
        endif()
    endif()

But once I tried to change things around I started to ask myself:
  • Why do we not use -static, thus removing the need for the check, listing of both flags and linking everything possible static - which would be what one would expect. For example if the shipped compiler uses pthread for handling threads and one compiles just with -static-libgcc and -static-libstdc++ one will still have to ship the libwinpthread.dll, because it didn't get linked statically. So what's the reason for not using -static?
  • If you don't want to change it, would it be okay to pull the VERSION check into the upper if and do a TDM + shared/TDM + static check in an inner if?

Given the occasion of discussing linker stuff, I want to bring the other topic about properly linking dependencies again to attention. I still feel it should be changed... ;D

57
General / SFML Game Development - Use of assert in resource holder
« on: September 18, 2013, 04:26:19 pm »
So I've been reading parts of the book on my vacation and I've noticed a little issue. It's more a question of deign than an actual bug. The implementation of the resource holder makes use of assert, which is great and it's explained quite nice, but the issue is, that there's no way to prevent stepping into the assert, except by logical exclusion up on programming. As we probably all agree, we should write code that leaves as less doors for making mistakes as possible, thus having no way to check, whether a resource already exists from outside of the class, forces the user to either step into the assert or make unnecessary comments everywhere, which might get over read later on, to prevent the loading of two identical resources/with the same ID.

My conclusion is, that the resource holder class should have a exists() function to check the existence of resources, before loading them and praying it won't blow up in the assert. I mean one doesn't necessarily have to check the existence every time, but having no option to do so, seems rather dangerous/bad.

For examples:
TextureHolder textures;

if(!textures.exists(Textures::Airplane))
{
    std::vector<std::pair<Textures::ID, std::string>> textures_assets = load_textures_info_from_file();

    for(auto& asset : textures_assets)
    {
        if(!textures.exists(asset.first))
            textures.load(asset.first, asset.second);
    }
}
 

I know the other code looks prettier and one doesn't always have to check it if the logic allows it, but letting the user step into asserts because there's no way to check any kind of existence seems like a bad design.
Sure asserts are there for debugging, but you can't guarantee that all the possible scenarios will be played out, while running a debug build, thus releasing a game with possible bugs.

What do you guys think? Why didn't you implement such a function? :)

What about a separate forum for the book? :P

58
General discussions / Up to 40% off on C++ books
« on: August 21, 2013, 11:20:36 pm »
I know the title sounds cheesy, but I thought for all the new comers but also advanced programmers I have to share that offer Scott Meyers just reposted on his blog.

Quote from: Scott Meyers
Quote from: Pepped-up marketing folks at Addison-Wesley
Please feel free to point folks to informit.com/cplusplus which features a Buy 1 Save 30% | Buy 2 or More Save 40% discount code for all C++ titles.  Note, while only the most recent C++ titles are featured on the landing page, the discount code applies to ALL titles (there is a giant "Shop all C++ Titles" button at the bottom of the page and folks can search for your products by your last name).
According to the banner at the top of the page, the deal also includes free ground shipping within the USA. To get the discounts, you have to enter the magic promotion code CPLUSPLUS at checkout.

You might want to check against the oh so very often linked StackOverflow book list, to see what's really recommended and what's "just" recommended. ;)

59


What's it all about?
The SFML community is rather active and it's hard to keep yourself up-to-date with the latest discussions or project presentations. I'm spending quite a bit of my time reading the forum and looking at GitHub discussions, thus I don't miss that much content. But instead of keeping everything to myself, I'm writing some short recaps on various project presentations, discussions and other community news.

Where does that all happen?
All the posts will be published on my development blog. Since I'm using that blog for more than just SFML News, you can also just keep checking the SFML News category.

What can I do?
It's always nice to get some feedback in the comments or here on the forum.
You're also free to share it via all the social media (Twitter, Facebook, Google+, Your Own Blog) you know! :)

Current Content


60
General / Version of the external libraries
« on: February 17, 2013, 07:59:31 pm »
So I've wanted to build x64 MinGW binaries for SFML and actually already did it (see the working x64 nightly build package), but then I started thinking about the versions of the external libraries.
I haven't found out which ones are used at the moment and thus couldn't get matching versions. So I went ahead and took the most recent ones (at least a few month ago they were recent), but if one would want to add them to SFML, then we'd have miss-matching versions, which is kinda not nice.

Thus I see three options and want to discuss them:
  • Update all external libraries to the most recent (compatible) versions.
  • Find out the current specific versions and match the new binaries with the old versions.
  • Make a mixture of versions.

Personally I'd suggest option 1, but would also gladly follow option 2, if I'd get the exact version, which were used.

Btw. the 'problem' is only with FreeType and GLEW, since JPEG is already around 15 years old and one can convert the current import libraries for OpenAL and libsndfile to work with MinGW x64 compilers.

You can see here a working repository with x64 binaries. The only modification, that I had to do was add the binaries and edit the src/SFML/CMakeLists.txt.

Pages: 1 2 3 [4] 5 6
anything