Ashley's Forum Posts

  • You do not have permission to view this post

  • <span ="Apple-style-span" style="font-family: Arial, Helvetica, sans-serif; font-size: 15px; -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; ">@MelodiousRefraction, have you tried updating your graphics card drivers to the latest version?  It's not to do with pixel shaders, it's to do with OpenGL framebuffer object support.</span>

  • You do not have permission to view this post

  • I appreciate you liked the last site, Kisai, but from our point of view it wasn't very good.  We need a site to educate new visitors quickly and clearly show what our site offers.  I think our old site did not do this well, and needed replacing!  I'm really happy with this one and I think it will work out better in the long run both for long-time users and first time visitors.<div>

    </div><div>We've deliberately launched the site early without all the features we want to have.  Like with Construct 2 itself, we're releasing early and often.  So if you have suggestions, let us know!  This is not the final site forever!  We're going to keep evolving it, fixing things, adding features and polishing it over time.  We need to hear from you though - tell us what you like and don't like, and we'll be right on it.  The site wil be under active development for the forseeable future so we're listening.</div>

  • You do not have permission to view this post

  • If you can afford it, get an SSD. You only need a 64GB to install windows + your fav programs on then have a bigger HDD for all else. SSD really is an excellent upgrade for any system.

    Seconded! Literally feels like it doubles the performance of the system.

    Just be warned - I've heard SSDs fail quite regularly. If you make sure all your important files are on a different drive, you should be fine. Just remember by default Windows puts your files in My Documents etc., which will be on the same drive as Windows. Then, if the SSD fails, no worries - just pop in a new one and reinstall Windows. Of course, you should be backing up all your important files regularly anyway!

  • You do not have permission to view this post

  • — - yep, for security reasons browser makers sometimes blacklist drivers, like Firefox 5 did with my card - you'll get software rendering if your drivers aren't up to date. (Sadly nVidia don't seem to have any recent drivers for my card.)

    Tom - first sighting of IE9 being faster than Classic! Impressive!

    A lot of that is because of the pixel fill rate of the card, though. It gets interesting if you resize the sprite to 12 by 12 and run it again:

    You're right - if you do that the time to render the sprite is very small, and then you end up basically measuring the overhead per draw call. CC is exceptionally good here - it has an extremely low overhead renderer, specially written for that goal. However, it's an unrealistic goal - even with lots of particle effects, it's very rare for games to be drawing more than a few hundred sprites on screen! So CC is optimised for a very rare use case. So I actually don't think it's important that browsers aren't so good there. When do you ever have 10,000+ 12x12 objects on-screen other than in some technical test? The reduced performance is probably the overhead of the javascript, browser security checks and overhead, and so on.

    As for your other test, it probably still is only measuring small-object draw performance. A test that checks the raw event running performance - perhaps a 'repeat 10,000 times' event performing some simple action - would be interesting. I might make one!

    Also, I'm a little confused - you said HTML 5 is supposedly able to be close to c++ speeds (when compiled to machine code), but you also said that it wasn't fast enough to do pixel perfect collisions.

    Google claim their Crankshaft engine is close to C in speed. However, the pixel perfect collision engine in CC is also very unusual in its extreme efficiency - between Davo and I, we came up with a system that generates bitmasks in memory (one bit per pixel) and intersects them using MMX instructions to check 64 pixels in one CPU instruction! It had to deal with rotation, scaling, byte-addressing and bit shifting, machine endian, aligned allocation and memory padding to name a few of the challenges. It's probably one of the most extraordinary bits of code I've helped write. In short, it uses every trick that C++ offers to access the raw CPU capabilities. Javascript offers very few of those capabilities. It's a browser programming language, not a machine programming language.

    But who knows - maybe it will be possible in the future? Browsers and processors are getting faster after all... polygon collisions are a safe bet for the time being, though.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Hi all,

    In response to lucid's thread, I've made two projects to test HTML5 graphics performance, one for CC and one for C2. Both create as many sprites on the screen as possible before the framerate falls to 30fps. I've adjusted both projects to try and make them as fair as possible, they're attached at the bottom. This only tests the drawing speed - not the event engine efficiency.

    The .cap is a Classic r1.2 project. Its engine is optimised C++ code and as you know it uses DirectX 9 to render everything hardware accelerated.

    The .capx is a Construct 2 r45 project. Its performance depends almost entirely on the browser. IE9 is by far the best performing browser, so if you're on Vista or 7, try testing with that.

    You can run your own tests to see how it fares for you. You will need to leave it running for a while, and give it at least 10 seconds to stabilise - it takes objects away if the FPS drops below 29, and adds more if it's still above 30, so it may take a while to settle down and get the best number. Make sure no other applications are running during the test, for fairness.

    Remember: This is testing on-screen objects - many games will have hundreds of objects, but rarely have more than a hundred on-screen at once. When they're offscreen, obviously they take no drawing time at all.

    Here are my results. You can check your graphics card by clicking the about icon in C2.

    Graphics card: GeForce Go 7600 (old laptop graphics card)

    Classic: 748 objects

    C2 with IE9: 619 objects

    C2 with Chrome 12: 124 objects (if you go to about:flags and turn on the experimental 'GPU accelerated canvas 2D', this goes up to 450 objects! I think this will be enabled by default in a future version of Chrome)

    C2 with Firefox 5: They've blacklisted my graphics card driver from hardware acceleration, presumably because it's old. If I force it enabled (about:config - gfx.direct2d.force-enabled), I can get up to 440 objects. Without that it struggles to get over 20 objects but I think that's because my laptop is so old they've decided not to support it.

    Conclusion: Support is a bit patchy and still in-the-works on Firefox 5 and Chrome. IE9 performs the best, though, and is 82% as fast as Classic. That's awesome, considering it's running in a browser! FF5 and Chrome, once their support is sorted out, are both about 60% as fast as Classic. That's still fairly good, considering most games in Classic probably don't push the renderer that hard.

    Bottom line: HTML5 seems to be pretty fast!

  • IE9's canvas performance isn't quite as good as a native EXE's, but I thought it would be better than that. Can you send me both the CC and C2 projects you tested with and I'll investigate? I'm still confident good performance is possible in HTML5.

  • You do not have permission to view this post

  • Taking several suggestions here, how about this:

    Here's a mockup image.

    • there is no permanent animations bar - when you launch the picture editor, it pops up floating to the right of the picture editor (also like inkBot's picture suggested).
    • the animation frames show as a separate bar floating beneath the picture editor. This allows you to size them bigger rather than locking them within the picture editor like CC.
    • the picture editor is modeless - modal dialogs mean you can't click anywhere outside the dialog until you close the dialog, like the CC picture editor. If the C2 picture editor is modeless, you can use the rest of the UI while the picture editor is up.
    • this means you can use the property grid still to set animation properties.
    • you can also use the main Construct 2 window's undo and redo buttons, to affect changes you made to a texture or animation.
    • on multimonitor setups, you could keep the picture editor up on one monitor and quickly check something in the event sheet editor, etc.

    Sound about right? I prefer free-floating bars (like the "expressions pallette" in the event sheet editor's parameters dialog), since they offer you much more flexibility in positioning and using your screen space.

  • Try it in IE9. Rock solid 60fps pretty much no matter what's going on. Most browsers are compiling Javascript to machine code and can reach speeds close to C++. Browsers are also heading towards hardware-accelerated canvases - IE9 is the first to do it really well, and uses the GPU for all rendering. It doesn't really matter what programming language you use to send draw commands to the GPU (whether its C++ or Javascript) - it's always going to be blazingly fast so long as you offload all the work to the graphics card.

    I think Firefox 5 might now be a lot better too, but I'm on an old laptop and the troubleshooting page says it's blacklisted my driver! Give it a shot, it's supposed to be using hardware-accelerated Direct2D (the 2D version of DirectX for Vista and up).

    So shortly nothing will be slow in HTML5 - people just get the impression from old browsers which aren't optimised yet.

  • Something that always bothered me in CC... no calls for flip or mirror in actions.

    Could we get those added for C2?

    HTML5's canvas can't mirror or flip images automatically, AFAIK. You'll have to pre-flip and pre-mirror them in the editor, but I'll add tools to make it easier.

    Being able to call up and manage assets from folders rather than bogging the game file down with them is just beautiful and useful.

    You do know if you save as a project everything's already in separate files, in C2? So would it be enough to just be able to manage when those textures are loaded in to memory?

  • Will it be possible to import animations at runtime?

    Maybe in future, but there are too many other essential features to do first, so anything along those lines is probably going to be postponed 6 months+ away.

    [quote:1dym73cr]And what do you think about having animations as behaviors?

    It's an interesting angle, very innovative, but I don't think it fits. You can't arrange animations in to folders neatly. It also doesn't really make sense to add animations to objects like Text. It also rubs me the wrong way in a general way - I don't think an object "behaves" like it is animated, although it can "behave" like it wraps or like a solid thing. There's also the question, what does a sprite without any animations look like or do? Finally there are technical issues in the engine - unless I made some tricky changes, you'd get multiple "set animation" etc. actions, conditions and expressions for each and every animation you add via a behavior. So nice idea, but in short I don't think it will work.