I need help with DSFML

[OdraEncoded]

Hello, I'm picking up D this month to make a game with DSFML. I think the language is neat so far but I'm having problems using DSFML and I need help with some things.

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

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. :/

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?

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?

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

[Jebbs]

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!

[OdraEncoded]

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.

When I said error I meant a dialog box.



Since my first post I changed my code to call GC.collect(); at the end of the main loop. With the console, "Destroying VertexArray" is printed every frame. Without the console, the program crashes with that error dialog as soon as it's opened, or, as soon as it reaches GC.collect().

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.

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?

I have literally copy pasted everything.

• Windows 7
• 32 bits
• https://github.com/Jebbs/DSFML#nightlies

Thanks for the reply.

[Jebbs]

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.

[OdraEncoded]

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?

DUB version 0.9.21

Thanks for the help

[Jebbs]

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.

[Jebbs]

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.

[Jebbs]

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