Arima's Forum Posts

  • Please do not create multiple threads for the same game.

  • Still, I would expect HTML5 developers, by definition on the bleeding edge of tech, to not care about outdated/unsupported platforms.

    Quite a few of us are only HTML 5 developers because we want to make games with C2 but have no other export options.

    Why shouldn't the state of MMF be used as a baseline for comparison? You're well aware Ashley, or as he was known back then, Tigerworks, made construct due to dissatisfaction with clickteam's solutions. This is in part due to Ashley being a better developer, but the vast majority of it is due to learning from clickteam's mistakes!

    You just described why the state of MMF shouldn't be used for comparison. Ashley has proven to consistently be a better developer with better design ideas. MMF has been stuck on legacy code and structure for ages and C2 was built properly without those problems. They're just too different to compare.

    Hiring someone new doesn't change anything: that is one person that is sucking money from Scirra. That same person could be developing something else instead. It's as if you all think the editor is perfect already when it's far from it!

    Someone's not 'sucking money from Scirra' if they are contributing to C2 and implementing features people want, even if you personally don't want them.

    I don't think the editor is perfect, and I haven't gotten the impression that others arguing for native do either. I've stated repeatedly that if native exporters were to happen without hiring someone else, then they should be made later after the rest of the todo list is done.

    Actually I can, and I just did. My personal grievances with Apple aside, the point is that you're always reliant own third parties

    That... Doesn't make any sense. It sounds like you're calling iOS overpriced hype because we're reliant on apple, a third party, to develop iOS? We're even more reliant on microsoft for their development of windows. Not to mention...

    And there's that "third parties are unreliable" issue again. Back when clickteam was developing the android exporter, they ran into some bug in the official Android SDK that prevented them from continuing. Chrome for windows 8 ARM still has many of it's capabilities artificially limited. JIT compilers for iOS are inaccessible, third parties cannot compile. Apple's software can, though, so it's not an engineering or technological problem. This goes to show that even when making native compilers, the list of possible problems with third parties is huge!

    You're arguing FOR one of the main reasons to make native exporters - exporting HTML 5 only causes scirra to be much MORE reliant on third parties, and more third parties, rather than less!

    I'm not saying making native exporters would be problem free, of course it wouldn't. However, as said, the jit compilers on iOS being inaccessible is one of the points that native would solve since we wouldn't have to use them at all.

    Sticking to HTML5 has its cons, but at least there you know the issues will eventually be fixed, since you have giant players throwing their weight behind HTML5's success.

    That's still relying on third parties to fix them. Besides, how do you know that they'll be fixed? Because they're large companies? Google just discontinued support for hardware acceleration on XP and vista. I know you don't care about it, but a lot of the rest of us do. Who's to say they won't make some other decision that significantly impacts us? As you stated, apple doesn't let anyone compile JavaScript except for themselves. They've had this stance for years. What makes you think they'll change that stance? I'm very grateful to intel for making node webkit and crosswalk, as well as them making it free, but what if they change their minds? What if ludei changes course and decides to become a publisher or makes some other decision that ends their service for getting HTML 5 games on iOS? What if they desire to use an exorbitant pricing structure that most of us can't afford? What if they never manage to get their platform working properly for everyone? Guess what happens - our only option is to switch over to another third party - if there even is one - and hope they do better.

    By making native, we rely on third parties far, far less than sticking with HTML 5, where every single device C2 exports to is more dependent on third parties than if it was native.

    Example dependencies:

    Native windows desktop: Microsoft.

    HTML 5 desktop: Microsoft, google, intel. Possibly others, I'm not sure who else is involved (node.js, webkit, etc).

    Native iOS: apple.

    HTML 5 iOS: apple and ludei or intel.

    It's like this everywhere, and not only does HTML 5 require support of a company's operating system, but it also requires that company to additionally properly support HTML 5 in a way that is sufficient for us making games (for example - sony. Ps4. Gaming machine. Yet C2 games run terribly on its browser).

    Why do you think Ashley's solutions would be better than existing solutions?

    I've already explained that in my previous posts. Another point I didn't mention is they did quite a good job on construct classic's runtime, and that was their first attempt. I imagine a 2.0 would be even better, same as how C2 is better than CC.

    can you imagine the waste it would be if we had a native blackberry exporter? Symbian? Tizen? XNA? Ouya? Windows Mobile? Ubuntu touch? Palm OS? Bada?

    It's pretty obvious which platforms are the successful ones by now. Native could be made for the major players, and HTML 5 would still exist for the rest. A native exporter would not have to be made until a platform had proven itself.

    Keep in mind I'm talking about the IDE only, not the engine powering the games or the exporter. The most complicated parts are the event editor, the image editor, and the saving/loading of it all into XML. Sounds like, at most, a few months work to convert, though only Ashley can say with any certainty.

    I'm doubtful the IDE could be easily decoupled from the exporter engine and such (and besides, what would be the point then if you had to bring it back from the web to desktop to export?), but because neither of us know the specifics of how C2 works behind the scenes it's pointless to speculate.

  • Windows XP is too old to even be considered! Why don't you go ahead and ash Ashley to support internet explorer 6 as well?

    Because Internet explorer 6 doesn't have the features necessary to run HTML5 games. XP does, and until recently, chrome supported hardware acceleration on it by default. That's more users that can purchase your game. It's that simple. Besides, Ashley already said he's going to make node webkit have hardware acceleration all the time.

    I think that the fact that third party plugins aren't necessary for the vast majority of projects says more about the lack of power in the SDK than it does about the power of construct.

    I disagree. My point was that the built in plugins cover the majority of what games need. IDE plugins would be cool to have at some point, though.

    Working on native exporters is a trap, just look at the state of multimedia fusion 2.5 - practically a joke, after all those years they release a meager update with either nothing new (support for skinning), features it should have had from the start (utf-8) or, at best, features the competition had for nearly a decade (zooming/rotating the layout).

    Again, I disagree. The state of MMF should not be used to assume what the state of C2 would be if they made native exporters. C2 already is vastly better than MMF, is updated way, way faster, works better and has most features that games need, and scirra working on native exporters would not send C2 back to MMF levels of problems, nor would it entirely stop progress on the IDE if they hired someone to work on them concurrently.

    iOS is, as well as everything else apple makes, overpriced hype.

    You can't just call a platform with over 700 million devices sold overpriced hype. Even if not all of them are currently in use, a quick google search implies more than half still are. that means the number of iOS devices in use is rivaling the total number of playstations ever sold (somewhere north of 400 million including psp and vita). Even if you personally don't like it, lots of other people do and it has been a huge moneymaker for some.

    They should be the ones fixing their memory management and enabling webGL/javascript compiling for third parties - we moan at ludei for not fixing cocoonJS but who's knocking on apple's door telling them to get their act together?

    Lots of people, actually, and have been for quite a while, but apple doesn't want to for some reason that they apparently don't want to disclose (or at least in my search for answers I don't recall finding an official reason). Also, memory management is ludei's problem, not apple's.

    And what's the alternative? Making native exporters? Well let me tell you a story about a similar company that went this route, and that's an established game-making company with many employees:

    Which company was that? Regardless, one company's failure does not mean another company will not succeed. There are quite a few frameworks that export native just fine.

    The current editor is quite simple

    It's really not. It's the result of years of work and quite a lot of code.

    so it's not like it would be difficult to port.

    Unless there's some tool like emscripten that could do most of it automatically, I think you're vastly underestimating the task.

  • It's not a matter of defending XP or the use thereof, it's the matter that a significant portion of the user base still uses those operating systems, so it makes sense to target them if you can. 10% or more users is quite significant.

    Regardless, as Ashley said, he's going to make node webkit always run with the blacklist off, which should mean that XP and vista will have hardware acceleration again. I'm a bit concerned about the potential instability, because if the chrome team has decided not to support XP and vista anymore that means they won't try to improve stability on those operating systems either, but hopefully it will still work fine for most people.

  • Arima

    Is your disappoint to do with mobile technology generally or C2 using an interpreted language. There are major problems with developing for a mobile platform when compared to desktop.

    I'm aware of the performance difference between mobile and desktop hardware. The problem is how much JavaScript lags behind native.

    How important is WebGL Effects on mobile to everyone? Cause these are really, really hard to code .

    I might have to hire someone to code it for me.

    On mobile they're less important to me currently because they slam performance so hard so I avoid them anyway, but as hardware improves I'll want to use them more. Maybe the first version can skip them?

    Oh, and Arima - you argue "there's too much uncertainty", but with a native port you'll have uncertainty over supported features instead. As I said before, a native engine is not going to be a magic bullet where everything works perfectly, it will tradeoff performance for other porting incompatibilities.

    I don't think that's an issue of uncertainty because before starting on a project we could check to find out what features are supported on each platform. That actually sounds like certainty to me. And again, native can support the vast majority of what most games need.

    I also absolutely cannot see why examples of single bugs like memory management is an argument for the extraordinarily expensive and time consuming development of native engines. It is *obviously* much easier to fix those problems first before even considering it. This is an ongoing work in progress, but we will get there.

    Well, I didn't mean that was the only reason, I meant for all the reasons combined.

    With modern devices with an up to date browser and OS, performance is already outstanding: as I said before my Nexus 5 can outperform some of the desktop machines in our office on some benchmarks.

    There's an argument to make a native engine to support older devices, but a native engine could easily take so long to develop to maturity that the next generation of phones and software updates would have already filtered down and far reduced the problem. This already happened with desktop. I dread the idea that we spend a year holding up everything else to write a native engine, and then by the time we're done HTML5 performance on mobiles is not a problem. What a colossal waste that would be!

    I understand, but that's the same problem that performance is always behind the competition. Also, again, I suggested hiring someone instead of tackling it all yourself so it wouldn't hold up all the other features so much.

    I still believe that C2 should have native to truly be considered a serious dev tool so we wouldn't have to rely on hope for the exporters. I mean, imagine visual studio or whatever you're using to develop C2 suddenly decided that you couldn't deploy your creations to XP and vista anymore. That'd be insane, right? You wouldn't want to rely on a tool that pulls stuff like that. That's basically what happened to us with chrome and node webkit. I guess I could stick with the old version of NW but what about bug fixes and all the enhancements I'd miss out on, like the improved controller support, and what if C2 is updated to require the new version of node webkit? Then I'd be stuck on an old version of C2. These kinds of things are just unacceptable and are simply going to turn people away from C2, which I very much want to succeed and thrive to it's full potential!

    Anyway, I've made my argument, and I don't know what else I can say to convince you, so I'll stop trying for now. I'll continue to use C2 regardless, and look forward to Tomsstudio's exporter as well as the ongoing improvements to C2 itself.

    Node-webkit is perfect.

    It's not. Node webkit has no hardware acceleration for XP and vista.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Yeah, system>compare values doesn't do any picking so it should be fine.

  • ...wanted to think about this one for a while.

    Ashley - you made a good argument earlier, but I disagree about some of the reasons you posted.

    Exact compatibility with a browser I don't think is all that important, as games don't need everything a browser can do. Again, we don't need an entire browser engine - we just need what games need. Hundreds of thousands of games have been made without needing an entire browser engine.

    As for the issue about third party plugins - as much as I appreciate all the work put into them, even with C2 as it is now, the vast majority of games could be made without them. If C2 was feature complete, then even more so.

    By hiring someone to work on native exporters concurrently, it would reduce the impact the extra work would have on C2 itself. Tomsstudio is showing that it's possible. I agree that the path you took up to this point was the right one, though. Trying to make native exporters while also making the editor and such from the start would have been too much to take on at once.

    Yes, we'd have to create custom code for some platforms. But so does everyone else, to some extent. The HTML5 exporter would still be there for those who wanted to use it instead. It would give us a choice rather than having only one option.

    The point of asking for native exporters wasn't just about solving performance problems, though that was a big part of it - it was also about other things like the issue of no memory management on iOS and about you being able to directly control the quality of C2's own exports.

    More thoughts/feelings:

    • feeling a bit discouraged after years with less improvement than expected
    • disappointed code performance will always be behind the competition's, especially the platforms that really need it like mobile
    • no manual memory management with JavaScript can cause stutters when garbage collection is running. We just have to hope gc collection improves to the point it doesn't cause stutters anymore on every platform, since so many use different code for gc.
    • being rattled by chrome's recent xp/vista software rendering nonsense. We just have to hope the chrome team changes their mind.
    • misses out on export to a lot of platforms (3ds, vita, ps3, ps4, Xbox 360, Xbox one)
    • all we can do is hope that sony and microsoft enable support for html5 games on ps4/xb1, and that performance is acceptable - I tried a test on the ps4 browser and the performance was terrible.
    • I'm feeling better about the android situation after discovering crosswalk is capable of running a game with a lot of assets, but I'm not confident about the situation on iOS. Apple has had the tech for jit just sitting around in the operating system for years and don't let anyone else use it, which makes no sense to me. If they don't want the web competing with the app store, then why do they allow jit on the web, but not in apps? It just makes it harder to make an app using web tech, which as an app, would be on their store. They also have shown no inclination to change their stance.

    What it really boils down to is too much is based on hope. I'm just tired of relying on hope for the quality of exporters to improve, and worse, once we get them, having to hope that a quality exporter isn't later screwed up in some way. Because of the recent XP/vista chrome problem, I feel uncomfortable about the exporter situation rather than secure. Are they going to screw something else up? What am I supposed to do if they do if they do? I have no options, and neither do you, which hurts the quality of your product and your user's products. What's worse is that we don't just have to hope for one company to do things right and keep doing things right, we have to hope for a whole bunch of them to do so, and even if they all did everything perfect C2 would still lag behind in speed and miss out on several platforms it could otherwise export to.

    I think these problems detract from the perception of C2 as a 'serious' tool that can be used for serious development. When choosing an engine for a serious project that might take years and many thousands of dollars, I'm concerned about how many developers are going to look at C2 and just see too many limitations, caveats, problems and potential problems compared to the competition and use something else. There's too much uncertainty. Many people who choose C2 and discover the various issues will eventually move to other engines because of it, as seen by several people who commented they have already done so in this thread.

    I'm afraid I'm still in the native bandwagon. I see how you're playing the long term game and respect it, and I understand your point about trading one set of problems for another, but I think it is more important for your long term benefit to make native exporters, so that C2 doesn't end up as a 'getting started with game development' engine instead of being something worthy of sticking with or even switching to for more experienced developers.

  • There's the pairer object, you could use that which sort of works like a dynamic container (I haven't used it in long enough that I can't remember how well it would work for this purpose though), or you could store uids in instance variables as well as the offset distance and angle, then use a for each loop to place the objects each tick.

  • C'mon, patience. Tom's working on it.

  • This is an English speaking forum, please stick to English or provide a translation.

  • As far as I know, no.

  • The easiest way would be to place another object at its location then use the move at angle action, and have it move 10*NumberOfSeconds at 315 degrees. Keep in mind the location might not be exact depending on the fluctuations of dt if you're using it for physics.

  • Construct is almost exactly the same as MMF2 (now called Clickteam Fusion).

    It's really not. C2 is light years ahead of MMF in pretty much every way aside from native exporters.

  • If you're on XP or vista it uses swiftshader which is software emulation for webgl, but it's not perfect, and sometimes the effects don't work correctly.

  • You put all of the assets into 1 layout and it ran at 750mb? Pretty impressive heh.

    Sorry, no, should have been more clear, I added maybe 500 mb of images to the about 250 mb that was already there, and spread the new images across 3 layouts that never get visited.

    If the VRAM usage of the construct classic version of loot pursuit is anything like the C2 version (C2 version should be less because I set it up better), total VRAM in use shouldn't be above about 100 mb at any point.