Platform-specific Problem

[Reo]

I'm creating a simple tile-based game similar to Chip's Challenge in LUA, and I'm having a strange problem. I mainly test my game on the TI-Nspire CAS Student Software that came with the calculator, and my game works fine. However, when I transfer the program to my calculator and run it, a few bad things happen:

1. The level-area, composed of a solid background color with two object layers and the player, doesn't draw right. It only draws the player and the background.
2. When I attempt to move the player, the script crashes with an error in the collision detection functions saying that it's trying to compare my player's position to nil. What it should compare it to is the result of an expression that returns the object ID of an object at a position in the "level table" (where objects are stored) specified by a function argument.

I've figured this much out: the level loads right, because a function called in the level initiation function that scans the room for a certain number of objects works. I just don't know where to go after that. Is there any platform-specific difference that I'm missing that's stumping me?
I'd rather not share my source code unless necessary because it's very messy. If needed, just tell me.

[Jim Bauwens]

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.

[adriweb]

Here are several things you might want to pay attention to :

- 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, contraty to the device, which refrehes 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().


About your 2nd question, the code would indeed be needed...

Good Luck

[Reo]

- 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

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

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

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

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.

[NecroBumpist]

Functions based inside gc (ie gc:drawRect(), gc:drawString(), etc) only work if they are called indirectly from within on.paint().
And as said earlier, you have to refresh the screen yourself, so either set a timer, or do it manually.

Examples:

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10

local ggc; -- global graphics context function on.paint(gc) gcc = gc; end function on.enterKey() gcc:drawString("Herp", 0, 0, "top"); end

That will not work. This will.

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

local extra; function on.paint(gc) -- do normal painting if extra then extra(gc); extra = nil; end end function on.enterKey() extra = function(gc) gc:drawString("Herp", 0, 0, "top"); end platform.window:invalidate(); end

You're problem for 2 is most likely either you're passing the wrong arguments, or your accessing part of the table that doesn't exist (out of bounds), causing it to return a nil value, which is later compared to something else, like a number. Lua doesn't allow this.

Either read through the calling function, or add some conditional code to make sure the inputs are safe.

The error's line number would be appreciated as well.

[Reo]

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

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

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

Code: Select All | Copy To Clipboard

1 2 3

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:

[NecroBumpist]

Well then, your problem is that the leve1 table simply doesn't have what you're looking for in it.
So display the answer of the expression you're using (y * levelsize+x+1) and see if that looks wrong.
That value is simply not in the table, because the compare value is nil.

[DJ Omnimaga]

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.

[Reo]

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.

They were both on 3.0.2, until I updated the computer software to 3.1.0 to see if something changed.

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

Thank you.

Well then, your problem is that the leve1 table simply doesn't have what you're looking for in it.
So display the answer of the expression you're using (y * levelsize+x+1) and see if that looks wrong.
That value is simply not in the table, because the compare value is nil.

I'll try this out later.

[DJ Omnimaga]

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://www.omnimaga.org/index.php?topic=6763.msg156233#msg156233

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

[Jim Bauwens]

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

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

Code: Select All | Copy To Clipboard

1 2 3

function drawPlayer() platform.gc():drawImage(playersprite,originx+((playerx-camerax)*16),originy+((playery-cameray)*16)) end

I see that you are using platform.gc(). This is not recommended, because its not the same as the gc passed to on.paint (it is not yet initialized).
The solution to this is to pass gc as parameter of the function:

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10 11 12

function on.paint(gc)     ...     drawPlayer(gc)     ... end function drawPlayer(gc)     gc:drawImage(playersprite,originx+((playerx-camerax)*16),originy+((playery-cameray)*16)) end

What I also see is that when you copy layer0 into level1 and level2, you use this:

Code: Select All | Copy To Clipboard

1 2 3 4 5

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

I assume layer0[num][ i] is a table? If so, this means that level1[ i] is a reference to it, not a copy.
This way, if something happens to layer0 it will effect level1 and opposite. I don't know if this is intentional, but you need to watch out with these things.

Also, I suggest you too look at the way Levak's sudoku (http://tiplanet.org/forum/archives_voir.php?id=3550&play=) handles drawing to the screen. It makes having multiple screens (intro, game, menu) a piece of cake. I don't say you have to copy code directly, but it is a huge help in the long term, as it makes your code more clear and easy to handle.

[adriweb]

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....