Ossa Sepia

August 12, 2019

Camera Tests of a Sunday

Filed under: Lyf, Young, old and oldest — Diana Coman @ 3:49 p.m.

As I've finally retired my 14+ years old1 Sony camera and got myself the currently recommended still-Sony camera, I was rather curious if it does anything to my daily lack of photo-enthusiasm. So I started with a test on the nearest rose bush that I brought out from wilderness2 and into the light - for added photographic points, there were even a few water drops still on it (click for full-resolution, ~6MB with-droplets-image):

Water drops on a rosy-yellow opened rose with a bud nearby.

Water drops on a rosy-yellow opened rose with a bud nearby.

It certainly looks *better* than what the 14+ year old camera can currently obtain (though it used to do better) and it's certainly true that the new camera is lighter, smaller, with a bigger screen and the same sort of interface even, only improved - for once, actually improved! Such wonder. So I stalked a butterfly too but it didn't want to open up its wings while observed:

Brownish butterfly (perhaps a Small Heath aka Coenonympha pamphilus aka Pamfil?) on a garden bush.

Brownish butterfly (perhaps a Small Heath) on a garden bush.

While I was watching the rose and the butterfly, my child was watching me with a certain electronics-related interest since I had told him that he may indeed use all the new components but only as he gets to actually know them with the help of everything he has. So after a while, off we went to figure out just what do resistors do in a circuit and how to measure intensity or voltage and what a potentiometer might possibly be. As he had more work to do on the figuring out front really, I continued with my own camera testing:

Child making a series circuit to see the effect of different resistors.

Child making a series circuit to see the effect of different resistors.


What does this potentiometer do?

What does this potentiometer do?

