how to check if something is null?

Monkey Forums/Monkey Programming/how to check if something is null?

sandfella(Posted 2013) [#1]
I have:
Field _unit:CUnit


and later I check:
if (_unit = Null)
   _unit = new CUnit

..which seems to return nullpointer exception (at least on android).

I know how to solve this without using "if something is null", that's not the actual problem... The actual issue is that I wanna know how null works in monkey and if different targets require something special.

Any takers?


sandfella(Posted 2013) [#2]
...uhhh... actually looks like I'm blaming the wrong line of code :) The above stuff works just fine... (that's inside "OnUpdate")

...the nullpointer exception happens during OnRender where I do NOT check the if thing ;)

Solved.


sandfella(Posted 2013) [#3]
Ooh, when I have debug mode on, I can actually see android telling that it was "p_OnRender(MonkeyGame.java:2592)" that caused the issues ("java.lang.NullPointerException")

Well, one last thing. Does the _unit=null thing work on all default monkey targets? I assume yes (based also what I saw in the documentation).


ImmutableOctet(SKNG)(Posted 2013) [#4]
Well, one last thing. Does the _unit=null thing work on all default monkey targets? I assume yes (based also what I saw in the documentation).

Monkey was built to work more or less the same way on all of its targets, so yes, that's how it works.

All of Monkey's default game-based targets are garbage collected, and in terms of programming in Monkey, the garbage collector is pretty much the same on all targets.

However, the garbage collectors tend to behave differently with large amounts of data/a large number of objects. So if your games stutter for seemingly no reason, it's probably the target's native garbage collector having problems with your overall demands.

From what I've heard, lists tend to be slow with Android and its collector; don't quote me on that though. And C#/XNA was the main target to have the "too many objects" issue (Bullets for example), but with the optimizations Mark made in V70, that may no longer be an issue.


sandfella(Posted 2013) [#5]
Ok, thanks for the insight.

Lists slow? What's the alternative then. Please tell me it's not arrays... ;)


Gerry Quinn(Posted 2013) [#6]
One could probably re-invent Monkey.List using a pool for Nodes. If the data objects are also pooled, that should eliminate most garbage collection (you will still have it for enumerators and the list itself).

Arrays of objects will also create garbage unless the objects are pooled or in some other fashion re-used.

But it's all relative to the sort of game you are doing and how much churning of collections is going to be involved. You might be as well to code everything in the simplest way first and see if it performs okay.


sandfella(Posted 2013) [#7]
I like Lists... so yeh we'll see how it goes. :)