31
Graphics / Re: sf::Image::loadFromFile test case
« on: July 06, 2012, 07:40:07 pm »
I think he's just pointing out that some people do use 8-bit png.
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.
32
Graphics / Re: sf::Image::loadFromFile test case
« on: July 06, 2012, 09:07:41 am »
While I realize you can get the error message (or suppress it!) by temporarily rebinding sf::err() to (for example) a std::ostream[buf?], it might be good to have a nice way of getting an error code that's simple for a program to interpret. Even just beginning all error messages with "Error xyzpqr:" would help.
33
General discussions / Re: SFML 2.0 RC
« on: July 06, 2012, 09:04:04 am »
Maybe an OFL font? I'm not sure really; I'm not a lawyer or anything.
34
Graphics / Re: Why is my class not drawn?
« on: July 06, 2012, 03:41:55 am »Hmm, guess i should just add that error class as a member instead of inheriting...I think I'd recommend this... why on earth are you inheriting from error anyway?
35
Feature requests / Re: Few suggestions
« on: July 06, 2012, 03:21:41 am »
I remember thinking that too! Even if it's only an explicit conversion, it would be nice to have.
EDIT: Posted this before seeing Laurent's response, heh. Um... actually, it already has explicit conversions, doesn't it. <_<
EDIT: Posted this before seeing Laurent's response, heh. Um... actually, it already has explicit conversions, doesn't it. <_<
36
General discussions / Re: SFML 2.0 RC
« on: July 06, 2012, 12:19:02 am »
I was browsing the git repository a little while ago (can't quite remember why) and noticed this. 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.
37
General / Re: Trying to set up SFML 1.6 in Code::Blocks, but getting segmentation fault
« on: July 01, 2012, 07:49:35 pm »
Um... if you're using a static version, why do you have dlls...?
38
General / Re: SFML and Qt
« on: July 01, 2012, 07:48:41 pm »
Even if you could make an SFML window and then add Qt widgets, I don't think it would be any different from making a Qt window with Qt widgets and then using SFML to draw in it.
39
Audio / Re: Questions about sound in a game
« on: July 01, 2012, 06:14:03 pm »- I want to play a music, and automatically starts a new music when this one is done. Is there a way to know when the streamed music is about to end ? Like a callback or something ?I think you'd have to periodically (perhaps at the end of your main loop, or in other thread) checking to see that the music is still playing.
- I want to play a sound everytime someone shoots. So one SoundBuffer for all of them, but how do I dynamically create the Sound objects ? Do I need to keep a list of all active sounds, and delete them when they're finished ? Is there some auto-delete flag ?In order to avoid having to check if a sound is finished, I used a boost::circular_buffer rather than a queue as Nexus recommended. It does mean that sounds may be cut off occasionally, and it limits how many sounds you can play at once, but depending on your needs it may be sufficient. If you expect to have more then ten or twenty sounds simultaneously, though, it's probably more space-efficient to go with a non-fixed-size container like the queue.
40
General / Re: Implementing SFGUI into a SFML project
« on: June 29, 2012, 06:27:37 am »
I can only assume it had something to do with this?
41
General / Re: Thor and CMake Error - OSX
« on: June 29, 2012, 01:34:27 am »
Um, if you built dynamic libraries they should be in /usr/local (go there by pressing Command-Shift-G in the Finder and pasting the path), where there's a lib folder and an include folder; if you built frameworks they go in /Library/Frameworks. So, that's where you should be looking for the SFML libraries.
42
Graphics / Re: sf::Text missing glyphs [Bug]
« on: June 29, 2012, 01:29:33 am »
Well, to be fair, my issue wasn't missing glyphs but malformed glyphs, so maybe the cause is completely different...
43
General / Re: Beginner - SFML wait for message
« on: June 28, 2012, 11:40:59 pm »
In SFML 2.0, you can use app.waitEvent() instead of app.pollEvent().
44
System / Re: [SFML 2.0 RC] - Threads
« on: June 26, 2012, 03:49:13 pm »
Would that really be able to avoid the warning? I thought Thread didn't have a default constructor.
45
Audio / Re: Help Beat Detection
« on: June 26, 2012, 04:04:12 am »
std::vector is guaranteed to be stored in contiguous memory (ie, just like an array), so it's not great when you're doing a lot of insertion but is one of the best if you need random access on a group of objects that doesn't change a lot.
std::deque still uses array-style allocation, but it may split the array up into chunks in completely different areas of memory. If you need random access and fast insertion/deletion at the front and back, it's a good choice. If you need insertion in the middle, I think it's not as good, though I'm unsure on that one.
std::list puts each element in its own location in memory with a pointer to the next and previous elements, so they could be widely spaced out in memory. This means you can't have random access, but you have fast insertion and deletion anywhere in the list.
In other words, yes, deque is a good choice for what you're doing. A list would work too; I do see what Nexus means by the space overhead though, since it stores two pointers along with each element, which means the pointers take up well over half the space used. I doubt this would be a problem in most cases, but apart from that either deque or list would be equally suitable for what you're doing. So you might as well use the deque.
Bonus of using deque is that you can push_front to insert at the front, instead of using insert.
std::deque still uses array-style allocation, but it may split the array up into chunks in completely different areas of memory. If you need random access and fast insertion/deletion at the front and back, it's a good choice. If you need insertion in the middle, I think it's not as good, though I'm unsure on that one.
std::list puts each element in its own location in memory with a pointer to the next and previous elements, so they could be widely spaced out in memory. This means you can't have random access, but you have fast insertion and deletion anywhere in the list.
In other words, yes, deque is a good choice for what you're doing. A list would work too; I do see what Nexus means by the space overhead though, since it stores two pointers along with each element, which means the pointers take up well over half the space used. I doubt this would be a problem in most cases, but apart from that either deque or list would be equally suitable for what you're doing. So you might as well use the deque.
Bonus of using deque is that you can push_front to insert at the front, instead of using insert.