And after quite a while of circuit-making and switch-switching and delighted laughter when things happened exactly as he thought they would (and surprised questions when they didn't), he remembered suddenly that there were still some remains of a certain walnut and cocoa Chec3 of very young age indeed. So I ran faster than him and managed to mess up a picture of sorts while there were still any pieces left on the plate:

Pieces of walnut and cocoa marbled cake on a green plate.

Pieces of walnut and cocoa marbled cake on a green plate.

Now that this camera is indeed all it was said to be and even something extra (I hadn't quite realised just how much smaller and handier it can possibly be), all that it's left is for me to put this take-photos-thing on the list of daily (or at least regular) requirements, huh. Though I still think the kid got the better toy this time...


  1. It's a usual lifespan, even on the young side really! 

  2. When we first moved to this house we've been told by a very-convinced woman that the garden is "very low maintenance, don't need to do anything really." Even at that time, it was enough to look at the garden and one could indeed see that she hadn't bothered - for years even - to do absolutely anything at all about the garden but that of course does *not* mean that nothing was *needed*! Still, she had no idea what I meant, of course, of course. She saw no need for anything and therefore nothing was needed - not as if this is not the usual excuse, isn't it? 

  3. Chec is a sort of easy-made marbled cake made in 1001 variations as the chef decides: in this incarnation I left out the rum and it contained crushed walnuts + the few brazil nuts and macadamia nuts that were lost among the walnuts; and cocoa in half the dough of course, as otherwise there'd be no marble effect. 

August 7, 2019

A Visit at the Recycling of War Artefacts Museum

Filed under: Lyf, Tgdyk tgdyk — Diana Coman @ 7:08 p.m.

His name was H. and he was made to fly. H. flew sometimes for fun, sometimes for duty and nobody really stopped to separate the two - how did it matter whether or when it was one or the other, anyway? After all, H. had made loops in the air when followed by the eyes of children waving flags but also when trying to avoid a quite different type of followers. In between flights though, there was also a lot of travel on land and on sea, chasing the next possibility to fly and getting in the process a lot of markings from all the travel and from all the chasing. But it was in the end a simple fire after taxying that kept Harrier ZD4611 down long enough for it to be declared the past and rather than repaired, just hung on ropes at the museum, in a bit of a mixed-up exhibition, next to a bomb of previous times:

A WW2 bomb next to a Harrier plane active from 1990 to 2010.

A WW2 bomb next to a Harrier plane active from 1990 to 2010.

We visited the Imperial War Museum in London (IWR) at the end of June this year but I never bothered to write down anything about it - it's a bit of a mix really with some interesting bits (there are Robert Capa's photos taken during the landing of American troops on the beach in Normandy on 6th June 1944; there are also regular events with WW2 veterans - at times and depending on your luck, you might get a glimpse of what they made of it), some reasonable parts (I hadn't seen the insides of a bomb before) and some terribly propagandistic stuff - at times the three are even mixed, what can you do. As I was clearing up my old camera today, the few pictures I took at the time (and promptly forgot about) came to light and so here's the entrance too, from the only awkward angle I could find at the time to avoid having some t-shirt clad icecream eater in the picture:

Barrels of 2 naval guns stranded on land in front of the former-hospital that is now the Imperial War Museum in London.

Barrels of 2 naval guns stranded on land in front of the former-hospital that is now the Imperial War Museum in London.

The entrance though is quite representative of the whole place - it makes me think more of recycling and propagandistic posing than of war itself (then again, everything is indeed forever recycled and arguably propaganda of one sort or another too). The building itself is a former hospital that recycled in the 19th century the Ionic for its columns. The two guns pointing away from it are barrels of naval guns taken from 2 different ships - the link being that both shot at least once during WW2. The shells are planted in neat rows for framing the picture I suppose and serve inevitably as climbing/sitting places for bored children. Mine liked at least the guns (they are BIG) but wasn't impressed by the shells (why are they yellow?). He liked the aeroplanes inside but that's be default currently - if it's an aeroplane, then and therefore it is interesting. And he listened politely to the old man telling his story of what it was like living as a child in London during the war, bombings and deaths and then evacuation and all. After which he raised his hand and waited his turn and asked of course about the one thing that was indeed most interesting from his point of view: *what* was inside this bomb exactly and *how* did it work?


  1. According to the Imperial War Museum docs, the plane is a vertical/short take-off and landing jet aircraft constructed in 1989, used in Iraq, Kosovo and Afghanistan and retired in 2010. 

August 6, 2019

The Widgeting Paws of Pointerism (Notes on Graphics in Eulora, V)

Filed under: Coding, Eulora — Diana Coman @ 5:02 p.m.

It took indeed more than a week and I'm rather surprised it didn't actually take even longer than two weeks to get *anything visible* out of it. It's all one strand like Stan's spittoon after all, so there's rarely just "one sip" that doesn't bring in the whole rot with it and I have to fight over and over the urge to just burn it all down and start a sane thing from scratch1. Nevertheless, a lot of deep breaths and assorted cussings later, here's a brief summary of the main achievements, in the order they were made:

  • some useless crap was removed and the whole thing made to work without (e.g. the doll with its dependence on a special sector in the map file);
  • the initial loading and "pre-caching" of meshes, textures, materials, maps and 2D stuff was excised (there are still the shaders remaining though as well as 1001 "preferences" in as many files in yet as many different places, sigh);
  • the actual handling of 2D icons and GUI images in general (e.g. buttons, borders, arrows, window decorations) aka the PAWS was dissected and exposed and roughly mapped as ugly as it is;
  • as recorded proof of breaking PAWS and because of its shameful lack of proper way to load images on actual demand, the whole thing has had a run with the stupidest "mouse pointer" available in there and otherwise with absolutely no 2D images at all for the very lulzy effect that it even looks better in some ways than with all of the various pieces of "art", here it is:
    That snot on the screen is the mouse pointer on the black background starting screen.

    That snot on the screen is the mouse pointer on the black background starting screen.

    PAWS's shame: the better-looking interface with no images whatsoever (clicking the invisible widgets still works!)

    PAWS's shame: the better-looking interface with no images whatsoever (clicking the invisible widgets still works!)

The path that led in the end to the above started with me looking - as initially planned - at how the character (as moving sprite) is handled or rather mishandled, consider: there is the CEL layer that supposedly provides on top of CS the sort of structures needed by games to store and manage the various entities and objects; PS however "uses" it in principle but in practice it still mainly does its own thing anyway (and by now I strongly suspect that this pattern is simply because nobody ever spends the time to understand what they use); specifically, the PS way is to have a pscelclient class that supposedly manages game entities on client side (shouldn't CEL have been enough for that, you ask? most probably yes but that'd have taken someone to figure out first exactly how it works and who has time for that!!); but then there is *also* a pscharapp class that handles the appearance of the character (apparently that's too low stuff for "management" to handle) and there is also a psclientchar that moves about equipped items because this is yet neither management nor appearance but absolutely something separate - though you'll be hard pressed to notice much separation in the code for all this theoretical separation; and to top it all, the inventory and doll views that precisely reflect character's appearance and equipped items are actually the domain of something else entirely - the PAWS; and the PAWS (which is supposedly so separate as to bother to be a plugin by itself) in fact messes about with pretty much anything and everything from the engine to shaders and textures and 2D images (which are still loaded as... textures, but those are textures-this not textures-that) and xml-defined maps and hardcoded paths to all sorts of files it expects - nay, demands - to be present and just-so and at-start but oh-so-configurable. At which point it became clear that the PAWS mess is indeed such a large part of the whole mess that I'll simply have to get to the bottom of it just in order to move further at all.

Looking at PAWS more closely revealed that it's meant to be a GUI system. This initially rather puzzled me because there IS in fact already another GUI system in there, one that PS uses/relies on as a dependency, namely CEGUI. Then again, the PS style is to "use" something by simply sitting on top of it and mushrooming a lot of managers with hardcoded paths and expectations that they know the whole possible world upfront so there should be no surprise at PAWS, which is precisely this sort of thing - it mushrooms widgets and pointers rather than something-else and pointers, that's about all the difference from all the other PS masterpieces.

Masterpiece aside, what IS this GUI system PAWS? As far as I can tell, it's a lot of widgets so well organised that there are no less than 3 methods "FindWidget" because the 1st one (defined in pawswidget) checks the current widget and its children only, the 2nd one (in pawsscript) checks also the parent of the current widget while yet the 3rd one (in pawsmanager because yes, of course there are all sorts of managers) simply delegates it all to "mainwidget" aka a sort of calling the 1st one from the top of the tree (but no, they couldn't possibly notice that it's meant to be a tree and there are well-known algorithms for searches in a tree). Anyways, the fun part with widgets is the way in which they are defined really as each widget has an .xml file (in data/gui) that supposedly defines appearance only (though more concretely it's about which elements it contains and on what position) and a .cpp file (in client/gui usually) that supposedly defines behaviour. The funny bit however is that both of those, for all their pretense of clear separation (they even are in totally different dirs, yes?), quite directly reference both one another's bits and pieces AND global, all-of-a-sudden-made-hardcoded parts: the appearance references by name other widgets (that it uses for specific roles and in specific places so it's not just a name really) and "resources" aka pre-loaded images; the behaviour code in turn has to reference various components of course. And in all this, apparently nobody noticed that before you can talk of behaviour and of appearance, there has to be somewhere a *structure and nature* of the thing that actually is the core and therefore the driver of everything else... Then again, what structure and nature and such silly notions, when the whole thing is bent on defining anything and everything by its current, temporary position or at best some role it might fulfill for a while2.

The widgeting PAWS further has all sorts of notions regarding appearances: there are "skins" and "styles" and "resources" and they are all both hardcoded and expected to be fully known upfront. The Great Paws knows not only all the world that is but also all the world that could possibly be (the world as it defines it is all nothing but labels anyway so it makes sense in a way). And it enforces this by whining and even wagging its finger at the user if it ever finds that a file with what it *knows* is the "right" name is missing from its expected place, quite literally giving orders to the user, as the message spit is this:

"ART ERROR: PawsTextureManager loaded the image %s which was missing from the imagelist.xml and was loaded on demand. Add the image there!"

I'll add to the above: and blow your nose and stand up straight and cut your nails shorter! Imagine that, being such a shitty user that the poor, poor PAWS had to actually load an image on demand (how degrading!!), you nasty user, you! And note that this "on demand" is anyway the sort of "you demand what I'm willing to do or no dice" not any sort of actual demand: it only means it deigned to look (because it had to use that image) in the *same place* it looked initially (when it tried to load everything that there should ever be) just because you are the sort of shit that failed to put the image there when it looked the first time, you know? What sort of user does such a thing to a poor piece of code, you tormenter, you, shame on you!!!

Before you get your hopes up that there is at least some sort of "loading on demand", bash those hopes one over the head: for one thing this "on demand" still relies on the predefined list of what there *can* ever be so that if you request a "resource" it doesn't know about than tough luck, it won't try to look for it, it's not that stupid to do something useful; for another thing, there is no way to actually call this on demand: it's just a way of doing rigidly the same thing but expecting a different result because meanwhile the world should have better come to its senses and fit the expectations already, what.

If the above sadness is not enough, add to it this significant bit: PAWS considers itself a plugin and as such entirely separated from the actual client and therefore unable to use whatever the rest of the client knows. Sure, in practice this separation "works" by means of the main client class simply passing pointers to PAWS on creation - why use CPP if not for pointerism, after all. Moreover, the added benefit of this separation is that PAWS also gets therefore to have its own set of repeated XML parsing of all sorts since it can't use the already-repeated XML parsing that the client anyway suffers from. And finally, it makes somehow perfect sense to "separate" the main client from the GUI system seeing how they both use the same graphics engine anyway and moreover the main client loads some images as textures while PAWS loads...well, some images as textures, yes. But they are not the same "class" of textures, so that's significant separation, see?

Besides deep red, I tell you what I further see: since I have no intention to pass even more pointers on or otherwise to force this "plugin" nonsense on everything just for the very specialness of PAWS, it's way more likely that the paws will be clipped more to size and therefore will take their place as yet another of the many classes inside the main client, possibly together with all the rest of very-special-plugins if need be (of course the dependencies are not that simple). I'm still pondering this, mainly because the idea is to touch as little as possible the code rather than as much as it takes to clean it (mainly because clean it won't be anyway). But one way or another, I will have to find some reasonable way to bring PAWS in line with the rest and have it go and load resources from wherever (and whenever) it is told to. This might even require more discussion in S.MG's boardroom but at the moment and as a result of all the adventure above, I have at least a much clearer idea as to what the 2D part is all about so there is therefore a point to even start the discussion from.


  1. While it might *seem* faster that way, it's not, nor does it really make sense if one calmly considers everything involved. Urges like this are simply focused on getting rid faster of the current set of problems and do not care nor stop one second to consider the alternative set of problems that are bought by such "solution". So yeah, urges make very poor guides, how surprising. 

  2. And no matter how much I try to *not* see it this way, it always is the case that the closer one gets to the "how things look" and therefore in this case to graphics, the more confusion and more monkeying there is. 

August 3, 2019

Silently Unhappened on TheOdinProject.com

Filed under: Dark Modern Ages, Outreach — Diana Coman @ 2:49 p.m.

From the series of "I must be doing something right if *they* are so afraid of me", I had today the lulz surprise of finding out that a derpy forum1 "unhappened" silently my account2. As in literally, vanished entirely not only my "page" but also what comments I left for others leading to the great achievement that now there are replies to my non-existing comments3. Wouldn't you say that's great for learning? You get for once a user who can and is willing to actually help others around and then you ...unhappen this user without a word even because... what exactly? No idea but possibly they have a bucketfull of "oh noez" that I kicked over without even trying or something4.

Oh noez and all that but imagine it - after making an account and engaging with some newcomers there for their benefit5, the loss on my side is... what exactly? That I will now totally set the bozo bit on this particular derpy forum? That they give me now an excellent antecedent as to why exactly it's a mistake to even take any notice of their "forum" interface and accounts and all that pretense at all? And that clearly from now on I'll document upfront each and every descent I still deign to make into such sad holes? Or perhaps that they are slowly but surely adding concrete fuel to my otherwise sluggish motivation for pillage and burning, that must totally be their gain I'm sure.


  1. Since can't derp without pretense, it's called theodinproject and I'm not going to link it, no. It has a stylised hunting trophy icon and is otherwise a sad trap for web-developer wannabe misguided souls. It runs on "Discourse" too so that it's in *that* bucket rather than in a different bucket (e.g. flarum, *BB and so on.) for all the difference that makes to the caught crabs within. 

  2. Here's what it says today at the link for my account, preserved in amber for the future: archive.is/FcGC6 

  3. Here's an example of a reply to one of my comments and I'll let you judge how terrible my comment must have been given the reply: "That's an excellent point - I did take some statistics/logic and reasoning courses as well, though, so hopefully that'll help with the literal-ness!" 

  4. By now it's probably extremely easy too as I'm clearly alien to them. 

  5. In fairness it was all of 20 minutes first-pass sort of thing, to get the pulse of the place - apparently it didn't even survive the lightest touch, who knew there are such wallflowers on the internets. 

July 29, 2019

Overview of FFA Ch1 - Ch19

Filed under: Coding — Diana Coman @ 9:51 a.m.

Over the past few days I've taken the time to finally go through all the currently published chapters of FFA (1-19 with some bis and a,b,c on the way too) and got as a result a clearer idea of the whole thing as it builds up from basic definitions of large integers to the Peh interpreter machine with its own registers, two stacks (data and control, respectively) and the Cutouts mechanism for controlling access to sensitive data. While initially I was planning to add to my previous notes on FFA Ch1-Ch4, my experience of getting back to FFA after a significant break pointed to the need for a higher-level overview of what-where-why even before looking for such detailed illustrations of the code involved. So here's my current overview of FFA - open to any criticism you are able to throw at it, as always - consisting first of a brief list of main approaches in FFA and then the 4 "layers" that I see to the whole thing so far.

Main FFA Approaches and Algorithms

  1. Strictly non-branching on input values and therefore practically the death of "if". No ifs, no buts, so what's left is MUXes1: essentially the "if" goes down one level, from a logical switch (which operation to perform) to a mechanical one (which buffer to copy the result from); the same operation is always performed but its result is not always used.
  2. Strictly constant-time execution for any given inputs size. This means in practice strictly worst-time, of course, as it's always the case when you require all to be the same. The only way for all to be equal is by making them all equal to the worst, no way around it. Then again, some people's worst turn out better than other people's best so take "worst" with a pinch of context, as always.
  3. Comba multiplication algorithm: calculating sequentially the *columns* of a product; additional optimisations for the squaring case (mainly avoiding calculating the same products twice).
  4. Karatsuba multiplication algorithm: calculating the product XY as a combination of cheaper operations (additions and shifts preferred by far to multiplications) on the half-words of X and Y; additional optimisations for the squaring case.
  5. Barrett's modular reduction: calculating X mod M by means of an approximation using the "Barrettoid", B, that can be precomputed from any given module; X mod M is approximated first as X - M*B and then adjusted by at most 2 subtractions of M (i.e. the error of X - M*B as approximation of X mod M has only three possible values: 0, M or 2M).
  6. Stein's binary GCD: rather quasi-Stein as it's adapted to FFA requirements, most notably the constant-time execution requirement (by iterating over the full number of bits rather than stopping when the smallest number is 0).
  7. Miller-Rabin compositeness test: an adapted version of MR, forcing any given witness into the acceptable range and providing a "one-shot" test for any given value N and witness W.
  8. Peh interpreter machine: basically the "cryptographic machine" that the user gets to push the buttons of; Peh has a data stack and a control stack, a set of registers and an instruction set including the ability to define and call subroutines and loops as well as to define Cutouts aka a protected area for sensitive data.

FFA Layers (from bottom up)

  1. Representation of arbitrarily large integers as fixed-size (i.e. specified for every run) arrays of machine-words (with iron-specific size of machine-words changeable via knobs in the code). In FFA terminology, such integers are called "FZ".
  2. Basic arithmetical, modular arithmetical and logical operations on FZ entities in constant time and handling any overflows/underflows. This part builds up from the most "naive" approach (aka most straightforward if rather costly) dubbed "egyptological" through successive refinements (optimisations of the original algorithm followed by radical changes of approach) until the final result uses Barrett's reduction for modular operations, Karatsuba with Comba core-case (i.e. below empirically-established thresholds) for multiplications and a variation of those (Karatsuba + Comba + specific threshold) specifically optimised for squarings.
  3. Primality-related algorithms working in constant time on FZ entities: Stein's binary GCD2 and an adapted MR3 that can adequately handle any value of a given witness (by forcing it effectively within the valid range).
  4. Peh, the finite-tape, dual-stack and cutouts-enabled interpreter. While I still need to turn this inside out a few times more, I can tell already that I want a Peh-iron!

And while there are still a lot of experiments and timings and playings to go through with all the FFA, I'm happy at this point to sign the remaining chapters as I went through them with pen in hand and as far as I can tell they do what it says on the tin (not to mention that I certainly would use FFA and in fact I'm itching to drop already the shitty gpg, ffs!):


  1. Multiplexer aka a way to select only one of several inputs. 

  2. Greatest Common Divisor 

  3. Miller-Rabin 

July 24, 2019

Naked Models (Notes on Graphics in Eulora, IV)

Filed under: Coding, Eulora — Diana Coman @ 11:30 a.m.

What's the first change you'd do to an empty-headed character such as Testy? Why, chop some bits off, change his sex and get him naked at least, even transparent at that, since he's pretty much just as tedious and boring as all children dolls 1. Of course the first attempts failed to produce anything visible because it turns out that using Cal3D sprites in Eulora's client goes through several layers of inmisdirection: Crystal Space (CS) wraps the Cal3D code in its own SprCal3D plugins and factories and whatnots; on top of that, there is also the rather elusive Cel (Crystal Entity Layer) that is meant to be a game-specific part of CS keeping track of game entities; and messing within and across all is Planeshift's (PS) own GEM concoction interlaced with delayed loaders and Dead-Reckonings2 and cloning of materials (why? no idea yet) and surprising, undocumented transformations. Still, after a while of hacking through all the above, I could at least get some parts of Testy showing... if lying down rather than upright:

Spot the bottom in the grass!

Spot the bottom in the grass!

The prostrate position makes at least sense in that "movement" also looks a bit like some swimming look-alike: parting the legs and advancing sort of thing. Then again, it turns out that using a different model (e.g. Cally) makes it even more interesting - the model is upright when waiting but it dives straight back to the horizontal as part of moving and it furthermore cares not one bit for whatever movement animation one loads. So there's a clue for another day - current movement needs a good bashing over the head and a deep dive to figure out what's all this nonsense. But until then, here's naked Cally who borrowed Testy's skin for a spell:

What bits is she missing?

What bits is she missing?

Anyway, since position of the model is always a matter of applying one transformation or another, I went ahead and applied the obvious transformation, 90 degrees and upsy daisy on her feet:

Upsy-Daisy with muddy skin!

Upsy-Daisy with muddy skin!

And funnily enough, once the 90 degrees rotation is applied to the factory (i.e. presumably to ALL entities built out of that factory) the Testy model remains upright even during movement without any perceived change. On the other hand, the Cally model is upright without the 90 degrees rotation but nevertheless dives down for movement and pops back up as soon as movement is done. So it would seem that movement has its own assumptions that it doesn't bother to make public, how lovely. Seeing how it's most probably to do with the model's initial position or similar, I might even need to end up again with the full environment, Blender and all installed to get to the bottom of it and probably see exactly what or how the exporter is also broken and specific. Such joys to come but for the moment they are not yet here since the more pressing need is first of all to disentangle some more the PS+CEL+CS+CAL3D mess regarding animated entities so as to actually be able to *use* the walk/fight/move animations rather than just "add" them and moreover to be able to add and remove on the fly as many and as diverse entities as wanted, beyond the "main character" guy. And all this is getting deeper into PS swamps so it's likely to take more than a week indeed - ideally by then I'll be able to cut off at least some parts of the existing code (precaching and preloading especially) and lighten the client start a bit if nothing more.


  1. Changing graphics is this exercise in tediousness and pointlessness, it eerily reminds me of playing with dolls, just one step lower than that since those are just images of dolls, fancy that. And playing with dolls was utterly boring even when I was 5! It's like an endurance test along the lines of watching paint dry. Tinker with this and tinker with that, all for "the looks" of it and can't even satisfyingly throw it at anything to hear it break. 

  2. Not kidding, although it's way less exciting than the name they had the chance to land on: it's mainly looking to see if your character falls down and breaks their neck. 

July 20, 2019

The Young Hands Club

Filed under: Outreach — Diana Coman @ 9:08 p.m.

Since I already have a eager young hand and it turns out that even online young hands still need some space in which to mess around as much as their growth requires, I've went ahead and set up The Young Hands Club precisely for this purpose. A sort of very public learning club if you want - and even if you don't!

Now let's see what comes out of it in one year's time. The opportunity is there, the options are all yours supposedly so... what will you *do* about it?

July 17, 2019

The Mirror Land (Notes on Graphics for Eulora, III)

Filed under: Coding, Eulora — Diana Coman @ 10:26 a.m.

Getting some actual landscape as in getting the height right turns out to be only half (the reasonably well-working half) of the terrain task: once I had in place at least the generic mechanism for creating factories and meshes, the terrain factory required only a few iterations, false starts and mandatory dives into CS's entrails to get working and save Testy from his usual fall into the sky-sphere:
Terrain generated from heightmaps only (no mix of materials, only base material).

After setting up the lighting a bit better too, it looks even more reasonable (next to the crater that is currently empty, yes):
Base terrain from heightmap.

The truly frustrating bit turns out to be the painting of the landscape in the desired materials. For the relatively easy part, the Terrain2 construct of CrystalSpace provides a "terraformer" that can be fed a "material palette" (i.e. a set of materials to use) and an indexed image - as a result, the terrain will have a reasonable mixture of the materials depending on heights and an ok fading of the materials into one another where they meet so it doesn't look that terrible, especially once all normals are in place too so that lights stand a chance to work:
Terrain from height map *and* material palette with 3 materials: grass, sand and rock.

The trouble however is that so far I haven't quite managed to get to the bottom of turning down the reflective mirror-like surface of this landscape! In theory, materials have those 2 light-reflecting properties, namely the extent to which they are "diffuse" or "specular" (i.e. "shiny"). Still, for all my futzing around with those for all three materials (sand, grass, rock), the observed effects are pretty much non-existent. So much for the theory and welcome to this graphics thing of tinkering. To see clearly what I mean, here's a rather surreal rendering with the ambient light turned on to higher levels so it's more obvious (note that the effect is precisely the same even with low ambient light - it's just harder to realise what it is exactly; similarly and as expected, one can mask the effect to the point that "it's fine" by turning on the fog button - it makes sense since it dulls the ambient light, I'd say):
mirror_land

On the positive side, the futzing with lights and whatnots is really something of less concern for me at this moment since I'm not that interested in obtaining an image *just so* - my goal is in figuring out *what* sort of things one can set, what do they do and how to set them while the game is running. In this sense, at least the basics of the terrain seem to be in place for now: heights are read from a heightmap file, the materials are indeed used according to heights, the rest is for another day. I suspect though that in usual tradition, the only real solution here is to dig in the end in that shaders pit as well since it's most probably a shader thing: the terrain object uses a different, terrain-specific shader and for some reason the defaults for that end up producing more of a mirror than a soil, at least given *everything else* (such is graphics, everything and anything can be the culprit). Note that I specifically used and set precisely the same parameters for materials as they are in the client currently in use - so it's most probably something else/somewhere else that I'm not setting just right for now.

The next step now is to figure out animated meshes too, hence Cal3d objects. So in the next episode, it's Testy himself that will change and get created directly from code. Once I have at least one way to do this too, I can go back a bit and look again into integrating them into (or extracting them out of...) the rest of the PS infrastructure. Then again, before doing that, I might still need to dive in and figure out the shaders in more detail to extract some way of specifying them without xml and directly from code too, perhaps. That promises though to be a lot of figuring out and additional mess so depending on whether it can or not wait a bit longer, it might not be exactly next in line - basically I have lots of work competing for my attention, a sort of inverted looking-for-work, it's the... (lots and lots of) work looking for me!

July 14, 2019

A Working Cuntoo Install on AMD FX-8350 (with script)

Filed under: Coding — Diana Coman @ 10:20 p.m.

Since the relatively recent discovery that Cuntoo work is apparently not really going anywhere for lack of more public testing and reporting, I'm doing my bit and publishing what I've got so far on installing Cuntoo on a local box and prodding it for a while. First, to introduce the box in question, so you can easily replicate it:

  • AMD FX-8350, 4GHz, Octa Core
  • Gigabyte Ultra-Durable GA-78LMT-USB3
  • 2*8GB DDR3 RAM
  • 1TB Seagate Barracuda

Since I wanted to do this from scratch to make sure it's easy to replicate, I ignored my previous Cuntoo-compilations and I made myself first a bootable USB-stick with Gentoo's livecd. Initially I took the minimal install_amd64_minimal_20190703T214502Z.iso but that proved iffy to use because it was apparently a bit too spartan for my requirements (esp. no make on it). So I traded space for time as it were and used instead the much larger livedvd-amd64-multilib-20160704.iso (2.2G vs 292M for the minimal iso). Perhaps this was quite overkill and there is something in between that does the job just fine so if you find/have that, just use it - the bootable USB-stick really is just a way to "get in," nothing more. Note that on some .iso images you might need to run isohybrid first if you want to use them to boot from USB (rather than burning them on a CD/DVD). As for making the bootable USB stick, that's as easy as using dd to transfer the .iso to your USB drive - do be patient if your .iso is big as dd is silent.

Armed with the bootable USB stick, I popped it into one of my USB 2.0 slots and turned the machine on. If you have the same setup as mine, the F12 key will give you the boot menu (or Delete for the full BIOS menu) and you'll need to select the USB stick *from the hard-drives* (you'll need the PgUp/PgDown keys and not the +/- as some docs mislead me). Once the live-dvd Gentoo image boots, you can proceed with the Cuntoo-related tasks, in order (note that you'll be doing all this inside the live-dvd image so if you reset, *the environment will reset too and your changes will be lost* so you'll need to start from the beginning again. With many thanks to Hannah for her mini-series of posts detailing her ordeal with Cuntoo and therefore inspiring my script-making right from the start, here are the steps and the relevant script parts:

  1. Add to your /etc/hosts file the IPs of any websites you'll need - the exact list depends on what you choose to do at each of the following steps (e.g. where do you take your V from) but at the very least you'll need the IP1 for trinque.org to get the Cuntoo tarball!
  2. Obtain and import any gpg public keys you need - similar to the step above, the exact list here depends on whose stuff you use but as a minimum you'll need Trinque's key, of course. As I've used only Trinque's and my own stuff, my gpg-importing bit of the script looks like this:
    # gpg keys
    curl -v "http://ossasepia.com/vpatches/diana_coman.asc" -O
    gpg --import diana_coman.asc
    curl -v "http://wot.deedbot.org/FC66C0C5D98C42A1D4A98B6B42F9985AFAB953C4.asc" > trinque.asc
    gpg --import trinque.asc
    
  3. Get and install a working GNAT. My choice here for expedience is to use the frozen Adacore version that I'm hosting on this site. Correspondingly, the relevant part of the script grabs it from my website, checks the provided sha512sum on it and installs it (if the GNAT dir doesn't already exist from a previous run perhaps):
    # GNAT
    GNAT="gnat-gpl-2016-x86_64-linux-bin";
    GNATZIP=$GNAT.tar.gz
    
    if [ ! -e $GNATZIP ]
    then
      curl -v "http://ossasepia.com/available_resources/gnat-gpl-2016-x86_64-linux-bin.tar.gz" > $GNATZIP
    fi;
    
    if [ ! -e $GNATZIP.sha512 ]
    then
      curl -v "http://ossasepia.com/available_resources/sha512sum_gnat-gpl-2016-x86_64-linux-bin.tar.gz.txt" > $GNATZIP.sha512
    fi;
    
    if [ "$(sha512sum $GNATZIP)" = "$(cat $GNATZIP.sha512)" ]
    then
      echo "Matching sha512sum for Adacore-GNAT."
    else
      echo "FAILED sha512sum test for Adacore-GNAT, stopping."; exit
    fi;
    
    if [ ! -d $GNAT ]
    then
      tar -xvf $GNATZIP
      cd $GNAT
      sudo ./doinstall
      cd ../
    else
      echo "GNAT dir already exists so GNAT is assumed installed! Skipping GNAT install."
    fi;
    
    PATH="/usr/gnat/bin:$PATH"; export PATH
    echo "Updating PATH variable to $PATH in order to use GNAT."
    
  4. Get and install your favourite V. Make *sure* it can be found (e.g. update your PATH variable with V's location). Once again, since I can rely on my previous work on packing V (namely mod6's implementation of V), my life is that bit easier now and my script relies on my website to get and check everything:
    # V
    VDIR="starter_v"
    VZIP=$VDIR.zip
    if [ ! -e $VZIP ]
    then
      curl -v "http://ossasepia.com/vpatches/starter_v.zip" > $VZIP
    fi;
    if [ ! -e $VZIP.diana_coman.sig ]
    then
      curl -v "http://ossasepia.com/vpatches/starter_v.zip.diana_coman.sig" > $VZIP.diana_coman.sig
    fi;
    
    echo "gpg --verify $VZIP.diana_coman.sig $VZIP"
    gpg --verify $VZIP.diana_coman.sig $VZIP
    
    if [ ! $? -eq 0 ]
    then
      echo "FAILED sig check on $VZIP, stopping."; exit
    else
      echo "Sig check fine for VZIP"
    fi;
    
    if [ ! -d $VDIR ]
    then
      unzip $VZIP
    fi;
    
    cd $VDIR
    chmod +x build.sh
    ./build.sh
    cd ../
    PATH="$PWD/$VDIR:$PATH"; export PATH
    echo "The PATH var for using gprbuild, vk.pl, ksum, vdiff and vpatch is: "$PATH
    
  5. Get Cuntoo itself (note that it's ~800M so depending on your connection, this step may take a while):
    # Cuntoo itself
    CUNTOO="cuntoo"
    CUNTOOZIP="$CUNTOO.tar"
    
    if [ ! -e $CUNTOOZIP ]
    then
      curl -v "http://trinque.org/$CUNTOOZIP" > $CUNTOOZIP
      curl -v "http://trinque.org/$CUNTOOZIP.sig" > $CUNTOOZIP.sig
    fi;
    
    echo "gpg --verify $CUNTOOZIP.sig $CUNTOOZIP"
    gpg --verify $CUNTOOZIP.sig $CUNTOOZIP
    
    if [ ! $? -eq 0 ]
    then
      echo "FAILED sig check on $CUNTOOZIP, stopping."; exit
    else
      echo "Sig check fine for $CUNTOOZIP"
    fi;
    
    tar -xvf $CUNTOOZIP
    cd $CUNTOO
    

Once all the above finished without any error or problem, all you need to do is to run the bootstrap.sh script according to Trinque's instructions. If you are at a loss as to the kernel config - by far the ugliest part in this - and your hardware is similar to mine, I was able to use Stan's "Dulap-II" config with minimal (possibly it works even without any) changes so go grab that one and feed it to the script - note that you'll get a quite spartan but absolutely functional environment and you can customize it from there as you want it. Here's the full bash script too if you want to use it: cuntooprep.sh.

NB: at the moment I'm writing this, the known path-issue within Cuntoo's scripts is still present in the Cuntoo.tar file so you'll need to do the change manually for the signature to verify on the genesis.vpatch that you obtain at the end. The change you need to make is explained in the logs and you can do it after running the bootstrap.sh script if you already started that.

Once you get the genesis.vpatch, verify it against Trinque's signature - if it doesn't verify, chances are that you still need to fix the paths issue so see the paragraph above and remember to actually re-run the scripts/make_portage_tree.sh script after you made the change! Then simply reboot and choose to boot from the disk on which you installed Cuntoo. You can then recompile the kernel to tweak any configs you want, for instance with those steps:

  1. cd /usr/src/linux
  2. make oldconfig
  3. make menuconfig (and/or change whatever you want directly in the .config file before running this - I've ended up finding the *text* file BETTER than the bloody gui thing simply because nobody can tell where something is in there, ugh.)
  4. make && make modules_install
  5. cp arch/x86/boot/bzImage /boot/bzImageNew
  6. change /etc/lilo.conf to add the bsImageNew as another boot option (DO keep the old one too, at least until you are sure the new one is fine!)
  7. lilo
  8. shutdown -r now

Once you had enough of recompiling the kernel, the next step would be to have a look at what you'd like to add to your system - chances are there'd be quite a lot of things that you need before you can actually do a lot in there. Cuntoo has its own preferred repository in /cuntoo/portage and a distant second in /usr/portage. So when you run emerge, you'll see either ::cuntoo or ::gentoo appended to the packages required, depending on which of the repositories is used. To enrich the cuntoo repository and effectively get rid of the madness where gentoo just doesn't "have" anymore the packages you want, you'll need to copy the tarball of your package into /cuntoo/distfiles and the ebuild+manifest+patches+shit into /cuntoo/portage/package-path. My initial attempt with MySQL was a step too far at this stage as it served only to point out more clearly what a mess porting the dependencies to Cuntoo will be - MySQL itself requires all sorts! So I looked among those "all sorts" and picked out one with better chances of being standalone, namely curl. With this adjusted aim, I was actually able to "port" the curl ebuild to Cuntoo as it were, simply like this:

  1. Download the tarball without installing it: ebuild /usr/portage/net-misc/curl/curl-7.60.0.ebuild fetch
  2. Copy then the tarball to /cuntoo/distfiles
  3. Copy /usr/portage/net-misc/curl to /cuntoo/portage/net-misc/curl
  4. Go into /cuntoo/portage/net-misc/curl and snip away the ebuilds that are other versions than 7.60.0 as well as the references to them in the Manifest file (NB: you'll need to keep all the patches though regardless of what their names say as they are still applied to the 7.60.0 version anyway).
  5. Now run emerge --ask -v net-misc/curl and look closely: it should say ::cuntoo and it should report that it has to download precisely 0Kb. If all that is true, let it do it and you'll have gotten Curl in your new and sparkly Cuntoo!

Now I must say that I'm a bit at a loss as to whether the above curl-experience should get the grand name of "making an ebuild" or not or what - to me it looks more like hacking an ebuild at best and moreover a quick look at gentoo's docs re making ebuilds reveals enough *other* stuff to eat that I don't see it happening all that soon. So I don't even know - is *this* sort of hacking ebuilds that Trinque was asking for? Or writing them from scratch or something else entirely or what?


  1. Obviously, unless you use DNS but why would you still use that anyway? 

July 12, 2019

My First Hours on Dev.to

Filed under: Dark Modern Ages, Outreach — Diana Coman @ 2:46 p.m.

As I really have too little time to waste any of it on fretting about how to start on things, I just picked Dev.to as the first online place to explore in search of young hands that grow from their right place and not from arse1. The choice was quite arbitrary really - it popped out on my unordered list as a relatively lively place and it uses GitHub old accounts so at least I did not have to make yet another "account". As a result, I now have in there too, that same old end-of-uni photo of mine that GitHub also has but so what. Anyway, to start it off, I gave them some content for free, sure, what's a few paragraphs to me now, here it is:

Come work on what matters, so you matter too.

I'm part of TMSR - the place where well-thought Bitcoin innovation happens steadily, publicly, unfashionably and with inescapable, far-reaching consequences. From a new model of software development to a MMORPG and building up a working market for computer artists plus everything software and hardware in between, the focus is at all points on owning what you do and growing your knowledge and ability at a sustainable pace.

The programming language of choice is Ada (with a fully-documented rationale as to why Ada) but work with legacy code includes C, C++, Python, Lisp and potentially anything else really.

Come work with me on things that matter, if you want to matter too. I write (and have been writing for a while) at http://ossasepia.com

The post above quickly got a few "hearts" and so far (1 day later) precisely no comments at all. Apparently love is easier to get than conversation, did you ever notice that? And what does it actually tell you, hmm?

The easy love aside, I didn't really wait (or expect) for any conversation to actually start from my first post, no matter what I'd have written there2 and so I just started looking around at the whole thing instead, trying to figure out its structure and therefore some way to *systematically* explore it. That quickly bumped into the obvious fact that the whole thing seems rather on purpose built *against* systematic anything. There are tags for instance to group supposedly by interests the content and you can "follow" tags even with "weights" attached but you can't see ALL tags (I know because I asked them, right there, in the "hello" thread, yes). You can see "the top 100" tags and supposedly that should be enough for everyone, screw the unpopulars, apparently I'm not supposed to be able to find them even if I am willing to go through as many tags as it takes to precisely reach them too! There are also profiles of course and you can "follow" those too but again, no way to actually see a list of them and be able to just go and talk to each one, no. Gotta try and map the space through the conversations that they feed you (literally, it's a "feed", right?) or otherwise go pretty much by chance, here and there, looking under each stone in search for people nowadays. Oh, and the platform is some Open Source pile of code, of course. Anyways, doesn't it strike anyone as really weird this thing where precisely online stuff that is by its nature exactly fit for systematic organisation and access is instead by design anti-systematic? Note that it's not just a matter of "offering also a fuzzy path to follow" but rather limiting the option to that and nothing else.

Anyways, 100 tags at least are better than none, so I started reading from there, for lack of any other better strategy really. Reading3 and commenting of course, since the whole point is to engage with people, what else. So after a few hours yesterday reading and commenting around there, here's how my dashboard on dev.to looked like:
day1_devio1

Looking at the numbers this morning (after another 15 minutes spent on dev.to), I have: 1 post published (with "under 100 views"), 29 comments written, 10 "followers" and 4 "total post reactions." Hopefully I find a way to get faster at this as I do it more since I can't say I really have as much time as the current rate promises to eat up.

As for people actually following on what they said and making their way to irc and/or to this blog (or Stan's, since there was one DrBearhand whom I pointed towards FFA), I'll believe it when I see it happening and not earlier. But in any case if those I reached already fail to actually act on their own words now, it's their failure and nobody else's anymore, certainly not mine - from here on, it's on them entirely. What do you think the actual rate will end up like, 1 in 100? 1 in 1000? 1 in 1mn?


  1. It's Stan's term-of-art, see the logs

  2. I suspect I'm getting old really, there's no other explanation for this sort of lack of silly expectations here. 

  3. Really, having read lots and lots of legacy code prepared me for everything and anything, there is that. 

Older Posts »

Theme and content by Diana Coman