About this blog
A cool and ugly project + Side projects of an outsider
Entries in this blog
I entered the "Let Loose the Kraken!" contest, which was my first weekend contest and the first contest where I could really put myself there and do hard work.
I am very happy with the result, and that I managed to make (and simply get) ideal conditions for rapid development.
Ideal conditions involved unemployment and an understanding girlfriend, with whom I cold make the fact understood "long" before the contest, that for three total days, I would be absolutely unusable, sometimes pissed off, sometimes tired, that I would only be able to pay attention to programming.
I had a great luck with time too. The contest started in my country at 8 AM.... Three full workdays for the project without the need to break my sleeping routine.
So it ended up an intensive but quite friendly 12 hours per day developing.
I sketched up 5 ideas, 3D wasn't even considered, as I have never used an engine and 3D requires too much tweaking anyway (cameras, object sizes etc).
Luckily the sliding puzzle idea came up quite early. After maybe 1 hour of brainstorming. Making a puzzle was kind of default to me, I like puzzles, my girlfriend's parents always play with puzzles, and lately I was thinking about making a puzzle (a totally different kind). The simple ideas came rapidly, so in another 30 minutes I had all the game in my head.
Outline of the game:
The game is a level based sliding puzzle where you have to match the pieces of the Kraken's arms by sliding one row or column of the game-board at a time. All of the Kraken's arms must reach all the boat pieces to complete the level.
Idea is one thing, it has to be tested. Making a new kind of puzzle (maybe this type already exists, I don't know about it) can be risky in this time interval because if it's not that good, you can throw it out. But at least it's not as hard as prototyping a physics simulation thing or a 3D gameplay.
Luckily (for this project but not so otherwise) making games are always rapid prototyping for me (even if it's a proven concept like minesweeper), all the games I made were prototyped in max 2 days, so I have experience in that.
Throwing together the prototype was done in a half day with placeholder graphics for the cells. In this case, the prototype simple meant that I could slide the rows or columns in the game field, and see if it's interesting or boring, too easy or too hard, or is there a method the user can exploit that totally kills the challenge in the game. No winning conditions were examined, reaching a ship did absolutely nothing, the cells' images were just images.
There were quite amount of framework code lying around, as setting up an openGL window with the 2D projection, loading/uploading textures, font loading and rendering, generic mouse handling stuff, the windproc with the message loop, a ready to use Visual C++ project (these all mean I just used the skeleton of an old 2D editor I started but abandoned)
Prototyping involved hacking like crazy. I tend to hack but this time it was very embarrassing even for me.
I didn't expect to make decent art for this time interval. But it turned out I had plenty of time, and that I am quick with simple pixel-art. There was no time to try out ideas, but the themes were pretty default anyway. I admit I got some help by getting opinions about the finished images of each thingy, the opinions were about some colors only, otherwise it was "it's cute "
I used reference images, but just as a guide and only by eye. I mean I didn't manipulate or draw on top of the images. So the quick method was: draw the bulk of the image with a 6-8-10 pixel soft-edged brush (and refine curves by drawing with the background color), that gives you nice curves and smooth edges, then simply draw the outline pixel by pixel (on a different layer) in 10x zoom. It's easy to do as you can see the fading pixels and you can set up a vague mental threshold which pixels should be part of the outline. Then refill the shape with solid colors and get rid of the reference sketch.
The outlined, solid colored but semi-realistic objects in front of simple gradients Japanese style was the default choice, as I'm not good with lifelike smooth shaded or "cute characters" art.
I did the art as the "stepping away" part of programming and vice-versa.
There is no sound or music in this game, as I have never worked with those. But I don't think I would put sound in it anyway, because I guess most of us either listen to music or don't want sound at all.
The download link and some teaser images:
This little game turned out to be pretty good after playing with it for some time, I think I will make a polished releasable-to-the-wild game of it (and completely rewrite the thing). My girlfriend is testing the game "intensively" because she like it and she has ideas.
I don't think I will change the style, I like it Japanese (I will look into Japanese 'Kraken' mythologies and hope some kind exists...), but maybe some better frame and button style will be done. And more sets of textures for different resolutions.
Anyway, I soo needed this coding marathon as I hadn't done coding (apart from some random fixes for my portfolio) for more than half years. There's nothing like it.
I decided to use this entry as a surface for showing my programming experiences and portfolio in a brief summary for anyone who is interested. I know it's not the professional way to do so, but my profession is mechanical engineering anyway.
In advance, here are some links about some stuff I did and do:
I am proficient with the C language, we started with it in the University. I coded on DOS platform and now I code on Windows. I tried some other languages and made things with those, but I stayed with C. Programming is a hobby for me, but a very important one. It's on a par with my profession.
The story begins in the University (Faculty of Mechanical Engineering and Informatics,
University of Miskolc) in 2004, in the first semester, "Computer science I." course, C language.
I fell in love with programming. My first graphical homework program was one of the best in the course.
From now, I will only list the programs that I made outside the few courses we had. Most of them are learning projects, but there are some programs that I actually use or used a lot.
My first own program was a prime number searching text program, that automatically made a little log file and printed some statistics when its execution was aborted. When the program was launched again, the counting continued from the number in the log file, and the statistics were also loaded from it. A percentage indicator showed the process during execution. Basic input (the highest number, to which the program should check the numbers), input validation and file usage.
3rd Semester, Computer Graphics. That started my 3D and graphical "career".
This time, I started my first big (and longest lasting) game project, which I actually finished and polished. It is a Scorched Earth clone, a 2D turn-based artillery game with complex AI ("bot" type), graphical menus, color themes (256 color palette graphics), team play and free-for-all mode, mouse and keyboard input, in-game console, save/load game, popup windows, multiple weapons and shopping, cellular automata, effects, complex scoring and money management, and so on. The terrain is generated with random Bezier-curves.
I had to make two tools for the development: a graphical 16x16 bitmap sprite editor and a color palette editor.
I worked on this project (with pauses and other projects) for almost two years. We played with this game with friends for many hours.
Meanwhile I was exploring the 3D world with a small wire-frame display program with hard-coded vertex and edge data; and a 3D Bezier-curve editor. 4 viewports, one of them is 3D. The user could rotate and zoom the view, move one of the fixed number control points with simple keyboard interface.
Another "big" (learning) project parallel with Tank Wars was ray-casting. I could only use the 256 indexed color mode then (VGA), so it was limited. Anyway, everything came from my head, I reinvented everything apart from the rotation matrix. It has texture mapping, shadows, alpha mapping, Phong-shading (I didn't know what it was called that time), specular highlights, reflection and refraction. There was a static scene, where the user could "fly around" and make renders when pushed a key.
All the texture data were hard coded, but the models was generated by the program (sphere, cylinder, some boxes). Most of the features couldn't be applied to the same surfaces, because of the very limited range of colors.
This was a long lasting project too, so I made other stuff meanwhile. Some of the noteworthy:
A graphical minesweeper clone with mouse input. I made it mainly for learning, so the gamplay was polished and there was a very simple start menu, and save/load field features.
3D Rubik-cube manipulator. The sides could be rotated, rotating view, keyboard input.
I'm not sure when I was engaged in assembly programming, but it didn't last long. I needed that for speeding up my DOS applications. I didn't know that time, that assembly itself won't speed up my stuff...
Anyway, I made a small text viewer with the very basic text formatting features, like tabulator and newline, breaking wider-than-screen lines. It had a primitive syntax highlight feature: highlighting C++ style comments (//blah blah). It was only usable for small text files.
Windows and OpenGL Era
My first program outside the class (well, my homework for my class was again one of the best: a revolved surface editor, where the user could place the points, then press a button, to generate the revolved surface from it, displayed in wire-frame mode), so the first OGL program was of course the Rubik-cube program. The user could manipulate the cube (turn the faces). It had a small pop-up menu, 2x2x2 and 3x3x3 modes, planar shadow, mouse input. Simple, but finished (uses GLUT).
Tank simulator prototype
At first, it started to be a small learning program for texture mapping. It became a bit more... I started using GLUT, but soon I dropped GLUT because of it's limitations, and moved to Win32 programming.
It focuses more on physics than graphics.This stuff uses the Fixed Function Pipeline, but implemented some advanced stuff with it, like cascade shadow mapping.
Read the descriptions on Youtube under the videos about the features.
There were several small programs for trying things out, like environment-mapping.
We were introduced to this program on the "Numerical Methods" curse. It was very high-level for my "experiences" with other languages. It was extremely useful for me, it gave me a new, higher-level viewpoint of how applications work in a higher-level environment. This new experience led me to Win32 programming.
Outside of the class (well, my homework was far more than a homework again...), I made a small image viewer program, with zoom, pan, menu, etc.
I made a lot of small programs with it during the university, many of them were used by my classmates too for speeding up monotonous design tasks.
I liked Matlab very much and I'd be happy to do some serious work with it in the future.
Back to C, OpenGL and Win32:
This is a small, polished game, where you can scroll and zoom the large field. The windowed user interface was programmed from scratch.
Using the minesweeper "engine", I made a small game prototype of a game that looked promising when I fantasised about it. It turned out to be not so promising...
A little algorithmic exercise for the problem arisen a few times in the forums. See for example this.
For a little exercise, I made common beginner programs: Tetris, Snake, Breakout and a board game ("Brain Vita"). It was like a race, I was curious how much time it would take to make working prototypes. Well, Breakout and Tetris took about 5-5 hours, the other two took 1-1 hours.
For my job (Phobextools Ltd. 2011), I needed a Graphical CNC editor program. This program is very close to being finished, but my contract ended, so little bug-fixes, small improvements and the proper release never happened. Anyway, I actually used that program in a daily basis, so most of it was polished, and it just worked and did it's job. Other employees still use that program for work, and that is the most important. The application had to be too specific for the machine anyway.
You can read more about it in this Journal, for example here.
I didn't update the Journal about the project, above is an image of an earlier version (it has debugging info displayed, win32 status bar was added later).
Finally, the biggest project I'm working on:
the Paper Modeller. This is a modelling software for making paper models from 3D data. Paper modelling is one of my hobbies and this program is to aid it. I plan to release this program, because I found that most programs are either very expensive or aren't suitable for serious paper model makers.
I'm talking about the features, implementation, thoughts, etc. in this journal (http://www.gamedev.n...mmers-programs/).and this blog.
For a more focused version of my portfolio, click here!
Thanks for reading and feel free to comment!
I'm still ""building my life"" so I'm still not at my computer, so the Paper Modeller project is still on hold.
But one can play with LEGO wherever one wants, so I've built my first ever MOC (my own creation) trial truck. I used to play LEGO a lot when I was a kid (approximately 10 years ago) but I didn't build much stuff on my own then, and mainly models (I mean for the looks) or only smaller parts of mechanisms. I hadn't built anything since then before now.
So my first real MOC project and my first meeting with the "studless" building system (in opposition with the older studded system which I was familiar with) lasted 4 days. I only had two kits (and one older one, but I used only a few parts from it). At first, I didn't take the "project" seriously, it was just for killing some time.
Due to these factors and the complexity/counter-intuitiveness of the studless system, the machine is quite hacky at some places, rebuilding the stuff would be a nightmare. If I had double amount of pieces, I could rebuild the whole thing using the older iteration as a reference. Maybe I'll do something about it, maybe it's time to move on to another project/experiment (experimenting with different suspensions for example).
[size="3"]So das auto:
It is an off-road vehicle with four wheel drive. It is not motorized (so "doesn't move by itself"). But it has a 2 speed gearbox, real differentials with a central differential and differential lock, working V6 piston engine and live axle suspension. The live axle suspension is pretty common in vehicles, especially off-road vehicles. Mine uses Panhard rods and trailing arms.
Building LEGO machines requires very much thinking in advance. You have to keep pretty much every features in mind from the beginning. Well, I couldn't do that, so the steering is not complete. It can be steered with a knob at the top of the vehicle (which is very common in LEGO kits too), but the steering wheel doesn't work. I managed to build the drive-train to it, but it has so many gears that the internal friction makes the whole thing jammed. So I took out the final gear, so the steering wheel is only decoration.
I don't have enough pieces to reinforce the body, so it has a small torsion under stress.
I'm satisfied with the model, it's pretty good for a first project with not too big piece inventory to work with.
I made the mistake, that I didn't make the intent of the application clear in this journal, I just linked my old one.
Thanks Zarfius for the comments that made me reply and write down the "goals", now I can just copy it here.
[size="3"]The goals of the application
Due to my relatively poor English, I can't really use the term "goal". In my previous entry, I was talking about my "goals", in this paragraph, I'll write about the application's "goals" (what it does).
The program is for aiding paper modelling, which has nothing to do with computer games. So the main feature is precise unfolding polygon meshes (so it's not the same as UVW unwrapping). I know there are many programs and plug-ins for that, but all the programs I found during a small research was either not "to my liking" or was "expensive". Some of them have manual unfolding (polygon-by-polygon, which is very tedious), some of them are only suitable for low or very-low poly models, some of them produces crappy unfolded geometry or are tedious to work with. And as far as I saw, none of them take the thickness of the paper into account (which is 0.5 mm for the cardboard I worked with for example).
A main goal is to make an algorithm that produces the best output with the least input even with high-poly meshes. Easily and intuitively modifying the unfolded geometry is a must too. And of course printing/plotting the result with different line types and textures. Later I'll add more features, like modifying surfaces of the original 3D mesh to be unfoldable (it's hard to explain what I mean by that); making slices of the mesh for layered paper structures; automatic/manual adding of "flaps" to the edges to be glued together, maybe basic documentation tools like guidelines, arrows, numbers, comments, assembly drawings, etc.
More explanations in my old blog, I don't want to rewrite/copy the whole thing here.
Reused the code from the previous version, and added new features like
Progress is slow and doubts arose.
- automatic welding of unfolded vertices/edges
It's hard to explain why I need this. So see the first three images of an unfolded box. Second: with welding, third: without welding. You can see how the algorithm builds up the unfolded geometry.
- displaying the split (cut up) edges in the 3D view
and added an "unfold edges only" edge selection method. Of course, welded edges are not displayed
really just using the same texture coordinates as the original mesh
- sharp edges are rendered as broken lines
- triangle identifier numbers on 3D and unfold geometry
This is just the beginning. I plan to add a lot of other and powerful features to it to generate much nicer geometry that needs fewer further manipulation.
And of course taking the thickness of the paper into account. That will be a huge pain in the ass. Maybe I should start with a *perfect* shell generation algorithm (offsetting the faces). Well, even 3ds MAX cannot do that....
You can read more about the algorithm if you like, here.
I played (struggled) with it a lot, programming-wise. With the help of Gamedev of course. Now it has expandable/shrinkable groupboxes, and the whole "Right Panel" is scrollable with left mouse button drag. It still flickers (I didn't dare to use WS_EX_COMPOSITED style for the panel), but (IMHO) feels/looks quite slick. And it will be helpful in the near future, because I still haven't bought a new monitor, and the current has an approx 200x200 pixel dead area at the botton-right corner.
Of course, it's far from finished/polished, but at least I can forget about it for a while.
Or whatevers... I still have no idea about the mechanics of the editor. Especially the mechanics of unfolding.
I unfold the geometry, then I edit the unfolded geometry, then I press unfold again, and Bam! all the editing is lost. Or maybe every unfolding should go on a new "Sheet"? (if the user wants of course). After unfolding, the 3D and the unfolded geometry should be totally separately handled? What about other stuff in the future? When I add new meshes, like layered things of the 3D mesh? How about importing new meshes?
Maybe the user could select which sheet the new unfolding should go, and override the unfolded geometry on that sheet?
So a lot of brainstorming and design is ahead of me.
The first three demonstrates the welding stuff. The box is segmented only for testing this feature.
The other seven images are about the unfolding of the car model, modified by edge selection. The algorithm splits (cuts) the geometry at selected edges. It took me about ten minutes to make it (excluding 3D modelling). I tried two variations for the roof.
The last three shows the GUI.
The main causes of doubts is the serious lack of knowledge and the unclear goals of the whole "project".
My former tool programming projects had clear goals: to make something useful for me and for a very certain, special task where an unfinished but working application is enough. Those goals were achieved pretty damn well in my opinion. I could make tools (the "DNC Editor" for example) that speeded up and facilitated work by orders of magnitude. They weren't finished, they had bugs, sometimes they crashed, they worked only on the target computer but that was enough.
This "project" has no clear goals.
There can be two main goals: making something useful for special tasks and a certain group like tools for game development in some cases, or making an application that's useful for the public.
Maybe it isn't worth a journal entry, but I successfully implemented the automatic smoothing generation feature for shading the models. It was a necessary visual feature (totally smooth or totally faceted display was not only ugly, but disturbed the spatial sense too) but it was also important for editing/unfolding.
- useful for special tasks and a certain group: the problem with this goal that this tool would not be so useful for me or for a certain group. I will not make paper models, at least not in the near future (near <= 5 years) and I don't know any certain "groups" that would do so.
- useful for the public: the problem with this goal is that it requires a finished, polished product, and I simply do not have the knowledge to produce one. It's much harder (in my opinion) to produce a good tool for the public than a game. Just think about the GUI (maybe that's the most important thing to get right).
And unfortunately I don't have the drive to do what it takes to produce a finished tool: to learn. I think I'd need at very least one year of intensive learning, for which I don't have the time, the mood etc [size="1"](I'm a mechanical engineer, and 8 hours per day of brainwork is just enough for me).
So, the whole project pretty much hangs in the void with a minor goal: to have some fun. But honestly, digging myself into MSDN, crying over my total lack of knowledge about memory management, etc is NOT that fun.
The fun is in the algorithms, the GUI layout and input/selection/edit features etc. Maybe a more suitable area would be the design for me and it would be better to be part of a team.
Anyhoo, about the progress of Paper Modeller:
I managed to fix the smoothing algorithm I mentioned in my previous entry: smoothing non-continuous surfaces. That's was a pretty hard task, but I also managed to "optimize" the algorithm while at it, so despite the more calculation needed for handling non-continuous surfaces, the algorithm is twice as fast in average. I even made a test mesh for it: screenie
I made a basic, context dependent GUI, which is (by chance) very similar to 3ds Max's right side toolbar. I have lots of glitches with the GUI, it will be a lot of work to get it right (programming and "user experience"-wise). But at least I can move on and I don't have to shit around with ""hotkey"" input.
Reimplemented selection and added some new features. I think my "biggest strength" is the ability to introduce useful features (if it is an ability at all...), so in the end, I think I have some pretty useful selection stuff (maybe more useful than Max's).
Implemented "sheet selection", so different sheets (where the unfolded geometry will be put) can be selected for display and for editing. It's much like the upside down tabs in AutoCAD like software than 3ds Max's multi-viewport layout.
The main problem with it that it's a bit out of place: it's openGL rendered, self implemented stuff, not a win32 widget thing.
Maybe I'm just being pessimistic.
That's pretty much it for now, screenies:
Smoothing is usually controlled through smoothing groups.
Smoothing groups are polygon/triangle based: every triangles have one or multiple smoothing group ID:s which control the vertex normal calculation: which triangle normals should be used for calculating the final interpolated vertex normal. The ID:s can be assigned in multiple ways (I guess every mayor 3D modelling applications support that), manually assigning values or "auto smooth" features with angle threshold.
It is important to note that .obj format doesn't support multiple smoothing group ID:s per triangle (or at least some exporters doesn't).
My approach is different: the automatic smoothing generation is edge based. That means in some cases the output of my algorithm and triangle/polygon based algorithms will differ even with the same angle threshold (see first image: the windows of the car).
This approach suits better the needs of a paper modeller, where some sharp edges are need to be perforated or etched before bending. These bend-edges are displayed too (see images below), and will affect the automatic unfolding feature. It will be possible to manually define bend-edges too.
The algorithm starts with simply detecting bend-edges (by the angle of the two side triangles), then comes the ugliest son-of-a-bitch hacked algorithm ever, it's such an ugly bitch that I even made a screenie about it:
It works nicely but in some degenerate cases it doesn't give good results (shared vertex but non-continuous surface), I'll deal with it some time...
See the screenshots with different angle thresholds below.
Some smaller stuff: I managed to use DevIL for loading images as textures, thanks for the posts in the other entry and Gaiiden for putting some focus on that entry!
Added "zoom to extent" feature, and vertex normal display (it's only useful for debugging the smoothing).
Replaced the jaw/pitch camera rotation to "arcball" rotation (or whatever it's called..).
Next: *sigh* selection and undo/redo *sigh*. I'll dig myself into Aardvajk's journal....
Maybe some refractoring too *sigh*
I decided to make an entries about the progress with screenshots. So here it ising:
(a power out killed my well parsed literature masterpiece so I have to rewrite the post but in a simpler way):
So, I'll try to exploit unemployment and work on the paper modeller again. That means restarting from scratch again, reusing pure functions (yeah, I have some of those!!!!44).
- window + menubar (only decoration yet)
- 3D grid + basic camera control (rotate, zoom, pan, dolly)
- coordinate system icon
- wavefront .obj loading
- vertex data
- face data: with polygons, to preserve "edge flow" which is a very important thing in polygon modelling. But polygons are converted to triangle fans, polygon stuff will be maintained through the edges (selectable/non-selectable or visible/non-visible).
- vertex normal calculation: I don't think I'll bother with smoothing groups, the mesh should be split accordingly. I use the angles between the incoming edges as the weights of the triangle normals, I think that gives the best results. The loader always recalculates vertex normals and ignores normal data in the .obj file.
- smooth + vertex display of the meshThe next things would be texture data loading, splitting the mesh according to the texture coordinates (so only one indexing, geez I don't speak English).
Or not, I'm not sure yet. spliting the mesh would probably screw unfolding, and the user wouldn't know why. So maybe I should only split the mesh for render, if I ever implement vertex buffer whatevers.
And of course loading the texture(s). *sigh*, I have to look for an image loader library for C. And atlas the textures *sigh*.
Sorry for the crap language, the former version was better (...)
EDITED some typos...
I'll try to discipline myself again and write better code, but I guess I'll fail again. I even fell with the very first step: I just can't think of a way to avoid using globals with WindProc (and the number will grow, since it's an event based program).
The CNC file editor was a great experience, I learned a lot with it.
Fucking boring journal post.
Anyhoo, I'll do my best (...) to be a programmer this time.
Well, not MMORPG but genius 2D game idea anyway.
The [font="Comic Sans MS"][size="7"][color="#ff0000"]P[color="#0000ff"]i[/color]s[color="#708090"]s[/color]i[color="#ffff00"]n[/color][color="#ff00ff"]g[/color] [color="#800080"]i[/color]n e[color="#00ffff"]a[/color]rt[color="#afeeee"]h[/color][color="#008000"]q[/color]u[color="#00ff00"]a[/color][color="#2e8b57"]k[/color]e[/color][/font] ftw.
You are a little kid called Timmy or Ricky or whatever, whose mother is a cleaning maniac. Little Timmy/whoever needs to piss, but an earthquake happens! The mission is to piss into the toilet and let as few drops of pee fall outside the toilet as possible. The pissing force and the angle is controlled real time by the mouse position (by dragging an arrow), while it's possible to walk and jump around. The pee would be simulated as accurately as possible.
If There's too much pee outside the toilet, Timmy's mom will slap him on his face and game over! The game would be level based. Harder levels mean more obstacles, moving objects like cats or whatever, more pee, things fall in the way of the pee, Timmy is further away from the toiled etc. As Timmy empties his pee, the velocity decreases, and finally, the pee will only come in bursts rather randomly and then just dripping at the end (we all know this thing...).
A possible improvement would be to add running to the toilet: a timer, while Timmy can hold back his pee, then if he runs out of time, pee would spray randomly, which would make the game even harder (since too much would be out of the toilet already). If the mouse is released, piss stops coming (need to improve this part of the idea), but the timer would restart again.
So! If anyone is interested in the idea, go ahead and steal it! (I'll be pretty pissed if you make trillions with this, but ftw)
Note: I'm not fully serious here (I just had the idea 10 minutes ago), and I'm in work obviously and my employer is wondering why I am giggling and [size="1"]drooling[size="1"] like a retard kid....
Limited Undo Levels
This is an important feature to avoid the overflow of the command buffer, and because a very large number of undo limit can slow down the execution of undo/redo horribly due to the command pattern stuff (because a lot of commands can't be reversed).
Undo limiting means if the undo number limit (defined by the user) is reached or the command buffer is too small, the first command(s) from the queue has to be executed on the old data and has to be deleted from the queue.
The size of a command is computed before adding it to the queue, then the first commands in the queue are executed/deleted as many times as it's needed to free enough space in the queue. After that the command is added to the queue.
The queue uses memory mapped files, so it only uses the smallest necessary system memory (in 128 kb granularity).
I was always afraid of it. But it's so easy to use! (if you don't give a shit about neat code, nice design, and just get it done).
So, I've added a menubar, with some options window, and my favourite, a sort of undo manager, I don't know how to name it. It's a listbox with all the command names in the command queue, so the user can undo/redo multiple commands at a time. The undoed commands are highlighted, so it's pretty easy and straightforward to use.
Adding menus was a necessary step, because I was running out of hotkeys....
The next step is a toolbar, but I don't really feel like drawing all the little icons.
Added some new features, like scaling, and some others too.
I added Undo/Redo functionality.
There are unlimited levels of undo/redo at the moment, I'll have to add limitations as the next step (buffer override, performance issues)
The system uses a command queue system. The command queue is simply a big buffer (statically allocated 5 MB at the moment, I will change that to "Memory Mapped Files" later).
The command structure contains the size of the command, the type of the command and simply the arguments. Arguments can be anything, ints/doubles/string (from clipboard for example). Everything is just pushed into the queue. The queue """manager""" is just a huge switch statement, so I am not limited, I can push whatever I want and however I want into the queue. All I have to do is read the data in the same order.
The data is duplicated ("old"/"current") at startup/load: the old (loaded from file, for example) state is saved. The current data is updated at every command with the last command in the queue. The old data is unaffected. At Undo, all the commands except for the last one are executed on the old data. The command structure is not deleted from the queue so it's possible to Redo. If a new command is issued after Undoing, the commands after (and with) the undone command are deleted. (well, not actually deleted, but the end of queue pointer is adjusted, so they will be overwritten).
Later, when limiting the undo levels, the old data has to be updated with the first command in the queue, and the first command has to be deleted from the queue (only if the undo limit is reached, of course). It will be hard to implement because of the shitty design: global variables... I have to rewrite every editing functions....
This whole thing took about 10 hours to implement (I had to rewrite every functions for the command pattern)
My job as programmer
I overestimated my ability to do intellectual work in full time then intellectual work for another few hours a day. And my weekends will be "troublesome" (girl). I could do the job, but not this way, so I cancelled it in time.
Well, I started a topic in the Breaking in about algorithm programming possibilities and employment. Guess what? I've got a contract job as an algorithm programmer! It's just a 1,5 month term thing for fair amount of money (at least in Hungary: about 300 euros). The task is interesting image processing stuff, I can't tell you more (privacy). If I do it well, I can get a longer term contract (which I won't accept, because I have other and this time more important plans).
That means I have to put both editor projects on hold, because I'm doing it in my free time.
So: Am I a real programmer now?
I haven't worked on the "project" too intensively (because I worked with it intensively) but I managed to optimize the thing, so it's lightning fast now. I optimized it by using two dimension array to store the file like I mentioned previously. I can do that, because the specifications say that the max linelength of the G-code is 256 (or less in case of older implementations, I found that 70 is the minimum). Maybe that means a lot of wasted memory, but the 10-20 times faster parsing is totally worth it.
I fixed lots of bugs (and left even more), reworked the state machine (the former was a joke: every edit feature had it's own state variable. Total crap), some refractoring. It's easier to polish a program, if you are actually working with it and it's not just some toy.
I added new and pretty useful features, such as:
I think this is becoming a pretty useful and cool tool (I mean the CNC editor). I guess there are some features that are not very common.
- Snap to point
- Cycle between overlapping points for selection
- Rotate selected with center point - reference point - new direction
- Mirror selected Vertical/horizontal constrains work with these too
- Set start/depart of selected sequence
- Some special features for my need:
- Display foam (the stuff the machine cuts)
- Set foam position and size
- Toggle tool-swept path: it would be easier to explain if I spoke English. So the hot wire melts the foam, and it melts in a much bigger diameter than the diameter of the wire. And that's a very important info for stable cutting, for designing trajectories for small surface features, etc
- Windowing: I added dialogs for text/number imput. Such as setting feedrates, entering comment text etc. Message boxes.
- Better file stuff: save/save as/open/new works pretty much like in other programs
- Data type-in: If the user hits enter during certain commands, values can be typed into a dialog box instead of clicking with the mouse in the editor. Offset values for moving, angle for rotation, insertion coordinates, etc.
- Feed system reworked. There are no default feeds, all feed values are loaded from the CNC file and the user can only assign those loaded values. However, the user can define new feed values and redefine existing ones (obviously, the data is updated accordingly). I found this system to be quite intuitive (much more intuitive than making all the feeds accessible and with some hard coded default values that totally fucked up the whole thing when loading the values form the CNC files on top of this "feed table". And better, if there weren't any pre-defined feeds and feedrates were just thrown around without control). The only flaw is that gradual feed changes cannot be used (or have to be edited manually)
- Calculating total machine time
- Progress bar...One very important thing is still missing: Undo/Redo. That will be the next big and unavoidable step.
Note, that the help text inside the program is OFF, the "manual" is the right thing.
The Mechanics may be a bit strange. The selection is based on a "starting point" (from now: "sp") and an "end point" ("ep"). So only a continuous sequence can be selected. I don't know if I'll alter it in the future to be able to select multiple sequences. For some features like delete and move it would be useful, but a CNC code is a sequence after all. For example: how/where would I copy/paste multiple sequences? Anyway, the "sp" can be selected with left click, the "ep" with shift+left click. The selection remains, until another point is clicked or esc is pressed. (so no "deselection" on every clicks, it's just like in most CAD software).
Some features behave differently if only the "sp" or only the "ep" or both/neither of them are selected. Most of the time the place of the effect varies. Before "starting point", after "end point", between them, or after the last point.
(the different effects will be listed like this: only the "sp", only the "ep", both, neither of them)
For some reason my hot shit project blog doesn't get the audience she deserves.
- basic constrains: when moving stuff and pressing 'shift', the movement will be constrained in a vertical/horizontal line depending on the mouse position.
- adding a point: before "sp", after "ep", after "sp", after last point. Snapping to grid (0.01 mm step) can be toggled. The adding feature has the basic constrains and
- tangential constrain: collinear with first segment after "sp", collinear with last segment before "ep", collinear with first segment before "sp", collinear with last segment. And
- cross constrain: the point will be placed at the intersection of the two lines that are the neighbours of the segment where the point is inserted
- reverse direction of selected sequence
- reduce point count on selected sequence
- set feed rates: only "sp" selected: simply inserts a F... command at that point, both selected: inserts a F.. command at "sp", clears all other F... commands from the sequence, inserts a F.... with the appropriate value after "ep" (the last feed rate change before "ep")
- remove close points: removes all points that are too close to each other (in the sequence, not in absolute coordinates)
- round all points: al points are rounded (floor/ceil/to closest) to a certain value (this will be used to test the interference between the precision of the machine and the CNC file's values)
- Clipboarding features: paste before "sp", after "ep", replace selection, paste after last point
- Copy with base point/paste at mouse position
- can start from an empty project: add points with the add command
- Some eye candy features:
- the direction of the sequence is displayed when selected: a small arrow. This arrow implies the line for the tangential constrain too
- the segment where the new point will be inserted is highlighted
- a little ruler with the measure is displayed
- legend with feedrates (my favourite)
These are pretty much everything I needed. There's a main issue though: it's very slow. So much string parsing/reparsing/seeking all the time. Sometimes the application needs to parse 20000 points, that can be 25000 lines of code. Just a regular CNC program. But I don't think that's too much. But it takes about 4-5 seconds just to parse the whole text. Not to mention other operations: parsing+manipulating+reparsing etc etc. I need to do something about this, because it's more than annoying unfortunately. The problem is that the lines in the text vary in length (a line is between two '\n' characters). Maybe I will drop the original idea to just store the whole file in a one dimension array. I think I have to use 2 dimensions, flags pointers and other shit to avoid parsing if possible.
But at least I can work with it. Except for the speed issue it's very good and fast to work with. I could make a program in 15 minutes with it, before that it took a whole day in stressed attention. Just to put together the final program from the pieces. Of course the time to draw the lines with CAD isn't affected. Making a CAD software would be too great job (well, not that great just a lot of time). But I can even make simple programs from starch without the need to make the stuff in some vector editor first.
Anyway, [size="4"]Here it ising
[size="7"]here it ising
(it's pretty abandoned at the moment, but the whole point of this """"journal"""" is to let you all know I'm the mostest awesomest guy).
Maybe I'll get back to it again, I made a little side-project to warm up a bit. It took 3 days, maybe I'll expand it to a pretty usable tool.
It is a graphical G code (.Dnc) editor I made to speed up my CNC related work. I looked for free programs on the net, but I couldn't find any that did the things I wanted in the way I wanted.
The main issue is that I use a program called "DeskCNC", which is a very cool tool, but it's CNC editing features are not so cool (CNC means um.... Computer[size="1"]something Numerical Control. It's an engineering stuff). The main thing it misses, that it can only work with non-intersecting closed polygons, it simply cannot generate the CNC program (G code) for non-closed polylines and intersecting stuff. But the problem is that I need very tricky trajectories (it is for a hot-wire foam-cutter machine). So I need to break the desired trajectory to pieces and complete them to a closed loop (with a CAD software). That means I have separate files that can be loaded by DeskCNC, and their G codes can be generated (separate files of course)
Until now, I had to open the .Dnc files with notepad and edit them manually: copying together, adding different feedrates etc etc which took awkwardly long time (some files were 1MB...).
So I wrote my own tool to do the things I want: manipulating the code graphically, copying, pasting, deleting, moving sequences, adding points, reducing the number of points (because the accuracy of the dnc file generated by DeskCNC is much better, than the actual machine (stepper motors), which produce some artefacts on the cut surface), adding feedrates/comments etc.
Well, three days of coding (approx 30-35 hours), and I have everything I wanted (except for one small bug I made a thread about on gamedev).
The program works with the G code, and manipulates that, so the commets/empty lines etc never get lost. The vertex data, that's parsed from the text is only there for display and selection. At his time, the text is always re-parsed every time the length of the stuff is affected (line deleted, added etc). This is quite slow, I will have to use a much smarter design and manipulate the vertex data and the text synchronously.
It has a nice feature: the sequences are coloured according to the feedrates.
I'm quite happy with it, but it has its limitations of course: