Messages

31

Graphics / Weird issue drawing on OSX..kind of..

« on: January 28, 2015, 07:56:33 am »

This is related to my binding so it is probably my own fault more than anything else, but I am hoping someone can at least point me in the right direction as to what might cause something like this.

Basically drawing works correctly for SFML, but not DSFML. Check it out:


My guess is that something crazy is going on with the vertex arrays, but who knows?!

Oddly enough, no one that uses my binding has reported this happening. It only seems to have happened to me so far. I am currently attributing it to my very old and crappy Mac box. You don't even want to know the specs. It'll make you cry.

Any speculation is welcome.

32

D / Re: Loving it but a few questions

« on: January 25, 2015, 08:10:06 am »

I haven't built/ran anything on a Mac in quite  some time, but I can tell you this isn't just a D issue. You'll need to either make sure the libraries or frameworks get installed to the correct path in your friend's computer or include them directly with your executable and have them load when you run it. It should be the exact  same process as it would be with the C++ version. If you do a search for that I'm sure you'll find the right information. I only have one Mac machine so I haven't had to try getting a build to work on other Macs.

33

D / Re: DSFML-C "Nightlies"

« on: August 10, 2014, 07:56:25 am »

I have just updated the original post to include the most up to date code that will build with the code in DSFML's master repo. I'm almost finished getting my build system in place, so the original post will always have the most up to date binaries from now on.

34

D / Re: I need help with DSFML

« on: August 10, 2014, 07:20:39 am »

My apologies for taking so long to get back to you. I have been busy with a ton of things lately, but I finally managed to look into this.

One of the things I have done recently is put together some build systems to make sure I can distribute up to date builds more easily. That in itself isn't that important to this, but what I do have are some nice new dlls for testing, and with the newest build of everything I couldn't reproduce your errors. It's possible something was fixed between now and then. I'm going to update the links to everything everywhere here in a second, so you'll have access to the newest ones. I'd like you to see if using them fixes your problems.

Let me know if you have any other issues!

P.S.

According to Sonke, there isn't currently a way to let DUB know to build in debug vs release. You need to do it via a flag. When I built in release, my command line was

dub build --build=release

35

D / Re: Bizzare issue playing audio files

« on: July 27, 2014, 05:47:12 am »

Sorry for my own late reply! I have been kind of everywhere lately.

I'm glad you got it working, but let's see if I can make it less hacky.

• The latest precompiled nightly seems to be missing several functions in the audio library, resulting in unresolved symbol errors when used with the latest DSFML sources.

This is because I haven't had a chance to update the binaries for the most recent version, so that one is on me. I'll be building them tonight for each system though.

• Visual C++ does not allow implicit returns, so I had to add a few return statements in order to get DSFML-C to compile.

Can you let me know where this happens so I can fix it in the source code?

• sfErrAudio_getOutput causes unresolved external symbol errors with the latest DSFML-C, so I had to comment out it's use.

This might have been caused by some miss matching with the D code and C libraries. One of the changes I did over in DSFML-C was merging SFML's source directly into the repository. Because of that, it fixed an issue that I had before where I had to define the error output for each module. sfErrAudio_getOutput shouldn't exist any more. There should only be sfErr_getOutput declared in dsfml.system.err.

• An invalid file descriptor exception was thrown when I called music.openFromFile, even when the audio file existed. Trying to open a file that doesn't exist also results in an invalid memory operation error, which I don't think should happen normally... But I was able to get things working correctly by enclosing the call to openFromFile in a try/catch block, and once I suppressed the error everything worked perfectly.

That sounds like another error on my part. I'll look into it and get it fixed.



It's awesome you managed to get it working though! Let me know if you have any other problems.

36

SFML game jam / Re: Potential Schedule

« on: July 13, 2014, 02:00:25 am »

Ah, perhaps I should have explained better. The number of rounds isn't fixed. 6 is the "worst case" type situation. A theme is going to be chosen only if it has greater than 50% of votes. If something is picked sooner then there just won't be any more voting. I just want to make sure there will be enough time if it ever comes to a not so quick selection.


By the way, my plan for voting is that after each round any themes that have 0 votes are automatically dropped and any theme with the next lowest number of votes(or maybe a little more depending on the round, number of votes, and number of themes voted on)  is dropped too. If we had done that for the last jam, it would have cut the number of themes to vote on in half in just the first round.

37

D / Re: I need help with DSFML

« on: July 13, 2014, 01:19:09 am »

Not sure if this is much of an update, but I to am having trouble getting things to build in release mode using DUB. I'm currently waiting to hear back from Sonke on the issue. I'll take care of that before I see what is causing the issue with getting rid of the console. I'll also be updating the binaries as it seems that I haven't built new ones in a while.  I'll let you know when the new ones are up, and if I manage to sort this out.

38

SFML game jam / Potential Schedule

« on: July 12, 2014, 10:32:37 pm »

Hey all,

I have been putting together some thoughts on getting the jam automated, and I am at a point where I am trying to nail down an actual schedule for when things will take place. Since we will be switching to voting rounds, I obviously want to give enough time for that in case we need to do many rounds, so things are set out far in advance. I'm just looking for people's opinions on if the ranges for things are too long/short.

Here's what I got:
2 months before the jam starts theme suggestion opens
2 weeks later theme suggestion closes
1 day later first voting round starts
5 days later first voting round closes
1 day later second voting round starts
5 days later second voting round closes
repeat voting cycle
1 hour before jam starts theme is announced
Jam goes for 72 hours
Entry submission opens 24 hours before jam ends
Entry submission closes 1 hour after jam ends for the stragglers and slowpokes


