It also might be a blacklisted card or driver as well, rather than the hardware itself.

You know, opengl/directx doesn't require you to install drivers every freaking time

Actually, directx is notorious for not being backwards compatible with itself. For example, if you have dx10 installed, that doesn't mean you can can play dx9 games. You still need to install dx9.

More so, dx9 isn't even truly compatible with itself. There's a zillion different versions of it, most of them confusingly with the same version number, and because games rely on a dx version made at a specific date as later versions might make breaking changes, they make sure to install that version along with the game. That's why steam installs directx like every time you install a game. Sure, the computer might have dx9 installed, but does it have the RIGHT dx 9 installed?

[...]it extends, improves and rationalises the markup available for documents, and introduces markup and application programming interfaces (APIs) for complex web applications. For the same reasons, HTML5 is also a potential candidate for cross-platform mobile applications.

Games are applications. The definition of application (computing): "A program or piece of software designed and written to fulfill a particular purpose of the user." That purpose can include entertainment/gaming.

Javascript on client computer might be disabled (for example due to a security reasons), what's next?

JavaScript is disabled in the browser, not as an entire computer setting. If you disable it in Firefox, it won't affect node webkit.

Ashley - I'm aware of that situation. If a person was making a game where the intro/title screen was 50 mb and level 1 was 100 mb, there would be no problem having them both on a 512 mb card. Knowing what we could do would be made easier with 'remaining VRAM' or 'total system VRAM' expressions, if they're possible.

Another example is if someone was making a very resource intensive game, they could do this instead:

Game starts, intro_and_main_menu layout runs.

At start of layout, load images from disk to ram: "loading" and "Level 1"

C2 now has the "intro_and_main_menu" "loading" and "Level 1" layouts in RAM and "intro_and_main_menu" in VRAM.

Upon clicking new game, go to layout "Loading"

C2 then dumps all the textures from the "intro_and_main_menu" layout from VRAM, loads the very small amount of textures on the "loading" layout and runs it.

On start of layout: load images to VRAM: "Level 1"

C2 now has both layouts "loading" and "Level 1" in VRAM. This happens smoothly as the loading layout can keep running, being animated and there's no concern of the music stopping from it taking so long to move the textures to the gpu. The loading layout is small enough that it's not a concern having them both in VRAM at the same time.

On textures loaded to VRAM: "Level 1", go to layout "Level 1"

C2 dumps "loading" layout's textures. Level 1's textures are already in VRAM, it starts instantly.

This way we get flexibility and control over how we want it to run.

As for the pausing problem when creating objects from other layouts that haven't been loaded yet, we could just do the same for objects with 'load object files into ram' and 'load object files into VRAM' actions with triggers for when they're finished.

Having 'unload layout textures from VRAM', 'unload object textures from VRAM' and 'unload all unused textures from VRAM' actions would be useful as well.

I can understand why you might be reluctant to incorporate this at the risk of confusing less experienced users, but that's why it could be an advanced option so the more experienced users can use it instead. Professional games use loading screens in this manner quite often, it would be very useful for us to be able to do the same if we want to. While C2's memory management as it is is fine for many games, it isn't optimal for all types of games, and this way we could choose how we want it to run.

Sorry I haven't managed to make this clear. Here's an example:

Current scenario, with C2 as is: on preview or double-clicking a node webkit exe, NW or the browser starts up and loads all of the files from disk into memory, decompresses the needed ones for the first layout, sends them to the graphics card and starts the game. For this example, let's say with this process the game takes 1 minute to load.

Suggested scenario: on preview or double-clicking a node webkit exe, NW or the browser starts up and loads the files for the first layout from disk into memory, decompresses them, sends them to the graphics card and starts the game. This will result in the game loading in a fraction of the time.

With no interaction, the game will not load any other layout's images, from disk or into VRAM, and upon switching layouts, the game will pause as it loads the images from disk, decompresses them and sends them to the gpu. While that at first seems like it's worse, it's actually better when used with the actions I suggested, which results in this:

• On preview or double-clicking a node webkit exe, NW or the browser starts up and loads the files for the first layout from disk into memory, decompresses them, and sends them to the graphics card. This starts the game much quicker than loading everything at the start.

• First layout starts with a company logo and maybe an intro sequence before showing title screen. At the start of this layout, the action 'preload layout images to ram: "Level 1" is run. While the user watches the logo/intro and messes with the settings in the title, the game loads level 1's images from disk. This is basically what C2 does automatically once with the loader layout, except in this case it doesn't load the whole rest of the game - just the layout specified. When complete, this trigger event runs:

