next »

[increpare]

All events will fire in the exact order that you add the listeners. The only difference being the sound API which runs in a different thread (which is why you bizarrely always have sound working beautifully even when AS3 code is grinding to a halt).

I change an item in a listarray (using setItemAt), and I can't then access the list item renderer until creationcomplete gets called on it.   I *could* use callLater to get around this, but I probably shouldn't

[st33d]

Ah - wait a minute. Are you using one of Flash's Components?

If you are, then yes, they're fucked. We avoid them like the plague. We generally make our own components in a manner not recommended by Adobe because we avoid using their piss poor code.

[increpare]

Ah - wait a minute. Are you using one of Flash's Components?

If you are, then yes, they're fucked. We avoid them like the plague. We generally make our own components in a manner not recommended by Adobe because we avoid using their piss poor code.

Yeah, using spark (flex's successor to mx).  Was fun at first in the way that confusing large infrastructures can be fun, but I'd be mega-wary about using it again without having everything planned out in advance.

[bateleur]

Sometimes I just want to do something, and then do something else

Yeah, I have this problem sooo often.

I usually end up just writing my program as a huge chain of callbacks using closures. That works fine actually, but if anyone else ever had to read the resulting code it'd make them want to stab themselves with a fork. (Or, more probably, stab me.)

[Overkill]

More of an annoyance than anything, but too many people out there write Lua in all-caps letters, like LUA. However, Lua isn't an acronym, it's Portuguese for "moon". http://www.lua.org/about.html#name

[Triplefox]

I usually end up just writing my program as a huge chain of callbacks using closures. That works fine actually, but if anyone else ever had to read the resulting code it'd make them want to stab themselves with a fork. (Or, more probably, stab me.)

Me too. The main culprit is when I'm initializing stuff; after that I'm running in real-time and can work with events instead of fighting them. Example:

Code:

	public static function doSave(?e : Dynamic)
	{
		flash.Lib.current.stage.removeEventListener(flash.events.Event.ENTER_FRAME,frameUpdate);		
		flash.Lib.current.stage.removeEventListener(flash.events.KeyboardEvent.KEY_DOWN,hotKeys);
		RenderLayer.off(); // lets us avoid having events appear on dead listeners
		flash.Lib.current.addEventListener(flash.events.Event.ENTER_FRAME,doSave2);
	}
	
	public static function doSave2(?e : Dynamic)
	{
		flash.Lib.current.removeEventListener(flash.events.Event.ENTER_FRAME,doSave2);
		World.gui.startLoad();
		World.gui.updateLoad("Saving...");
		flash.Lib.current.addEventListener(flash.events.Event.ENTER_FRAME,doSave3);
	}

	public static function doSave3(?e : Dynamic)
	{
		flash.Lib.current.removeEventListener(flash.events.Event.ENTER_FRAME,doSave3);
		Profile.serialize("savegame");
		RenderLayer.on();
		World.gui.finishLoad1();
		World.gui.finishLoad2();
		flash.Lib.current.stage.addEventListener(flash.events.Event.ENTER_FRAME,frameUpdate);		
		flash.Lib.current.stage.addEventListener(flash.events.KeyboardEvent.KEY_DOWN,hotKeys);
	}

(repeat same for load game.)

It is a pain to maintain this kind of code because it's so easy to leave a thing out and end up with save2 and save3 both triggering at the same time, but when it works it's solid.

If I really needed to reduce those kinds of errors, there are some options for abstracting it with function pointers etc. But what is really wanted is continuations, which at this time I can only get by putting together a runtime interpreter that executes things line-by-line and then ends the callback on a yield...but it wouldn't be worth it for these one-off cases.

[Glaiel-Gamer]

I know this is like the infinityth time this has happened but this ticks me off to no end.

*hits F5*
*game builds*
*game runs*
*CRASHOMG*
*hits enter*
*fixes code*
*hits F5*
"Would you like to pass the exception on to the program being debugged" NO FUCK JUST FORCE IT TO QUIT REBUILD AND LET ME TEST AGAIN FROM THE START

[LemonScented]

Glaiel, you can turn that off. One of the first things I change on a fresh Windows install. I forget the exact procedure, and I daresay it differs on different versions of Windows, but search help (or Google) for something like "disable error reporting".

[Riley Adams]

raaargh, random segfaults from hardware vertex/index buffers.

EDIT wow, now it's segfaults everywhere... this sucks.

EDITEDIT: I think I figured it out, kinda, sorta, ish.

[mcc]

Android update: Up until now, I have been basing my code on an obscure, barely supported API basically estranged from the mainstream Android API. I have now successfully converted my code to a different, even more obscure, even more dubiously supported, even more estranged-from-the-mainstream API

Yes, that's right. Forget JNI, I am now a NATIVE ACTIVITY

[bateleur]

Why did the designers of PhysX think it would be a good idea to make it non-deterministic? 

No, I don't mean it runs differently on different machines (although of course it does). The problem is that running the same sequence twice on a single machine can give different results.

I'm not sure whether they failed to discuss this issue at all during design, in which case they need a good slap... or if they discussed it and decided it was OK, in which case they need at least two good slaps.

[Triplefox]

No, I don't mean it runs differently on different machines (although of course it does). The problem is that running the same sequence twice on a single machine can give different results.

Is this from a "cold start" where everything is reinitialized? I ask because I remember seeing non-determinism from Box2D until I made sure to start it from scratch and not reuse any of the old structures at all.

[increpare]

I'm not sure whether they failed to discuss this issue at all during design, in which case they need a good slap... or if they discussed it and decided it was OK, in which case they need at least two good slaps.

I think the train of thought goes like "This isn't for rube goldberg machines"   How is it important for your game? (i do sympathise, though)

[_Tommo_]

PhysX has slowly become the worst physics engine out there, imo.

It should be deterministic, i remember to have read it somewhere in the manual... it is only buggy.
So that when you have critical joints (heavy object over light object, ragdolls, thin objects colliding) the solver COULD behave differently each time, and actually it does quite often, and in all those cases where tunneling and those other bad things happen.

In fact i think that this "glitch nondeterminism" depends on the same rounding errors that caused the glitch in the first place, so you can't really avoid it.

Other than this, in stable simulations it looked pretty much deterministic to me, even if I never checked in-depth.

[mcc]

The problem I have with indeterministic physics engines is you can't do things like replay a game by recording keystrokes

But PhysX isn't the only physics engine with an indeterminacy problem.

[mcc]

So you have two options with the Android NDK, use JNI or NativeActivity.

If you use NativeActivity, you're locked out from a bunch of basic API crap.

If you DON'T use NativeActivity you're locked out from a bunch of basic API crap.

But different API crap! Fascinatingly, regardless of which you choose, you will be locked out from certain kinds of file operations-- but DIFFERENT KINDS of file operations:

- Use JNI, and you will be able to access files stored on the hard drive but not (not easily, anyway) files distributed with your application bundle.

- Use Nativeactivity, and you will be able to access files distributed with the application bundle but not (not easily, anyway) stored on the hard drive.

It is looking to me like I'm going to have to stick with Nativeactivity, because I think I can still access anything from JNI-world by just doing nasty things with JNI (I think JNI is still available with Nativeactivity, you just won't have any java code in your app to make JNI easy) whereas some of the things that require Nativeactivity appear to require Nativeactivity, period. However the downside of this choice is that my app will require Android 2.3. This is awesome because I am told that there are literally no phones running Android 2.3 in the wild right now (?!) all the vendors have only moved up as far as 2.2.