This gives us time for 6 rounds of voting, and plenty of time to get a game done and submitted. The only things I am thinking of changing at the moment are increasing the time people are allowed to submit and closing entry submission a little earlier.

Thoughts?

39

D / Upcoming changes to DSFML

« on: July 08, 2014, 04:21:20 am »

I posted about this on the D forums, but I should have probably mentioned it here as well. Also note that this notice is targeted at DUB users.

I am in the process of working on getting DSFML 2.1 rolled out, and will start pushing some of my code into my github repo tomorrow. In order to make sure the new code doesn't mess with any existing DUB projects, please change the dsfml dependency in your dub.json from "~master" to "~2.0".

As always, feel free to email me or open up issues on github if you have any problems with DSFML.

project: https://github.com/Jebbs/DSFML
email: dehaan.jeremiah@gmail.com

40

D / Re: I need help with DSFML

« on: July 08, 2014, 03:45:12 am »

No problem! I don't know if I can get to it tonight, but I should have some time tomorrow to sit down and mess with this.

41

D / Re: I need help with DSFML

« on: July 07, 2014, 09:52:43 pm »

Thanks for all the information.

From the sound of this:

What do you mean by "It only had effect on the code that was after a debug condition in my program"? Can you elaborate a little on that?

In my program a statement such as

debug x = 5;

Will not get executed if I use the "releaseMode" option. But the statements in the wrapper such as this (template) are still executed.

It seems to me that while your actual application is building in release mode, the library is building in debug. This could be a bug in DUB. What version are you using?

After I hear back from you I will try to reproduce the bug and see if I can track it down.

42

D / Re: I need help with DSFML

« on: July 03, 2014, 09:43:50 am »

Hey there! Sorry you are having problems. I'll do my best to help you out.

For starters, how do I remove the console window?

I tried using the linker flag SUBSYSTEM:WINDOWS, but now my program crashes on exit with the error

core.exception.InvalidMemoryOperationError

Do you get the same errors when you don't use SUBSYSTEM:WINDOWS? And do you know if there is any specific object that is causing the error? Also, if you are using SUBSYSTEM:WINDOWS, how do you know you are getting the memory issue? When I hide the console and I get this kind of error it usually just crashes for me.

It seems that this is related to the "Destroying X" messages that were written on the console when there was a console. Since now there is no console, it is an error to print. :/

Those messages are just going to cerr, so that shouldn't effect the program in this way.

Furthermore, the code to print those messages are after a "debug" condition, so I tried building my program using "releaseMode" as a building option in my dub package but it didn't have any effect. It only had effect on the code that was after a debug condition in my program, does that mean I have to somehow build the DSFML wrapper in release mode?

What do you mean by "It only had effect on the code that was after a debug condition in my program"? Can you elaborate a little on that?

If you use DUB,  then you shouldn't need to build the wrapper. DUB handles all that for you. All my tests deal with the source code directly so I haven't tested with DUB in quite a while. Perhaps I should add that to my set of tests. That's said, if you build in release, you shouldn't be seeing them at all. Not sure what's going on there.

Besides that I'm worried that those "Destroying X" messages only ever appeared when my program exited. I heard D is garbage collected, but should I be destroying anything manually in DSFML? How? If not why stuff is only ever destroyed when the program exits?

That is normal for small programs. It is just cleaning up the used objects at exit. You'll only see the destroying messages during run time if you have actual garbage that needs to be collected. You can destroy stuff manually if you like, but it isn't necessary in most cases. If you want to, just call destroy on an object.

Source code of my worries: https://github.com/Jebbs/DSFML/wiki/Building-Your-First-DSFML-Program%28DUB%29

Are you absolutely sure that you are using that code and you haven't modified it in any way?

Some other info would be much appreciated too.
1. What OS are you compiling on?
2. Are you compiling in 32 or 64 bits?
3. Where did you get the shared libraries you are using?


We will get this figure out!

43

Audio / Re: When might the SoundBufferRecorder not record?

« on: July 02, 2014, 01:04:24 am »

It occurred to me that I introduced a small bug in my binding that was causing sf::err not to write to anything, but that itself isn't important to this problem. What I discovered  once I could again see errors was that I now get the "Failed to open the audio capture device" error, though I am not sure why. I have successfully recorded on my system before.

What are some reasons that the capture device might fail to open?

44

Audio / Re: When might the SoundBufferRecorder not record?

« on: June 30, 2014, 08:36:48 am »

No, nothing has changed. You should write a complete and minimal code in C++ so that we can investigate the problem.

If that's the case then I'm probably doing something wrong somewhere. Once I have a chance I'll write the same thing in C++ to confirm.

45

Audio / When might the SoundBufferRecorder not record?

« on: June 30, 2014, 02:43:56 am »

This might not be relevant anymore as my binding is still in 2.0 land, but I was curious when sound recording with the SoundBufferRecorder might not work.

Here's some context:

I'm using the sfSoundBufferRecorder methods from CSFML. No matter what I do, I can't seem to record anything. Thinking it might be some strange C++ to D thing I have altered sfSoundBufferRecorder_getBuffer to write the duration of the sf::SoundBuffer to the console before it updates the sfBuffer, but even there, it is always 0 as nothing was apparently recorded. sfSoundRecorder_isAvailable does return true, so I'm a little stumped.

Has any of this changed between 2.0 and 2.1? Could it have something to do with my own computer? Any help would be great.