Thanks for clearing that up, Ashley. Definitely a good idea to add it to the manual.

I suspected that was the reason you hadn't already. Glad to hear you still hope to at some point!

I've read up on it, as as far as I understand it, that's still incorrect, as I don't think C2 is blitting at all, I'm almost 100% positive it's billboarding instead (using flat texture mapped camera facing polygons). Even from the link you posted, it describes rendering being the process of having a scene file that is converted into a raster image, the drawing of the pixels themselves being a part of the process. I've rendered stuff in plenty of 3d packages, and none of them have ever wasted time rendering offscreen pixels, which would be a completely pointless waste of time, and I showed that C2 does not do that in my example above.

It's my understanding that first, a scene 'file' is generated that contains all of the vertex information for all of the objects in the scene (Ashley reuses the data generated for collision polygons as an optimization). Then that data is used to draw the screen from, drawing the parts of each object that are on screen back to front. This can cause overdraw by drawing the same pixel multiple times if that pixel is overlapped by multiple objects. While the vertex information for offscreen objects is still there, it isn't used for the actual drawing of the image itself because the graphics card only draws what is inside the screen.

I could easily believe that the graphics driver would cut down the undrawn vertex information to only what objects are on screen, which would make sense, but the drawn image itself? No. Cards have limits to their pixel fill rates and drawing offscreen pixels would be terribly wasteful. Also, the graphics driver or card having to check if the geometry is onscreen is a calculation that the driver can likely do far faster automatically than anything that could be done to try to optimize with JavaScript while still having the objects available to process in code/events.

In practice, it doesn't matter even if either of our understanding is incorrect. Not even minecraft draws things out into infinity - it, like games all the way back to the nes and earlier, create/generate and destroy/store objects based upon distance because even writing the most optimized assembly possible wouldn't be enough to overcome the fact that computers have limits. If someone wants to have a million objects in a layout like Bobofet, then they should implement a dynamic system to load and destroy objects as they get close to/far from the screen, same way everybody else does it.

Bobofet - if you're using a grid like minecraft, saving/loading the instances to/from an array would work great for that. Also, you might want to do a distance check for the tiles you're checking for collisions with to reduce the number of collision checks. Also, tiled objects render faster than lots of small sprites taking up the same space, or as Tokinsom suggested, paste the tiles to canvas then load the canvas image into a sprite.

Rexrainbow was actually talking about possibly making a plugin that would load/create or save/destroy instances based on distance automatically - I reccommend bugging him for it, because I want that plugin too. :)

rabidsheep - everything I've heard from people in the know indicates that is incorrect. GPUs are extremely optimized as chip makers try to get every bit of performance out of them as they can. There's no reason at all for a card to draw offscreen pixels as it's a complete waste of resources (unless you're doing something tricky intentionally like the what Ashley does to get text rendering in webGL by drawing text to an offscreen canvas then converting it into a texture that webGL can use).

You can demonstrate this by making a layout and sprite 1,000,000,000 pixels wide and tall. That would require the graphics card to process 1,000,000,000,000,000,000 pixels per frame (which no current card could handle) and I still get 60 fps.

Unless I'm misunderstanding your terminology somehow. I'm not sure how you consider rendering different from blitting to the screen.

If you think they're still being rendered because you're noticing the fact that simply having tens of thousands of offscreen objects in the layout affects the performance, that's not because of rendering, that's because objects have a little bit of overhead code-wise even if they're not doing anything at all, and they still get processed by collision and variable checks and such.

Tokinsom - that is a great idea, passing the canvas to a sprite so it doesn't hit the frame rate in webGL mode.

rabidsheep - graphics cards automatically don't render offscreen objects.

I don't know why anyone told you not to use global variables, there's no problem using them. Local variables as well. Simply use whatever is best suited for the task at hand. For example, I used to use the dictionary object for temporary variables is CC, but since C2 has local variables, I find those more convenient instead.

Eh, I'm kind of disappointed in the review - they reviewed a prerelease unit, and their biggest complaints are the lack of games and the ui, both of which will very likely change before the console is actually released. They should have treated it as a preview instead.

Wow, that is a lot of rep for someone who appears to have barely interacted with the site at all - and was apparently only active for less than a month two years ago. Seems like a bug. Tom?

The best options have been mentioned, creating them via events/using a single layout for multiple levels (if this is ui), or you can paste them in then use the arrow keys to align them by moving them all at once.

Whiteclaws - if you're copying and pasting the same thing across 50 levels, it can become a tedious task, especially if you make an edit and then have to redo the work. Nothing wrong with wanting tools to help improve that. That's one of the whole ideas behind the event sheet includes, so you don't have to copy and paste your events repeatedly for different layouts.

There's actually a feature CC had made specifically for this ? I think they were called in inheritance layers. You could enter a name of a layer from a different layout, and it would automatically have all of the objects from that layer created at the start of the layout (sort of like 'layer includes'). Hopefully C2 will get it eventually.

Well, there used to be the link to use mibbit - I've wondered why the link got taken down, as the irc channel still exists, it's at irc.esper.net, #construct.

R0J0hound - Are you planning to make this plug-in work with webGL at any point without using the workaround that it's currently using? I really hope you will, as it currently hits the frame rate pretty hard when using it with webGL.

Yes, but I thought that was what you wanted. Sorry if I misunderstood your post.