Brick Atelier

[Krice]

Still interested: How do you keep motivation working on very long projects?

I don't. I'm doing this because I like programming, and also game design in a way. If you like something you don't need any "motivation" to do it.

So, I refac... changed the way brush is moved to the pad. It made more sense to use the current brush as a temporary which you can then move to the pad if you want. Previously the brush was moved to the pad when you copied it from the selection, but I realized the pad would just fill up and it could be tedious to remove brushes from it. However, remember what I said about saving and loading? Eh.. I don't have save and load for this kind of situation. Tiles are saved as a tileset, with old school byte save directly to a file. I may need something more advaced for this. Maybe it's time to look for some kind of library that can compress files while at it. Just not a big fan of using external libraries.

 

[Moaning_Clock]

I don't. I'm doing this because I like programming, and also game design in a way. If you like something you don't need any "motivation" to do it.

I like programming and game design and many other aspects of gamedev as well but after a while I like to work on new games and I need more breaks to finish the game.

 

[Krice]

but after a while I like to work on new games and I need more breaks to finish the game.

It does get boring to work on only one project, that's why I have Brick and also four main game projects. I didn't use to have, but when I was programming Teemu (for a 7 day roguelike challenge) I found out it's useful to have a smaller roguelike project where it's easier to try out stuff. But motivation is interesting thing, because for some things you don't really need any motivation, in fact it could be the opposite, you need to restrain yourself from doing too much. This happens to me in the gym, I could exercise every day, but it's not healthy. I need to actively stay away from the gym and take couple of recovery days after training.

 

[Krice]

Save and load for the pad is ready for the pad data. I have been using a custom file format for save and load, but it didn't know how to save tiles. But it wasn't hard to add a routine for them, because tiles are just RGBA data, 8 bit per channel. The block is saved as an array and restored the same way, so the individual values are not separated with , as in other values (the format is text based mainly). It should work, but needs some testing.

 

[Krice]

I think paste is going to have three options, because it's possible to implement it in this way. So first one is when you switch the paste (move) tool away it will copy the pixels, the second one is that the area will stay as active paste, but it's invisible, and the third could be that the pasted area stays on top of everything else, which is something I have to test if it actually works with all the tools as expected. But there are those more esoteric ways to handle paste. Also, since I was planning to create a list of recent pastes I'll try to implement it as well. I don't know how useful it is though...

 

[Krice]

Options for paste were surprisingly easy to implement, even the fixed mode works, because the floating paste is its own thing. I do have to check what happens if there already is a paste and you paste again, it seems to work ok, but something fishy could be happening there.

Screenshot from the current version:

 

[Krice]

The list of copies works, too. Seems like a good idea that you can select older copies to paste. The next somewhat big feature is the color/palette editor. Or maybe just a palette editor, because I can add number input to that Handles pane.

 

[Krice]

I now have a plan for the color editor which is always a great idea. I didn't add number input to handles, because they woudln't fit without making everything else wider which is another "weird" problem when you design a gui. Instead of number input I placed arrows left and right to increase RGBA values by one, and a center icon to center the value. It's maybe not the most useful feature, but whatever. The color editor is going to have the number input and some other stuff. The main idea of the color (or maybe it's better call it palette editor) editor is that you can select a palette and edit palette colors, each palette having max 32 colors. The most tedious thing will be creating palettes and color database. I don't think palettes are copyright stuff per se, but you never know so have to be careful copying palettes from the interwebs.

 

[Krice]

