Sure no problem Static things are pretty easy because all they require is some collision code.  In fact, most of the things i've mentioned are a ton more easy to do than finishing the portal engine (in theory of course ) I have up to 16 tiles i can use, and so far they are these:

0) Empty space
1) Solid wall*
2) Solid wall
3) Laser
4) Electric Field
5) Spikes
6) Unauthorized material emaciation grid (blocks portals and crates )
7) Force Field (portals can go through but not you)

So if i don't add any more, i can double my length encoding and get better compression.

Mmm i suppose i haven't talked about what i am going to be implementing.  So here is what i am definitely planning:

Lasers (just like in the original)
Fields (areas that ossilate between charged and uncharged, and kill you if you are in them when they are charged)
Plasma ball things (just like in the real Portal ^^)
Buttons
Doors

Things i might but probably wont implement are cubes and turrets, as for that i would have to generalize my Portal code entirely to support multiple objects, as well as collision between all objects, even through Portals it would be a nightmare.

I'm thinking that there might be cubes, but in a different form, where they are passive (cannot be pushed around) and have no collisions between eachother, as the cube/button puzzles are a great part of the original Portal

I have a super wide screen, so this really doesnt affect me but i can see how a smaller bar would be helpfull.  The popup menus would be cool, kinda like that TiBD has.  Can that be done Eeems?

Map data format:
The data uses run length encoding for comression.  Lets say we had a simple map:

11111000001111
00000222220000
Pretty simple, each number representing a different tile.  With normal storage this would take
a single byte per tile.  Or we could represent the data in a different way:

150514052504
Seems much smaller, but what does it mean?  lets insert some imaginary commas and dashes to make
it easier:

1-5,0-5,1-4,0-5,2-5,0-4
Now you may or may not be able to see how the data is represented.  The first segment is 1-5, or 5 '1's in
a row, followed by 0-5, or five '0's in a row, and so on.  This is how the data in run length encoding is
represented.  And to further the compression (or confusion), each #-# segment is packed into a single byte.
Instead of two hex digits to represent a number from 0-255, we will have 2 hex digits, each from 0-15,
representing the two numbers of each #-# element.

The first Hex digit 0 to 15 is the tile number.  The second hex digit is the number of tiles to add to the
tilemap.  The digit goes from 0-15, but 0 doesnt make much sense, since that would mean this element doesnt
do anything , so we will add one to this after we decompress it so that it has a range of 1 to 16. 

There is a small disadvantage that if you have empty spaces of 17 or more in a row, it will take more than
1 byte to represent in the code.

Decompressing the Map:

[Data]->GDB1 //map data to GDB1
[tileData]->Pic1 //tile data for tilemap

0->N //element index for map data
0->I //map index for storing tile data

While I>=96 //until we have stored all tiles
{GBD+N}->A //Take the first element of the map data
N+1->N //Increment the map index
A^16->B //spit the map element into it
A/16->A two seperate elements

For(F,0,B //fill the map from current position I to I+B
A->{L1+I} //could be optimised with Fill but i couldnt get it
I+1->I //working :/
End

End //End while

After this code is run, the tile data will be decompressed into L1, as folows

0  1  2  3  4  5  6
7  8  9  10 11 12 13...
ect, it will be in a straigt line, but you will have to access it using your own routine.  Something like this

{Y*W+X+L1}
where W is the width in tiles of your map.  X and Y would be the tile coordinates starting at the top left at
0,0.


Displaying the map:

here is a rudimentary program that should be run right after the pervious decompressing program:

For(X,0,11 //loop through the entire screen coordinates with tiles of 8x8
For(Y,0,7
{Y*12+X+L1}->A //retrieve the correct tile from the data in L1
Pt-On(X*8,Y*8,A*8+Pic1 //draw the sprite to the screen
End
End


Also attached is a PEDIT program to create and compress maps into a Hex String into Str1, as well as an Axe program to decompress and display them.  Just put the string data into GDB1

I could see this being possible in axe.  The power of the greyscale will have to be proven first though.  I think the speed of asm is mostly needed when doing things like multiple objects and crazy stuff like greyscale

But I want to make sure that before using your suggestion (or SirCmpwn's), I won't run in any further problems, later, doing some stuff with these pointers

Well since L3 and L6 are the backbuffer and the main buffer, i should think so, but you'd have to check with Quigibo o.O Using built in routines would indeed be safer

Yesssss!  Loove the sound addition, can't wait to test it on calc, although it might take me a while to get my alligator clips out i don't have any adapter so i have to make one .  Love all the new commands, the 2 bit manipulation is especially awesome.

true, but does Mirage use any of the same safe areas that Axe uses?