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

Show Posts

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

Messages - Andrew

Pages: [1] 2
Audio / Re: For the SFML Developers: SoundStream Chunk
« on: July 15, 2014, 01:05:47 pm »
Please explain to me how my ManagedSoundThing still has a memory leak. I am very curious. When it gets out of scope and reference and/or is explicitly deconstructed, it deletes the array pointer from memory.

Audio / Re: For the SFML Developers: SoundStream Chunk
« on: July 15, 2014, 12:45:40 pm »
I figured out my constructor problem. Apparently:


is not equivalent to setting it in the preprocessor definitions, as the internet said.

Anyways, I have in fact given you a description of why I want const removed. Take a look at my AddSample method from before and see if you can get a working example of that (actually working) with const Chunk. You won't be able to; then you'll tell me that it's none of my business to write code intuitively like that and that I should just create a Chunk last minute. My response to that is that I want to use Chunk for the same reasons that you did in SFML! Instead, I had to make my own stupid class:

class ManagedSoundThing
                short* data;
                unsigned int numberOfSamples;

                        delete [] data;

Note that I have just shown you, in this code, yet another reason why it should not be const. Not only does my class store a short* and unsigned int at the same time, but if I were able to use a Chunk in it (properly), I would not be able to call "delete [] chunk.samples;" on it.

As I said from the beginning, this may seem like a minor problem to you, but it simply doesn't make sense to have inconsistent code. Why create a package for data that only you can use? The real life equivalent to this would be something like me having to mail you a keyboard and a mouse in separate packages even though I could have sent them both in one package - and you yourself are going to use your own combined package, but you won't let me use it.

Also, this has further implications for other code in SFML, which is also what I was getting at. A software library should have the goal of being as usable as possible in as many ways as possible. Unnecessary restrictions are the last thing you want to have.

Audio / Re: For the SFML Developers: SoundStream Chunk
« on: July 15, 2014, 11:01:34 am »
So when you're driving and you're going to make a left turn, do you instead take three right turns? Or would you rather access the left direction directly?

You SFML people are so difficult. You disallow or heavily discourage certain ways of doing things because either you don't like them, you don't understand why other people would do them, or you wouldn't do them yourself. It's this mentality of "I want you to write your code like this".

Sure, it's your project and your code. Technically you have the right to do what you want with it, but are you developing it for you or also for all of the other people who use it? Because I guarantee that this (general mentality) has caused unnecessary and unwanted frustration for plenty of others besides myself; if I've had unsolvable problems with these sorts of things, so have others.

I am saying this for SFML's benefit. If I'm coming across too negative then sorry, I'm just very frustrated. I spent the last couple of hours determining that the SoundStream must be inherited a certain way, else it will give linker errors that do not help you. Apparently you can either not specify any constructor at all or you must specify a constructor like this:

class AnotherSoundStream: public sf::SoundStream
        AnotherSoundStream(Chunk& chunk);

Why do I get linker errors if I don't have either of those two constructors? I have no idea, but I bet it's because "I can't see anyone doing it any other way." There goes hours of development.

Actually, I don't think it's allowing any constructors...

Audio / Re: For the SFML Developers: SoundStream Chunk
« on: July 15, 2014, 08:44:17 am »
sf::SoundStream::Chunk c;

c.samples = new short[200000];

for (blahblah)
    c.samples[whatever] = etc.;

Note: it may not all be generated at the same time. If this were to be the case, I would want to pass around the Chunk object reference, not a short* and an int. I'll give you an example:

void AddSample(Chunk& c)
    c.samples[c.sampleCount - 1] = 5;

Audio / Re: For the SFML Developers: SoundStream Chunk
« on: July 15, 2014, 07:48:46 am »
Here's what I can't do with const in place:

sf::SoundStream::Chunk c;

c.samples = new short[100000];
c.samples[0] = 5; //It says "expression must be a modifiable value".

Audio / For the SFML Developers: SoundStream Chunk
« on: July 15, 2014, 02:17:43 am »

This may seem like a minor request, but could you make the SoundStream Chunk's "samples" field be non-const?

(Line 55)

It's hard to explain why this is such a big deal for me, but basically it would make my code a lot cleaner, faster, and easier if I could change its value over time. I guess this is the best way to explain why:

I'm generating sound data programmatically, and I am not using a file or stream source of any kind. I would prefer to be able to just store the sound data and add to it all within the Chunk. Instead, I have to do something more like this:

short* soundData = new short[200000];

for (blahblah)
    soundData[whatever] = etc.;

sf::SoundStream::Chunk c;

c.samples = soundData;

In addition, I might want to make modifications to the Chunk over time. I would prefer not to have to maintain two arrays/vectors/etc. when there only needs to be one. Hopefully this makes sense.

(I'm also a little curious as to why it was made const in the first place and why that would be necessary?)


- Andrew

General / Re: CMake Libraries Version/Dependency Problem
« on: June 02, 2014, 11:54:34 pm »
Is this even related to my CMake/VS2013 problem anymore? If not, can you make a new thread? I don't want to get emails about other people's problems unless I'm helping them or they're undergoing the same situation and solving it.

General / Re: CMake Libraries Version/Dependency Problem
« on: May 23, 2014, 10:48:19 pm »
Ahh okay. Thanks guys.

General / Re: AW: CMake Libraries Version/Dependency Problem
« on: May 23, 2014, 10:01:11 pm »
For Windows and OS X all the dependencies are provided in the extlibs directory.

Are you sure about that? Because I didn't find all of the ones listed in the link Ixrec mentioned (https://github.com/SFML/SFML/wiki/FAQ#build-link-static).

General / Re: CMake Libraries Version/Dependency Problem
« on: May 23, 2014, 09:30:37 pm »
My point is just that I use SFML so I don't have to deal with problems like this. I understand that the change was made for good reasons, whatever they are, but now it's losing its ease of use for those who use VS2013 or other currently unsupported compilers/IDE's. Believe me though, I understand the extent as to how much coding can be a hassle; I just like to avoid it wherever possible. For now, I'd rather just use VS2012 so I can continue working on my own code.

Another problem with the switch is that if I use SFML in more than one project, I now have to copy a bunch of libraries and link all of them.

I'll give it another shot when I have time.

General / Re: CMake Libraries Version/Dependency Problem
« on: May 23, 2014, 08:52:23 pm »
What I mean is there isn't sufficient information about the dependencies. All it does is list a bunch of libraries, some of which aren't even found in the extlibs folder.

General / Re: CMake Libraries Version/Dependency Problem
« on: May 23, 2014, 07:46:06 pm »
Because now there isn't sufficient information or support for how to do it.

General / Re: CMake Libraries Version/Dependency Problem
« on: May 23, 2014, 02:08:24 am »
Alright I give up. 2012 it is...

General / Re: CMake Libraries Version/Dependency Problem
« on: May 23, 2014, 01:38:48 am »
Is there any practical way I would be able to combine all of these libraries into one, then?

General / Re: CMake Libraries Version/Dependency Problem
« on: May 23, 2014, 01:13:12 am »
Okay, so, from looking at that diagram I conclude that if I'm going to link network, audio, window, and graphics, I'll need to also link: ws2_32, openal32, sndfile, opengl32, gdi32, freetype, glew, and jpeg. Is this correct?

Also, is this linking supposed to happen in the VS2013 binaries solution (where I build the 2013 SFML libraries), or do I need to link in my actual project? Do I just need to add them to the link input list? Etc.


- Andrew

Pages: [1] 2