Messages

316

D / Re: Candidate for new official DSFML

« on: March 26, 2013, 12:36:46 am »

I wanted to work with other people before I first started the project, and even had started a thread about it, but not a lot of people were active in the D section and it didn't go anywhere so I started writing one myself. It wasn't until I had a good chunk done that other people started posting stuff. I considered helping krzat, but he posted once and was done, so I kept working on my own binding. I really don't mind working on it by myself though, mostly because once I improve it and get everything fully functioning the way I want it I plan putting the project in my portfolio to help get me into a certain program at a university.

As for the way the modules are set up , I see what you are saying. I actually had it that way originally, but I have encountered reasons in which it makes more sense for it to be all in one file rather than in separate ones. Plus, I have some plans that will reduce the number of lines of code and make things look quite a bit cleaner.

317

D / Candidate for new official DSFML

« on: March 25, 2013, 05:16:35 pm »

Hey all!

A while back I became very interested in the D programming language and had already fallen in love with SFML, but when I looked into it there didn't seem to be much support. Unfortunately, deadalnix's repo for a DSFML seems to not have had much work done on it in about a year and I think we deserve a good D binding. I wrote this(https://github.com/Jebbs/DSFML) from scratch, and I think I did a pretty good job of making it work well and as if it was an actual D API. There are definitely some parts that could use improvement, but I plan on doing active development to make sure everything is up to date and that the binding continues to improve overall! Hopefully I didn't jump the gun on giving it the name DSFML!

It's very similar to krzat's binding in a lot of ways, so if you were able to get his working then the same process will apply to mine for the most part. Things my binding feature are lot's of code compatibility with the C++ API, overloaded operators for many things, and a general avoidance of pointers in favor of built in D types. I also wrote some code to make Drawable inheritance possible and only have the need to write the draw code once and still it work with a RenderTexture and a RenderWindow. More cool updates/improvements to follow!

In any case, let me know what you guys think! This is my first project I have ever had done that other people would use. The very next things I want to work on for the binding are getting it up to date and then writing some tutorials, which I will do soon, but I wanted to finally release something for others to see!

318

System / Re: Time.aSeconds returns 1e-006 ?

« on: March 16, 2013, 12:19:48 am »

If you do some math, you will see that this is a very small number. The reason it isn't 0 is because time IS passing as soon as the clock is created, and that number you see is that amount.

319

D / Re: OO Wrapper

« on: March 10, 2013, 06:14:46 pm »

Just a heads up, I am almost done with my version of a "wrapper" for CSFML in D. It's very similar to this, but my ultimate goal was to have it become the official DSFML so there are a few extras on top of it just wrapping things in a OO way. Class has been taking up a lot of my time but I should have the first version finished in no longer than 2 weeks. (the end of this week is my last week of classes so I planned on finishing up the last of it asap)

I wanted to get it finished before I really said anything, but with Laurent's binding post I thought I should speak up!

And also, I have a few ideas for improving how it works that I will implement after I finish getting it "working".

Happy programming guys!

320

C / Re: user data variable in sfInputStream

« on: March 08, 2013, 07:18:31 pm »

I always forget that you did a .net wrapper. I'll check it out and see if I can make it work in a similar way.

Thanks as usual!

321

C / Re: user data variable in sfInputStream

« on: March 08, 2013, 02:46:35 am »

Shouldn' t the way the callbacks access the "user data" be left up to whoever is implementing the use of the sfInputStream though?

The issue that I am running into is reimplementing this in a different language. I wanted to get things working more or less like the C++ version, and having the extra parameter for each callback means I will probably have to write some wonky looking code instead of just writing a function with the same parameters as the C++ version and then assigning the address of that to to the callback.

Now, you are a far more experienced developer  than I, so far be it from me to argue with how you implement things. I'm sure you have reasons for doing things and if need be I can work around this. Just thought I would express my thoughts.

322

General / Re: [SOLVED] Weird DLL error

« on: March 07, 2013, 07:49:09 pm »

Inside the Debug and Release folders is usually where the dll's would be placed. Especially if you were to have someone else run your game/application as this doesn't require them to copy or move the dll's themselves into their system folders.  My guess is that it worked fine with Avast because it has its own dll search method since it was what ran the program.

323

C / user data variable in sfInputStream

« on: March 07, 2013, 07:13:36 pm »

I've been looking through a bunch of source code regarding sfInputStreams today and I couldn't seem to find anywhere the void* userData actually get's used other than inside CallbackStream. I'm just curious what it is used for and what "user data" get's assigned to it. Or what I should be assigning to it when using sfInputStream. I was thinking that it could be used to store the current contents on the stream, but I wasn't completely sure.

Thanks!

324

General discussions / Re: More Community-driven Development

« on: February 12, 2013, 12:43:50 am »

I think this is a fantastic idea. Not only could it lead to getting SFML features/bugs taken care of faster, but an active community will help bring in more users. And I'm sure various people would be able to contribute more than just code work. For example:

I mostly worked on the documentation, tutorials and website.

There are many intelligent and experienced SFML users (ie, not me) who could work on things like tutorials and possibly documentation. Hell, eXpl0it3r writes example code and explains things to people all the time. Being able to delegate certain tasks like these to people would give you (Laurent) more time for those important fixes and features instead of eating up all that time.

325

C / Re: Odd sfVideoMode_getFullscreenModes issue

« on: February 09, 2013, 06:35:24 am »

Nevermind! I am a complete idiot. I was iterating through the data incorrectly. I forgot that the size of each object was already being taken into account because it was a sfVideoMode*, so [i*size] was unnecessary and went through my memory at an accelerated rate. That was what caused the runtime access error.

Don't mind me!

326

C / Odd sfVideoMode_getFullscreenModes issue

« on: February 08, 2013, 07:32:05 am »

I'm having an interesting problem when I call sfVideoMode_getFullscreenModes. The number of modes it tells me I have is absurdly high, but only 9 seem to have any valid information. I am using the current version of CSFML, but I am using the library in D though I doubt that would make much of a difference.

Here is an example program I wrote:

void main(string[] args)
{
        sfVideoMode* modes;
        size_t count;
        int size = sfVideoMode.sizeof;

        modes = sfVideoMode_getFullscreenModes(&count);
        writeln("Number of fullscreen modes: ",count);
        writeln();

        for(int i = 0; i<count; i++)
        {
                try
                {
                        sfVideoMode temp = modes[i*size];
                       
                        writeln("VideoMode number ", i+1);
                        writeln(VideoModeAsString(temp));
                        writeln();
                }
                catch
                {

                }
        }
}

string VideoModeAsString(sfVideoMode videoMode)
{
        return "Width: " ~ text(videoMode.width) ~
                   " Height: " ~ text(videoMode.height) ~
                   " Bits per pixel: " ~ text(videoMode.bitsPerPixel);
}
 

If I don't include the try/catch blocks the program throws a runtime error after the 9th video mode. Anyways, here is what the program outputs for me.

Number of fullscreen modes: 57

VideoMode number 1
Width: 1920 Height: 1080 Bits per pixel: 32

VideoMode number 2
Width: 1280 Height: 720 Bits per pixel: 32

VideoMode number 3
Width: 1366 Height: 768 Bits per pixel: 16

VideoMode number 4
Width: 720 Height: 480 Bits per pixel: 16

VideoMode number 5
Width: 1280 Height: 800 Bits per pixel: 8

VideoMode number 6
Width: 0 Height: 0 Bits per pixel: 0

VideoMode number 7
Width: 0 Height: 0 Bits per pixel: 0

VideoMode number 8
Width: 0 Height: 0 Bits per pixel: 0

VideoMode number 9
Width: 1305645974 Height: 50482155 Bits per pixel: 6357136

I'm not sure what exactly is going on, but  I also want to point out that the very last video mode that I get's written to the console has changing values.  My guess I'll probably be ok if I stop when I get to a {0,0,0} videomode. I don't know if this happens on anyone else's system, but I just thought I would bring this to Laurent's attention.

327

General discussions / Re: A new logo for SFML

« on: January 30, 2013, 08:59:21 pm »

I vote for this.

I donno. I mean it isn't bad, but it reminds me a lot of SDL's logo, but the crescent thing wraps around the words more.

328

General discussions / Re: A new logo for SFML

« on: January 25, 2013, 11:22:33 pm »

Pelican for sure.

329

Graphics / Re: When rendering a sprite, it's antialiased. I need it aliased. How can I do this?

« on: December 22, 2012, 08:49:22 am »

TextureName.setsmooth(false);

Edit:
Just wanted to let you know the documentation is very well done. You could have found this answer very easily there.

330

D / Re: Destroy destructor crashes?

« on: December 18, 2012, 03:53:13 am »

You are very right. Scoped classes will not work for this kind of thing. There's just too much going on, and I didn't understand the semantics of using the scope attribute well enough.

I do agree that manually unloading all resources for D classes containing CSFML pointers is the best way to prevent memory leaks. I apologize if this was a frustrating point to get across to me. I just like to fully understand all the details before I implement a concept into code.