-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Data format of "saved" designs #3
Comments
So far I've deemed it too early to think about the format the original game uses. In this code, I use three different layers; metal, silicon and vias. The silicon layer can contain one of two possible values on each cell. Each cell on each layer contains information about connectedness to its neighbors. I've experimented with a couple of alternative ways and the code is currently a bit dirty because of that. I will refactor it once I settle on one specific way. It's an amount of information small enough so that whatever format should be decided to use, it would be trivial to encode the information one way or the other. For the same reason supporting multiple formats would be a problem either. |
It's absolutely vital to be able to read and write zachtronics' format, IMHO. How else could you convince anyone to have a look at KNOH, out there at kongregate, zach's forum...?
So then: the format's set - by the original. Re the several ways to encode a cell and its connectedness: not really for using it in the blob but maybe otherwise of interest might be a regular expression. Will post it tomorrow (too tired to be sure to get it right now). |
What about junctions? I mean in one cell you can have
? |
That is a WIP right now. It kind of works, but as I said, the code is still changing because I want the simulation logic to be as simple as possible. Right now they are not special cases, but rather silicon connects to itself (P to N) freely. This is not ideal. As I clean up the code I will implement this properly. I think I'll also end up making separate graphics for each case. |
What's a WIP?
Not exactly - but quite - what I did. Have you calculated how many you'd need? ;) |
WIP: Work in progress. |
Ay, sure - what isn't? Was thinking of "What I Plan"... what the heck! Re # imgs: it's just below a thousand in total, if I'm not totally mistaken. So, be it browser or not: either a sprite-sheet or combine simpler (and way less in nr) basic gfx programmatically. |
For now I'm going to keep the current procedural system (try the latest code for clarification). I'm working on the simulation logic right now. I believe after that is in place and we can test whether the circuitry behaves properly or not, we can contemplate changing whatever needs changing. It's all pretty simple as it stands, so I won't mind rewriting it all if I have to. |
Using a sprite-sheet in the core helps to decouple things. Just make sure you can adapt to a different cell size and maybe shape (ie non-quadratic). |
Ah, totally forgot: using a sprite-sheet implies some addressing logic. Part of that could be mentioned regular expression. Will provide soon, promised. |
It's all right, I have it figured out. I have to tweak the procedural graphics so that gates are more clearly identifiable and it's done. Saving and loading designs should be the priority right now, followed by testing mechanisms and finally creation, saving and loading of challenges or "levels". Did you have any luck figuring out the design save format? |
Good to hear that and yes, I agree on save+load prio. |
EDIT: the following is now a file in the repo, "doc/Whats-in-a-cell.md". What I wrote here is a bit out-of-date and contains flaws, so beware. Here's mentioned regexp, with rationale:
17 × 73 = 1241 configurations in total; see below for details. Before the explanation let me state that: It
Now here's the rationale: it decomposes into two main parts:
Metal layerPretty simple: either there is no metal ( Silicon layerHere we got three alternatives:
As by the above, there are a total of 1 + 64 + 8 = 73 configurations in the silicon layer. A junction then is further detailed like so:
Again, should expand on the last point. This time by example:
Hope that helps / is interesting for you :) |
I must say this is very well though out and certainly very exciting! This is certainly 100% compatible with the code with no major differences with the logic behind it. It would be trivial to implement saving and loading using this format. And yes, it is very much human-readable. In fact, I'm thinking that, by changing the internal representation of the cells to conform more closely to this (although, as you already said, it contains redundancies), the simulation logic could be simplified (maybe), and (maybe) made faster. I'll have to look into it. Would you mind if I pasted your comment as a reference file in the repo and implemented this format for the time being? Or would you like to revise it / wait to see if you can decode the official format? EDIT: We can always support both formats. |
Not at all - I'd feel honoured :) Plz note that I've edited the post, have added the calculation of possible configurations. I'm getting more than I was getting before (with a slightly different encoding, but can't see the error atm). So plz re-check 'em. |
Re using this to gain speed-up: well, wrt the usual space-for-speed trade-off we have at least the necessary condition (redundancy). That it's also sufficient remains to be shown... |
Added the document and made you contributor so you can edit it directly (or contribute to the repo in any other manner). |
Cool, thanks. Didn't know of this contributor thing, makes it really easy for me. Standalone, without the issue context it does need some modification. Will do. Guess it's getting time for me to fork, though... |
Here's another calculation: The original design area is 36 cells wide and 27 high, making a total of 972 cells. Now: that is not such a big number. How many bits would you need? Is that possible? I just decided to go to bed now, for it seems I must be missing something. Or can a whole design area really be encoded in a single 32-bit number?! |
Aargh, it's of course 1241 ^ 972, ^ rather than ×. A few more bits... G'night & sorry 8-} |
This format is wasteful in terms of storage space. But unlike the binary storage used internally in the game, it is more human-readable, and since the grid is not that big anyway I don't think space is a problem. I've been thinking the official format is probably base 64 encoded binary. Have you checked that? |
I just added (cf756fa) a definite convention for the encoding of connections and a note to the spec file - and fixed yet another flaw in my calculations. It's a total of 17 × 77 = 1309 configurations rather than 1241. For your convenience, these are the main changes:
and
|
Hey, I've got another thing in preparation that'll exemplify mentioned convention and show how to use it to programmatically create cell images; using far less basic images (rather 10s than 1000). I'll call it "Drawing cells corner-by-corner" or so. It'll have quite a bit of images. Although I'll make a markdown version of it this won't be as good as the html version that I'll make, too. Html, however, is not quite as accessible here in github as markdown. Eg can't view it immediately rendered, as you can with markdown. My qs are now about how to proceed:
[That last point's not at all to say that the thread here had no value. Rather on the contrary, it spawned a lot. But might be helpful when trying to get to that one info fast which one will be looking for in the future. And: we can always refer back to here when necessary.] |
Hey, what's up? [meisl wrote:]
Hope you didn't take that as offense...? Should you have indeed, then plz accept my apologies. Wasn't meant as offense at all. You know, I proved myself capable of being considerably more stupid than that already, so... I'll take more care though, in case. |
Hey! Hehe, no, no offense. I've been swamped in work lately. I'm taking a look at the pull request this instant. |
Oh, ok cool then :) |
Hi again! Had little time myself lately, but the next few days I could delve into something. For now my only idea is to try a differential approach - which is big words for a pretty unfancy and laborious thing: just collecting a whole lot of saved designs that differ in only one cell and by looking at the binary diff, try to get some idea of what's going on. I already crammed together a Perl script for the deB64-inflate part and well, I kept taking screenshots of the associated designs. Not really fancy, I know, but that's where I'd start off of. So what d'ya think?
|
Ok, some factoids that I collected (but wasn't able to put together yet):
|
My current way of investigating this is too tedious. So I thought of this:
So... I'm thinking of making something in JS where one can paste B64 from KOHCTPRYKTOP and the hypotheses would be JS functions. Along the lines of the interactive page I made for "Drawing cells corner-by-corner". For the B64-inflate part I'd use https://github.com/dankogai/js-deflate (licensed GPL 2). Nevertheless, I'll commit the PERL script and my current test data soon. |
Have put the stuff I have so far into the new branch "file-format". The PERL I'm using is 5.12 (build 1204) from ActiveState; the script, "decode-ktop.pl" will simply decode any Here's some more "facts" of which I'm almost sure now:
Then: I couldn't get https://github.com/dankogai/js-deflate to work with KOHCTPRYKTOP's data, so I'll be trying https://github.com/imaya/zlib.js (MIT license) instead. |
The precise format of the compressed data (ie after B64-decoding) is the one described in RFC1950 with CM 8 (compression method 8, ie deflate). This differs from raw deflated data in some additional header fields at the beginning and an appended Adler 32 checksum at the end. |
What the heck, I just can't resist:
So far I've found out that it's base64 encoded deflated (RFC1950) binary data that more-or-less represents the design area cell by cell. That's the rough idea.
BUT: plz note that in fact things aren't (can't be) as easy as "cell by cell". That's because of the connections that can be in the metal layer or the silicon (P or N, which of them might be implicit), or both.
So one (stupid) way to encode all this into a one-cell representative datum would be to enumerate all possible combinations.
However, that
a) would mean a lot of redundancy (think: connected-to-right implies right neighbour to be connected-to-left and so on). Although, one might just say (ie have said): "let deflate do its job"...
and
b) does not match the _in_flated size of the data compared to what I calculated (actual is way less than what I think it needed to be)
Hence I guess there's rather two chunks of information:
Those two chunks might be either one-after-the-other or interleaved. To me it looks rather like the latter. At least at the moment...
The text was updated successfully, but these errors were encountered: