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

Pages: [1] 2
Graphics / Isometric Depth?
« on: December 20, 2012, 10:37:45 am »
I am working on a map engine for isometric tile based maps. I am thinking on how to draw the sprites and map tiles in the right depth order.

I have made my own implementation of a vertex array with all kinds of extra features just for drawing isometric tile maps such as being able to draw for Y[0] to Y[1] so i was thinking i could store each drawable object in the game in some kind of depth sorting class that divides the screen into screen height / tileStepY (if a isometric diamond is say 32 pixels height then the step is 16 pixels) and then sorts the sprites by their bottom of their shape (the feet) into a bunch of arrays for each depth division. This way when i move a sprite in the map i just have to give its new foot position to the depth sorting class and it would move it to the correct depth division.

This would allow me to draw the map tiles for each depth division and then the sprites that need to be drawn next then goes to the next depth and draws the tiles of the map for that division then the draw that depths sprites. I can optimize this to detect depth divisions with no sprites so i can draw multiple depth divisions of the map tiles at once.

My question is, as i have no idea how this is normally implemented and have come to this style on my own, is this a bad idea or are there any problems anyone can see that i may run into later? I am not sure as well if i should store all active sprites in a overall array and then use its indices or something as an ID and use that to reference that drawable/sprite in the depth arrays or what but that is another issue.

How would you do isometric depth sorting/drawing?

D / Re: Destroy destructor crashes?
« on: December 17, 2012, 12:56:59 pm »
That all makes sense, apologies for not thinking of the module unloading.

The idea of using a struct seems tempting but structs are stored on the stack aren't they, so i don't think i would do this for my classes as they are generally long life span objects.

So i guess i will just go with a manual destroy method.

Thanks guys for all the support. Cant wait for an OO wrapper in D based on derelict3!

D / Re: Destroy destructor crashes?
« on: December 17, 2012, 05:08:38 am »
But am i right in thinking however that if i don't call sfImage_destroy on the classes contained image then it will sit in memory forever? i thought the sfImage was created in C/C++ so its not garbage colleted by D?

That's what i thought so it just seemed natural then to destroy the image in a destructor.

PS: I am not creating an OO wrapper for Derelict SFML as much as i would love one, i just want to have a class that uses and clears the memory of sfml objects properly and as much as i may be silly in what i am doing i just thought that this was the way to do it but i was wrong so i am not sure what to do.

D / Destroy destructor crashes?
« on: December 16, 2012, 03:40:49 pm »
Ok i am trying to wrap some classes in d with the csfml derelict bindings and naturally i want to destroy the sfml object with destructor however when i do that it crashes.

If i where to remove the destructor and have a manual destruction method to the class it doesnt crash if i where not to have a destructor or a destroy method and just leave the memory around it still works but the moment i use the destroy in a destructor it crashes.

It crashes with this error as reported by mago debugger:
First-chance exception: core.exception.InvalidMemoryOperationError

I dont understand why this happens inside a destructor but not in a method that does the same thing. Here is my test code about as minimal as i can make it to demonstrate:

module main;

import derelict.sfml2.system;
import derelict.sfml2.window;
import derelict.sfml2.graphics;
pragma(lib, "derelictUtil.lib");
pragma(lib, "derelictSFML2.lib");

class Image {
        sfImage* image;

