Arima's Forum Posts

  • You seem to be missing the point of what we're telling you (and it's beginning to seem intentional), so let me try to make this as clear as possible: your condescending and rude tone, attitude and behavior is the problem here, not your points.

    Don't be rude and you can discuss things with moderators and everyone else just fine. There's no need for rudeness. It just makes people unhappy and derails discussion.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • helena - which ipad and which version of iOS are you running? I understand your reluctance, but posting your capx would make it easier to determine the problem. You can try deleting stuff until it's unrecognizable or the problem goes away to get some sort of clue.

    You are both fundamentally wrong. Obviously mobile devices (even laptops) don't have the power of most desktop computers, but that is not the point. The point is nobody using HTML5 and C2 is going to hit that limit. HTML5, and the JavaScript C2 produces isn't going to win any awards when it comes to performance.

    It actually is the point of this thread. Helena has a game working fine on her computer but not on her mobile device. The reason is the difference in power.

    As I mentioned, even coding natively won't help you if you do something like try to use more memory than a device has. It's true that JavaScript is not as performant as native objective c, but neither is action script, and that fact is true on desktop as well. It's simply a limitation that has to be taken into account when designing a game. The fact that desktops are so much more powerful makes the performance difference for JavaScript vs native on the desktop pretty much irrelevant.

    Kyatric, the missing gameplay isn't a concern. The stuff you mentioned rarely takes 3% or 4% of most games.

    No. Just... No. This is wildly untrue. If it were the case, then we could all be running the latest games on pentium 3's. Just having pathfinding alone would put a game way past the 3-4% mark. Add collision detection, ai and everything else and then multiply it by the number of instances on screen to get a vague estimate of how much CPU it'll use. It's a lot more than you think.

  • You do not have permission to view this post

  • You do not have permission to view this post

  • Ipad4/iPhone 5s: 77 GFLOPS

    Geforce 9800gt: 504 GFLOPS

    Nvidia TITAN: 4,500 GFLOPS

    As Kyatric said, it's not an excuse, it's a fact. My graphics card from almost 6 years ago is still slapping some of the latest tech in the mobile world silly in terms of performance, and the latest desktop cards are running circles around my 9800gt. Most people don't even have the latest tech, either, often still using things like the iPhone 4S which are significantly weaker.

    It is possible to get good looking graphics on mobiles, but concessions must be made: lower resolution textures, less intense code, less polygons, ways to fake higher level features at reduced image quality. The citadel demo was restricted in the same manner. Believe it or not, 2d games can actually be harder for a gpu to render on mobiles than 3d because of the fill rate, which is one of their weak points. If you have two sprites overlapping each other, then the area that is overlapping is drawn twice. That's overdraw. When you've only got 3 passes of the screen to work with, it's very, very easy to go above that. Also, transparent pixels are more expensive to calculate, and while 3d objects are generally opaque, images often have lots of transparency, making it worse.

    I'm not trying to claim the situation on mobiles for c2 is perfect (referring to cocoonjs here, I haven't tried crosswalk for android yet). A perfect example is the lack of memory management - if the game described by helena was coded natively, the texture could be split up and it could be coded to load the necessary segments of the background and dump the unneeded ones, keeping memory use low. As with everyone else - finding ways to work around the hardware limits to achieve a certain effect.

    If cocoonjs implements memory management, then at least the very tall background could be implemented.

  • All browsers on iOS aside from safari use the web view - which is basically a crippled version of safari that doesn't have JavaScript optimization, so everything that uses JavaScript, like c2 games, is much slower. Same thing with a web app saved to the home screen.

    Also, remember that mobile devices are nowhere remotely near as powerful as desktops. They have very little processing power and memory in comparison - even if you were coding in raw assembly, there's just some things they cannot do. AFAIK, iOS devices can't handle textures above 2048x2048 and start having to resort to tricks to stitch large images together, an example of which being how Safari is known to either reduce the resolution of images or not load images at all that are too tall, which sounds like might be happening in your case with the background. You might also be asking too much from the CPU, via too many collision checks or physics or something.

    You also might be having overdraw problems, as the graphics card can only calculate so many pixels per second. Many devices are only able to draw each pixel on the screen three times per frame at 60fps - and that's only fully opaque ones, transparent ones require more calculation. Fully transparent pixels in a texture count towards the pixel fill rate, too - they also are processed by the gpu.

    There are ways to improve memory use and such: I suggest start by reading this: https://www.scirra.com/blog/112/remember-not-to-waste-your-memory

  • You do not have permission to view this post

  • You do not have permission to view this post

  • There are keyboard shortcuts, with them you can type a lot of events.

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