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.
Building without Arial.hpp makes libsfml-graphics.so 269 KB on my system, so the inclusion of a default font file does add quite some size bloat, looking at it in relative numbers (>100% of the original size). While in absolute numbers, ~300 KB may indeed not be that much, I imagine only a small number of people actually use it, as most of them actually want to switch to their preferred font or write a customized bitmap text renderer.
It looks more like a debug feature to me that is primarily used by people who want a quick prototype program without any other resources, but it is not really something anyone would use in a large-scale project. I actually was not even aware of its presence and always assumed SFML would fail to display text if you didn't load a ttf file, until I checked out the source code.
if(NOT ${lib} MATCHES ".*/.*")
string(REGEX REPLACE "(.*)/bin/.*\\.exe" "\\1" STANDARD_LIBS_PATH "${CMAKE_CXX_COMPILER}")
set(lib "${STANDARD_LIBS_PATH}/lib/lib${lib}.a")
endif()
In other other words: SFML 3 will be released much sooner than you expect :lol:
QuoteMaybe you should commit the changes, update the documentation, and wait a little while? Or you could even think about a beta release, which would look like the real release, except it would have the beta tag attached to it, along with a warning that things might still change. I really think it is important to get this one right.
I don't think people need a release to know which naming convention they prefer. They can write a sample code themselves if they really need to see it in action.
And I don't want to commit this modification until I'm 100% sure that it's the final one. Imagine people who start to convert all their code, and suddenly I go back to the original naming convention...
Thanks for sharing your opinions.
camelCase + get/is should be my final decision.
Mobile devices, with OpenGL ES 2, will be supported later. That's one of my top priorities for SFML 2.
QuoteWill it support OpenGL 4.x ?
The window module already supports any OpenGL version.
i downloaded latest include files from github
and libs/dlls compilted by
http://www.sfml-dev.org/forum/viewtopic.php?t=6548
i just dont know what to do with that, dont wanna go back to 1.6
Quote from: "Nexus"It is the new Graphics API, see here.
But how can you only have linker errors? Many identifiers have changed, it shouldn't even compile. I recommend a complete rebuild. The new classes and functions can be looked up in the online documentation.
this was after I did a complete rebuild.
It is the new Graphics API, see here.
But how can you only have linker errors? Many identifiers have changed, it shouldn't even compile. I recommend a complete rebuild. The new classes and functions can be looked up in the online documentation.
