Ashley's Forum Posts

  • Closing as not a bug.

  • Both run 60 fps here.

    My best guess is:

    1) all your 'for each' conditions are redundant except the one in 'on start of layout'. Events naturally run for-each instance, so you only need that condition in corner cases where the event system's default behavior is not enough. Adding 'for each' to an event where you don't need it can cause slowdowns because it forces Construct 2 to repeat the event 250 times with one instance each time, rather than handling all 250 instances in one go. I had to create 5000 stars to get the fps to drop on my computer (!), and the fps nearly doubled when I took out the redundant 'for each's!

    2) I can't see the GameMaker project, but I assume you just painted stars directly using some draw function. This is more efficient than Construct 2's sprite object and is one of the areas scripting can get ahead of events. Despite spending a lot of time ensuring sprites are as optimised as possible, they still carry a lot of "weight" like instance variables, collision polygons, and the event system which has to do extra processing compared to what a script would do. (GameMaker's Sprite is not really directly comparable since it represents an image only, its Object is a more appropriate comparison.) In most cases I would think the same thing in both would run about the same speed, but this is one of those specifically-designed cases where a difference can be seen. Not totally sure here, but it's my best guess.

  • Ah, thanks for the report, should be fixed in the next build.

  • You do not have permission to view this post

  • If you already know the necessary server-side coding, there are just a few really important points you need to know:

    • run the game in an iframe on a different domain to your website. We run the games off static1-4.scirra.net, and the parent frame is scirra.com. These count as different domains, and the browser blocks the iframe accessing anything in a different domain, meaning the website's info is safe from the game. (This is the same principle that stops any website AJAX'ing Facebook in the background to get your personal info.) You can also try sandbox="allow-scripts" on the iframe for extra security.
    • have a whitelist of allowed file extensions or filenames - do *not* allow anyone to upload any .aspx, .php files etc! Just have a whitelist of files that are allowed e.g. index.html, *.js, *.png, and reject anything else.
    • it's best to manually verify all entries to ensure there's nothing obviously malicious going through.

    Our arcade actually has extra steps to ensure double security: the Arcade export format is data-only, so the user does not actually upload any javascript code at all. This means the games only ever use our official runtime code and previously approved plugins. However this is technically complex to set up - you should be OK with the above steps only.

  • Try this:

    http://www.scirra.com/labs/sbmobileweb3

    It's "Space Blaster" adapted for touch control. I haven't publicised this much though because it has a few problems:

    • there's no sound because Safari doesn't support HTML5 audio properly (this can be worked around with the PhoneGap or appMobi containers)
    • it was designed as a desktop game, so it's too intensive to get good performance on an iPad 2 (it will be worse on iPad 1). Games need to be designed to be simpler and less intensive to work well on mobile, but I haven't had time to do this
    • there's no way to stop Safari changing orientation, which can mess up the game at certain points. It's designed for portrait

  • I think the main trouble with new exporters which people aren't really thinking of is third party plugins and behaviors. There are already over 100 topics in the Plugins forum, and think about a few years down the line, especially if C2 increases in popularity. Imagine there being 1000 third party plugins. It's great that C2's extensibility makes it more useful to a lot of people, but on the other hand it causes a disadvantage with new exporters.

    Take a new C++/EXE exporter: after a lot of work it may be possible to have an official runtime working. However, what do we do about the 1000 third party plugins? That's years more work if we try to do it ourselves. Then, the Javascript SDK is designed to have an extremely low barrier to entry: you can just pop open Notepad and type some javascript you remember from web page development, and you've got a new plugin. For a C++ exporter, plugins would likely also have to be written in C++. The tools are much more complex for this (e.g. Visual Studio is a lot more complicated than Notepad, especially if you get build errors), and the C++ language is *much* harder than javascript, you need to worry about memory and pointers and such and a great deal of things javascript takes care of for you. Not only that but if you're porting a javascript plugin to C++ double care has to be taken to ensure it's *exactly* compatible, to ensure ported projects actually work the same (otherwise there will be subtle and frustrating differences when you port your game). The question is how many javascript developers are up to this, especially if they're just hammering out a plugin in notepad in their spare time? I anticipate the majority of plugins would not be ported. Then, the majority of existing projects cannot be ported anyway due to their dependence on third party plugins. You can design a project from scratch using just the right set of plugins but one of the strengths of keeping the HTML5-only approach is all plugins automatically work on all platforms without any worry whatsoever.

  • I don't think either PhoneGap or appMobi's audio engines support looping.

    PhoneGap supports the 'On ended' trigger, so you can do 'On music ended -> play music'. I haven't managed to get appMobi to support that one yet though, so for appMobi you'll just have to do something like "Every 30 seconds -> play music" (and work out how long the music track actually is).

  • This has been on the todo list for ages, I'll try bump it up.

  • I think the OGG encoder simply doesn't support such low frequencies - 8 KHz is pretty darn low. Have you tried using another tool to upsample it to say 44100 Hz?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Remember Adobe have already announced they're stopping development of Flash for mobile, so HTML5 is probably better in the long term for mobile gaming.

  • imothep85, Construct 2 supports WebGL and my last benchmark can get 14000 sprites on-screen at 30 fps. So it should be able to do 7000 at 60 fps already.

  • Well, I've said it before and I'll say it again, right now other exporters are not even an option! We're a tiny 2-man team and the HTML5 exporter + runtime has been in development for over a year, and we're still tweaking and adding stuff to it. It's just impossible for us to take on such a large project. Other companies either have more resources, or less features and no third-party plugin system which makes it much easier to write ports since there's a great deal less technical complexity. We're also still too small to safely throw money at the problem and just hire a bunch of people to do it. On top of that, we genuinely think it's only a matter of time before HTML5 is really fast and great for mobile games. We're a little ahead of time, really. And I cannot think of anything worse than spending time we don't have developing iOS/Android native runtimes, then by the time we're done, HTML5 is fast anyway so all that time was wasted. Not only am I happy to wait it out, it's our only option really.

  • Having your site go down when you turn your computer off is a pretty big downfall!

    And if you're running a server from your own computer, most ISPs have conditions saying you're not allowed to use your computer as a server, so they may end up blocking your connection as well. Hosting is really cheap, TBH it's best just to get a cheap paid host, there's a lot of benefit to that.

  • You do not have permission to view this post