106
D / Re: DSFML-C "Nightlies"
« on: December 30, 2013, 05:50:21 am »
Just updated the first post to include a user contributed OS X build as well as a 32bit Linux build.
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.
107
D / Re: DSFML-C "Nightlies"
« on: December 30, 2013, 05:49:38 am »So if it is finding the lib files automatically when building DSFML, where do I put the new ones I just downloaded for it to build against? Will what you posted (the dmd main.d line) work for building DSFML too?
Just realized I didn't answer this, but I think our other conversations covered it, yes?
108
D / Re: String, Dstring, and Char[] oh my...
« on: December 29, 2013, 10:36:57 pm »
Had a chance to look at some code!
It took me a bit to get things set up since I didn't have any Derelict stuff, so I just added the source files directly instead of messing around with building static libraries. The ones I used were https://github.com/DerelictOrg/DerelictAL and https://github.com/DerelictOrg/DerelictUtil, which could be newer than what you are using since all of the OpenAL stuff is in a single file now as opposed to being in derelict.openal.al, derelict.openal.types, and derelict.openal.functions.
Any who, the only changes I made to your files were in soundactor.d, where I commented out importing derelict.openal.types and derelict.openal.functions, and then I uncommented lines 105:
Once I added libsndfile-1.dll into the bin folder, I ran it, selected a file, and then hit the play button....and well, it worked. Granted, I did get some runtime memory errors on occasion which are probably related to the sound class(I know how I'll fix them), but it loaded the sound file(I used both a .wav and a .ogg) and played it. It would only play a single file each time I ran the program, though. It worked in both debug and release configurations. I used my own dsfml-xxx-2.lib files, but I used the included dll's.
So...yeah.. I really wish I could help but I don't know what I could do. Unless there was more that I needed to uncomment to see the error, it sounds like it is something in your own code.
It took me a bit to get things set up since I didn't have any Derelict stuff, so I just added the source files directly instead of messing around with building static libraries. The ones I used were https://github.com/DerelictOrg/DerelictAL and https://github.com/DerelictOrg/DerelictUtil, which could be newer than what you are using since all of the OpenAL stuff is in a single file now as opposed to being in derelict.openal.al, derelict.openal.types, and derelict.openal.functions.
Any who, the only changes I made to your files were in soundactor.d, where I commented out importing derelict.openal.types and derelict.openal.functions, and then I uncommented lines 105:
sound.setBuffer(buffer);
and 107:label.setString(to!(dstring)(temp[(temp.lastIndexOf('\\') + 1)..$ - 4].dup));
Once I added libsndfile-1.dll into the bin folder, I ran it, selected a file, and then hit the play button....and well, it worked. Granted, I did get some runtime memory errors on occasion which are probably related to the sound class(I know how I'll fix them), but it loaded the sound file(I used both a .wav and a .ogg) and played it. It would only play a single file each time I ran the program, though. It worked in both debug and release configurations. I used my own dsfml-xxx-2.lib files, but I used the included dll's.
So...yeah.. I really wish I could help but I don't know what I could do. Unless there was more that I needed to uncomment to see the error, it sounds like it is something in your own code.
109
D / Re: String, Dstring, and Char[] oh my...
« on: December 29, 2013, 07:30:40 am »
Haven't been able to get to it quite yet, sorry. Work is slowing down for the now though, so I'll get off pretty early tomorrow. I planned on looking at this then and I'll let you know once I see something!
110
D / Re: Issues with Sprite.color
« on: December 28, 2013, 06:55:47 am »
Yep, definitely missed this.
Found the reason for it, and just uploaded a fix.
Found the reason for it, and just uploaded a fix.
111
D / Re: String, Dstring, and Char[] oh my...
« on: December 28, 2013, 01:42:33 am »
Sure. I'd be glad to look at it.
My email is dehaan.jeremiah@gmail.com
My email is dehaan.jeremiah@gmail.com
112
D / Re: DSFML-C "Nightlies"
« on: December 24, 2013, 09:33:59 am »OK, I did manage to find the instructions a little buried, but doesn't it build against the DSFML-C libraries?
Buried? There was a link to the build instructions on the page I linked above.And it wouldn't build correctly if it couldn't find the dsfml-xxx.lib files. Those are what connect it to the dll's.
Edit:
Some of the wording in the wiki could probably be improved. I'll look into this and see what I can fix.QuoteHow do I tell it where to look? It seems to succeed automatically, but I don't know how to guarantee it's building against the latest libs.
On Windows, you need to use the -L+Path compiler option. For example:dmd main.d -L+C:\Users\Jeremy\Desktop\dsfml\ dsfml-graphics.lib dsfml-window.lib dsfml-system.lib
This looks for all the .lib files in C:\Users\Jeremy\Desktop\dsfml\
You have to make sure the right dll's end up in the exe directory though.
113
D / Re: String, Dstring, and Char[] oh my...
« on: December 24, 2013, 09:27:54 am »
So, using the nightly DSFML-C build and modifying parts of your code, it worked fine for me(save for a new error I found in the Sound class that I now need to track down).
Your original code for choosing the file was this:
However, the original code that Adam Ruppe posted in the D forums didn't return the entire char array. It returned a pointer to it. Correcting that fixes all your problems because a C char* uses \0 as a finalizer, so the to!string function works like it is supposed to. Using to!string on the whole of fileNameBuffer will convert the entire thing, giving you the garbage characters at the end of the good stuff.
Anyways, here's the same code with the revisions I made. http://pastebin.com/nR4WJVx8
A couple of notes about your code:
Color is a struct, so you can skip using "new" when you create Color objects. That way, you don't have to dereference it when you call Window.clear.
When getting a slice, you can actually use "$" as a shorthand for the length of the array.
Hope all that helps!
Your original code for choosing the file was this:
auto openSoundFile()
{
char[256] filenameBuffer;
filenameBuffer[0] = 0;
OPENFILENAME info;
info.lStructSize = OPENFILENAME.sizeof;
info.lpstrFilter = "Audio Files\0*.wav;*.ogg\0\0".ptr;
info.lpstrFile = filenameBuffer.ptr;
info.nMaxFile = filenameBuffer.length;
if(GetOpenFileNameA(&info))
{
return to!string(filenameBuffer);
}
else return to!string("!!failed");
}
{
char[256] filenameBuffer;
filenameBuffer[0] = 0;
OPENFILENAME info;
info.lStructSize = OPENFILENAME.sizeof;
info.lpstrFilter = "Audio Files\0*.wav;*.ogg\0\0".ptr;
info.lpstrFile = filenameBuffer.ptr;
info.nMaxFile = filenameBuffer.length;
if(GetOpenFileNameA(&info))
{
return to!string(filenameBuffer);
}
else return to!string("!!failed");
}
However, the original code that Adam Ruppe posted in the D forums didn't return the entire char array. It returned a pointer to it. Correcting that fixes all your problems because a C char* uses \0 as a finalizer, so the to!string function works like it is supposed to. Using to!string on the whole of fileNameBuffer will convert the entire thing, giving you the garbage characters at the end of the good stuff.
Anyways, here's the same code with the revisions I made. http://pastebin.com/nR4WJVx8
A couple of notes about your code:
Color is a struct, so you can skip using "new" when you create Color objects. That way, you don't have to dereference it when you call Window.clear.
When getting a slice, you can actually use "$" as a shorthand for the length of the array.
Hope all that helps!
114
D / Re: DSFML-C "Nightlies"
« on: December 24, 2013, 07:42:32 am »OK, I did manage to find the instructions a little buried, but doesn't it build against the DSFML-C libraries?
Buried? There was a link to the build instructions on the page I linked above.
And it wouldn't build correctly if it couldn't find the dsfml-xxx.lib files. Those are what connect it to the dll's.Quote
How do I tell it where to look? It seems to succeed automatically, but I don't know how to guarantee it's building against the latest libs.
On Windows, you need to use the -L+Path compiler option. For example:
dmd main.d -L+C:\Users\Jeremy\Desktop\dsfml\ dsfml-graphics.lib dsfml-window.lib dsfml-system.lib
This looks for all the .lib files in C:\Users\Jeremy\Desktop\dsfml\
You have to make sure the right dll's end up in the exe directory though.
115
D / Re: DSFML-C "Nightlies"
« on: December 23, 2013, 11:19:30 pm »
Wiki recently had some updates.
Check things out here(for Windows):
https://github.com/Jebbs/DSFML/wiki/Getting-Started-in-Windows
Check things out here(for Windows):
https://github.com/Jebbs/DSFML/wiki/Getting-Started-in-Windows
116
D / Re: String, Dstring, and Char[] oh my...
« on: December 23, 2013, 10:08:16 pm »
I just started vacation from work today, so you can expect me to dig into this very soon!
Yikes! Looks like I had testing code still present in the libs I sent you before. I doubt this will fix your problem, but at the very least use the new ones I recently posted links to in the nightly thread.
Also, the message I get in console is
Stream closed?
Stream closed?
Yes, I get it twice for one file operation.
Yikes! Looks like I had testing code still present in the libs I sent you before. I doubt this will fix your problem, but at the very least use the new ones I recently posted links to in the nightly thread.
117
D / Re: DSFML-C "Nightlies"
« on: December 23, 2013, 09:39:43 pm »Also, for those who were used to building things in the past, is this download that is now linked to everywhere everything we need to get DSFML working on our system? I.E. this has DSFML and DSFML-C all wrapped up and we don't need to build DSFML on these seemingly DSFML-C files?
Correct.
Kind of. These downloads are only the C libraries that wrap SFML. It doesn't include any D code because that side off things is more likely to change and it's easy enough to rebuild if you need to.
118
C / Re: CSFML static linking & dlls
« on: December 22, 2013, 06:08:19 pm »QuoteShouldn't it be theoretically possible though? If you built a static version of csfml and sfml, and then linked all dependencies? Unless I am missing something, in which case I will feel very silly.You wouldn't be able to link a static version of CSFML, since it's written in C++. Your C linker would complain about all these crazy C++ symbols that it doesn't know about.
Sorry for making you feel silly
That's ok.
I think my view on what will and won't link correctly is skewed because of D. I'm fairly certain that the D compiler would be ok with linking everything statically like how I described.
119
General discussions / Re: linking .a when dynamically linking sfml
« on: December 22, 2013, 12:04:43 pm »
Because Windows is silly and requires what's called an import library to link with the dll's. Import libraries contain a list of all symbols found in a particular dll since you don't link to dll's directly on Windows like you would link to shared libraries on Linux. They have the same extension as static libraries(.a for gcc and .lib for VC++) for what ever reason.
Edit:
SFML marks all static libraries with the -s suffix, which helps to prevent one from confusing an import library with a static library on Windows.
Edit:
SFML marks all static libraries with the -s suffix, which helps to prevent one from confusing an import library with a static library on Windows.
120
C / Re: CSFML static linking & dlls
« on: December 22, 2013, 10:15:03 am »There's no static version of CSFML.
Shouldn't it be theoretically possible though? If you built a static version of csfml and sfml, and then linked all dependencies? Unless I am missing something, in which case I will feel very silly.