Arima's Forum Posts

  • C2 has half or less features of CC, and who cares? Desktop developers want native apps, they don't care about html5, js and how fast they are

    C2 has easily more than half of CC's features - especially the relevant ones. A lot of the features that CC has that C2 doesn't are useless to most people (like the graph plugin or whatever). The fact that its lacking relevant features compared to CC isn't because it uses web tech but because it's much newer than CC and Ashley can only code so fast.

    Also, a lot - and I mean, really a LOT of developers are interested in html5. Google, apple, Microsoft, intel, and tons of other huge names are backing it.

    look at steam, every game is native.

    Not true. If you reread my first post in this thread:

    Html5 isn't some proprietary plugin like flash - it's part of the standard of the web as much as normal HTML is. It's not going anywhere. In addition, node webkit is an exe just as much as any other exe. There is a game on steam which uses it (game dev tycoon) and even has integration with steam's API. There's no reason not to use it.

    Game dev tycoon uses node webkit, same as C2 does. It's on steam. There are also games made with flash on steam, which isn't native either.

    I honestly don't understand what problem you have with the node webkit exe export then. If you don't care about the speed difference, and C2 can do almost all of what's relevant that CC could do, with almost all of the rest of it on the way, the games look and run exactly like other exes because they are in fact, actual exes that can be distributed on steam, what problem remains?

  • they are standartized (like html) web (like html) languages, that would be just silly to try make games on them, thats how currently html5 looks like

    I don't know enough about the technologies you mentioned to determine their viability for making games. I assume they aren't though, because if they were they would have likely gotten the kind of attention html5 has been getting. If it works, there's nothing silly about it - and there are even benefits, like how easy it is to get it on other platforms.

    > HTML5 is the future... It's set to replace Perl, PHP, and ASP.net as well as flash with less overhead and more functionality.

    Yes, i heard that, but don't touch exe, even if you can replace directx with opengl

    While JavaScript isn't as fast as C++, C2 still compares well to CC's event execution speed, and in practice is plenty fast enough for most games, especially on desktop. C2 even actually renders faster than CC does because its renderer was coded better: https://www.scirra.com/blog/102/html5-games-faster-than-native

    Simply put, the same game could be made with both CC and C2/node webkit, and players wouldn't be able to tell the difference aside from the loading screen unless they browsed the files inside the game directory.

  • I'm not sure what you're asking?

  • well, too bad. Just because html5 won't stay for a long time, but EXE games are forever (steam, anyone?)

    Html5 isn't some proprietary plugin like flash - it's part of the standard of the web as much as normal HTML is. It's not going anywhere. In addition, node webkit is an exe just as much as any other exe. There is a game on steam which uses it (game dev tycoon) and even has integration with steam's API. There's no reason not to use it.

  • Ashley - I think it should be an option we could choose, because the offline cache is only useful for some games and platforms. For those of us with larger games that aren't targeting the open web or platforms you mentioned, the offline cache is irrelevant because we're not using it since the game is offline anyway. Loading an entire large downloaded game at startup in those circumstances seems really unnecessary, and might limit some of what we can do from the high memory use (imagine something like an rpg with HD assets all being loaded at once). In addition, even if I wanted to use the offline cache for my game - which I don't - 99% of the time I'm running my game is in preview, which would load far faster if C2 had this feature.

    This is one of those scenarios where choosing to have the feature or not causes problems for the people who are on the other side of the fence - which is why having an option to choose would be optimal for all users (something simple like if use offline cache is set to on, all manual memory management events are ignored).

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I think this should be taken one step further - I think we should be able to have some manual control over the way the assets are loaded.

    It could be kept simple with two actions and two triggers:

    Action 1: 'load layout assets' - used to download the images of a layout. Works in the background while current layout plays, same as how the loader layout does.

    Action 2: 'preload layout' - used to load images in a layout to the gpu (like the action CC has).

    Trigger 1: 'layout assets loaded'

    Trigger 2: 'layout preloaded' (both triggers take a string so you can tell which layout has been loaded)

    With these actions/triggers, virtually all loading and pauses when switching layouts could be eliminated. Level 2 could download/load images to the gpu when level 1 is playing, or when the player gets to the edge of a level, make a 'loading' layer appear that could be animated, and go to the next layout when it's done.

    I would really like to have this because it would help speed up previewing and initial start up times for players. 99% of the time I'm previewing, it's on one layout. If I could control it so the preview loads that one layout instead of the entire game and manually load the others when I want them, it would be quite a lot faster.

    Similarly, it would also be useful to have 'load object assets'/'preload object'/'object assets loaded'/'object preloaded' to help stop stutters when an object is created for the first time and the game pauses as the images are sent to the gpu. But I think that's not as important as the layout ones.

  • When we didn't have this limitation, spam was out of control, we couldn't keep up with it.

    There are a number of easy ways to quickly increase your rep. You can also post links without using the link tags. People will have to copy and paste it, but it will still display.

  • Finally, an affordable eye tracking system. If it's as accurate as it claims, and can be used to control a computer in it's entirety instead of just applications made to work with it, this could be huge news for the disabled. At $95, I'm pretty tempted myself.

    Edit: upon digging further, it appears they have done a lot of work in that area already.

  • I'm not sure what it's supposed to be doing exactly, but it looks like you're destroying all the objects in the first for each loop then trying to run a for each on the objects that have been destroyed. Try having a every tick event after the second for each that destroys the classic_bck object instead.

  • I haven't tested it yet but in CC you could execute a file and instead of a file path, put a http web link instead.

    The browser object has screen width and height expressions.

  • I seem to recall if your card is blacklisted, chrome lists it's using hardware acceleration even if it's actually using swiftshader (because swiftshader is emulating hardware acceleration). Try running chrome with the blacklist disabled, if the performance improves, you know it was using it. That's the only way I know of to get chrome to reveal if it's actually using swiftshader or not.

  • Wow, awesome! I wonder if it would work with one of the 3d plugins...

  • Looks like it's free now.

  • Hmm, I suppose it's true that they might not recognize the phrase 'layout by layout loading' to mean memory management.

  • Disappointing is right. Mobiles have major memory constraints, and as such memory management is simply essential for having anything more than a very small game, even in tools that are not c2.