Arima's Recent Forum Activity

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • It's fine if you write your posts in other languages if you also include an English translation as well.

  • There's a thread for it here:

    I already deleted it for you though, so no need to post there.

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

  • pedropss - I didn't mean to imply that I was unhappy with him helping - it's simply the policy of this forum for everyone to stick to English, or to additionally provide a translation. It becomes very difficult for us to moderate when we have to translate everything but by bit.

  • Hey. You might have missed something. Riiiiight above your post.

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

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

Arima's avatar

Arima

Member since 11 Jun, 2007

None one is following Arima yet!

Connect with Arima

Trophy Case

  • Coach One of your tutorials has over 1,000 readers
  • Educator One of your tutorials has over 10,000 readers
  • Email Verified

Progress

19/44
How to earn trophies