Brick Atelier

[Krice]

Or you could just release your code under the GPL like the developers of the free tools you use have done. Pretty fair deal really.

I don't use GCC that much to be honest. I'm mainly using Visual Studio for developing, because it's just way better than Code::Blocks or any of the free tools. For graphics I'm using Paint.net which is a closed source freeware program (with optional donations) and Affinity Designer which is a commercial software. In fact I hardly use any open source programs, because they usually suck so much.

What sometimes happens to open source projects that they are taken over by some random dudes who just take the project and then start to generate money with it. Like what happened to Blender 3D. That's why it's quite wise not to open source everything.

 

[Krice]

I found a bug from the release version, whee. I began to work on the project just for the fun of it and found out that the temporary brush with "use as brush" is deleted during exit even it doesn't exist. It's kind of easy bug to make, since the "current" brush pointer is used for the temp brush and the brushes that are stored in the pad. The only difference is that the temp brush has a mask value of zero. The release version doesn't actually tell anything about the crash, because it happens during the exit procedure, it just maybe slows down the procedure for some reason. I think I already fixed the bug, at least the debug version no longer crashes. When you move the brush to pad I'm actually not sure if it stays as "temp" brush as well as a brush stored in the pad, in which case it could be deleted twice, although debug version doesn't give any kind of crash or error message.

 

[Krice]

I made an actual 'temp' brush pointer so it's easier to handle everything. 'current' pointer is now only pointing to either to an existing brush (list) or temp brush. There is still some pointer stuff going on which looks ugly, but I think it now works as supposed and there is no memory leak etc. You can also delete the temp brush if you want to. I'm still trying to figure out how to implement drag and move for brushes in the pad.

 

[Krice]

Trying to think how to implement paste resize and rotate. Dislike the idea of a widget, there has to be other way to do it. Maybe some kind of tools to rotate and resize, but they would also require some kind of widgets I guess, or maybe not. Resize and rotate for pixel art is hard enough, but overlaying a widget at least feels like even harder task. Maybe it's not that difficult.

 

[Krice]

I made a pattern mode for the stamp brush. It almost works, I think I know what is the problem. In pattern mode the brush doesn't slide with the mouse location, it draws the brush as a pattern so you can for example create a brick brush and draw an area with that brick pattern. It's not the most exciting feature, but it was surprisingly easy to implement so why not.

 

[Krice]

Big surprise even to myself, but I can't figure out how to implement that pattern feature. It should always start from 0,0 where you begin to draw, but how to update that offset when mouse is moving. I have the source location of the movement, it's already there.

 

[Krice]

This fails for some reason, I can't see what is the problem. The offset values seem to be ok, but the pattern breaks and it looks random, especially with both x and y axis movement. Am I missing something?

void Brush::Pattern_To(Painter &pnt, int x, int y, const Point &offset)
{
    const int br_w=Get_Width();
    const int br_h=Get_Height();

    int sx=offset.x % br_w;
    int sy=offset.y % br_h;

    //use individual pixels (color data) of the brush, but offset it to
    //create a pattern of that brush
    for (int dy=y; dy<y+br_h; dy++)
    {
        for (int dx=x; dx<x+br_w; dx++)
        {
            if (brush_data->mask->Is_Mask_Pixel(sx, sy))
            {
                Pixel px=Get_Drawing_Pixel
                    (dx, dy, brush_data->pixels->Get_Pixel(sx, sy),
                        pnt.pixels->Get_Pixel(dx, dy), Solid);
                pnt.Set_Pixel(dx, dy, px);
            }
            sx++;

            //wrap brush data around to draw as pattern
            if (sx>=br_w)
                sx=0;
        }
        
        sy++;
        if (sy>=br_h)
            sy=0;
    }
}

 

[Krice]

Thiis is one of those bugs... I tried to isolate the drawing routine, it does seem to work perfectly, but somehow mouse coordinates don't work with it. It's a mystery, since if mouse coordinates would give "wrong" location for the offset, it should be everywhere. I've noticed it does seem to break when there is both x and y mouse movement at the same time, but I can't see how it's different than just x or y movement, they both change the offset.

 

[Krice]

I'm trying to write undo/redo for copy/paste -operations, because they are not part of the undo system. It can be either a command or image undo, but copy/pastes are a separate class. Even trying to figure out how to write undo/redo for that is a head scratcher. It needs a new undo node type, so I have to make the current one an abstract class, because it can't hold the undo/paste data. Then I have to figure out if it's a command or image undo, because it's more like a command undo. In fact creating two different types of undos with their separate calling routines was a mistake in the first place. Maybe I need to fuse it to one generic undo system it should have been from the beginning, so regardless of what you undo/redo it just works.

 

[Krice]

Refactoring C++ is sometimes nice, because a reason many people whine about: inheritance. In this case when you have a class (Undo_Node), you can inherit from it if you need to create different types of objects, but they work with the same base class implementation through public interface, so there is no need to change routines that are using the class, because they don't notice anything, other than the creation of the object which now needs to be a derived class.

//Undo node stores command data and tile position.
class Undo_Node
{
    int redo_command;
    int undo_command;

protected:
    int tile_position;

public:
    Undo_Node(int c, int p);
    virtual ~Undo_Node() = 0;
  
    virtual void Action() = 0;
    void Post_Action();
    void Pre_Action();

    void Display(int x, int y);
    virtual void Display_Tile(int x, int y) = 0;
};

//This node is all other types than paste.
class ImageUndoNode : public Undo_Node
{
private:
    Masked_Tile *tile;

public:
    ImageUndoNode(int c, int p, Tile *ct, Tile *cm);
    ~ImageUndoNode();

    void Action();
    void Display_Tile(int x, int y);
};

//This node is for paste operations.
class PasteUndoNode : public Undo_Node
{
private:
    StaticPaste *paste;

public:
    PasteUndoNode(int c, int p, StaticPaste *s);
    ~PasteUndoNode();

    void Action();
    void Display_Tile(int x, int y);
};

 

[Krice]

I began to rewrite this for wxWidgets. I started from scratch basically, because it's impossible to cut and paste the code in many cases. Some data can be imported to the new project, like command data etc. The good thing is that wx obviously has gui code ready, so I don't have to worry about that. I don't yet know if it has some kind of useful canvas feature for drawing.