kibiblog :3

I've just started trying this out. At the moment this is more a proof of concept than anything else. All the same, I'll give it a shot.

Today I spent a great deal of time working on quietude (you can find it on my github!). One mildly frustrating aspect of C that I'm still wrapping my head around is the way parameters and return values are treated in functions. As far as I can tell, function parameters never leave the function scope. For instance, in the case of the following:

In other news, I nabbed the neocities CLI. It works like a charm (even if the github repo that arch uses is dreadfully outdated and I had to spend more time than I can excuse tracking down its current version. (for those in a similar boat, get the package from ruby from your package manager and then run gem install ruby. don't forget to update your PATH!)). It's dreadfully elegant and there's even a post on the main neocities site that helps one set up a git hook that automatically pushes updates to neocities whenever git push is called.

I think that'll be all for today. Bye <3

Memory is such a miserable thing. The concept of making sure that there's only ever one reference to a given piece of memory (or, naturally, otherwise heavily documenting exceptions to this rule) does certainly make sense! While working on Q today I was rewriting a bunch of stuff because I misunderstood splint's /*@shared@*/ annotation. Tragically it refers to proper garbage collection environments, which Q most certainly is not. This means I've had to purge this annotation from my program and (most especially) header files. Sad! Not of course that I don't appreciate this; already my stricter approach has helped me spot a potential memory leak that wasn't being handled properly. There's just so much work and learning that goes into it, I suppose.

I got together with a new girl last night. Pretty awesome if you ask me.

In other news! I finally finished making all of the Q modules manage their memory in a less leak-prone fashion. Exciting! There's just really so much thought that goes into it. Of course I was perhaps working at a disadvantage having not realised that a simple way to dispose of a reference is merely to reassign it to NULL. So it goes! With that under my toolbelt and a greater understanding of splint's annotation system I'm in wonderful shape.

Though really I am just awfully exciting to get back to work on the qwalk module. It's a module that's much more closer to the fundamental gameplay which is a very, very welcome reprieve from the abstracted-upon-abstracted nonsense I've hitherto had to put up with! It'll be the main meat of Q in that it's the section where you walk around. The plan is for this to comprise the plurality (if not majority) of gameplay, so I'm anxious to get it right but also eager to start on it in any case. All I hope is that I can depend on qwalk, qattr, qfile, and mode going forward. Doubtless I will have to tweak them in the future but I only hope that those tweaks are minimal. Or failing that that I at least get a break from larger-scale tweaks. They really kill me, you know! I so hunger to work on the meat of the game and see and feel more tangible results, rather than interfaces which interface with interfaces which interface with interfaces which interface with interfaces which interface with interfaces...

Hopefully going to make this one quick! I've stuff to do and spent ages with Q today.

To begin, I finally (actually this time!) finished the rough draft of qwalk. Some three quarters of today's work were spent fixing the logic in qwalk_logic_obj_move(). The trouble was, I realised that, because certain objects could move (e.g. the player!) we could have the same square occupied by multiple objects. This much is actually acceptable! However, what I didn't consider until just earlier was that, because the amount of QwalkObj_t instances in a QwalkLayer_t is strictly fixed against QWALK_LAYER_SIZE, to have a number of elements that exceeds that even by one would yield either a segfault or merely ignore whatever the final element to be added was. Because of this, I had to make a conceptual split of the play area into two layers, layer_earth and layer_floater. The former is the ground (or earth) itself, and the latter the layer for objects which float above the earth, or alternatively sit upon it. I had to add some new functions (both static and extern!) in order to account for this change.

That final quarter of my time was spent debugging qwalk. I only got so far as managing to get it to compile without any warnings or errors (no small feat considering I use a number of gcc's -W flags in my Makefile). In any case, what awaits me now is... shudders... linting....

Au revoir!

Great news! qwalk's logic submodule is finally more or less complete. There are still a few more tweaks that I can only really know how to make in hindsight (i.e., when the rest of the module is completed) but for now I'm quite happy with it.

That, dreadfully, is where my happiness ends. splint is quite frustrating. I've spend the past few days trying to get it to stop complaining about what is essentially one bug. Although I suspect there may have actually been such a bug and although I suspect its advice may have actually helped me, I wasted far more time on it than was necessary. I think I misunderstand a basic principle about C. It seems that splint only really knows how to analyze programs at compile-time. This is to say, memory allocated at runtime is seemingly none of its business. Whence, naturally, the static in static memory checker.

It was dreafully confusing, though! I accidentally left a now-incorrect owned annotation on some struct member or other (namely a struct that had a more-or-less equivalent setup to the trouble struct that was causing splint to throw errors) which caused it to stop throwing these errors. For this reason I thought that there was a genuine issue with my implementation! After all, if the one dynamically-allocated implemenation was free from this issues, whyever should this identical one not be?

So it goes! The issue was discovered and dealt with by way of a few well-placed /*@i1@*/ annotations. I do find it troubling that splint gets so confused by all of this! No doubt there is a solution but it is one I am not privy to. Perhaps after more research I'll stumble upon something, or better yet discover that my implementation was truly buggy! For now, merely asking splint to ignore it shall suffice. It did however feel like such a miserable waste of time. Too bad!

In other news: I've now begun work on the I/O submodule of qwalk. This should cost substantially fewer headaches than its sister module, should being the operative word here.

And in other other news: I finally got around (with oodles of generous help from my darling girlfriend, Nyx) to getting my blood drawn. I've been off of my HRT meds for terribly long on account of my nasty habit of kicking the can down the road. No more! Once the work is done I shall have it sent to them and they will give me those darling drugs which yield the most womanly curves on my body once again, and that right soon!

At last! I have finally finished the barebones qwalk module. I have linted it and, moreover, I have a demo to show for it. Next up is writing read/write functions for qwalk! How exciting! And then after that is writing parsers that turn the text data files into save files. It will be wonderful.

Understandably, I hope, I'm rather exhausted now. I think I'll just leave it there. It's finally done. Check it out on github if you'd like! Just use `make` and then run `./test`. Easy as can be!

Hi! I've done a teensy bit more work on qwalk proper to facilitate reading/writing to storage, which is all well and good. It works like a charm! You can readily read/write an entire QwalkArea_t to/from a file.

More importantly, however, I've begun work on something wonderful: a development tool to easily create and edit a QwalkArea_t! I thought about keeping all of the data for any given one stored in a human-readable text file, but at this point I'm skeptical of the efficacy of that. My plan was always to develop development utilities and I suspect it'd be much too irritating to even try to edit a QwalkArea_t by hand on account of the fact that there's 2,500 squares per QwalkArea_t. Not to mention the storage space this method would gobble up! For those reasons they are merely stored in a binary format and will only be readily editable via my tool (short of editing the binary by hand... *shudder*...).

In either case, I'm aiming for development of the tool to be finished by the end of the week at the very latest. In fact, I think I shall treat that as a deadline. Naturally as I add functionality to qwalk I'll need to tweak the tool, but all of the fundamental functionality had better be implemented before Sunday.