sqiddster - as far as I understand, in full-screen mode, the graphics card only has to draw that one application's window, it doesn't have to consider any of the others, so that means less work for it.

Yeah, it's just frustrating having no other options available. I have access to a low-end laptop that simply doesn't have any better drivers available, so the performance is subpar, not to mention getting a lot of users to update their graphics card drivers is a difficult task, they often simply won't bother, or aren't computer literate enough to feel comfortable doing so. If I could set it full-screen mode and lower the resolution, then at least I could try to work around it somehow. :/

I was referring to having a larger version of an object with the same number of points in the collision mask. Sorry if that wasn't clear enough. Having more points, as you point out, will be more work than an object with less points as there are more polygons to check, but two objects of different size with equal collision masks should require the same amount of processing power to check.

I would definitely like an option to set the screen's resolution, and I would also like an option to go into true full-screen mode. Currently node WebKit uses a borderless window that's set to the size of the screen. True full-screen mode generally has better performance.

Part of the problem with low-end laptops, as far as I understand it, is the lack of proper OpenGL support. If the computer doesn't properly support OpenGL, then it uses something that I think is called ANGLE that translates the OpenGL calls to directx, but incurs a performance hit. If it can't do that either, then it falls back to software rendering, which obviously incurs a performance hit as well.

You can already do this with subevents. Simply have a 'state' variable and change it, and it will use the sub events in the same manner. You don't even need to use separate event sheets, but if you want to, just use event sheet includes.

If 'state' = "clockwise"

• rotate sprite clockwise
• (or include event sheet)

If 'state' = "counter clockwise"

• rotate sprite counter clockwise
• (or include event sheet 2)

Because the collision detection is polygon-based, one large object check requires the same processing power as a smaller version of that same object. Having one large object to check is definitely more efficient than having lots of small objects.

fassFlash - that was unnessecarily rude, how about trying some constructive criticism instead? Like "your work would really be improved by learning about color theory. You can search google for color theory tutorials, it'll make your work look much better."

From forums, articles, conversations with people more knowledgeable than I am, etc. It probably would be good to have a manual entry or maybe a tutorial explaining some of the more technical details behind unsderstanding rendering.

2D and 3D aren't mutually exclusive. If C2 got 3D capabilities, you wouldn't have to use them. There's really no downside to having both.

Tobye - it's sounding like probably not with the current state of the tech, as Ashley explained. For future game design, it's probably best to use the method Yann described.

Ashley - thanks for the detailed reply, I had been wondering how they did it in 3d.

Ok, let's not start throwing accusations of trolling or insults. —, as it has been pointed out, the information contained in the earlier part of the thread is not the current situation, and hasn't been for quite a while. Scirra has a huge todo list and they hadn't gotten to it yet at that point those posts were made. The current situation is a lot of work has been done by both scirra and ludei to get c2 working smoothly with cocoonjs, and it works quite well.

Hmm, I wonder if something like this could be implemented as a plug-in at some point. It seems like something people frequently want to do, and if a plug-in could stream in and discard segments of a texture dynamically based on distance, I think it would really help.