241
SFML projects / Re: 'Tiled' Tile-map Loader
« on: October 18, 2013, 01:51:48 am »
Just go to zlib.net, scroll down a bit and get the package with the DLL. 
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.
242
SFML projects / Re: 'Tiled' Tile-map Loader
« on: October 17, 2013, 09:53:27 am »
Its so easy, just read the messages and you see "LNK" and "unresolved external symbols" and many function names. That means you did not LiNK a number of external symbols, namely functions and from the names they belong to "pugi" and "zlib".
Now just add those libraries in the project settings and/or adjust the library search path so they can be found and linked...
Now just add those libraries in the project settings and/or adjust the library search path so they can be found and linked...
243
Graphics / Re: Fonts, don't we all love fonts...
« on: October 16, 2013, 11:04:10 pm »
It was too much code for me to read all, but from what you have written my conclusion is you most likely have written some code that corrupts memory and then sometimes it does manifest in wrong behaviour of unrelated code - the font and you had also written about a (de-)queue getting corrupted. It can be difficult to accept, but if two unrelated things bug out its most likely your own code.
Those warnings about uninitialized data could be the hint you need, maybe if you fix them your problem is gone, or maybe not and you would have to look at all pointers if any gets out of range of its allocated memory.
Those warnings about uninitialized data could be the hint you need, maybe if you fix them your problem is gone, or maybe not and you would have to look at all pointers if any gets out of range of its allocated memory.
244
General discussions / Re: Exceptions in SFML 3 ?
« on: October 15, 2013, 08:47:53 pm »This made me curious now and I directly looked at the SFML source. Guess what I found?Otherwise, you have no option to get loadFromFile() out of sf::Image in any way, it's hardcoded into the class (which also forces me to something). In my eyes it's problematic because the loading routine is not an extension, it's core functionality.But given its core functionality, it would rather be strange to extract it from the core (sf::Image) to a separate class, wouldn't it? Or which core are you referring to? The loading functions are clearly specific to the respective resource classes, you can't have a generic loader in SFML.
The load methods are in no way integral to sf::Image, they just forward the call to the sf::ImageLoader class already with 2 references to store the decoded data and x,y. Btw. ImageLoader is a singleton
without having a need to be one, it could just as easily be a class with only static methods or a namespace as it got no member variables.There is also a SoundFile class already.
And the Shader class got some external helper functions getFileContents and getStreamContents in a private namespace that seemingly could be moved somewhere to be reused.
There is some code duplication in the underlying helper functions that could be avoided, for example loading from file does not just load a file and reuse load from memory but got this intermingled and replicated. If loading without decoding was done by a single function for all of SFML and then the different resource classes would just have functionality for decoding from memory there could be a reduction in internal code.
245
General discussions / Re: Exceptions in SFML 3 ?
« on: October 15, 2013, 11:39:58 am »As for actual SFML changes, the only one I really want is changing loadFromFile so it doesn't demand a std::string for the filename. As it stands I have to use standard library filestreams and loadFromMemory to load images with non-ASCII filenames on Windows, which is a bit annoying. And yes Windows is inferior to Linux for not using UTF-8 and all that, but still, that's a detail I'd like to not have to think about.Thats actually more like a deficiency of the C library on Windows. The problem is the filenames get treated as ASCII and not as UTF8, but cause of some lucky circumstances UTF8 uses the same encoding for characters up to 127.
To fix this shortcoming (maybe it could also be called a mostly silent bug) SFML would have to treat the std::string as being UTF8, then convert it into widestring and use some function that accepts these for handling files. Or maybe it is also possible to change the codepage from C to UTF8, but there I'm not so sure its supported from Windows. http://utf8everywhere.org/
Now to repair this there is the possibility many resource classes would have to change their load methods, if there was only a single outside function there would be only a single point of change.
246
General discussions / Re: SFML 3 future design ?
« on: October 14, 2013, 10:55:36 pm »For example I was reading through the documentation of the Drawable hierarchy and its maybe just a documentation thing and not a problem with the classes, but I was trying to find whats different and whats common and there some annotations in the short list for new methods, overwritten and slightly different, overwritten just to adapt to the underlying data but doing exactly the same and unchanged methods would have helped. Also the pages got a bit long with having to scroll up and down so splitting them in two may be helpful, maybe such that one could have a page with only the differences to the base class. Compared to other libraries SFML docs are nice already, but some improvements can always be had.Btw, I read some of the documentation of SFML recently and for some classes you get that long list of methods where only half of them are interesting to most people. There I really wished sometimes it was cut in two parts and I (or the library user just needing a little thing in that diagram) needed to concern myself only with one of those easily understood smaller parts.
Do you have concrete examples?
Then like was discussed above all those different create and load functions clutter up the resource classes, when there could be just 2 or 3 contructors mostly and people could just use a single generic Load for all of them and Decode could also be split off, though I see how that could disrupt current users a bit.
247
General discussions / Re: Exceptions in SFML 3 ?
« on: October 14, 2013, 10:03:27 pm »
I'm not really into Java, but from an outside view it definitely looks like exceptions are tedious and overused in it. Especially cases when some standard library class throws some checked exception and you pretty much have to put a try/catch around it to rethrow something unchecked or modify the whole calltree. Or when every function in the call tree needs a try for cleanup, because stupid Java designers thought the only resource one would use was memory, but a garbage collector is not concerned with you for example not exhausting file handles while someday if you are lucky some finalizer runs.
In C++ this is a bit more sane, exceptions get used for really exceptional cases and if you do it right everything gets automatically cleaned up by RAII and destructors. A try block is a rare thing there, for when you know a second strategy to recover, to print some error message out in main or if you insist on wanting to play with insecure lowlevel things. But you can never fully prevent them, even if you check if a file is there beforehand there could theoretically be a bad sector on the HDD or the user could take out the CD or pull the USB connector or the server could stop answering or ...
Btw, I read some of the documentation of SFML recently and for some classes you get that long list of methods where only half of them are interesting to most people. There I really wished sometimes it was cut in two parts and I (or the library user just needing a little thing in that diagram) needed to concern myself only with one of those easily understood smaller parts.
In C++ this is a bit more sane, exceptions get used for really exceptional cases and if you do it right everything gets automatically cleaned up by RAII and destructors. A try block is a rare thing there, for when you know a second strategy to recover, to print some error message out in main or if you insist on wanting to play with insecure lowlevel things. But you can never fully prevent them, even if you check if a file is there beforehand there could theoretically be a bad sector on the HDD or the user could take out the CD or pull the USB connector or the server could stop answering or ...
Btw, I read some of the documentation of SFML recently and for some classes you get that long list of methods where only half of them are interesting to most people. There I really wished sometimes it was cut in two parts and I (or the library user just needing a little thing in that diagram) needed to concern myself only with one of those easily understood smaller parts.
248
General discussions / Re: Exceptions in SFML 3 ?
« on: October 14, 2013, 12:55:57 am »
Correct me if I'm wrong, but the Music class seems the only thing that is really profiting from streaming. All other things including short sounds should be small enough they can easily be loaded at once and you can't use half an Image or half of a Font file or half of a Shader.
249
General / Re: Trying to understand slow calls to RenderWindow::display
« on: October 14, 2013, 12:47:00 am »
You could try glFinish() and see if the display method produces more consistent timing then, but only for satisfying your curiosity with a little more testing, as it slows your program down.
Still the other people are right, you shouldn't worry about that and measure the whole frames, you will have 1/60 second anyway.
Still the other people are right, you shouldn't worry about that and measure the whole frames, you will have 1/60 second anyway.
250
General discussions / Re: Exceptions in SFML 3 ?
« on: October 14, 2013, 12:23:45 am »
The idea is to make all resource classes simpler by cutting out the 6 loadFromMemory, loadFromFile and loadFromStream. The Buffer class would then also replace the weird self-defined stream classes and the file loading for all things would use it, which arguably would make it simpler.
DecodeImage would be a free function and the only one to know about the png, jpg and other libs and then Image needs only know about already decoded bitmaps. Maybe the other classes could also be simplified in that way.
DecodeImage would be a free function and the only one to know about the png, jpg and other libs and then Image needs only know about already decoded bitmaps. Maybe the other classes could also be simplified in that way.
251
General discussions / Re: Exceptions in SFML 3 ?
« on: October 13, 2013, 11:25:50 pm »
Actually its more than 2 things that are done by the loadFromFile methods: access of the file system to get the file size, allocating memory for encoded data, loading the data, identify the data format and the size after decoding, allocating memory for decoded data, decoding, freeing memory from encoded data, using the data(upload to graphics card, creating glyphs and so on).
SFML hides memory allocation already for many things and I think that should be kept that way in the future, so that part can be ignored. Then there remain just loading, often decoding and using; and I think what can be easily done with a function needs no loader or decoder objects just to satisfy some OO extremists.
If those 3 responsibilities get split it would nicely separate concerns and the resource classes would stop needing to know how to access all kinds of other libraries. It could look like these (assuming its with exceptions):
SFML hides memory allocation already for many things and I think that should be kept that way in the future, so that part can be ignored. Then there remain just loading, often decoding and using; and I think what can be easily done with a function needs no loader or decoder objects just to satisfy some OO extremists.
If those 3 responsibilities get split it would nicely separate concerns and the resource classes would stop needing to know how to access all kinds of other libraries. It could look like these (assuming its with exceptions):
sf::Buffer buf=sf::LoadFile("picture.png");
sf::Image img=sf::DecodeImage(buf);
sf::Texture tex(img);
sf::Image img=sf::DecodeImage(buf);
sf::Texture tex(img);
sf::Texture tex(sf::DecodeImage(sf::LoadFile("picture.png")));
Then people could easily replace parts, for example:FancyData data=fancyBufferedZipFileSystem.load("picture.png");
sf::Texture tex(sf::DecodeImage(data.ptr(),data.size()));
sf::Texture tex(sf::DecodeImage(data.ptr(),data.size()));
std::unique_ptr<uint8_t[]> bitmap=MyRaytracer.renderImage(x,y);
sf::Texture tex(sf::Image(x,y,bitmap.get()));
sf::Texture tex(sf::Image(x,y,bitmap.get()));
sf::Buffer buf=sf::LoadFile("picture.newformat");
MyBitmap bm=MyNewDecoder(buf.ptr(),buf.size());
sf::Texture tex(sf::Image(bm.x,bm.y,bm.ptr));
Maybe even add another variant of the Buffer?MyBitmap bm=MyNewDecoder(buf.ptr(),buf.size());
sf::Texture tex(sf::Image(bm.x,bm.y,bm.ptr));
sf::MemMapBuffer buf("picture.png");
sf::Texture tex(sf::DecodeImage(buf));
Another weird example for demonstration:sf::Texture tex(sf::DecodeImage(buf));
sf::Http h("http:://www.example.com");
sf::Http::Response response=h.sendRequest(sf::Http::Request("downloads/myshader.vs"));
if(response.getStatus!=sf::Http::Response::Ok)
throw std::runtime_error("could not download vertex shader");
sf::Buffer vsbuf=response.getBody();
response=h.sendRequest(sf::Http::Request("downloads/myshader.fs"));
if(response.getStatus!=sf::Http::Response::Ok)
throw std::runtime_error("could not download fragment shader");
sf::Buffer fsbuf=response.getBody();
sf::Shader shader(vsbuf,fsbuf);
Without exceptions that would all get longer and possibly loose the return values for getting something useful, but I think you can imagine the code yourself. Providing versions with and without exceptions shouldn't be all that difficult.
sf::Http::Response response=h.sendRequest(sf::Http::Request("downloads/myshader.vs"));
if(response.getStatus!=sf::Http::Response::Ok)
throw std::runtime_error("could not download vertex shader");
sf::Buffer vsbuf=response.getBody();
response=h.sendRequest(sf::Http::Request("downloads/myshader.fs"));
if(response.getStatus!=sf::Http::Response::Ok)
throw std::runtime_error("could not download fragment shader");
sf::Buffer fsbuf=response.getBody();
sf::Shader shader(vsbuf,fsbuf);
252
Graphics / Re: RectangleShape vs Sprite
« on: October 13, 2013, 12:20:28 am »
Well sorry, I had read in the forum often already and several pages deep at that and had not seen such a thread, so it didnt occur to me to use the automatic search for something even older.
I have read those threads now, but the thing with only the shape having a size to be set is still a bit unclear to me. I think I'll try switching to the sprite and see how it works then.
I have read those threads now, but the thing with only the shape having a size to be set is still a bit unclear to me. I think I'll try switching to the sprite and see how it works then.
253
General discussions / Re: Unofficial Nightly Builds
« on: October 12, 2013, 08:55:01 pm »
Did you notice the official MinGW got a 4.8 version? Maybe you could add it to your list of compilers.
254
Graphics / RectangleShape vs Sprite
« on: October 12, 2013, 08:41:27 pm »
I tried to find the difference between using a RectangleShape and a Sprite by reading the docs, but they seem to have mostly the same functionality, only that a RectangleShape can have a size, an outline and the option to not use a Texture. I assume a Sprite should just get scaled instead of setting a size?
Whats the usecase where a Sprite should be prefered? Is it just a bit more efficient?
Whats the usecase where a Sprite should be prefered? Is it just a bit more efficient?
255
General / Re: rbSFML
« on: October 12, 2013, 08:30:09 pm »
Hi,
I started making a little game with rbSFML on Windows to practise Ruby programming and would like to tell a bit of my experience with it.
I followed the readme on github, but the clone command in there didnt work somehow, scrolling up and using the slightly different clone command provided by github worked. rake test produced some errors, but rake samples and later my program worked flawlessly - after I found out myself SFML should also be compiled with the Ruby DevKit.
What I noticed is that the .dll files don't get packaged into the gem and you need to copy them into the folder with your own Ruby files or add them to the path variable. I already had another version of SFML in the path from using it with C++ and Ruby would crash when it found that. It would be nice if you could fix this and put them into the gem such that Ruby gems can take over the work of fixing the path, as that would installation much easier when distributing a game. Or is that not possible and I should try rake static?
The documentation seems a bit incomplete, but after finding out the code actually exists I could just look at the docs on the SFML website for C++. It would just be a little less confusing if there was a notice that not all classes are documented.
The only thing I found missing in rbSFML, while using it, were the constants for the Text styles, for making it bold for example, but I could put a number from a SFML header in manually.
Oh and one weird thing was when I tried activating vertical sync for the RenderWindow. I printed the frametimes to the console and the program did go slower from waiting, but the cpu utilization did not drop when looking at the task manager like I had hoped for, so I commented it out. I dont know if this comes from rbSFML, its a normal thing with SFML or maybe just my graphics driver? Maybe I should try it again in C++.
Anyway, thanks for making it available.
I started making a little game with rbSFML on Windows to practise Ruby programming and would like to tell a bit of my experience with it.
I followed the readme on github, but the clone command in there didnt work somehow, scrolling up and using the slightly different clone command provided by github worked. rake test produced some errors, but rake samples and later my program worked flawlessly - after I found out myself SFML should also be compiled with the Ruby DevKit.
What I noticed is that the .dll files don't get packaged into the gem and you need to copy them into the folder with your own Ruby files or add them to the path variable. I already had another version of SFML in the path from using it with C++ and Ruby would crash when it found that. It would be nice if you could fix this and put them into the gem such that Ruby gems can take over the work of fixing the path, as that would installation much easier when distributing a game. Or is that not possible and I should try rake static?
The documentation seems a bit incomplete, but after finding out the code actually exists I could just look at the docs on the SFML website for C++. It would just be a little less confusing if there was a notice that not all classes are documented.
The only thing I found missing in rbSFML, while using it, were the constants for the Text styles, for making it bold for example, but I could put a number from a SFML header in manually.
Oh and one weird thing was when I tried activating vertical sync for the RenderWindow. I printed the frametimes to the console and the program did go slower from waiting, but the cpu utilization did not drop when looking at the task manager like I had hoped for, so I commented it out. I dont know if this comes from rbSFML, its a normal thing with SFML or maybe just my graphics driver? Maybe I should try it again in C++.
Anyway, thanks for making it available.