Ashley's Forum Posts

  • 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.

  • 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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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.

  • Hi all,

    In my relentless feature-trimming in C2, I've come to wonder about the animations system.

    For example, take animation angles. The animation angles system seems to complicate the UI and engine quite a lot, when I think there may be simpler alternatives. The fact you can specify any angle at all for an animation, such as one at 90 degrees and one at 91 degrees and one at 91.1 degrees, definitely seems to be overkill, especially since Construct has always been good at rotating objects smoothly.

    Some common use cases I'm aware of are:

    1) a platform character with a mirrored copy of the texture for facing left and right. Normally this would be two animation angles under one animation (0 and 180 degrees).

    2) an isometric character which has a different texture for 8 different directions

    3) variations on an animation stowed away in animation angles, which probably shouldn't be in animation angles anyway

    Further, sub-animations are a nice idea, but I'm not convinced anyone's actually used them. I'm not sure what features we thought sub-animations would enable, but it doesn't seem to be anything you can't do with ordinary animations and events. Sub-animations make the UI more complicated and have been a source of tricky bugs in the engine, so I think they should be dropped completely from C2.

    So what could we do instead, that covers all these features, but in a simpler way? I thought about it, and I propose a new system for C2 which:

    • has no sub-animations
    • has no animation angles
    • allows you to arrange animations in to folders, a bit like things in the project bar. For example, you could have an animation folder "Walking", with two animations contained within called "Left" and "Right". The names of these animations would then be "Walking\Left" and "Walking\Right".

    This is more organised than a flat list of animations, while removing the cruft of sub-animations. You can still simulate animation angles with different animations in a folder, e.g. "Walking\Right", "Walking\DownRight", "Walking\Down" etc. and setting up some simple events that chooses them based on the object's angle. There would also be no animation "tags", so behaviors would not try to set animations for you. The events to set up animations are so trivial it doesn't seem worth trying to make the editor do it for you with unnecessary tags and angles gadgetry. Also, predefined tags like "walking" and "shooting" mean Construct is making certain assumptions about the kind of game you're going to be making, and I don't think a general creation tool should assume things like that for you. (Bit of a philosophical point.)

    Another example - take an object with these animations:

    Stopped

    --- Left

    --- Right

    Walking

    --- Left

    --- Right

    Running

    --- Left

    --- Right

    It's dead easy to set the right animation - something like this will do:

    + On left key pressed

    -> Player: set instance variable 'direction' to "left"

    + On right key pressed

    -> Player: set instance variable 'direction' to "right"

    + (negate) Player: is moving

    -> Player: set animation to "Stopped\" & Player.direction

    + Player: is moving

    + Player: speed < 20

    -> Player: set animation to "Walking\" & Player.direction

    + Player: is moving

    + Player: speed >= 20

    -> Player: set animation to "Running\" & Player.direction

    etc.

    To me this system seems just as capable, and a lot simpler both engine-side and for the user. What do you think?

  • esizing in the image editor after a sprite image has been saved once doesn't change the "Size" of the sprite

    This was by design, but I suppose it's better if it scales the object proportionally. Will add to the next build...

  • You do not have permission to view this post

  • You do not have permission to view this post

  • You do not have permission to view this post

  • <font size="6">Download Construct 2 public preview 45</font>

    Link to release 44

    New this build: an early version of the image editor! This is a joint effort between me and Davo so far.

    <img src="http://84.45.57.142/downloads/construct2/r45.png" height="452" width="532" border="0">

    It's not very far done, so first assume it does absolutely nothing at all. Now, here's what it can do:

    • Display the texture being edited.
    • Clear the image to all transparent.
    • Import and export image files in PNG, JPG, BMP, TIFF and GIF format. (Note there's a bug in Classic where it doesn't save alpha channels correctly - this is fixed in C2.) I recommend PNG for everything since it's got good lossless compression and alpha channel support!
    • Mirror and flip the image.
    • Crop away transparent edges. This always leaves a 1px transparent border around the image. This will ensure that older graphics cards and browsers which sometimes have "hard" texture edges show them softly still. (I just realised this is annoying for tiled background - I'll turn it off for tiled textures in the next build :P
    • Resize the image canvas. You can align the image top-left, center or have it stretch with the canvas.
    • Toggle the background brightness, in case you're viewing e.g. a white spot with alpha channel.

    That's it! No actual drawing tools yet. These are on the way, as well as support for animations. However, it's a bit quicker than launching an external editor, and hopefully should eliminate the "why is it launching Paint?" headaches.

    Since you can undo texture edits there's also an option to always save when you exit without prompting, to make working a bit faster. There's a checkbox for it in preferences, and in the prompt to save changes in the image editor itself.

    The image editor also uses an OpenGL renderer - watch out for graphics glitches, since this might trip up some drivers. (That can usually be coded around, though.)

    Changelog

    • [Feature] Picture editor
    • [Add] 'Always save' option for the image editor in Preferences.
    • [Change] Sprite: hot spot now defaults to centered, but rounded to the nearest whole pixel in its texture. This should correct some pixel-perfectness issues.