ErekT's Forum Posts

  • + a million. C2 really needs something like this.

  • Looks like texture bleeding. Try adding an empty one pixel border around your sprites and see what happens.

  • If you decide to use LoadState/SaveState instead it all becomes real easy. Just add this Action in a running event sheet:

    (System) - Save game to slot "autosave"

    If there's no autosave slot yet, C2 will create one, otherwise it'll overwrite the old "autosave" with the new. Then use (System) - Load game from slot "autosave" to load it. The autosave Action could be placed inside an On Start of Layout condition for instance.

    And to avoid your savegames getting bloated with unnecessary information, add a "NoSave" behaviour to objects that don't need saving (i.e. stuff that gets reloaded/reset on level changes).

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Has anyone else noticed a big slowdown in LoadState lately? Pre-v145 loading a state was almost instant for me but now the same state(saved at same point so should be equally big) takes about two seconds.

    It surprises me how extremely underestimated the workload for a 3D engine is in this thread.

    ...

    C2 is a 2D game creator for a good reason...

    This right here. Adding new features is the easy part. The hard part is making sure it will work safely and predictably across different rigs, take care it doesn't break anything else, and make sure it can't potentially break later on or paint you into a corner in terms of adding new features. Put simple, the more features you add, the harder it gets to maintain it all. And 3D support is such a massive added layer of complexity that it could very possibly see C2 degenerate into a buggy mess that gets updated twice a year. I'm amazed that one guy is able to maintain and push out new updates every week for C2 as it is.

  • So um, not to nag but have you made any decision on whether or not to look into this? It's kind of crucial performance-wise I think.

  • How come that people bring CC into play? I thought the headline made the context clear: "Status quo of HTML5 gaming". The current state of HTML5 gaming. As far as I know CC has nothing to do with HTML5.

    Is it the first paragraph of the original post? It is just an optional introduction to tell you a bit more about me, to let you know my relation to the Scirra products. That's all.

    Ah I did miss something :P But like Captain said, if you use wrappers like node-webkit or cocoonjs you'll get the consistency that browsers lack no? Unless you need web deployment that is.

  • But... node-webkit is the export option of choice for C2 Windows deployment. If CC can only produce Windows executables then isn't that what you need to compare it to? Forget about inconsistency between browsers; CC could never do browsers anyway. Unless I'm missing something.

  • Unfortunately no. Not for fullscreen anyway.

    [SPECULATION TIME]

    html5 is the problem here I think. It's intended for browsers as far as I know and browsers don't need/provide access to screenmode changes. Exporters like node-webkit do a good job of camouflaging themselves as native exes but they *are* in fact just running browsers minus the browser interface. So even fullscreen is just a window stretched to fill the screen so the end-user can't tell the difference. In other words, node-webkit at least can't change screen resolution because it can't access it. C2 works around this by providing options to scale everything up to the current resolution (whatever the desktop or target device uses) and that's cool in most cases. But speed-wise not in all unfortunately. Good news is you can control resolution in window mode now at least, and maaaaybe that's just the first step in a grand solution Scirra is planning. So I'm hoping anyway :P

  • Depends on the game. 3D games are resolution-independent which means the game has a bunch of 3D objects with levels of detail (polygons) that stays the same regardless of screen resolution. In these cases all screen resolution does is determine the number of pixels used to draw the 3D objects on screen. 2D games, and especially 2D games with pixel art like you see in most 70's to 90's era games, rely more on specific screen resolutions to draw properly but like 3D, 2D game objects also have individual levels of details(pixel resolution) that can be scaled up or down to fit the target screen resolution.

    Your gfx card has a selection of screen resolutions that it supports, usually in the range of 640x480 to 1900x1200 or something for newer cards. When you set a game to run in one of these resolutions you're telling it how many pixels to use to represent the graphics on screen. But all the rendering calculations, physics etc take an equal amount of time to process. So in terms of strain on the CPU and GPU game objects have little to do with the screen resolution itself.

    Hope that helps?

  • Cool!

  • One thing that would be nice is an external script system that compiled runtime builds can run. You could allow for modding with that. Maybe this is possible already with the JS SDK?

  • This is a very nice concept. I like the general design and animations very much. Seems to me there's not *that* many animations or effects that C2 should croak over em. But I often got jerkiness when a projectile moved within range and the character didn't always respond to input during those times. You say things sped up when you turned off animations.. do you use a lot of collision polygons for your frames? If so, maybe try to use simple boxes instead?

    EDIT:

    Actually, scratch all that. I tried to lower the desktop resolution to 800x600 and the game ran so much smoother it's not even funny. So I got a lot further than before and yeah, you have a *lot* going on in some areas. The jerkiness for collisions went away but I got it in other places. When new gfx got shifted into video mem perhaps? I dunno. Hard to tell.

  • Been asking for this to get added. The way I understand it, sample filtering gets applied on image load so to switch it on/off would require a reload of all the gfx... Which is fine by me. As long as the option is there.

  • I get the same green with red lines as sqiddster in Chrome on:

    Geforce GT 540 M / driver version: 295.73

    Win 7 64 bit