and displacing a different sprite instead of the heightfield pretty much gives you textured 3D backgrounds.

Wohoo! Now we can talk about something else

It could be crashing just because you're spawning things at an exponential rate?

I made sure that wasn't the case. It's just spawning one each 500ms. While one could probably avoid spawning from a family, it's still a crash and therefore, a bug.

This is REALLY useful advice for people going the python route. IMHO should be in the wiki.

System: Every 500 milliseconds

System: 0 len(EditBox 0 .Text) Greater than 0

SystemCreate object Sprite 0 on layer 1 at (random(640), random(480))

This worked as expected in 995. Can't reproduce.

Also, while I think that a 3D model loader would be great, I'm sure that if we had one, people would be asking for animation XD so yeah. For 3D, go to a 3D engine.

Now let's make some kickass 2D games!

yeah I was spawning the spawner object along with some other one, so that the spawner would spawn some more things. This was a mistake on my part.

However, the runtime does crash when spawning from a family.

I've been scouring the nets for info on how other games do it.

Has anyone any kind of reference?

thanks for the examples, the first one did it.

Seems I wasn't getting any results because the erase object needs to be on top of the other objects (duh!) and works within a single layer.

this will be useful, I'm sure... I plan to use it to mask shadows out of an occluded object!

Also, a shader makes it VERY slow.

Really. It's slow, even in modern hardware. For that performance, I'd rather go full 3D.

She did this for attention >.>

~Captain Obvious

This is why we can't have nice things

[quote:24iqqnos]Credit and stuff like that, you wrote it, you get all the credit

I think that goes without saying. Otherwise I need to call my lawyer, some people owe me!

I like where this is going.

As for multiple resolutions, one could create several canvases, family them (hah) and then delete them all in runtime, keeping the needed size. Of course this would still eat up the total VRAM at startup :s

I've been thinking of 4-player splitscreen too, but that's not as easy... yeah I could envision the 4-way splitscreen as each corner of the screen, but what about the angles? imagine widescreen, 4 players each in their split-corner, then both players in the upper half approaching each other.... vertically! O_o

4 player-splitscreen could be done with rotation, so that the camera rotates to accomodate any merges, but this example doesn't rotate the playfield, I'm not sure how hard that would be.

Also, 4 player would mean 3 canvases? that's a lot of VRAM if one could only 'paste to screen'.

Hey, that'd be a neat way to control a renderer with events! foreach *default family* ordered by z, paste to screen. Construct 2, perhaps? with a "draw normally" attribute that does this by default, and then one could uncheck it and move and paste stuff around freely like it's done with canvas... and then canvas would just be a buffer!

so um... back in topic. 4 player-splitscreen, any ideas?