Alright, in a small lapse while i have had my computer taken away, i decided to try a visualization of a compression method i have been thinking about. It uses 2 layers, one that is overlayed over the first to make the complete level. Each individual layer is able to be compressed in opposite directions using RLE, and so its much more efficient than using a single direction RLE for a single level. So there is a vertical layer and a horizontal layer, and they overlay to create the final level. This has yielded a compression of over 20 bytes off a previously 60 byte map, so it has great potential. And at the worse, i can put all the data into one layer and have it be regular 1 layer RLE.

The *downside* to all this, is that the levels have to be hand compressed, and it takes about 20 min to do a single level and get good compression. It was very difficult to get the screenshot below to have good compression, but it ended up cutting over 20 bytes off. This means that for a level editor, it would not be able to fulfill the full compression of levels, and would have to default to regular RLE.

Here is an example Basic program decoding some of this new data. Also there is a picture showing the two layers of the level. Red is transparency.

That seems like an excellent concept, but I don't really see why it means the level has to be hand-compressed. Surely we can design you a method to algorithmically make some guesses on a good horizontal-vertical balance and get something decent from that...

wow... that looks very nice...

thought not very computer noob friendly at this moment i would say :/
though i think i would be able to do a lot with it XD
with a looooot of time needed

I think it would have to be a very advanced compressor at that, since things like overlay and wraparound and such are the prime function of the compressor. It definitely couldn't be written in TI-Basic, it would have to be pretty advanced.

And im not sure if i want to implement it actually, since it requires so much work to compress each level, if i make an error in level design i have to go through the whole process again. And im not sure the bytes would even overset all the extra code to decompress.

One thing that might simplify it is only encoding transparencies where it's actually transparent; it looks to me like in some cases you write long sets of non-transparent areas, then overwrite that on the orthogonal second pass. Is that correct?

The overwriting is actually a critical part of the compression. Both layers use RunLengthEncoding, and so the longer the run, the better the compression. So on the first run, i can try to cover as much correct space as possible, while also filling in some unwanted space that is going to be overwritten anyway.

You're thinking subtractive; that can work. I was thinking additive, where you simply omit small details like single items on the vertical passes to make the runs longer, then you can fill in those single items on the horizontal pass (and maybe they appear in decent-length horizontal groups).

Im going subtractive because im trying to get the Runs as long as possible, and i dont see how that works if you are doing additive?

Alright, taking a break from the actual game to design the main menu ^^ Here is the current menu design i have thought out. Tell me what you think!

Very nice Aperture for Aperture science, and you caught the sign-like feel of the, well, signs that they use. I feel like the Play/Load/Exit text could jump out a bit more somehow, though.

Yeah, im still trying to figure out a good thing to put there. It might be enhanced with some sort of advanced cursor animation for all i know XD

Neat! Let me know if you'd like me to take a stab at it at any point; I do enjoy doing pixel art.

wow... that looks very nice!

Note that i just realized my image is to tall to fit onto a calc screen so a bit of the empty space is going away

Well, your image is 192x134, i.e. 96x67 pixels, so you only need to get rid of three rows.

Ooh, you could have a portal animation with the text showing through the portal, depending on which one is selected

Ooooh, I love it! Or how about a pair of portals appear on either side of the line of option text strings when you select Play/Load/Exit, and have the text chosen get sucked into one and accelerate between the pair of portals?

*cough* *cough*

Got a little bit of a cough there? I r confused what you're coughing at.

Builderboy - btw, isn't this project called PortalX?

Well thats its working title, the actual title has a subtitle in addition to Portal