rawr, double post update!
Anyway, I've fixed up many collision/jumping bugs as well as added the ability to slowly move in the air if you have no initial x velocity (basically you use this to get out of holes).

And I finally made a chrome friendly screenie, heh heh

Also I have a bunch of ideas for different blocks: think conveyor belts? super bouncy or floaty ones? some with massive friction, others with none? And I have an idea on how to implement moving platforms as well....(pixel testing collision makes for lots of flexibility in the engine )

He's only copying 720 bytes since his picture doesn't take up the whole screen (What are the dimensions of your pic btw? If the length is less than 96 it could get a little messy)
Anyway, if you want to put the pic data into the appvar, you'd have to do something like...
GetCalc("appvSC",1536)->P
Copy([Hex],P,720*2)
Copy(P,L6,720)
Copy(P+720,L3,720)
Repeat getKey(15)
Dispgraphr
EndBut there's not really a point to putting it into an appvar anyway since it's stored in the program...so
[Hex]->Pic1
Copy(Pic1,L6,720)
Copy(Pic1+720,L3,720)
Repeat getKey(15)
Dispgraphr
End

Welcome to Omni. Here are your peanuts

Thanks for the support ^^

Currently I'm working on adding lots of awesome features to my map editor to facilitate the ease of entering said data. Basically, the current process I have to go through to add a new map goes like this:
1)Create map entry in a program
2)Compile program and run to write in new data
3)Compile sprite editor
4)Make tiles, paste hex into another program
5)Compile program and run to write in new data
6)Make map and write out NPC convos
7)Compile and run 2 programs to update NPC data
8)Write down all the tile coordinates that are warp tiles and their destinations
9)Write down all the NPC tile coordinates
10)Enter all of this data into the map data program
11)Compile, run it.
12)Debugging requires repeats of entire parts of the process.

As you can see, this is not good for my flash chip nor my sanity, so my new mapmaker will hopefully be able to boil down the process to this:
1)Hit "Create New Map" and enter appropriate data (tileset, name, etc.)
2)Make map and tileset
3)Select warp tiles graphically (with the map viewing engine, to save hassle on writing down numbers and stuff)
4)Select NPC tiles the same way
5)Use old process for NPC convos, but that's ok i guess

Also, I posted a new release in the release thread, so check it out if you were having any bug issues before

Can I request some sort of sign function that would return the sign (65535, 0, or 1) of a number? Too bad sign{} is already in use though...

Hm. Yeah, that's true. I guess it's not really very useful then lol

shmibs: thanks! and I would love to help you optimize for blastermaster .
ztrumpet: Currently the collision is pixel based, but theoretically maybe I could make a special case for the sand tiles...perhaps
Binder: The program is on Normal mode. here's what it looks like on Full . It's so fast I can barely control it

Currently I am having issues with slopes, and I'm thinking I'll just resort to having slopey-ness be part of a block's list of attributes (instead of pixel testing) in addition to friction, bounciness, and breakability. (which I haven't really added yet either). So while I brainstorm about this, you guys can have fun with this new build that has different tiles in it (and hopefully fixes shmibs' bug)

Note that I haven't yet added level support and that the game, every time you run it, reads whatever happens to be in L1

So would changing this make the new nibble routines opposite the ones found in .4.6? (or the same?)