EDIT: Wait. Wait! On the specific issue of accessing files (where my real complaint was, no apparent access to android.content.Context.getFilesDir()), I may have been saved. They saw fit to include two fields which the header comments document as the "internal data directory" and the "external (removable/mountable) data directory". Now I just have to figure out what that means...

EDIT EDIT: DENIED!

It has been confirmed that's a bug in android 2.3.x (fixed in 3.0)
you need to use JNI to retrieve those paths...

EDIT EDIT EDIT: Got it!

Apparently the secret technique to using JNI with NativeActivity is understanding that the documentation is LYING and the field labeled in the documentation (by "the documentation" I mean "the comments in the header file") as "The NativeActivity Java class" is in fact the NativeActivity Java object.

(I looked past that two or three times, each time going "that's stupid. why are they giving me the NativeActivity class? I need a NativeActivity object!". What I should have noticed is that the field was typed as jobject, not jclass.)

[bateleur]

How is it important for your game?

Difficult to quantify. As MCC has guessed, I need it for replay functionality. However, it may be that slightly imperfect replays are sufficiently good. Experimentation is underway...

So far I'm about a litre of coke, two cups of tea and half a bar of Bournville through the process of hacking a solution together. I'm just beginning to get to the stage where I can see how this stuff might start working eventually.

[Draknek]

In my experience for physics replays you generally need determinism, small differences will quickly build up.

[TobiasW]

Why did the designers of PhysX think it would be a good idea to make it non-deterministic? 

No, I don't mean it runs differently on different machines (although of course it does). The problem is that running the same sequence twice on a single machine can give different results.

Hum:
http://developer.nvidia.com/forums/index.php?showtopic=2028&pid=8737&mode=threaded&start=#entry8737
http://developer.nvidia.com/forums/index.php?showtopic=2028&pid=5558&mode=threaded&start=#entry5558

[_Tommo_]

http://developer.nvidia.com/forums/index.php?showtopic=2028&pid=5558&mode=threaded&start=#entry5558

How ironic is reading "SDK3.0 will have determinism, let's look forward to that". Date, April 2008.

@Bateleur: what about storing position+orientation at each keystroke? It could avoid the buildup of small errors.