        this(uint width, uint height) {
                image = sfImage_create(width, height);

        ~this() {

        void destroy() {

void main() {

        auto image = sfImage_create(100, 100);

        auto myimage = new Image(100, 100);

Can anyone tell my why this is happening and or how to fix it?

C / Re: RenderState proper usage?
« on: November 22, 2012, 03:37:57 pm »
Confirmed now that it all works thank you very much, Laurent feel free to move this over to the D catagory if you see fit. Thanks again to you both!

C / Re: RenderState proper usage?
« on: November 22, 2012, 02:33:05 pm »
awesome, thanks so much for the support. Both of your works and support have been invaluable to me and i really appreciate everything you are both doing.

I will update my bindings and give this a test as soon as i can get back to my work terminal and report back.

C / Re: RenderState proper usage?
« on: November 22, 2012, 09:13:11 am »
I have the version that does not take a sfTransform* but just a normal sfTransform so i am up to date.

Changing the states transform to this:
state.transform = sfTransform_fromMatrix(1, 0, 0, 0, 1, 0, 0, 0, 1);

Still doesn't work, one step back actually, now it instantly crashes like it did before hand. As incorrect as setting it to null if its not a pointer is, at least that made it display blackness until the mouse touched the window.

With the chance this is actually D specific i will link my issue report to the Derelict3 bindings to this thread.

C / Re: RenderState proper usage?
« on: November 22, 2012, 05:39:43 am »
It turns out that the D bindings aparently cannot support an instance for sfTransform_Identity so i need to define it myself, how would i do that. I havent looked into transforms yet.

C / Re: RenderState proper usage?
« on: November 22, 2012, 02:18:42 am »
huh, sfTransform_Identity doesnt exist in the D binding which is odd they where updated a week ago. I am using the latest sources that i compiled myself, 2-3 weeks ago however, and the documentation that it built does had sfTransform_Identity. I will file an  issue report with the derelict3 bindings but in the mean time is there any way to replicate sfTransform_Identity myself? I hope thats the only problem.

Sorry that this has now fallen a bit into the D category rather then C but i was originally doing something wrong with the C binding which derelict 3 mirrors.

C / Re: RenderState proper usage?
« on: November 21, 2012, 02:43:10 pm »
Update, i was wrong it does show a black screen and doesn't instantly crash like before however it does crash the moment i move the mouse over the window the same way as before.

C / Re: RenderState proper usage?
« on: November 21, 2012, 12:30:18 pm »
ah, ok then. Thanks a heap Laurent your assistance always swift and useful. Now i can get on with trying my shader lighting and vertex array tilemaps!

Does sf::Transform::Identity really do the same thing as null in the c version? other then that its the same so i have no idea why it would be different. Aleast when you give an example so like mine i know that its not something i have broken this time  :P

C / Re: RenderState proper usage?
« on: November 21, 2012, 12:10:35 pm »
ah silly me forgot that setting them to null is not the same as setting them to nothing. It doesnt crash now however it shows only black, why is that?

C / Re: RenderState proper usage?
« on: November 21, 2012, 11:41:52 am »
Hmmph. Must be something i am doing wrong then. Here is my test case as simple as i can get it and as close to C as possible (i use D so ignore the .ptr it just converts string to char* and the switch/case/default may be a little different but that should be it in the way of differences).

        const sfContextSettings settings;
        sfRenderWindow* win = sfRenderWindow_create(sfVideoMode(800,600,32), "SFML Test", sfDefaultStyle, &settings);

        sfImage* fg = sfImage_createFromColor(400, 300, sfGreen);
        sfTexture* fgt = sfTexture_createFromImage(fg, null);
        sfSprite* fgs = sfSprite_create();
        fgs.sfSprite_setTexture(fgt, 0);

        sfRenderStates state;
        string frag = r"
                void main() {
                gl_FragColor = vec4(1,0,0,1);

        sfShader* shader = sfShader_createFromMemory(null, frag.ptr);
        state.shader = shader;
        state.blendMode = sfBlendAlpha;

        sfEvent event;
        while (sfRenderWindow_isOpen(win)) {
                while (sfRenderWindow_pollEvent(win, &event)) {
                        switch (event.type) {
                                case sfEvtClosed:
                sfRenderWindow_clear(win, sfBlack);

                //sfRenderWindow_drawSprite(win, fgs, &state); //Causes crash
                sfRenderWindow_drawSprite(win, fgs, null);


So down by the last few lines, when i render the sprite with the state it instantly crashes however if i draw it without the state then it works and draws a green rect up the top left of the screen. If the state where to work along with the shader then it would draw a red rect instead.

What am i doing wrong here?

C / [Solved] RenderState proper usage?
« on: November 21, 2012, 10:26:25 am »
Heyo quick question about sfRenderState in the C bindings. I know in the C++ bindings you can provide a shader for example rather then the entire RenderState when drawing something but in CSFML you have to provide i complete sfRenderState or null.

My question is what should be in that sfRenderState along with the shader, following the example, to make it work. I have been trying to get a shader to work myself in CSFML but no matter what i do it crashes when i call the draw function so i thought that it may actually be the sfRenderState that is causing the crash.

Appreciated, Nekroze.

Graphics / Re: Shader Lighting? Newbie here.
« on: November 17, 2012, 09:03:52 am »
Sorry to keep pathetically bringing this up but i still cant get it working. Is there anything wrong with the above that would cause it to fail?

I just don't know what i am doing wrong here.

Pages: [1] 2