-> on finished loading images to ram: "Level 1"

   -action: preload layout images to VRAM: "Level 1"

Now C2 loads level 1's images to VRAM, while the user continues through the title layout. When it's done:

-> on finished loading images to VRAM: "Level 1"

   - action: set variable level1loaded to true

Now, when the player clicks new game and goes to level 1's layout, there will be no loading times at all, not to get the files from disk or into VRAM.

If the player clicks new game before the loading is complete:

->If clicked on new game

Level1loaded is false

• action: show layer: "Loading"

-> on finished loading images to VRAM: "Level 1"

If layer "Loading" is visible

• action: go to layout "Level 1"

At the start of layout "Level 1"

• action: preload layout images to ram: "Level 2"

...and level 2 loads in the background as the player plays level 1.

Using this method, all loading aside from the initial layout can be hidden, as long as the player doesn't tear through the startup screen, and even if they do, as I showed in my example, then an animated loading screen can be shown, and this would solve the problem Jayderyu was having with the music pausing as well when the game pauses for too long.

The result: even the most impatient player will be playing level 1 long before the game would have loaded otherwise if the entire game needed to be loaded. This would help a lot also for online games, getting them into the action quicker since downloading is slower. Maybe an extra action could be made: 'create offline cache' which would then download everything that hasn't already loaded. This way we could have both reduced start times and create an offline cache, the best of both worlds for the platforms that would use offline cache.

It would also benefit preview times tremendously, as it would only load the single layout, instead of the whole game, and I don't know about others, but most of the times I preview it's to test one layout. Larger games do start taking a while to load without something like this.

Again, this could be an option, so those who don't want or need to use it don't have to, and can keep using C2 as it currently is. It's one of the features I want most, actually, because of the reduced preview times.

* Node-webkit game weight

Pretty much irrelevant in this day and age with 1gb games and high speed Internet connections being normal. Besides, it doesn't really add that much.

* Different resource loading methods

I don't know what you mean by this. Both node webkit and native exes load resources from disk. Node webkit is actually more capable than CC here in that it's a simple matter to load stuff from the Internet as well.

* Different scaling (or almost-fullscreen scaling) (html5, as i figured out can't stretch game to fullscreen with integer but without letterbox, you know)

That's not node WebKit's fault. That's because of tiling and fuzziness problems when scaling pixel art to sizes that aren't integers (2x, 3x, etc). Rendering at non-integer scales like 2.1 will cause the same problems in a native game. I haven't worked with the integer modes, but as far as I know you can work around this by dynamically supporting screen sizes.

* Lags

You said you didn't care about the speed difference. If you're having framerate problems, it could be because your graphics card and/or driver is blacklisted and it's running in software mode, or you're trying to do too much with the CPU or GPU. Node WebKit's custom mouse cursor actually lags less than CC's did. CC will lag too if you tell it to do too much.

almost is a keyword here, you know

Again, the lack of feature parity with CC is not because of a problem with node webkit.

Arima - if your game is already offline (e.g. node-webkit), then there is nothing to download. As above, there may still be pauses between switching layouts not because anything is being downloaded, but simply because loading all the images in to memory can take a moment. And to clarify, layout-by-layout memory management means it does not load the entire game to memory on startup, only the first layout, and when you switch layout it only loads the next layout's images, and so on.

Ashley - Sorry, I suppose I wasn't clear - I'm aware of what you stated. By "Loading an entire large downloaded game" I wasn't referring to downloading assets from the internet when running a node webkit game, I was talking about a node webkit game that had been downloaded before running, and loading all of the assets from disk at once at the start being unnecessary, increasing startup and preview times, since as I understand it even with layout by layout loading, all files are loaded into ram at the start, they're just not all loaded into VRAM on the GPU at once.

Also, with the actions I mentioned before, I was theorizing that in addition to the action to preload assets from disk, there could also potentially be an action that could preload stuff to the GPU like CC had, which could be used to eliminate that pause. Perhaps this is better wording:

Use offline cache: on (same as current, loads or downloads everything at start)

Use offline cache: off (loads or downloads files of only the first layout)

Preload layout assets to RAM - downloads from Internet or loads from disk, depending on platform. Happens invisibly behind the scenes

Preload layout assets to GPU - sends assets of a layout to the GPU. If the files have not been downloaded or loaded from disk yet, they are downloaded/loaded first.

And triggers for each when they're done.

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

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.