Normally, it should work on both the platforms without a problem.
There might be issues with color though, so be sure to use setColorRGB.

The only way I can help with 2 is that you give me some bits of code, so I can look into it.

- Don't use platform.gc(): as your standard GC context (only use the on passed in the on.paint(gc) event).
- Make sure you refresh the drawing buffer often enough. That might be the real problem of yours, here. Actually, the software refreshes constantly, contrary to the device, which refreshes only when needed or when it's asked. So make sure that when you want to draw something and update the screen consequently, call platform.window:invalidate().

I only use platform.gc() in functions that are called only during on.paint, though I use platform.gc() most of all because I've split my drawing functions into groups. I also refresh my screen every 0.1 seconds, and I believe that this should be enough.
Really, I believe that the first problem is caused by the second. It's like the table is totally gone after the level init function, and I have no idea why.
There's no color issues between platforms either; I forgot to mention that I develop this on for a CX with the CX student software. So if anything there'll be issues on a regular nspire which I'll have to solve later.
Here's some code where I think there are problems, with some comments.

startLevel
function startLevel(num, keepkeys, startx, starty) --Pass this function a level number, and it'll warp the player.
if layer0[num]==nil then --If the level doesn't exist, the player must have won.
pause=1 --However, I have no screen for this yet, so for now it
else --just pauses.
if keepkeys == 0 then --If I somehow want to start the level with keys from the
keys = {0, 0, 0, 0} --previous.
end
if startx > 0 then --Assuming that if you specify one starting coord, both are used.
playerx = startx
playery = starty
else
playerx = startpos[num][1] --If none specified, get them from a table.
playery = startpos[num][2]
end
levelsize = math.sqrt(#layer0[num]) --This works because levels are completely square.
local area = (levelsize*levelsize)
level1 = {} --Table where the first level layer will be contained.
level2 = {} --Table where the second level layer will be contained.
for i=1, area do
level1[i] = layer0[num][i] --Function that copies the original level data
level2[i] = layer1[num][i] --to the two layers for gameplay. Possible point
end --of interest.
backgroundcolor = {mapcolor[num][1],mapcolor[num][2],mapcolor[num][3]} --Each level can have a unique background color.
levelnum = num --
maxbluekeys = 0
for i=1, area do --Scans the level for blue key fragments and
if level2[i] == 6 then --totals them because all must be collected
maxbluekeys = maxbluekeys + 1 --to create a blue key.
end
end
camerax = 0
cameray = 0 --Reset the camera position
fixCamera() --and move it to the player.
end
end
collisionCheck
function collisionCheck(x, y)
local compare = level1[(y*levelsize)+(x+1)] --Object ID of this position in layer 1. <  What is said to be "nil" when game crashes
if compare > 0 then --If it's above 0, it's a flavor of normal solid block.
return true --Returning true says "Yes, there will be a collision."
elseif compare == 0 then --If nothing's there,
return false --there's no collision.
elseif compare == -1 then
if keys[1] > 0 then --Here is where we have negative block IDs,
keys[1] = keys[1]-1 --where blocks determine their solidity
level1[(y*levelsize)+(x+1)] = 0 --based on logic.
return true --This is a yellow key door.
else
return true
end
elseif compare == -2 then --Red key door.
if keys[2] > 0 then
keys[2] = keys[2]-1
level1[(y*levelsize)+(x+1)] = 0
return true
else
return true
end
elseif compare == -3 then --Green key door. Green keys last until level end.
if keys[3] > 0 then
level1[(y*levelsize)+(x+1)] = 0
return true
else
return true
end
elseif compare == -4 then --Blue key door. Found in pieces that can
if keys[4] > maxbluekeys-1 then --be put together, and will last until the
level1[(y*levelsize)+(x+1)] = 0 --end of the level.
return true
else
return true
end
else --If nothing else, assume it's false for no reason.
return false
end
end
EDIT: I disabled collision detection by always evaluating compare as "0". If I move around to the left side of the level, I can get some garbage tiles (tiles that don't draw in the right place) to draw in one row, and they disappear when I leave that row. This mystifies me.
Here's a screenshot of what it looks like when it's working on the PC:

Here's a picture of the odd occurence I just described on the calculator:

The red key value is actually a measure of the area of the level because I hacked up the drawing function for it to debug. The value on the calculator is actually one less than on the PC.

What concerns me is that this works absolutely fine on the PC; both problems do not occur on the PC. What I'm wondering is exactly what varies between each platform that's causing my issue.

Also, as far as I know, I'm drawing correctly. Here's an example of some of my drawing code:

on.paint
function on.paint(gc)
if title == 0 then
drawHUD()
drawLayer1()
drawPlayer()
drawLayer0()
if pause == 1 then
gc:setFont("sansserif","r",48)
gc:setColorRGB(150,0,0)
gc:drawString("Paused",159,106,"middle")
end
else
drawTitle()
end
timer.start(0.1)
end
drawPlayer
function drawPlayer()
platform.gc():drawImage(playersprite,originx+((playerx-camerax)*16),originy+((playery-cameray)*16))
end
Though some of the tiles fail to draw right on the calculator, everything else draws on both platforms.

Here's a screenshot of the crash I'm getting:

Question, what version of computer software do you have and what OS version does your calc run on? For example, from OS 3.0.2 to 3.1.0 some Lua functions stopped working and new ones got added. I do not know which ones, though.

Also welcome here. This game also looks nice so far too.

Ok, then the OS is not the issue. I remember the emulator was not really a real emulator, though, and therefore it did not emulate the real machine correctly. In fact the student software cannot even run Ndless nor Ndless games when we use the versions with OS 2.x. From what I remember, games like PacMan and Nyan Cat were not even full screen or some stuff did not show up.

The best solution would be to use Goplat's emulator, but then the problem is that you won't be able to see the color, as it emulates the regular TI-Nspire, not the color one. http://ourl.ca/9360/210357

Texas Instruments just fails epically at keeping their emulation accurate. We had the same problem with their 83+ emulators. The worst part is that the 84+ emulator that came built in older Nspire models did not emulate the 84+ correctly either. X.x

About that gc thing, jim'post is exactly what to read and learn.

The reason platform.gc() is not recommended is that it's actually going to be gone (kind of) in future version of the lua API.
So please, use the gc passed by on.paint(gc), as Jim showed you.

the reason platform.gc() was created and made available in the first place was to be able to access some primary functions like string length etc. (getStringWidth...) before the on.paint event....