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 - Jebbs

Pages: 1 [2] 3 4 ... 24
16
D / Re: Text width, and sound
« on: August 25, 2015, 07:25:32 pm »
I'm using OSX. And have the less recommended DSFML (what do I call it?). And don't seem to have sound.

I'm not sure what you mean by this. Are you talking about the master branch and not the rc branch?

Quote
How do I get the width of a Text object's text?

Hapax is right about this one. That function should work.

17
D / Re: Error when closing window
« on: May 23, 2015, 06:34:55 pm »
now when I exit the app I get an InvalidMemoryOperationError.

Any other information you can give me? Maybe a minimal example that reproduces the error when you build from the command line?

And you can suppress the destructor output by defining the version DSFML_Quiet_Destructors.

Documentation is spotty at best, but I hope to have a lot of stuff released mid summer. Until then, feel free to keep asking question!

18
SFML game jam / Next Jam
« on: March 18, 2015, 08:30:01 pm »
Hey all,

With zsbzsb doing some fantastic work on the website (seriously, check it out) we need to figure out when the next jam will occur.

Either sometime this spring or sometime this summer would be a good place to start. Anyone have any suggestions for actual dates? Once I get a feel for times that work best I'll put up a poll and get can get it nailed down.

19
Hey, sorry. I'm actually in the process of moving so things are nuts for me right now.

Anyways, the anti aliasing thing could be in the binding. A good way to check it though would be to create a minimal example that shows the issue and then port it back to C++ to see if you experience the same issue. Having the minimal example for that would also be good for me for checking.

As for the memory issue, that is most likely something that is going on in the binding. I have been focusing on completeness over optimization, but with the next release I should be in pretty good shape to work out any kinks.

This should be the last week that things are wonky for me, so I will get to it as soon as I can.

20
Holy crap. Are you creating multiple RenderTextures and then drawing to all of them each frame?

That would be your memory issue. RenderTextures are not light objects and should be used sparingly. I'm surprised it isn't causing performance issues.

As for the text thing, I bet that has something to do with needing an openGL context before the font texture is created. It makes sense.

21
That's good to hear that you've had that much success already. I wonder if you could even omit the collection call.

I'll still be looking at your code this weekend so I'll let you know if anything jumps out at me.

22
I'll look into this more over the weekend, but the money issue could be caused by the GC. It doesn't return memory back to the OS when it does collections and can be a bit of a hog. Try importing core.memory and calling GC.minimize() to see if that does anything.

23
D / Re: Shared/static library naming advice
« on: February 12, 2015, 01:58:48 am »
Because I thought that it would be cool to have all the shared libraries (the ones people could see) be called dsfml :P

24
D / Re: Shared/static library naming advice
« on: February 11, 2015, 10:47:30 pm »
It's basically my own version of CSFML.

25
D / Shared/static library naming advice
« on: February 11, 2015, 08:11:02 pm »
Hey all,

I'm gearing up for the next release of DSFML, and there was one issue that I can't really decide on my own as I am not sure what is best. I wanted to get some advice from the community before I made a final choice.

My dilemma is that the naming conventions of the libraries needed to get DSFML going are a little wonky. If you don't use DUB, then you have to link to two sets of libraries to get everything building correctly. The back end (C/C++) shared libraries use dsfml-xxx, and the front end (D wrapper code) uses dsfml-xxx-2. This has caused confusion for more than a few people.

I have thought of a couple of solutions, but I am not terribly happy with any of them.

So far I have:

  • Rename the back end to something else, such as dsfmlc-xxx, and use dsfml-xxx for the D wrapper code.
  • Rename the front end library names to something else to make it more apparent that they are the wrapper code, perhaps dsfml-xxx-lib.

I know this is a weird question to ask, but I don't really get a lot of feedback on this kind of thing when I try to discus it with the users on github.

People that don't use D are welcome to chime in as well. :P

26
D / Re: [xcb] Unknown request in queue while dequeuing
« on: February 11, 2015, 03:53:09 pm »
I was able to make it work by calling XInitThreads before anything else was called, although neagix never confirmed that it had worked for them. SFML merged the xcb branch not long ago, so when I start working on the 2.3 release this will be completely resolved. Until then, I'm going to add a method to the thread class that will expose XInitThreads on Linux.

I'm gearing up the release of 2.1, so that method will appear in the master branch pretty soon.

27
D / Re: Trouble Linking DSFML...
« on: February 06, 2015, 01:05:49 am »
If it works with dmd but not gdc then that leads me to believe that static libraries are incompatible between the two compilers.

Creating an option for building them with gdc and ldc are on my todo list though, so it will come soon.

28
D / Re: Trouble Linking DSFML...
« on: February 05, 2015, 07:00:58 pm »
If the compilers can't find the libraries, that means they either aren't in a standard search location or you aren't giving the right location to the linker.

You get it working in a terminal outside of the IDE, so that makes me think that Code::Blocks simply isn't searching for where they're located. Maybe you could try putting them in a standard search path? It's probably time I do some tutorials for common IDE's. I've opened up an issue on github so I don't forget.

Quote
"./main: error while loading shared libraries: libdsfml-graphics.so.2: cannot open shared object file: No such file or directory."

This is Linux saying that it doesn't know where to look for the shared libraries at run time. Try exporting the location of the libraries before running "./main"

Judging from what you posted already, this should work.

export LD_LIBRARY_PATH=/SFML/DSFML-nightly && ./main


Lastly, I don't use gdc so I can't really say much about it. If you wouldn't mind giving me your full command line that you used outside the IDE, I will look into that more and get back to you.

29
D / Re: Trouble Linking DSFML...
« on: February 04, 2015, 04:57:51 pm »
What issues did you have when building with the nightlies?

Also, the docs are written for the last stable version. The nightlies are for what is in the master branch, and until now I haven't had anyone that has mentioned a problem with them so I haven't gotten around to updating the docs. That's my fault. :(

One thing that isn't mentioned is that the back end library DSFML-C no longer required you to get sources for SFML and build that first or do any special set up. Building should work right out if the box.

30
Graphics / Re: Weird issue drawing on OSX..kind of..
« on: January 30, 2015, 01:13:30 am »
Figured it out. It was definitely my fault. Basically the thickness of the shape wasn't getting initialized in the constructor, and in D floats initialize to NaN. When the outline was being calculated it made some of the vertices be all crazy as hell.

Pages: 1 [2] 3 4 ... 24
anything