-
SFML 2.0 Release Candidate (http://www.sfml-dev.org/download.php#2.0-rc) is ready!
Please try it, and report anything that should be fixed for the final release:
- critical bugs
- public API issues (it won't be changed until SFML 3)
- packaging issues
- anything else that you find relevant
The tutorials are not ready yet (I'll now start to write them), so if you have no idea how to install and use this version, don't do it, wait for the final one instead.
The Linux version has no install script, you just have to copy the contents of the archive to your preferred install location (typically /usr/local). I'm still not sure what should be done for Linux packages:
- since I have no Unix makefile, it can't be done with "make install"
- building from sources is often recommended on Linux, anyway
- official distrib packages should be available quickly after SFML 2.0 is released, anyway
There doesn't seem to be a "standard" way of packaging libraries for Linux.
-
Very nice! :)
Is the release candidate the same as the latest Git revision 19276a?
-
Is the release candidate the same as the latest Git revision 19276a?
It's the same as the revision tagged "2.0-rc". Which should be the latest one, yes.
-
Not sure if this is a bug or something I'm doing wrong, but after I ran the Mac installer and created a new SFML project in Xcode, I tried to build it and got an error:
ld: library not found for -lsfml-system-d
-
haha the first error is on me! :P
Go to your project build settings and at the bottom edit SFML_LINK_DYLIBS_SUFFIX to "" (empty). That's should do it.
(Project using frameworks are not affected by this issue.)
-
Nifty!
How do you plan work on porting to Android (https://github.com/SFML/SFML/issues/39)?
Actually I was experimenting with porting 1.6 to Android when I saw the announcement ;)
-
haha the first error is on me! :P
Go to your project build settings and at the bottom edit SFML_LINK_DYLIBS_SUFFIX to "" (empty). That's should do it.
(Project using frameworks are not affected by this issue.)
Thanks, works like a charm!
-
How do you plan work on porting to Android?
I have no plan yet. All I can say is that I'd like to work on it soon, maybe SFML 2.2.
-
Aaah this comes perfectly as I've just started to work on Ymir ^^
Now I can work more rapidly on it and make an awesome game in Ruby!
I'll be quite quick to let you know if I find anything :)
I have found some things when you do advanced stuff with OpenGL and threads but I expect they won't be fixed as I think you see it as outside the realm of SFML.
-
Congrats Laurent! ;)
DJuego
-
I know there has been an issue with the sf::text constructor and the default font recently. Just downloaded the latest SFML release version (SFML-2.0-rc, debug libs, dynamic link) with codeblocks 10.05, Windows 7 and I get this error output to the console:
It repeats these two errors a total of 3 times...
An internal OpenGL call failed in Texture.cpp (146) : GL_INVALID_ENUM, an unacceptable value has been specified for an enumerated argument.
An internal OpenGL call failed in Texture.cpp (147) : GL_INVALID_ENUM, an unacceptable value has been specified for an enumerated argument.
Heres my code:
sf::Font mFont;
mFont.loadFromFile("fonts/arial.ttf");
sf::Text mText("Hello",mFont);
Its only when I initialize the sf::text or set the string it produces these errors. It will still draw and display correctly though. Just thought it might mean something.
Ps: love the new forum layout.
-
This error implies that you have a crappy graphics card (or drivers) that don't support OpenGL 1.2. Is that true?
-
I highly doubt it. Its an Nvidia Geforce Card (cant remember the model off the top of my head) thats only a a few years old. It will run just about any game I've thrown at it pretty well. I updated the drivers a couple months ago too. I will post the exact specs and version numbers later today when I get home. (I'll try running off the onboard graphics card as well)
-
Can you check the OpenGL version that your driver gives you?
sf::ContextSettings settings = window.getSettings();
std::cout << settings.majorVersion << "." << settings.minorVersion << std::endl;
-
Great news!
Thank you :)
-
You were correct Laurent. Apparently my drivers were not installed correctly so I was stuck with Opengl 1.1. I reinstalled my video drivers and I now have OpenGL 3.3. Error messages gone life is good. Sorry for the false alarm.
-
Hey awesome, well I'll be using this for Ludum Dare this weekend, so I'll let you know if I encounter any bugs! ;)
Good work Laurent and his minions/bug catchers!
-
The tutorial for OS X / XCode is online
http://www.sfml-dev.org/tutorials/2.0/start-osx.php
-
The tutorial for OS X / XCode is online
http://www.sfml-dev.org/tutorials/2.0/start-osx.php
This is also a RC of the tutorial. Tell me if something that is not clear enough, should be developed, added, removed, ...
There is no french version yet; I'll write it after you gave me some feedback on this first draft.
-
// Create the window with the OpenGL 3.2 Context.
window = new sf::Window(sf::VideoMode(800,600,32),"RadiumCoreCross",sf::Style::Close,sf::ContextSettings(24,8,4,3,2));
std::cout << "OpenGL Version" << window->getSettings().ContextSettings::majorVersion << "." << window->getSettings().ContextSettings::minorVersion << std::endl;
sf::ContextSettings settings = window->getSettings();
std::cout << settings.majorVersion << "." << settings.minorVersion << std::endl;
It appears on osx lion where 3.2 opengl is supported the context isn't being set to 3.2 but rather 2.1 opengl instead?
Is 3.2 opengl supported for SFML 2.0 ?
-
OGL 3.2 is not supported on Mac. (https://github.com/SFML/SFML/issues/84)
-
http://www.g-truc.net/post-0411.html
That is incorrect OGL 3.2 is supported and I have used GLFW to render with it. I am on OSX Lion 10.3 of course. My guess is that this SFML does not support 3.2 for OSX Lion.
-
did you click on the link I gave above and read the text ? ;)
-
Yeah I did 5 seconds ago haha thanks, awww man I really wanted to use 3.2 I guess Ill have to wait then =(
-
Laurent, some time ago (http://en.sfml-dev.org/forums/index.php?topic=4646.msg48312#msg48312) you wanted to rename the CMake variable SFMLDIR to SFML_ROOT in order to avoid confusion with other (CMake-proposed) variables like SFML_DIR. Is that still a topic?
-
Laurent, some time ago you wanted to rename the CMake variable SFMLDIR to SFML_ROOT in order to avoid confusion with other (CMake-proposed) variables like SFML_DIR. Is that still a topic?
Yes, I'll probably do that for the final 2.0 release (I have other CMake renaming to do).
-
SFML 2!?
(http://images1.wikia.nocookie.net/brookproves/ca/images/a/a1/Awww_yeah.jpg)
-
Laurent, some time ago you wanted to rename the CMake variable SFMLDIR to SFML_ROOT in order to avoid confusion with other (CMake-proposed) variables like SFML_DIR. Is that still a topic?
Done.
-
Does the move to SFML 2.0 decouple the OpenGL window stuff ( AKA, is it easier to port to ES 2)?
Regardless, congrats.
-
Yes, absolutely. But there are still important modifications left to do before SFML is 100% ready to be ported to OpenGL ES 2.
-
This is great news. I'll be downloading and testing the .NET version 2.0 RC tonight. I'll probably use it in my current project.
Thanks Laurent
-
The Code::Blocks tutorial is online :)
-
The Visual Studio tutorial is now online too.
-
Do you want a "SFML and Ruby" tutorial? In case you do what do you want it to contain?
-
Do you want a "SFML and Ruby" tutorial? In case you do what do you want it to contain?
It's up to you. If you feel like Ruby users would need a tutorial then I can put one there, but you can also create your own website, or just put an HTML doc file in rbSFML packages, or nothing at all.
-
I have an issue, even if it's not a big deal. And maybe it's just due to my messy installation of SMFL.
When I launch the tutorial example :
#include <SFML/Graphics.hpp>
int main()
{
sf::RenderWindow window(sf::VideoMode(300, 200), "SFML works!");
sf::Text text("Hello SFML");
while (window.isOpen())
{
sf::Event event;
while (window.pollEvent(event))
{
if (event.type == sf::Event::Closed)
window.close();
}
window.clear();
window.draw(text);
window.display();
}
return 0;
}
I get a run-time error. The window appears properly and the text is well displayed. But when I close the window, I get a segfault error (-1073741823). Why is that ?
I'm on Windows 7 64-bits, and compile with gcc 4.6.something.
Thx and nice job!
-
Might be this one
https://github.com/SFML/SFML/issues/59
-
Hi Laurent! I know this thread is for issues with 2.0, but I was wondering if this version 'fixes' the 'fps issues' of 1.6?
Thank you.
-
I'm not sure it's the same. I launched the do-not-crash example, and it crashes :)
#include <SFML/Graphics.hpp>
int main() {
sf::RenderWindow window(sf::VideoMode(300, 200), "SFML works!");
sf::Font fnt;
fnt.loadFromFile("C:/Windows/Fonts/ARABTYPE.ttf");
sf::Text text("Hello SFML");
text.setFont(fnt);
while (window.isOpen())
{
sf::Event event;
while (window.pollEvent(event))
{
if (event.type == sf::Event::Closed)
window.close();
}
window.clear();
window.draw(text);
window.display();
}
return 0;
}
Nevertheless, if I comment some lines, it works (if I don't draw the text)
#include <SFML/Graphics.hpp>
int main() {
sf::RenderWindow window(sf::VideoMode(300, 200), "SFML works!");
sf::Font fnt;
fnt.loadFromFile("C:/Windows/Fonts/ARABTYPE.ttf");
// sf::Text text("Hello SFML");
// text.setFont(fnt);
while (window.isOpen())
{
sf::Event event;
while (window.pollEvent(event))
{
if (event.type == sf::Event::Closed)
window.close();
}
window.clear();
// window.draw(text);
window.display();
}
return 0;
}
I will investigate further when I have time. Btw I don't know whether this is the right place to talk about this, is it ?
-
I know this thread is for issues with 2.0, but I was wondering if this version 'fixes' the 'fps issues' of 1.6?
What FPS issue?
I'm not sure it's the same. I launched the do-not-crash example, and it crashes
What's important with the no-crash code is that it assigns the text's font in the constructor, so that the default font never gets instanciated. Your code doesn't do that.
-
What FPS issue?
The ones with .SetFramerateLimit(). My games vary a lot in some builds.
-
My bad. I called the constructor with which you can load a font, and now it works perfectly fine. I guess it's the same problem then.
-
The ones with .SetFramerateLimit()
I'm not aware of any problem with that. Would you mind pointing me to the forum thread or issue that discusses it?
-
You should try SFML 2, the implementation of timing functions have changed and is supposed to be more reliable.
http://en.sfml-dev.org/forums/index.php?topic=6854.0 (http://en.sfml-dev.org/forums/index.php?topic=6854.0)
Sorry, I guess I read this out of context.
The thing is, if I set the frame-limit to 60, I get different fps on different computers (below 60 in some), yet if I don't specify a limit, the fps goes 80's in all comps. Also, in some instances on my fastest comp, my fps goes up to 100's regardless of set frame-limit.
Maybe I'm running old version of 1.6? Is the one on http://www.sfml-dev.org/download.php (http://www.sfml-dev.org/download.php) the latest?
I'm using Code::Blocks.
-
Maybe I'm running old version of 1.6? Is the one on http://www.sfml-dev.org/download.php the latest?
There is only one version of SFML 1.6 -- otherwise they would have different numbers ;)
-
Hi! I wanted to try SFML but seeing the state of transition from 1.6 to 2.0 - wanted to ask. Are tutorials on site from 1.6 version up to date with current API? Or should i wait for them to be rewritten?
-
The tutorials which are up to date are those in tutorials/2.0. Missing ones are being rewritten and will be uploaded as soon as they are ready.
-
Hi! I wanted to try SFML but seeing the state of transition from 1.6 to 2.0 - wanted to ask. Are tutorials on site from 1.6 version up to date with current API? Or should i wait for them to be rewritten?
Just a note that in general, it's not too hard to look at a 1.6 tutorial and the 2.0 documentation (the documentation for 2.0 is up to date, as far as I know), and figure out how to do the same thing in 2.0. Version 2.0 introduces a lot of changes/new things, but it's still good old SFML so things are still related.
-
Well I used SFML-2.0rc for the last 72 hours during Ludum Dare and it worked great. I used the Xcode installer and the Visual Studio 2010 binaries.
(And just in case you're interested, the game is here (http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=1695).)
-
IDK if it was posted/mentioned before, but I've noticed that in the CSFML binding, Graphics.h doesn't include SFML/Graphics/Sprite.h.
-
IDK if it was posted/mentioned before, but I've noticed that in the CSFML binding, Graphics.h doesn't include SFML/Graphics/Sprite.h.
Thanks!
-
I not really sure if it's a bug or if I'm doing something wrong, but when I called the isAvailable() member of SoundRecorder anywhere in my program, i get a segfault when my program finishes. My Debugger tells my the segfault happens in alcCloseDevice () (...myprogramdirectory...\bin\Debug\openal32.dll). here is some minimal code to reproduce it:
#include <SFML/Audio.hpp>
#include <iostream>
int main()
{
// Check that the device can capture audio
if (sf::SoundRecorder::isAvailable() == false)
{
std::cout << "Sorry, audio capture is not supported by your system" << std::endl;
return EXIT_SUCCESS;
}
return 0;
}
edit: of course i am using the rc2 build and i am on a windows xp machine with codeblocks and gcc
-
Please check the task tracker before posting.
https://github.com/SFML/SFML/issues/30
-
I'm sorry... Of course I checked the issue pages before i posted, but only searched for SoundRecorder. My bad, I will look more carefully next time.
-
There's not a lot of issues for each module in the tracker, so instead of searching for a particular keyword you can just activate the module filter (ie. click on the module name in the tag list) and check the few issues associated to it. That's what I always to when I have do find an old issue :)
-
Well I used SFML-2.0rc for the last 72 hours during Ludum Dare and it worked great. I used the Xcode installer and the Visual Studio 2010 binaries.
(And just in case you're interested, the game is here (http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=1695).)
Hey nice game !
We used SFML too for the 72h compo at Ludum Dare: check it out !
http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=10655
-
We used SFML too for the 72h compo at Ludum Dare: check it out !
http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=10655
But you didn't use SFML 2rc or did you? Because I only get a blank command line window and then nothing happens which speaks for the typical ATI bug which is present in SFML 1.6.
As a side note, SFML projects (http://en.sfml-dev.org/forums/index.php?board=10.0) was specially created to present your games to the SFML community. So it would be nice to see an announcement there. ;)
-
There is a problem when building static libraries with Mingw-w64 (32 and 64 versions). It is in the Macros.cmake file at lines 18-19:
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()
The problem is that the libs are split between a couple of directories. Specifically, in my 32-bit version, libopengl32.a, libgdi32.a, libwinmm.a and a few others are not in <mingw>/lib, but rather in <mingw>/i686-w64-mingw32/lib. This totally breaks the above code, which assumes they are in <mingw>/lib, and the make fails.
-
There are issues for that on the tracker.
-
Another bunch of buggies from CSFML: In the include files, sfCircleShape has _GetOrigin and _GetScale instead of their camelCase versions, and all of sfRectangleShape's functions suffer from the same problem.
-
Another bunch of buggies from CSFML: In the include files, sfCircleShape has _GetOrigin and _GetScale instead of their camelCase versions, and all of sfRectangleShape's functions suffer from the same problem.
Wow, there was in fact a lot of functions that were still using the old naming convention. I wonder why I didn't check using a regexp before.
-
I don't know if this is a bug, but i found out sf::Keyboard::isKeyPressed() really slows down your programm if it is used every loop? I used it 5 times per gameloop and got ~10fps in the game. Now i changed to a Keyboard-Event-based input and i got 80-100 fps (on the same crappy netbook)? Found the issue with the valgrind profiler.
I know the event-based is the preffered way, but the other was more intuitive in my opinion.
-
I don't know if this is a bug, but i found out sf::Keyboard::isKeyPressed() really slows down your programm if it is used every loop?
It's the first time that I hear about that. It would be interesting to know if other people experience this problem too.
-
Actually i found that to be true too...that exact line of code seemed to slow down my computer
-
On which OS?
-
It's just a personal opinion but I think the design of the sf::Shape part of the API is ugly and non-natural. Of course, I know nothing about the under layer (which is OpenGL) so I won't criticize. If SFML 2.0 is meant to be a widely used version, from my point of view, this should need a face-lifting before being released :)
When I say ugly, I'm talking about writing CircleShape, ConvexShape (which should be ConvexPoligon by the way) and RectangleShape. Theese name are long because of the substring "Shape" which make things ugly. Why don't you put everything in a namespace named sf::Shape ?
When I say non-natural, I'm talking about why RectangleShape doesn't inherit from ConvexShape because a rectangle is no more than a convex polygon. Why can't I move my RectangleShape's points anymore and - by the way - why have point's properties (color, outline color) disappeared ? I found them very useful. Now I would understand if this comes from a technical reason belonging to a layer below the SFML but it took interest in using sf::Shape. Why don't you add other shapes such sf::TriangleShape.
I just want the best for Simple and Fast Multimedia Library :)
-
When I say ugly, I'm talking about writing CircleShape, ConvexShape (which should be ConvexPoligon by the way) and RectangleShape. Theese name are long because of the substring "Shape" which make things ugly.
You have a quite... special understanding of ugly. sf::Shape::Rectangle is more beautiful because it is... hm, longer? Or do you always write using namespace as soon as you see a namespace?
Honestly, the names match their meaning perfectly. "Shape" is the base class, and "RectangleShape" is a specialized shape (namely a rectangle), so its name is standing to reason.
When I say non-natural, I'm talking about why RectangleShape doesn't inherit from ConvexShape because a rectangle is no more than a convex polygon.
Probably because some functions like setPointsCount() are not appropriate for a rectangle.
Why can't I move my RectangleShape's points anymore
You can, using setSize() and setPosition().
why have point's properties (color, outline color) disappeared ? I found them very useful.
There is now less confusion with global/point-local color. The special case of differently colorized points can still be achieved with sf::VertexArray.
-
When I say ugly, I'm talking about writing CircleShape, ConvexShape (which should be ConvexPoligon by the way) and RectangleShape. Theese name are long because of the substring "Shape" which make things ugly.
You have a quite... special understanding of ugly. sf::Shape::Rectangle is more beautiful because it is... hm, longer? Or do you always write using namespace as soon as you see a namespace?
Honestly, the names match their meaning perfectly. "Shape" is the base class, and "RectangleShape" is a specialized shape (namely a rectangle), so its name is standing to reason.
Finally you are right. Maybe because I'm used to write sf::Shape::Rectangle() to create my rectangle.
When I say non-natural, I'm talking about why RectangleShape doesn't inherit from ConvexShape because a rectangle is no more than a convex polygon.
Probably because some functions like setPointsCount() are not appropriate for a rectangle.
Why can't I move my RectangleShape's points anymore
You can, using setSize() and setPosition().
The reason may be about hardware acceleration but I can make a Rectangle using ConvexShape with wich I can move the point as I want. I thought I could use RectangleShape not to start from scratch when I want to make a parallelogram.
why have point's properties (color, outline color) disappeared ? I found them very useful.
There is now less confusion with global/point-local color. The special case of differently colorized points can still be achieved with sf::VertexArray.
I did not notice this class. How do I set a color ?
-
The reason may be about hardware acceleration but I can make a Rectangle using ConvexShape with wich I can move the point as I want. I thought I could use RectangleShape not to start from scratch when I want to make a parallelogram.
You got the point: if you want to manipulate your rectangle as a convex polygon (change every point individually and eventually get a non-rectangle), use sf::ConvexShape. If you want to manipulate your rectangle as a rectangle (change size and position, and let SFML ensure that it will always be a rectangle), then use sf::RectangleShape.
I did not notice this class. How do I set a color ?
This class is the low-level layer of SFML. You construct your own vertices (a vertex is a 2D point with attributes: position, color and texture coordinates), and then you draw them as either points, lines, triangles or quads. So there's no global function that would work on your whole vertex array, instead you have to manage the points individually -- which is what you need, apparently.
-
On which OS?
Sorry for the late reply. OS is Ubuntu 12.04 64bit on Intel Atom :).
Can i help solving this bug? I'll try to reproduce the bug on my other PC with 12.04 tomorrow.
I'm not sure but as far as i can remember, the most CPU time in KeyPressed was used in an other SFML-internal function which was called inside KeyPressed. I hope i can find the name of the function again.
I'll will post all results tomorrow evening :)
-
The reason may be about hardware acceleration but I can make a Rectangle using ConvexShape with wich I can move the point as I want. I thought I could use RectangleShape not to start from scratch when I want to make a parallelogram.
You got the point: if you want to manipulate your rectangle as a convex polygon (change every point individually and eventually get a non-rectangle), use sf::ConvexShape. If you want to manipulate your rectangle as a rectangle (change size and position, and let SFML ensure that it will always be a rectangle), then use sf::RectangleShape.
I just looked at the API docs, and I may have (probably have) missed something, but it may be nice to provide a function/operator to convert a RectangleShape into a ConvexShape (and similarly with a CircleShape). Quite a low-priority feature, I might say, but what do you think about this possibility?
I too think RectangleShape should inherit from ConvexShape, just because a rectangle is a convex shape. But I don't think it should inherit from ConvexShape in its current form, and I haven't given enough thought to this to propose any kind of clean alternative. I don't think it's a show-stopper though, so I'm not too concerned with it.
-
I can't tell if there is a reason for this or not. When you create an sf::CircleShape the origin is set as if it were at the top-left corner of a bounding box encasing the circle. I find it more intuitive to have the circle's origin at the centre of the circle.
-
I just looked at the API docs, and I may have (probably have) missed something, but it may be nice to provide a function/operator to convert a RectangleShape into a ConvexShape (and similarly with a CircleShape). Quite a low-priority feature, I might say, but what do you think about this possibility?
Why woud one need such a feature?
And don't forget that shape classes are just helpers, you're free to create your own shapes, either derived from sf::Shape or even from scratch with vertex arrays. Don't be limited by SFML classes, they are just there to provide simple features for simple use cases.
I too think RectangleShape should inherit from ConvexShape, just because a rectangle is a convex shape.
So you're the kind of programmer that would make a Square class inherit from Rectangle? ;)
What you suggest is not possible. ConvexShape is less constrained than RectangleShape, so the latter would inherit functions that would be able to break its contract.
I can't tell if there is a reason for this or not. When you create an sf::CircleShape the origin is set as if it were at the top-left corner of a bounding box encasing the circle. I find it more intuitive to have the circle's origin at the centre of the circle.
This is a convention, all graphical entities in SFML have their origin in the top-left corner by default. It's easy to change that by calling setOrigin.
-
I just looked at the API docs, and I may have (probably have) missed something, but it may be nice to provide a function/operator to convert a RectangleShape into a ConvexShape (and similarly with a CircleShape). Quite a low-priority feature, I might say, but what do you think about this possibility?
Why woud one need such a feature?
And don't forget that shape classes are just helpers, you're free to create your own shapes, either derived from sf::Shape or even from scratch with vertex arrays. Don't be limited by SFML classes, they are just there to provide simple features for simple use cases.
There are cases where one wants to construct a specialized shape, but after that, just use it generically as convex shape -- similar to the old factory functions that returned a single type. Thor contains such a function sf::ConvexShape toConvexShape(const sf::Shape&);
It is not strictly necessary, but a little bit more convenient that sf::Shape pointers which have no value semantics. Although I could also use aurora::CopiedPtr<sf::Shape> to give them value semantics ;)
But if it's necessary for SFML, is a different question. At the moment I'm not even sure how much of the Shape functionality will remain in Thor -- some parts seem to be very specific, maybe I'll remove them or provide them as examples.
I too think RectangleShape should inherit from ConvexShape, just because a rectangle is a convex shape.
That's not the only criterion for inheritance, take a look at the Liskov Substitution Principle.
-
There are cases where one wants to construct a specialized shape, but after that, just use it generically as convex shape
In this case it's not hard to use sf::CongexShape directly. Defining a circle's or rectangle's points manually is really straight-forward.
-
... But I agree that the new shapes API is still not perfect. I can't change it now because SFML 2 is going to be released, but I'm already thinking about something that could replace it in the future.
However, we could work on solutions and provide them soon, for example in Thor if you're interested in improving this area. Later, some of these solutions could be integrated to SFML if they prove to be good enough (like boost and std ;D).
I don't know if it would be a good idea, that was just the monday morning suggestion :)
-
I just looked at the API docs, and I may have (probably have) missed something, but it may be nice to provide a function/operator to convert a RectangleShape into a ConvexShape (and similarly with a CircleShape). Quite a low-priority feature, I might say, but what do you think about this possibility?
Why woud one need such a feature?
It could be easier for creating custom convex shapes. That is, you could take a rectangle as a starting shape, and then slightly transform the points (so it's not a rectangle, but still a convex shape), rather than starting from scratch.
I too think RectangleShape should inherit from ConvexShape, just because a rectangle is a convex shape.
So you're the kind of programmer that would make a Square class inherit from Rectangle? ;)
What you suggest is not possible. ConvexShape is less constrained than RectangleShape, so the latter would inherit functions that would be able to break its contract.
Don't forget I said I wouldn't do this in its current form :) Doing so right now would certainly violate LSP. I suppose I'm thinking of a more component-based design for the shapes, where shape classes are created through composition of various attributes/capabilities. And I figure with a design like this, implementing it with inheritance would require a little less typing :D (plus allow polymorphic behavior, if done carefully, though I don't know if that's a worthwhile goal).
But I'm ok with the shapes API for now. It's not like these little details are going to stop me or anyone else from making a game. I'm just thinking out loud.
-
Don't forget I said I wouldn't do this in its current form
Any other form that I can think of doesn't involve inheritance. To me, the current design is the best that you can get if you want to keep inheritance: sf::Shape has all the common attributes plus functions to read points. Functions that set points (ie. that wouldn't fit in the RectangleShape class) are kept in ConvexShape only.
I suppose I'm thinking of a more component-based design for the shapes, where shape classes are created through composition of various attributes/capabilities. And I figure with a design like this, implementing it with inheritance would require a little less typing (plus allow polymorphic behavior, if done carefully, though I don't know if that's a worthwhile goal).
If you have a precise idea of what this solution would look like, I'll be glad to hear more about it :)
-
I don't know if it would be a good idea, that was just the monday morning suggestion :)
Yes, it's a good idea in my opinion :)
I just don't really have an exact imagination of how I could improve it. The only thing I'm quite sure to leave in its current form is thor::ConcaveShape, I don't know however if it's a candidate for SFML because of its rather complex triangulation algorithm. And it doesn't inherit from sf::Shape, since the latter only supports convex shapes. thor::Arrow could also be useful to visualize vectors, but it's not integrated with sf::Shape either...
One approach consists of minimalizing the Thor Shape API for 2.0, and of adding features as soon as I've found a good way ;)
-
In CSFML, SoundStream.h isn't #included in Audio.h (public headers). Also, in the same SoundStream.h, there are still CamelCase function names, but maybe it isn't necessary to report them, since you indicated you will use regexp. (Am I wrong?)
-
In CSFML, SoundStream.h isn't #included in Audio.h (public headers). Also, in the same SoundStream.h, there are still CamelCase function names, but maybe it isn't necessary to report them, since you indicated you will use regexp. (Am I wrong?)
Have you checked the latest modifications on the repository?
-
Oh, hell, I forgot that. Thanks :)
-
I've been messing around a little more with the release candidate in the last days and I couldn't find anything that not yet on the issue tracker. Great job!
What's still left to be done before the final version is released?
-
What's still left to be done before the final version is released?
I must finish to write the tutorials.
-
The documentation about events says "Depending on the type of event, the event instance will be filled with different parameters" but where to find more about how is filled an event when it's a precise type of event ? E.g: if the event type is sf::Event::Closed, how is the event filled ? The same question for the other seventeen one.
-
It's not hard to find the matching member:
MouseButtonPressed/Released -> event.mouseButton
KeyPressed/Released -> event.key
...
Closed and a few others have no parameter (what would you expect?).
This is of course explained in detail in the tutorials.
-
If this was explained, I wouldn't be here for asking :) I didn't expect anything special for events that are triggered when a window closes but as I'm writing a binding I wanted to be sure.
-
If this was explained, I wouldn't be here for asking
It's in the "Handling events" tutorial.
-
If this was explained, I wouldn't be here for asking
It's in the "Handling events" tutorial.
It was implicitly said :) Maybe a line like "The other three events (Closed, LostFocus and GainedFocus) have, of course, no specific parameters" would have removed my doubt.
By the way, maybe there's a small error in the documentation, shouldn't sf::Text::getStyle() and sf::Text::setStyle() returns/takes a sf::Text::Style instead of Uint32 ? I'm saying that based of sf::Sotcket::bind() which returns a sf::Socket::Status, they are both an enumeration. It's been a long I haven't practiced my C++ so I may be wrong...
-
Maybe a line like "The other three events (Closed, LostFocus and GainedFocus) have, of course, no specific parameters" would have removed my doubt.
The new documentation will be much better :)
By the way, maybe there's a small error in the documentation, shouldn't sf::Text::getStyle() and sf::Text::setStyle() returns/takes a sf::Text::Style instead of Uint32 ?
No, because you can combine several styles. In C++, combining multiple items of an enum produces an integer, not a variable of the enum type.
-
Hello,
I have a problem with the git version of CSFML, when I try to compile I get the error:
undefined reference to `sfWindow_setSize'
If I remove this function call, there isn't any error anymore, and the compilation succeed.
-
The function exists, make sure that you use a rencent revision of CSFML, that you properly compiled it, and that you're not mixing with an older version.
-
yes it is a recent version of the GIT, I downloaded/compiled it again just before posting.
and indeed it is a weird error, because the function is there, without any case error.
1.6 is also arround but I mouved it outside of /usr/lib, I put it in /usr/lib/sfml-1.6/ so if I don't provide this path it should not be found
(I also moved the 1.6 includes)
I have this error only with this particular function. And I have no idea why because it's there in the sources.
If I remove this function from my sources, there is no error.
I have not tryed yet to test from a more simple hello world example. I'll do tomorrow.
-
I remember another user having a similar issue with sfImage_createMaskFromColor. The function is well defined and exported, but missing from the compiled libraries.
-
Hi,
It seems that there is a problem with sfMouse_getPosition() and sfMouse_setPosition().
It seems that it provides interaction with sfWindow but not with sfRenderWindow.
cheers
-
Indeed. That's a problem.
-
Hmm, interesting. Mostly playing around with some odd threading stuff here. I made a system where you have n threads (where n is the hardware concurrency), and the first available thread grabs any tasks that are pushed onto a concurrent fifo task queue and executes them.
Now, originally I had it written so one of those tasks was the final render pass, which does the drawing to an sfml window and the window.display(). The window inputs always happened on the main thread (which was separated from this task system by making it just wait for tasks and then run those tasks, letting other threads "jump into" the main thread for a bit, kinda inefficient but as a stopgap solution it worked).
This worked fine when I was running it with my integrated graphics card (NVIDIA Optimus technology defaulted to this for the unrecognised executable), regardless of how many threads I was using. However,when n was >= 5 (meaning 6 or more threads were in use, one main thread and 5 task threads) it'd render a few frames and then crash.
Modifying the code so both final render and input polling occurred on the main seemed to fix this problem so I'm putting it down under "nvidia opengl multithreading weirdness" and "you dolt, graphics cards are not meant to run on potentially different threads in the same program every render" and moving on.
-
Indeed. That's a problem.
Do you plan to resolve this for the 2.0 release ?
-
Do you plan to resolve this for the 2.0 release ?
I'll try.
-
Hi Laurent!
I've not been able to compile with <SFML/Network/Http.h> except if I make the change below in the header file.
Also Ftp.hpp and Http.hpp are in Network.hpp, but Ftp.h and Http.h are not in Network.h, so the patch below correct this too.
diff -Naur LaurentGomila-CSFML-bfebe0a/include/SFML/Network/Http.h CSFML_git_2012-05-24/include/SFML/Network/Http.h
--- LaurentGomila-CSFML-bfebe0a/include/SFML/Network/Http.h 2012-05-22 17:56:01.000000000 +0200
+++ CSFML_git_2012-05-24/include/SFML/Network/Http.h 2012-05-24 05:55:57.000000000 +0200
@@ -37,19 +37,19 @@
/// \brief Enumerate the available HTTP methods for a request
///
////////////////////////////////////////////////////////////
-enum sfHttpMethod
+typedef enum
{
sfHttpGet, ///< Request in get mode, standard method to retrieve a page
sfHttpPost, ///< Request in post mode, usually to send data to a page
sfHttpHead ///< Request a page's header only
-};
+} sfHttpMethod;
////////////////////////////////////////////////////////////
/// \brief Enumerate all the valid status codes for a response
///
////////////////////////////////////////////////////////////
-enum sfHttpStatus
+typedef enum
{
// 2xx: success
sfHttpOk = 200, ///< Most common code returned when operation was successful
@@ -78,7 +78,7 @@
// 10xx: SFML custom codes
sfHttpInvalidResponse = 1000, ///< Response is not a valid HTTP one
sfHttpConnectionFailed = 1001 ///< Connection with server failed
-};
+} sfHttpStatus;
////////////////////////////////////////////////////////////
diff -Naur LaurentGomila-CSFML-bfebe0a/include/SFML/Network.h CSFML_git_2012-05-24/include/SFML/Network.h
--- LaurentGomila-CSFML-bfebe0a/include/SFML/Network.h 2012-05-22 17:56:01.000000000 +0200
+++ CSFML_git_2012-05-24/include/SFML/Network.h 2012-05-24 05:55:20.000000000 +0200
@@ -30,6 +30,8 @@
////////////////////////////////////////////////////////////
#include <SFML/System.h>
+#include <SFML/Network/Ftp.h>
+#include <SFML/Network/Http.h>
#include <SFML/Network/IpAddress.h>
#include <SFML/Network/Packet.h>
#include <SFML/Network/SocketSelector.h>
-
Thanks :)
-
Hey Laurent,
Is there a problem with the server that is hosting the C++ RC 2.0 files?
I'm getting literally <500 bytes/second.
Thanks,
Bread
-
There's no known problem. I just tried to download something and got more than 1 MB/s.
-
Ok, it must be something on my end.. other networks seem to be downloading it fine.
Thanks for the quick reply! I'm looking forward to making these forums my home haha.
-
No flip function for the Sprite class? :'(
-
No flip function for the Sprite class? :'(
I'm pretty sure you can scale by negative amounts to flip. So sprite.setScale(1.0f, -1.0f) would be a flip along the x-axis.
-
I'm pretty sure you can scale by negative amounts to flip. So sprite.setScale(1.0f, -1.0f) would be a flip along the x-axis.
Yep! ;) Thank you. Always used the FlipX in 1.6.
-
Hi,
There is a problem with this funciton:
void sfPacket_readString(sfPacket* packet, char* string);
You may argue that the application should know what is the buffer size needed, but a malicious peer may send a bigger string, which will make the game server segfault.
Here is a test case that produces such a segmentation fault:
#include <stdio.h>#include <stdlib.h>#include <SFML/Network/Packet.h>int main
(){ char *buf
= "+++"; sfPacket
*p
= sfPacket_create
(); sfPacket_writeString
(p
, "0123456789ABCDEF"); sfPacket_readString
(p
, buf
); printf("BUF: %s\n", buf
); sfPacket_destroy
(p
); return 0;}
There are one parameter missing and a returned value missing.
It should be something like:
int sfPacket_readString(sfPacket* packet, char* string, int length);
We need a parameter length that tells the size of the buffer string provided, and the function should not try to fill more than that in oreder to prevent the segmentation fault.
We also need a returned value telling how many bytes where filled into the buffer, because if the buffer is of a larger size (for exemple 1024) and the function fills a smaller amount (for exemple 30), we need that value to extract the actual chunk. Using the NULL C string terminator is not enough / is not always a good method.
-
https://github.com/SFML/SFML/issues/117
-
Any Randomizer alternative?
-
Any Randomizer alternative?
std::rand (http://www.cplusplus.com/reference/clibrary/cstdlib/rand/) & std::srand (http://www.cplusplus.com/reference/clibrary/cstdlib/srand/)
-
Or if you're using C++11, there's the <random> (http://en.cppreference.com/w/cpp/numeric/random) header. If you seed your random generator and require the same results on different platforms, you can't rely on rand(), but the <random> header should be consistent across platforms.
Of course, if you don't need repeatable random numbers, all that doesn't matter. ;)
-
Hi,
it seems there is an issue with the API 2.0.
I post it here, not in feature request because I have read that there will be no change in the API 2.0 until 3.0.
It seems that it is possible to plug several joypads into the same computer to play multiusers game because there is a joypadID field in the event structure, but it seems that there is no equivalent for mices!
With the SDL it is possible to handle one mouse for each player. So this is impossible with SFML ?
-
So this is impossible with SFML ?
Indeed. This feature is not implemented yet.
I have read that there will be no change in the API 2.0 until 3.0.
The API can't be broken, it must remain backward compatible. But it doesn't mean that new things cannot be added.
-
So this is impossible with SFML ?
Indeed. This feature is not implemented yet.
I have read that there will be no change in the API 2.0 until 3.0.
The API can't be broken, it must remain backward compatible. But it doesn't mean that new things cannot be added.
Sorry, I don't see how this could be added without breaking API compatibility?
Wouldn't it be better to add the mouseID field to the event struct, and the mouseID parameter to the sf::Mouse methods now (even if it's ignored at the beginning), so that it wouldn't break 2.0 API when we add this feature?
-
It might be nice to have an operator| for Rects.
template<typename Num> sf::Rect<Num> operator| (sf::Rect<Num> lhs, sf::Rect<Num> rhs) {
sf::Rect<Num> intersect;
if(!lhs.Intersects(rhs, &intersect)) return sf::Rect<Num>();
return intersect;
}
template<typename Num> sf::Rect<Num>& operator|= (sf::Rect<Num>& lhs, sf::Rect<Num>& rhs) {
lhs = lhs | rhs;
return lhs;
}
Using the set intersection operator makes sense for this context, and it's slightly different than the member function which returns a boolean rather than the intersecting rectangle. Of course, it's not that important, since these are global functions and therefore I can just do this myself if I need it. Just a random thought in passing.
(It'd also be nice to have a "contains" operator that takes a Rect and a Vector, but I can't think of a reasonably logical operator symbol to use for that one.)
-
It is not obvious at all what operator| means in combination with rectangles, thus I recommend not to overload it.
Why do you call it "set intersection operator"? This one has the symbol ∩. If I had to choose the most appropriate C++ operator for set intersection, it would probably be & (because the intersection contains the elements that are in the first set and the second set) -- on the contrary, | would rather denote set union.
-
Sorry, I don't see how this could be added without breaking API compatibility?
Adding a member to a struct, and an argument with default value to a function doesn't break API compatibility.
-
The sfml-window tutorials are online.
-
Why do you call it "set intersection operator"? This one has the symbol ∩. If I had to choose the most appropriate C++ operator for set intersection, it would probably be & (because the intersection contains the elements that are in the first set and the second set) -- on the contrary, | would rather denote set union.
Huh. You're right, of course. (Duh.) Anyway, I think it's reasonably obvious that what operator& would mean for rectangles, since the logical and set operators are closely related, and documentation would clear up any confusion.
That said, I don't really care that much if it's added. It's just a thought thrown out.
-
Sorry, I don't see how this could be added without breaking API compatibility?
Adding a member to a struct, and an argument with default value to a function doesn't break API compatibility.
So when you say that the 2.0 API should not be broken, you exclude the C API?
-
So when you say that the 2.0 API should not be broken, you exclude the C API?
That's a good point. I don't know if I'm going to provide API compatibility for the C API, since its purpose is to be a base for other bindings and not a ready-to-use API for C programers.
But I can also find workarounds (like defining a new function for that extra argument), and clean them in SFML 3.
-
How can I compute fps in 2.0? :-[
Thanks.
-
what I get when I search for 'fps' : http://en.sfml-dev.org/forums/index.php?topic=8223.msg54975#msg54975 searching is fun! Do some. ;)
-
just tried the RC, looks nice. Just one weird quirk:
i installed it into a custom directory.
however, when i set the PKG_CONFIG_PATH accordingly and try pkg-config --libs --cflags sfml-all
it shows the following:
-I/home/laurent/release/2.0-rc/sfml/SFML-2.0-rc/include -L/home/laurent/release/2.0-rc/sfml/SFML-2.0-rc/lib -lsfml-system -lsfml-window -lsfml-graphics -lsfml-audio -lsfml-network
alas, neither my name nor my user login is laurent, so i guess this directory is hardcoded somewhere.
-
Yeah, pkg-config files contain absolute paths, they mustn't be distributed. I didn't noticed it because these files were added by someone else.
-
I was browsing the git repository a little while ago (can't quite remember why) and noticed this (https://github.com/SFML/SFML/blob/master/src/SFML/Graphics/Arial.hpp). I may be wrong, but I was under the impression that distributing Arial without a licence is not allowed, and that looks suspiciously like distributing Arial.
-
Interesting, I never thought about that. I should definitely find a free replacement. It's not clear whether I can take a GPL font or not, though.
-
Maybe an OFL font? I'm not sure really; I'm not a lawyer or anything.
-
What about Bitstream Vera (https://en.wikipedia.org/wiki/Bitstream_Vera)?
The license states:
Copyright
Copyright (c) 2003 by Bitstream, Inc. All Rights Reserved. Bitstream Vera is a trademark of Bitstream, Inc.
Permission is hereby granted, free of charge, to any person obtaining a copy of the fonts accompanying this license (“Fonts”) and associated documentation files (the “Font Software”), to reproduce and distribute the Font Software, including without limitation the rights to use, copy, merge, publish, distribute, and/or sell copies of the Font Software, and to permit persons to whom the Font Software is furnished to do so, subject to the following conditions:
The above copyright and trademark notices and this permission notice shall be included in all copies of one or more of the Font Software typefaces.
The Font Software may be modified, altered, or added to, and in particular the designs of glyphs or characters in the Fonts may be modified and additional glyphs or characters may be added to the Fonts, only if the fonts are renamed to names not containing either the words “Bitstream” or the word “Vera”.
This License becomes null and void to the extent applicable to Fonts or Font Software that has been modified and is distributed under the “Bitstream Vera” names.
The Font Software may be sold as part of a larger software package but no copy of one or more of the Font Software typefaces may be sold by itself.
THE FONT SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF COPYRIGHT, PATENT, TRADEMARK, OR OTHER RIGHT. IN NO EVENT SHALL BITSTREAM OR THE GNOME FOUNDATION BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, INCLUDING ANY GENERAL, SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF THE USE OR INABILITY TO USE THE FONT SOFTWARE OR FROM OTHER DEALINGS IN THE FONT SOFTWARE.
Except as contained in this notice, the names of Gnome, the Gnome Foundation, and Bitstream Inc., shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Font Software without prior written authorization from the Gnome Foundation or Bitstream Inc., respectively. For further information, contact: fonts at gnome dot org.
-
It looks too limited:
Vera itself covers only common punctuation and the Latin alphabet with some diacritics
DejaVu (https://en.wikipedia.org/wiki/DejaVu_fonts) seems to have a much wider glyph coverage.
-
Speaking of a built-in default font, it would be nice to have an easy way (perhaps some sort of compilation flag) to build SFML-Graphics without including Arial.hpp (or DejaVu.hpp if it's changed to that), without having to manually comment it out everytime. I personally never use sf::Text, as I have my own class that renders bitmap text, so there is essentially >300 KB of useless data in the graphics dll.
-
DejaVu (https://en.wikipedia.org/wiki/DejaVu_fonts) seems to have a much wider glyph coverage.
Oh didn't think about the glyph coverage, yeah this looks good.
Speaking of a built-in default font, it would be nice to have an easy way (perhaps some sort of compilation flag) to build SFML-Graphics without including Arial.hpp (or DejaVu.hpp if it's changed to that), without having to manually comment it out everytime. I personally never use sf::Text, as I have my own class that renders bitmap text, so there is essentially >300 KB of useless data in the graphics dll.
It's one thing just to not include a file and it's another thing to prevent any crash due to the missing file.
Also we don't live in the 90s anymore where every single bit was important, so imho it doesn't hurt to include those 300kb, although some might not like it. ;)
I'm not sure but does it also get included when you link statically?
-
Can you tell us why these 300 KB are so important?
-
I added an issue on the tracker for the default font replacement.
-
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.
-
Although I agree with you, do you think it's worth making the API more complicated for this argument?
-
Hello,
While comparing Network/Http.hpp and Network/Http.h it seems some values are missing for sfHttpStatus enum:
diff -Naur LaurentGomila-CSFML-8e856b0.orig/include/SFML/Network/Http.h LaurentGomila-CSFML-8e856b0/include/SFML/Network/Http.h
--- LaurentGomila-CSFML-8e856b0.orig/include/SFML/Network/Http.h 2012-07-08 01:45:50.000000000 +0200
+++ LaurentGomila-CSFML-8e856b0/include/SFML/Network/Http.h 2012-07-08 01:48:19.000000000 +0200
@@ -56,6 +56,8 @@
sfHttpCreated = 201, ///< The resource has successfully been created
sfHttpAccepted = 202, ///< The request has been accepted, but will be processed later by the server
sfHttpNoContent = 204, ///< Sent when the server didn't send any data in return
+ sfHttpResetContent = 205, ///< The server informs the client that it should clear the view (form) that caused the request to be sent
+ sfHttpPartialContent = 206, ///< The server has sent a part of the resource, as a response to a partial GET request
// 3xx: redirection
sfHttpMultipleChoices = 300, ///< The requested page can be accessed from several locations
@@ -68,12 +70,15 @@
sfHttpUnauthorized = 401, ///< The requested page needs an authentification to be accessed
sfHttpForbidden = 403, ///< The requested page cannot be accessed at all, even with authentification
sfHttpNotFound = 404, ///< The requested page doesn't exist
+ sfHttpRangeNotSatisfiable = 407, ///< The server can't satisfy the partial GET request (with a "Range" header field)
// 5xx: server error
sfHttpInternalServerError = 500, ///< The server encountered an unexpected error
sfHttpNotImplemented = 501, ///< The server doesn't implement a requested feature
sfHttpBadGateway = 502, ///< The gateway server has received an error from the source server
sfHttpServiceNotAvailable = 503, ///< The server is temporarily unavailable (overloaded, in maintenance, ...)
+ sfHttpGatewayTimeout = 504, ///< The gateway server couldn't receive a response from the source server
+ sfHttpVersionNotSupported = 505, ///< The server doesn't support the requested HTTP version
// 10xx: SFML custom codes
sfHttpInvalidResponse = 1000, ///< Response is not a valid HTTP one
-
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.
I second this. Though 300k may not be a lot, I just have this pet peeve on including anything I don't need. Just sort of an unexplained disgust.
-
While comparing Network/Http.hpp and Network/Http.h it seems some values are missing for sfHttpStatus enum:
Since it can be added later without breaking the API, let's not discuss it in this thread ;)
I second this. Though 300k may not be a lot, I just have this pet peeve on including anything I don't need. Just sort of an unexplained disgust.
Feel free to suggest a solution to solve this "problem" :P
-
I second this. Though 300k may not be a lot, I just have this pet peeve on including anything I don't need. Just sort of an unexplained disgust.
Personally I really don't care about 300 KB and I find it very convenient to be able to display text without caring about loading a font, although I agree that in large projects I would probably use a custom font, but SFML isn't for large projects only.
If the proposed solution does not involve more complexity I've nothing against it.
-
I have no experience with automatic building tools and how to supply them with parameters. What would adding something like a checkbox to cmake to toggle a certain compiler flag that switches inclusion of Arial.hpp for a project involve? How would it complexify the API? If it's too complicated, then it's probably not worth the effort for the potentially saved memory, but I will still keep manually commenting it out everytime I update SFML (which I do quite frequently throughout development). Even a compilation flag/macro (#define SFML_NO_BUILTIN_FONT?) without any cmake-visible option would help speed up that process.
-
I have no experience with automatic building tools and how to supply them with parameters. What would adding something like a checkbox to cmake to toggle a certain compiler flag that switches inclusion of Arial.hpp for a project involve?
As I've stated before it's easy to exclude one file, but it's another thong to guarantee no crashes. Because you can't just remove it let all applications crash ugly if they try to use the default font and then blame the developer. One would implement a switch that changes more than just the exclusion.
-
Disabling it at compile time is not a good option. Because I would then have to disable Font::getDefaultFont as well, and that would end up in two different (and incompatible) SFML APIs depending on how one compiled it. And the default version would still have it enabled anyway.
-
Ah well, it's probably not worth trying to find a clean solution to this then. I'll just keep manually removing it myself then, it's not a big deal.
-
I really like the Libertine fonts (http://www.linuxlibertine.org/) and they're free/libre/open source too.
Another license problem is that, as far as I can tell, you don't distribute the license with the binary dependencies. This is needed for the BSD license, for example.
-
There's an issue on the tracker if you want to discuss free fonts further.
Another license problem is that, as far as I can tell, you don't distribute the license with the binary dependencies
I distribute a license.txt file, which contains a mention of every dependency and its license. But I think that I should put a direct link to the license text too.
-
While comparing Network/Http.hpp and Network/Http.h it seems some values are missing for sfHttpStatus enum:
Since it can be added later without breaking the API, let's not discuss it in this thread ;)
Why you just don't apply the patch now?
If you apply it later, I'll have to update my code later...
-
Oh wait, I just understood that these values are in the C++ version but not in the C one.
I thought you wanted to add new codes, sorry.
I'll do it as soon as I can.
-
I stumbled upon a problem while implementing an event-based remappable input system: SFML makes no distinction between unknown keypresses and "A" keypresses. While this might not be a big issue for QWERTY users, other keyboard layouts, particularly QWERTZ (which is what I am using) have lots of keys that are not correctly picked up by the sf::Window implementation and end up being incorrectly fired as "A" keypresses (specifically, the ÄÖÜß^<# keys on QWERTZ keyboards). I described the issue and a possible, hopefully non-API-breaking fix here (https://github.com/SFML/SFML/issues/7#issuecomment-6858248). It basically involves adding an extra key (sf::Keyboard::Unknown or something like that) to the sf::Keyboard::Key enum and replacing instances of the bottom-catcher "return Keyboard::Key(0);" (which happens to be "A") in the sf::Window implementations with "return Keyboard::Unknown;".
This is quite a big issue in my opinion, and any kind of temporary "quick fix" would be better than having no way to eliminate incorrectly fired "A"-key events.
-
the « problem » is that :
enum Key
{
A, ///< The A key
nothing before so A == 0.
So something like :
enum Key
{
Unknown,
A, ///< The A key
should be enough (?)
-
Ah, good point. I guess it would still be a bit cleaner to replace Keyboard::Key(0) with Keyboard::Unknown though. I wouldn't only call it a "« problem »" though. :p
It is an issue that can limit the usefulness of KeyEvents quite a bit.
-
It is indeed a major problem. I added sf::Keyboard::Unknown as suggested to solve it.
Thank you very much for your feedback :)
-
Thank you very much for the fix! Glad I could help. :3
-
Can you tell us why these 300 KB are so important?
300 KB are not really important, but we can kill two birds with one stone here probably:
1) Get rid of 300 KB.
2) Get rid of default font crash bug.
Maybe you still remember my proposal from the past when I suggested to force the user to load a font. I really don't think that it would be complicated or annoying, it's as simple as:
sf::Font font;
font.loadFromFile( "foobar.ttf" );
sf::Text text( L"Hello", 12, font );
It's not the same, but you do it with images and sounds too, which is very reasonable. I still find it problematic that the library provides unmanaged resources.
-
Yes, I remember this solution everytime there's an issue with the default font. And I admit that it seems to be the best one so far.
However if I change anything in the public API, it must be done before SFML 2.0 is released... so I must take a decision quickly :-\
-
Indeed. ;) The only thing which is a little bit more annoying is providing a standard font. I see 2 options here:
1) sf::Font::makeStandardFont: Returns a new sf::Font, font data is included in sources. Pro: Easy. Con: 300 KB extra, always.
2) sf::makeDejaVuFont: Returns a new sf::Font, font data is included in separate(!) header only. Pro: 300 KB extra only if being included, which is intended if someone does it (not included by SFML itself). Con: Annoying to use in-place, see below.
Option 2 would be for sure a compromise and still easy enough, I think. Ex:
#include <SFML/Graphics/DejaVuFont.hpp>
sf::Font font = sf::makeDejaVuFont();
A big drawback is the following, which is invalid:
sf::Text text( L"I will crash :-(", 12, sf::makeDejaVuFont() );
I can't think of a real solution to satisfy everybody, except shared resource management through smart pointers, but I'm sure you're already screaming right now. ;)
-
I could live without a default built-in font. And since I'm too lazy to implement my own OS #ifdefs maybe there could be a sf::Font::loadSystemFont(sf::String) that looks for that font face in the system font directory? With clever use of environment variables it shouldn't be too hard :)
-
1) sf::Font::makeStandardFont: Returns a new sf::Font, font data is included in sources. Pro: Easy. Con: 300 KB extra, always.
2) sf::makeDejaVuFont: Returns a new sf::Font, font data is included in separate(!) header only. Pro: 300 KB extra only if being included, which is intended if someone does it (not included by SFML itself). Con: Annoying to use in-place, see below.
I like option 2. But then it becomes similar to providing the font file directly, the only difference is that with a header it is compiled directly into the final application. But then why not go further, and provide a generic system to embed any data into the application?
I can't think of a real solution to satisfy everybody, except shared resource management through smart pointers, but I'm sure you're already screaming right now.
Indeed :P
Smart pointers are not a big deal, but what's annoying is that they exist in C++11/TR1/boost, but as SFML has to remain compatible with pure C++03, I would have to rewrite it myself. But the name and API of the shared_ptr class would then be different. It's definitely too messy.
I could live without a default built-in font. And since I'm too lazy to implement my own OS #ifdefs maybe there could be a sf::Font::loadSystemFont(sf::String) that looks for that font face in the system font directory? With clever use of environment variables it shouldn't be too hard
That's a very interesting feature, and to be honest until now I avoided it only because there was a default font. But now, with the mentionned issues, I guess it would be a good moment for investigating that.
I'll take a look at Qt's source code, and see if the related code is not too complicated.
-
A drawback of the loadSystemFont solution is that it is impossible to guarantee that a given font will be available. Which leads to the "font family" system, ie. you give a more or less precise definition of the font that you want, with optional fallbacks, and the system finds the best match. It becomes already quite complicated.
-
No no no... I didn't mean it to be that complicated. loadSystemFont should just be an extended version of loadFromFile that searches known paths automatically. Like loadFromFile it would return false if the font doesn't exist on the system. Passing an empty string (the default) to loadSystemFont would load the default font for the system, whatever you choose it to be.
This solution would work for 99.99% of the userbase of SFML.
Windows users are the easiest. All their fonts are in %WINDIR%/Fonts and they always have Arial installed if thats what you want as default.
Mac OS X users I presume have the same situation as Windows users.
Linux users, most of them use one of the popular distros, would also mostly have the same paths and font faces installed.
-
the « problem » is that :
enum Key
{
A, ///< The A key
nothing before so A == 0.
So something like :
enum Key
{
Unknown,
A, ///< The A key
should be enough (?)
A good option however it implies declaring another constant. Like you said:
#include <iostream>
enum TestEnum{a, b, c};
int main(){
std::cout<<a<<" "<<b<<" "<<c<<std::endl;
return 0;
}
Outputs: "0 1 2". However the following code fixes the issue for the enumeration start constant:
#include <iostream>
enum TestEnum{a = 1, b, c};
int main(){
std::cout<<a<<" "<<b<<" "<<c<<std::endl;
return 0;
}
Will output: "1 2 3". No extra constant required.
Docs: Other data types - C++ (http://www.cplusplus.com/doc/tutorial/other_data_types/).
-
A good option however it implies declaring another constant.
We want a new constant. sf::Keyboard::Unknown is much better than sf::Keyboard::Key(0), isn't it?
No no no... I didn't mean it to be that complicated. loadSystemFont should just be an extended version of loadFromFile that searches known paths automatically. Like loadFromFile it would return false if the font doesn't exist on the system. Passing an empty string (the default) to loadSystemFont would load the default font for the system, whatever you choose it to be.
I'm wondering is this is relevant. I mean, if I write an application and plan to distribute it, I won't rely on a specific font being present on the user's system. Instead I'll provide the font with my application for 100% safety.
So who would use this feature?
-
A good option however it implies declaring another constant.
We want a new constant. sf::Keyboard::Unknown is much better than sf::Keyboard::Key(0), isn't it?
I thought you wanted the enum to start from 1 and not from 0.
-
I thought you wanted the enum to start from 1 and not from 0.
No we don't care. The problem to solve was that 'A' and unhandled keys had the same code.
-
I thought you wanted the enum to start from 1 and not from 0.
No we don't care. The problem to solve was that 'A' and unhandled keys had the same code.
Oh, my bad
-
I'm wondering is this is relevant. I mean, if I write an application and plan to distribute it, I won't rely on a specific font being present on the user's system. Instead I'll provide the font with my application for 100% safety.
So who would use this feature?
For the people who just want to see text you have the default whatever you define in SFML system font as a replacement for getDefaultFont() now. People who have an idea what font they might want on a specific system can either use the system font or specify their own. SFML should just make it easy to make use of the system fonts IF the user wants to.
-
Then I wonder if providing a default font still makes sense.
-
It's not a question of if there should be a default font, but where the font data comes from :)
-
that you changed the style of the methods?
Before was better.
GetPos ...
now
getPos ...
-1 to this
I used Google translate XDDDD
-
I like option 2. But then it becomes similar to providing the font file directly, the only difference is that with a header it is compiled directly into the final application. But then why not go further, and provide a generic system to embed any data into the application?
The difference is that you don't have a global sf::Font object. Nobody's against global data (just make sure to declare it static const, so it won't be included X times in the binary).
I would even go one more step further and say: Why not a generic loading chain with changeable adapters for choosing which backend we want? (filesystem, archives, binary data in executable, HTTP) :) But that's definitely something for a later version, also the idea with generic embedded data.
However, having something like
font.load( sf::FileSystemAdapter( "foobar.ttf" ) );
font.load( sf::ZipAdapter( "foobar.ttf", "meow.zip" ) );
font.load( sf::HttpAdapter( "http://sfml-dev.org/resources/foobar.ttf" ) );
// Same for all the other load() functions, e.g. in sf::Image.
would be great and powerful. Maybe in SFML 4? ;-)
but as SFML has to remain compatible with pure C++03
Do you plan to drop that requirement for, let's say SFML 3?
Before was better.
...
-1 to this
-1337 for flaming. :)
-
font.load( sf::FileSystemAdapter( "foobar.ttf" ) );
font.load( sf::ZipAdapter( "foobar.ttf", "meow.zip" ) );
font.load( sf::HttpAdapter( "http://sfml-dev.org/resources/foobar.ttf" ) );
// Same for all the other load() functions, e.g. in sf::Image.
Isn't it the sf::InputStream system, which is already implemented in SFML 2?
Do you plan to drop that requirement for, let's say SFML 3?
I don't know, I guess it depends when SFML 3 is released ;)
At least I'll provide conditional support for C++11 in SFML 2 (there's an issue on the tracker for that).
-
Isn't it the sf::InputStream system, which is already implemented in SFML 2?
Indeed, I wasn't aware of it.
-
Hi, just the case of the setString method in sf::Text class.
diff -Naur LaurentGomila-SFML-396f675.orig/include/SFML/Graphics/Text.hpp LaurentGomila-SFML-396f675/include/SFML/Graphics/Text.hpp
--- LaurentGomila-SFML-396f675.orig/include/SFML/Graphics/Text.hpp 2012-07-13 12:09:11.000000000 +0200
+++ LaurentGomila-SFML-396f675/include/SFML/Graphics/Text.hpp 2012-07-14 04:25:41.000000000 +0200
@@ -86,10 +86,10 @@
/// automatically be constructed from standard string types.
/// So, the following calls are all valid:
/// \code
- /// text.SetString("hello");
- /// text.SetString(L"hello");
- /// text.SetString(std::string("hello"));
- /// text.SetString(std::wstring(L"hello"));
+ /// text.setString("hello");
+ /// text.setString(L"hello");
+ /// text.setString(std::string("hello"));
+ /// text.setString(std::wstring(L"hello"));
/// \endcode
/// A text's string is empty by default.
///
-
Hi, just the case of the setString method in sf::Text class.
And? What are you trying to tell us with that? Or did I miss some talk about it? ???
-
He's pointing out typos in the doc. (S -> s) ;)
-
He's pointing out typos in the doc. (S -> s) ;)
Aha! I see! :D
Quite hard to spot if you don't know what to look for. ;)
-
Hi, just the case of the setString method in sf::Text class.
Thanks :)
-
Hi, I just wanted to ask, is SFML 2.0 rc stable enough for use? As in, my application wont have too many problems?
Also, how many changes will there be between SFML 2.0 and 2.0rc? I am wondering because I don't want to have many changes when SFML 2.0 comes out and I link to it.
-
SFML 2.0rc is quite stable. The main part of the API is frozen and changes to the API will only happen if there's a really, really good reason for. So you can consider it as stable. The most recent bigger change was the removal of the default font. If you're using the SFML 2rc binaries just don't use the default font and you won't have to change a thing when SFML 2 finally gets released. (If that ever happens :P)
If you want to see what the changes are between the RC and the current state you can take a look at the commit history (https://github.com/SFML/SFML/commits/master) up to the 2.0-rc tag (https://github.com/SFML/SFML/tree/2.0-rc).
-
I already asked in the chat and it looks like there's something between sfml and the drivers that doesnt work well...
The whole thing is explained here: http://en.sfml-dev.org/forums/index.php?topic=9074.0 (http://en.sfml-dev.org/forums/index.php?topic=9074.0)
-
I'm not sure, but i think i found an error in the documentation of sf::Shader...
If I create a shader like this:
sf::Shader shader;
shader.loadFromFile("Shader.frag", sf::Shader::Fragment);
and use it like it says in the documentation:
m_RenderTexture.draw(m_Circle, shader);
I get an error. It works when I do this:
m_RenderTexture.draw(m_Circle, &shader);
Same with the example that uses the renderstates. I have to pass the address not the value, like it says in the documentation.
-
m_RenderTexture.draw(m_Circle, &shader);
And that worked? :o
The draw function is taking the render states as reference, thus passing the adress to the function shouldn't work at all either...
See the two draw function declerations (http://www.sfml-dev.org/documentation/2.0/classsf_1_1RenderTarget.php#ab636d7363f6681077361ee274ba89a8d) and the header (https://github.com/SFML/SFML/blob/master/include/SFML/Graphics/RenderTarget.hpp#L197) to it.
Edit: I just now figured out how that all worked, since the documentation said that draw(obj, shader) is a short cut, but I couldn't see how it's being done, then I saw that the sf::RenderStates class has a constructor that takes a pointer to a sf::Shader and thus you indeed need to call draw(obj, &shader), which invokes that said constructor, creates a sf::RenderStates class and passes it as reference to the draw call. I don't know why the constructor takes pointers rather than references...
But if you use a RenderStates object yourself you shouldn't need to pass the adress. ;)
-
Yeah it works! Look closer :) Here is why: if you pass a shader the second argument to the draw function it is passed on to the constructor of the RenderStates, which has a constructor that takes a shader as a argument. Really nice shortcut :)
edit: But still, the constructor of the RenderStates only takes a pointer to a shader. So I think there is an error in the documentation.
-
Yeah it works! Look closer :) Here is why: if you pass a shader the second argument to the draw function it is passed on to the constructor of the RenderStates, which has a constructor that takes a shader as a argument. Really nice shortcut :)
Yep, noticed that myself... ;D
edit: But still, the constructor of the RenderStates only takes a pointer to a shader. So I think there is an error in the documentation.
Yep, it's a mistake, but I wonder why use a pointer instead of a reference?
-
Yep, noticed that myself... ;D
Yeah it is kinda tricky, but a really cool shortcut!
Yep, it's a mistake, but I wonder why use a pointer instead of a reference?
I haven't thought about that... Maybe there is a reason for it. We'll see what Laurent says :)
-
The reason is simple: null pointer = no shader.
I'm going to fix the doc, thanks ;)
-
... makes sense :D
No Problem. I'm glad I was able help :)
-
In fact it was already fixed, the online doc is just outdated.
-
I got Windows 8 Professional from my university and will install it sometime later this week. So unless anybody has done this already, I will soon let you know if SFML works well on Windows 8. ;)
-
I got Windows 8 Professional from my university and will install it sometime later this week. So unless anybody has done this already, I will soon let you know if SFML works well on Windows 8. ;)
It works, even on Intel GPU (I have a MSI U123 Wind with 1Gb of RAM and Intel Atom 1.66 Ghz and Intel GPU). If I try to compile and run the same code I have on Ubuntu it crashes (some OpenGL crash), so... go go Win8.
Also, I am using VS2012 Pro using SFML .dll files from VS2010 download, so far they work (RenderTexture, RenderWindow, Sprite, Events it's all I've tried out yet).
Off topic:
Before installing Win8, if you want to use Metro style apps you need a min 1024x768 screen res to run them. My notebook doesn't have that res but installing software the old fashion way and runing them from desktop works just fine.
-
It works just fine on Windows 8, even rbSFML does, already tried ;)
Though cmake don't like Visual Studio 11 yet(2012)
-
Though cmake don't like Visual Studio 11 yet(2012)
What do you mean by that?
I've no problems with VS11 and CMake. Do you have the latest CMake version?
-
Don't know, might have done something wrong cause it just didn't want to generate the needed files. Gave some error I don't remember but that didn't make sense.
-
Don't know, might have done something wrong cause it just didn't want to generate the needed files. Gave some error I don't remember but that didn't make sense.
Yeye it's always the fault of the software... :P ;D
-
Don't know, might have done something wrong cause it just didn't want to generate the needed files. Gave some error I don't remember but that didn't make sense.
Are you using the express edition by any chance? It seems there was a bug with Visual Studio express 2012 and cmake 2.8.9
Take a look at this, it was fixed on cmake 2.8.10:
http://public.kitware.com/Bug/view.php?id=13348
And this for an alternative fix:
http://stackoverflow.com/questions/12434696/visual-studio-express-2012-and-cmake
-
Are you using the express edition by any chance?
Well this could likely be, since I'm using Visual Studio 12 Premium (thanks university!). ;)
-
Hello,
in "include/SFML/Graphics/Transform.h" we have :
sfTransform sfTransform_Identity;
I have by error modified it. So after this modification it is not an identity matrix anymore.
"const" makes it unmodificable, but still if I provide it by error to a function like sfTransform_rotate() the function will apply silently while actually the operation has not been done without any error reported to the programmer.
So I would suggest to remove "sfTransform_Identity", and provide instead "sfTransform_getIdentity()" :
sfTransform sfTransform_getIdentity(void);
Cheers
-
"const" makes it unmodificable, but still if I provide it by error to a function like sfTransform_rotate() the function will apply silently while actually the operation has not been done without any error reported to the programmer.
Hum? Why would it apply silently? It will trigger a compiler error, that's the point of using the const keyword.
-
Hum? Why would it apply silently? It will trigger a compiler error, that's the point of using the const keyword.
Just remember what CSFML is made for :)
Is it made mainly to write pure plain C ?
Or is its main purpose for something else ?
-
and this is also why a function would be better.
-
I still don't get it.
-
I believe Cekota was suggesting sfTransform_Identity be accessed through a function that supplies a copy of it.
Currently it's not constant and may be changed by a user, and subsequent uses of the identity will (silently) fail to act as one would expect. The function would make similar scenarios less likely.
-
Yeye it's always the fault of the software... :P ;D
Or authors. :D
Your mileage may vary but software tends to work weird on some setups. On my laptop vc++2008's intelli sense works alright(generously speaking, I'm having problem with sfg shared ptrs). But on my pc, opening or closing a block with sharp bracket, using scope operator on class that just got a new function added ect. doesn't update itself and I must reopen the solution. There is no apparent reason to this(same windows, same installation, same settings, same files even).
-
I believe Cekota was suggesting sfTransform_Identity be accessed through a function that supplies a copy of it.
Currently it's not constant and may be changed by a user, and subsequent uses of the identity will (silently) fail to act as one would expect. The function would make similar scenarios less likely.
But the const keyword solves the problem. That's what I don't understand (he says it doesn't).
-
I don't know exactly what he meant there, either, unless he's paranoid enough to want protection against people casting away const, in which case -- good luck.
-
sorry, I thought it was so evident that CSFML is often used for building bindings to higher level languages, but it seems it is not.
indeed, if the variable is wrapped, then the const qualification is discarded
-
Ok, but... the binding will also make it const. CSFML is not supposed to solve potential mistakes in bindings that use it.
If I use a function and return a new copy every time it is called, it can even be worse: a binding that would not make the corresponding object const/readonly/whatever, wouldn't see it and it would "work" although the design has a major flaw.
This is purely a design issue, technical choices won't help. The only good solution is to make sure that the objects are const/readonly/... in all the bindings. So thank you for pointing out that they were not in CSFML :)
-
Ok, but... the binding will also make it const. CSFML is not supposed to solve potential mistakes in bindings that use it.
If I use a function and return a new copy every time it is called, it can even be worse: a binding that would not make the corresponding object const/readonly/whatever, wouldn't see it and it would "work" although the design has a major flaw.
This is purely a design issue, technical choices won't help. The only good solution is to make sure that the objects are const/readonly/... in all the bindings. So thank you for pointing out that they were not in CSFML :)
Well, I don't want to make you change your mind, but I would like to understand, because your are an experienced programmer, and I'm a beginner, so I would really want to understand in order to improve my skills.
The problem is that I really don't see what I can do with a const sfTransform_Identity. If I want to use it I will copy it and then use some rotate and translate functions on the copy. So in this case I was thinking that sfTransform_getIdentity() would makes sens.
So please explain me what I'm supposed to do with this const sfTransform_Identity ?
-
CSFML: include/SFML/Graphics/Texture.h:
CSFML_GRAPHICS_API void sfTexture_bind(const sfTexture* texture);
SFML: include/SFML/Graphics/Texture.hpp:
void bind(CoordinateType coordinateType = Normalized) const;
The parameter "coordinateType" is missing.
-
In the SFML API, there are a lot of function that have default parameters.
Sometimes these default parameter are easy to find from the headers.
Sometimes there are several definitions of the same function so that tracking the default parameter has to be made by reading the source code of SFML, not the header anymore.
When wrapping CSFML this is quite a pain.
More over hard I don't like coding the default parameters in the wrapper because, maybe one day the default value would change, maybe in SFML 3.X.
It would be nice to provide some facilities to get these default parameters.
There could be several ways to do so, one simple possibility could be defining some variable, for example:
<Value_Type> <Function_Name>_<Param_Nane>_Default = <Default_Value>
sfTextureCoordinateType sfTexture_bind_texture_default = sfTexCoordType_Normalized;
#define MAKE_DEFAULT_PARAM( func_name, param_name, param_type, default_value) \
param_type func_name##_##param_name##_default = default_value;
MAKE_DEFAULT_PARAM( sfTexture_bind, coordType, sfTextureCoordinateType, sfTexCoordType_Normalized )
-
The problem is that I really don't see what I can do with a const sfTransform_Identity. If I want to use it I will copy it and then use some rotate and translate functions on the copy. So in this case I was thinking that sfTransform_getIdentity() would makes sens.
If CSFML does the copy, then every user in every situation will be forced to do this copy. If I directly provide the object, then it's up to the user to decide if he wants to make a copy of it or not. There are many situations where you won't need to copy it, for example when you want to pass an identity matrix to a function that has a sfTransform argument.
So there's no problem, just more flexibility.
The parameter "coordinateType" is missing.
https://github.com/SFML/CSFML/issues/9#issuecomment-6586469
-
If CSFML does the copy, then every user in every situation will be forced to do this copy. If I directly provide the object, then it's up to the user to decide if he wants to make a copy of it or not. There are many situations where you won't need to copy it, for example when you want to pass an identity matrix to a function that has a sfTransform argument.
So there's no problem, just more flexibility.
Oh, I see.
Thank you very much for taking time to instruct me :)
The parameter "coordinateType" is missing.
https://github.com/SFML/CSFML/issues/9#issuecomment-6586469
Oh, I see.
Then I'll remove it from my bindings.
-
And what about providing the default parameters in an accessible way?
(as asked in my previous post)
While writing my binding, I've read sources of other SFML bindings. From comments, or svn commit messages (don't remember which) I have seen that this is not only a problem for me, but also for other binders.
-
And what about providing the default parameters in an accessible way?
Which parameters in which functions are not "accessible"? They are all explicitely documented. I think using macros would be quite ugly and make things even worse.
-
They are all accessible by a human.
By accessible I mean by the code.
While trying to reproduce the C++ API in a wrapper using CSFML, we have to hard code the default values.
Then in a future SFML 3.0, if some default values change, the wrappers will remain with the old default values.
-
And how would your macros automatically keep the wrappers up to date? ??? (and what are these "wrappers" by the way?)
-
Not sure if this is a bug, but on Linux (Linux Mint), the tilde key doesn't seem to be recognized, but it's fine on Windows using code:
while ( event loop ) {
if ( event.type == sf::Event::KeyPressed ) {
if ( event.key.code == sf::Keyboard::Tilde ) {
//blah
}
}
}
-
Please search before posting:
https://github.com/SFML/SFML/issues/7
-
Reinstalled my Ubuntu VM over the weekend and just noticed that CMake is no longer able to find the FindSFML.cmake file installed by SFML. It's obviously put into /usr/local/share/SFML/cmake, which I think has been different in the past? Is this intentional? (pulled from github on this Friday or so)
-
FindSFML.cmake is no longer installed by default, you must copy it.