Already having trouble with the second palette (first one is EGA, it's hard to get it wrong) which is MSX's palette. I found two palettes which of course are a bit different, but they both have the same colors. I'm just thinking about that palette, was it really the same for all games, no way? Or is it the default palette. It's such a weird palette, it has three reds, greens and blues, but no dark blue or bright red colors, or even bright yellow. I guess I really need to check out screenshots from games, although they are from emulators mostly.

 

[Krice]

Color editor has a funny user interface "problem" I guess, because you can edit and choose the palette, but you should also be able to set the color, either right or left mouse button color. But sometimes you maybe don't want to change the drawing color. Or maybe I should just remove that option and make it only for palette editing. But if you want to use the color then you need to add it to the palette first, which isn't always that practical. I think one way to do this is break sacred GUI conventions and set the color outside the dialog when you click the color.

 

[Krice]

The color editor is "ready" in theory, just have to get the button events to set right or left color. Then I have to add colors to the database and create some palettes. The solution to set the color optionally with "left" and "right" buttons is not what I could call pretty, but I guess it works.

 

[Krice]

There is a color list in Wikipedia, but I don't know, it somehow looks suspicious? Well I guess it's better than nothing. I could also add colors to database by their "true" luminosity or lightness, but for that I would need a routine to calculate it. Anyone knows how to do that? You know, considering stuff like blue color is less luminous than red even they have the same component value.

I'm not going to make the release any kind of stressful situation, maybe just go through everything and check if there is something badly broken and fix it before release. I know undo/redo doesn't probably work for cut-paste right now, but I don't care.

Edit: I did find lots of discussion about the luminance and was able to code a routine from that information, although the theory is beyond my understanding. But it seems to actually work, I think.

 

[Krice]

There is one final thing I want to add and it's exporting to a png, because at the moment there is no export whatsoever and if you want to use the tiles you need to write a custom loader for the tile format I'm using. It's not difficult (pixels are in raw format with a small header data), but still I would argue png export is a better idea.

 

[Krice]

The export gui blob is the image viewer I was working on, I just added a condition to run it in export mode which adds Ok and Cancel buttons. It did require another custom event loop, because you should be able to scroll the image if it's larger than the blob's content size. Luckily I found an easy way to implement scrolling by using SDL's clipping feature you can set when you display an image. Now the export only needs a windows file dialog call and maybe check if the file exists to overwrite it.

 

[Krice]

I think all the features are ok, now it's just fixing bugs and while fixing them finding new ones. Export wants to add .bmp to the full filename which becomes file.wst.bmp so there is one bug to fix already. SDL2 can only save .bmp format, but it's fine I guess.

 

[Krice]

Selection work tool doesn't undo or redo, but I'm going to leave it, it's probably too difficult to fix quickly. Export name bug is quite annoying, because the file dialog routine is overly complex. It's the data exchange between Windows file dialog and the program which makes it like that, but it can be fixed, it's just really tedious.

 

[Krice]

It was tedious, but now Windows file dialog part works more like a function than a class, it takes in the Filename data and changes the filename if it's selected/changed. Of course, I found out that Save As... has a bug where it does nothing in some cases. And the export file has to be saved actually, after selecting the name.

 

[Krice]

Export is finally done. I've been checking some stuff like debug routines and now options. There are 11 options and 4 of them didn't work. Fixed the easiest one of them which didn't check the shadow brush option. The option to set the alpha grid size for both width and height seems to be quite difficult to fix, because it "should" work and I can't get it. It only fails if width and height are different size, if they are equal it works fine.

 

[Krice]

There is only one known bug I want to fix before release, it's the retrace from seam tool when you switch to another tile. This is no longer an option, because you can't store or use the seam position in any meaningful way anyway. Next in the checklist were destructors and there were some missing deletes as always, mostly in containers. The checklist is now empty... I'm leaving some bugs on purpose, because I don't have the energy to fix them right now and they are not bugs that would crash the program.

 

[Krice]

I'm trying to find any info about what if any .dlls you should include if you are using MSVC to compile and including windows.h. I think all C++ compilers have this same problem, when you should just be able to statically link everything. When I look at debug - view modules there is a shitload of dlls the program is using. I don't know if you could somehow reduce the amount of that from some settings, because from Windows stuff this is only using the file dialog.

 

[Krice]

I got a bit frustrated about Visual Studio and did what I always do is that I make a C::B project and compile the project in GCC. It just works. I had to fix only two things GCC found, the first one was a missing cmath for floor function and the second one was a shadowing parameter for a constructor. Not bad for a project that has 20K lines of code. Now when it's compiled in -O2 optimization and no debug stuff I should maybe first test it for a while before release. Some memory related bugs may be visible now.

 

[Krice]

I guess the only problem with compiling in gcc are license issues. As far as I can understand you can ship closed source program with the basic libraries like libgcc etc. without also releasing your source code, because GPL is so ridiculous that it would have otherwise created a negative impact on that project. However I don't think you can statically link parts of even libgcc without "breaking" their rules.

I was also finally, after 100 hours of research, able to compile in Visual Studio Release mode. The only problem I had was an old meme that you should (for whatever reason) ignore msvcrt.lib in the project. The funny thing was that VS is using msvcrtd (debug version) in Debug mode, so that ignore had no effect for years... until I switched to Release mode, then I got bunch of linker errors telling I don't have stuff like memmove, or even new or delete, declared. That stuff is I guess in msvcrt.lib which is automatically linked if you don't use NODEFAULTLIB setting. That took like so much time and effort to figure out, because apparently NO ONE (except me) is using SDL2 and has never had that issue. The problem with MSVC compiled .exe is that you probably need some .dlls which could or could not be in the user's computer. Let's add that the reason I'm using Release mode is that Micro$oft, for some idiotic reason, don't allow you to release a program with debug libraries. Like, why, why the fuck not?

So each piece of shit compiler has their own specific problems.

 

[Krice]

The final touch before release was to figure out how to remove the popup console window, which is to set the subsystem to Windows app. Even if you have a regular main (not winmain) and you include sdl.h, it will replace the main with macro that works with Windows app style. Anyway, I think and hope everything is more or less ok. Known bugs can be found in readme.txt if you want to try this piece of.. art.

https://www.kriceland.fi/brick/

 

[Krice]

I tried to join PixelJoint forums to tell about this software, but it was worse than 2FA. You need to have some kind of points from a gallery(?) before you can post messages. What gallery, what points? Then I tried to send them feedback, but it took me to Discord page which I closed and that was my adventure in PixelJoint. Do they really have that many spam users if they need that kind of crap?

 

[ds]

I guess the only problem with compiling in gcc are license issues. As far as I can understand you can ship closed source program with the basic libraries like libgcc etc. without also releasing your source code, because GPL is so ridiculous that it would have otherwise created a negative impact on that project. However I don't think you can statically link parts of even libgcc without "breaking" their rules.

libgcc, libstdc++ etc. specifically have an exception to allow statically linking in non-GPL code:

You have permission to propagate a work of Target Code formed by
combining the Runtime Library with Independent Modules, even if such
propagation would otherwise violate the terms of GPLv3, provided that
all Target Code was generated by Eligible Compilation Processes. You
may then convey such a combination under terms of your choice,
consistent with the licensing of the Independent Modules.

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.