Code Separation about dsfml HOT 18 CLOSED

So this is more or less done, but unfortunately there are some issues.

Because of how the modules works, unless I either want to do some rewrites to CSFML or expose parts of the underlying system to the user(neither of which I want to do), then this can't be done. RenderWindow doesn't have access to the things it needs inside the Window modue, and Texture cannot access the sfWindow pointer in the Window class for Texture.updateFromWindow.

I'll see if there might be something else that I can do, but for now I think that the system will have to stay how it is.

from dsfml.

This is back in the works as I am working on a new version of the C back end. The audio module is nearly complete, which is probably going to be the most time consuming. The rest should more or less be a piece of cake since I am only going to be doing some minor tweaks to CSFML. I would estimate this should be finished in about 2 weeks from 05/26.

from dsfml.

I think I'll stop giving estimations. Life get's in the way too often. :P

I figured I'd give a little update for those that bother reading this though. I was just able to get the C code for the Network module to compile. It needs cleaning up, but it shouldn't take long before it is uploaded. The D code is mostly written as well, from when I originally started separating everything, but needs some minor tweaks before it is able to work with the new C portion.

from dsfml.

The Network Module is pretty much done, and will be uploaded tonight!
(Check the Experimental Branch for DSFML)

from dsfml.

Window Module has be uploaded to the Experimental branch. This is the big test for 64 bit on Linux systems!

@aubade, if you have any free time soon would you mind building the C code in 64 bits, and check to see if DMD can compile and run this in 64 bit mode as well without hitting that C ABI problem?

I used this to test on my machine, and it opened and ran as I was hoping it would(I made a LOT of changes :P )

module main;

import dsfml.window.all;

void main(string[] args)
{

    auto window = new Window(VideoMode(800,600),"Does it work in 64bit Linux?!");

    while(window.isOpen())
    {
        Event event;
        while(window.pollEvent(event))
        {
            if(event.type == event.EventType.Closed)
            {
                window.close();
            }
        }//poll event
    }//is open
} 

I need to download Visual C++ so I can start testing 64 bit code too!

from dsfml.

Nice! If the experimental branch works better than the master, I will definitely use it more often!

from dsfml.

Well, it's still unfinished so I wouldn't make the switch just yet. The Graphics Module still needs to be added too. I wouldn't say the experimental branch works better exactly, but the D code is going to be easier to work on with everything separated into different files. There are a couple of improvements here and there, but everything should be largely the same.

from dsfml.

Also, something to note:
Even if it doesn't work as expected on Linux(though I am confident it will), it will eventually become the new main branch of DSFML. There are important improvements that were made, so it will be silly to not use it instead.

from dsfml.

It looks like DMD's at least able to create a window (The thing that was borking up when I used DMD -m64 on linux previously) :D

However, I did need to apply a couple of fixes to get it to build (one relating to Cmake on the C side, and another likely related to DMD 2.063 on the D side.)

Edit: whoops. the patch file I posted inline only showed up halfway.
https://dl.dropboxusercontent.com/u/187059/dsfml.diff.txt should work better.

from dsfml.

That's great! Having support for DMD 64 on Linux is HUGE!

I think I just forgot about making the change for the CMake list. Whoops!

And yes, arrays should definitely be using .ptr. I think I did that for most of them(since you only found the one that needed to be changed), but I haven't upgraded to 2.063 yet. I'm always worried I'm going to find 12390127 new bugs when I upgrade my compiler :P

from dsfml.

I went ahead and fixed those. I'll try to upgrade my compiler tonight, and I'll start on the Graphics part once I get my homework done!(aka never :P)

from dsfml.

For what it's worth, 2.063.2 caused surprisingly few problems in my own code--most of it came from the tweaks to array slicing syntax (and code I wrote before I got all the way used to D's array syntax.)

And for Halsys' benefit, among other things the Experimental branch, once complete, will let us use things like SoundStream and InputStream in much, much nicer ways than the CSFML-based system the current branch uses does or would. :)

from dsfml.

Just made the switch! I received one more error than you mentioned. Maybe you just didn't realize you changed it?

Anyways, before I realized that dynamic arrays were reference types I wrote, onProcessSamples(ref short[] samples), which 2.063.2 didn't like. I just removed the ref from all onProcessSamples methods and it built just fine.

Edit: Just fixed those in the repo too. One more module to go!

from dsfml.

Good news everyone!

I haven't tested everything fully(that's really what the unit tests are going to be for), but I have successfully built both the C and D parts to the new binding I've been working on. What I have tested, which is most of it, runs on Windows just fine. I'm going to take a day or so to clean it up and what not, but I will be uploading it very soon for everyone to test out before I make the change to the master branch.

from dsfml.

Phew! It took me longer than I thought, but I have some stuff for you guys to check out.

There are still a couple of things left to add, though. I still need to set up the error catching(this maps sf::err to a D File struct so that all SFML error output can be used/redirected as needed by DSFML users) and I need to make sure that the new InputStream system is set up for all classes that use it. Other than that, everything should be good to go!

Here's how it's currently set up:

The experimental branch now only contains the new D code. I also have a little build script(only supports DMD currently, sorry) that makes it SUPER easy to build DSFML static libs for using in your project.
Note to Windows users: Don't forget to use implib on your dll's after compiling the C code and also link against the .lib file it produces. I'll eventually include these when I set up something else I'm working on.

I also started a new repository just for the C code. I also wrote up a little build tutorial that you can find on its readme, that should hopefully help out with everyone and new users alike.

I think I'm ready to close this issue! I'll leave it open for a little while longer in case anyone has any pressing issues they happen to run into, however.

Let me know how it works!

from dsfml.

Fixed a bunch of stuff and finally added the sf::err capture. It now routes to the D File struct in the dsfml.system.err module. I also added in all files/classes that need to be included(pretty sure anyways) so I think I'm ready to close this!

I'm currently working on the tutorial for building everything from scratch, and once I have it finished I will replace the current master branch with the experimental branch.

from dsfml.

That's great to hear! I'm sorry I haven't been able to provide any feedback for it yet--I've had some health issues that have made coding hard. But I'm going to try migrating my engine some time in the next couple of days :)

from dsfml.

No worries! I hope you feel better and everything is ok.

The tutorial is pretty much done so the change is likely to happen Saturday.

from dsfml.