I'm on USA's south-east coast.

The closest you could do is set private variables as a workaround, I guess, but it may not be something within the scope of the free version.

Yes, but the stat crunching and data manipulation aren't for the feint of heart.

I've been doing it all manually with lerp and such, but this would definitely simplify things and possibly be more effective.

Wow, that's a MASSIVE difference in performance between the two! For extra fun, leave both tests enabled simultaneously and watch the trippy fun!

Now as far as big games go, in the case of Penelope, I suppose during the start of your levels, you could spawn in all of the necessary objects before your fade-in (so users don't see the chug) and then just run loops in functions each time you need an explosion and have it pull from your cache of off-screen objects. It would be a pain and would be tough to retrofit in a game that is probably as far along as yours, but given enough instances of this, you might actually boost framerates on lower-end PCs by a worthwhile margin. It would just be time-consuming.

But maybe that's why I've been able to get so many objects on-screen at any given time in Courier. They're largely static (well, they move, but most aren't created dynamically). All of my levels are pieced together from lots of smaller pieces (to reduce how much of a hit your GPU will take and so I don't have to draw as much), but they aren't being actively created and destroyed on the fly. The only things that do that are effects, and I suppose I could probably improve things a little this way. I could probably manage more particles, fireflies, dirt in the air, etc. this way. I'll have to give it a try. I always knew it was more efficient, but that's a dramatic difference!

I like it a lot! I'm curious how you're going to design things with abilities being stripped. Mostly, I'm curious about player reward and bringing fresh things to the table. I look forward to how you're going to handle that!

Huh I forgot to hit Submit. sqiddster For such a large area, I don't think the performance would be any different doing it on a layer vs doing it on a big object. And the moment you have a second object on-screen with bumpmapping, you're now having multiple shader calls instead of one for the layer. It's almost always on a layer in my game since I have multiple objects with it applied.

And also, I agree the shader could use an overhaul. Firstly, the Y axis is still inverted so light is shown from the wrong direction vertically. It works fine for scrolling and layout scaling. I haven't tried anything more advanced than that, so I haven't run into the other issues that shinkan mentioned.

That is odd. And just for time-saving's sake, this error is not present when the bumpmapping shader is applied to a layer instead of to an object. Ie, putting the normal map on its own layer and applying the shader to the layer instead of the object. I suppose if it can't be fixed, this workaround could solve it.

Just wanted to pop in and say I really enjoyed it! It was a good discussion, easy to follow, and had some great things brought up. I like the open discussion format, though a little more structure can help. I look forward to hearing how you guys do with guests!

C-7 Thanks again. Which arms? and what needs improvement the effect or the sprites?

The robot arms just could look way more impressive with a little more work.

The breaking effect looks pretty good to me.if you got really fancy, you could show some light go up the tube really quickly like it is bowing just before breaking, but it looks fine and ran fine on my phone. Now you should work on improving those arms!

You will need to forgo the particle object in C2 and run it with events. Every 0.08 seconds, create sprite at x,y. Then tell your sprites how to move, rotate, scale, and fade out (and destroy). It'll the one or two extra events, but then you'll get the control you're looking for.