Over the past 2 weeks, I've been swearing my way through the client's entrails, as part of the previously planned cutting of some of the abundant tangles that get in the way of everything. It's been even more gruesome and disgusting than expected - see further for more details on this - but it needed to be done, so it's done. I have now a client that gets directly to the game instead of going through several screens just to show you anything1, does not expect to know the whole world upfront, does not imagine it needs the network and a ping-pong server to just show... a local widget and moreover, can even paint something on the bloody screen and react to controls just like that, without a babel tower of widgets and managers and all sorts. And as a tiny satisfaction, it does all this with 3000 LOC less than it took to not do it!
The relatively simple part of this detangling session was the cutting out of network dependency - it took a full day of touching almost every file but at least I had a quite clear idea as to what I could do it: separate the local command handling from the remote "messages" handling (those were grouped together in a single interface, psClientNet without ANY good reason - wtf does local command handling have to do with remote server communication?); remove the inheritance/implementation of network/remote messages handling that was littered everywhere (and I do mean *everywhere*); keep in the active loop so far only what is actually useful.
The less simple task was then to get the client to show something at all because of the tangles between the view, the "psCamera" class and - again, as usual - ~everything else. That was done too and some image made it to the screen but then I realised that ... the controls - aka moving anything, even the camera around - were not working anymore! Why? Well, because it turned out that the client's controls relied on various PAWS widgets being loaded and those widgets relied on one another and on all sorts of graphics being present and known and whatnot. How the fuck can you program like that with the GUI actually *driving* the very definition and use of controls? They are called controls and *not* banana-dispensers already!
Once I found a way to reinstate controls and character manipulation as well2, the next step was to make *sure* that no shaders are loaded by default somehow & somewhere because indeed, the ever helpful ps&cs would do just that (and otherwise whine loudly if the expected shaders were not found). As a result, I found out another very interesting thing: while CS will load the "default texture" aka "error texture" when the specified texture is not found, this seems to *also* have some unexpected side effects in that all of a sudden, the colours of the terrain itself may simply change from one run to ...the next. Here's the world as it looks on one of those runs with Foxy clad in "error texture":
There is the fact that the terrain plugin expects indeed to use shaders as if they couldn't possibly ever NOT be there but I still don't really have the words for this situation where I run the darned thing once and the hills are green, after which I run it again and they are sandy or maybe gray. I'm sure I'll figure out the why too, just as soon as I get to the bottom of that wonderful terrain plugin but hey, all the fun in its own time, right? For now though, here's Foxy in her own skin but without any shaders whatsoever, under a starry night sky:
The next step now is to figure out just how to do all that shaders are meant to do, directly from CS. An initial mapping of shaders in CS suggests that this is going to be a huge pain really and I'll have to find a way to cut the knots before going nuts: as the situation stands, CS considers shaders to be "compiled" bits produced by registered "shader compiler" plugins of which there are 2 varieties - a shader "weaver" that depends on the "xml shader"; both of those rely on xml anyway and the whole xml-for-shaders is effectively a sort of "let's now program in xml" that requires as a result ~7.5k LOC just to... parse xml.
Rather than waste the time disentangling all the above shader mess (it's not a straightforward thing either, as you might tell by now), my current plan is to try to go at it perhaps from the very practical angle of what and how are "compiled" shaders actually used/useful and how can I produce them as needed. As this is not really all that clear to start with, I can't say I have a sane way to estimate just how long it will take, but I aim to have at least something more concrete in 2 weeks maximum3 since one way or another this has to move forwards.
No, seriously, do you *really* want to play? Maybe you just started the client to...quit? Or to see the ...credits? Admire the splashscreen? Dunno, something *other* than playing? ↩
This involves in usual ps fashion several managers and spurious classes, all tangled up together and calling one another until nobody knows anymore what is where and for what reason, if there ever was a reason; nevertheless, this part - if it is to be cleaned - will have to wait for another day as at the moment there are more pressing matters really. ↩
There's Christmas and New Year in those 2 weeks too but who cares about those all that much. ↩
Comments feed: RSS 2.0