digitalsoapbox's Forum Posts

  • Or just download Tiled (mapeditor.org), which lets you layer and export tile-based images as PNGs.

    Nintendo takes awhile to respond. As in, a few months. The quality of the game is not relevant, you'll get some kind of response either way - there are actual human beings who read the submission emails.

    That being said, if you're using any copyrighted materials in your game, they won't allow you to publish it on their platform, free or not. Doing so would open Nintendo up to the same potential lawsuits the creators of ANY game using someone else's intellectual property without permission could be faced with. Even if you're not worried about protecting yourself, you can bet on them being worried about protecting themselves from any legal action. Your personal feelings don't really enter into the equation, and if you think they should, you may be too young to qualify for their Developer Program.

  • That's actually not how it works. Think of it like this: you have a piece of real world paper, and a stamp. It doesn't matter what angle the stamp is at when it touches the paper - the gpu calculates it in real time when drawing the pixels, and needs to make no modification to the stamp itself to do so, and it incurs almost no performance hit in the process, because gpu makers have optimized the operation like crazy.

    Actually, it depends less on the GPU makers/drivers (outside of stability) than the technology being used - in this case, HTML5/JS through C2. C2 isn't a 3D engine. Yeah, some things are similar in terms of what goes on GPU-wise, but different things work different ways. Either way, wasting cycles rotating an object to save a few kb in a bitmap isn't worth it in this day and age, where even our slowest smartphones are faster and have more memory than the hardware available at the time when rotating sprites to save a few bytes was even a relevant discussion.

    If it worked the way you suggested, practically no 3d game would be possible because every single texture on every polygon of every model is being distorted in an uncountable number of permutations based on perspective, angle and animation. It would use a ridiculous amount of memory to do so and would be completely pointless as very little of the saved work could be used ever again. Even if instead of saving an extra copy of the texture it just overwrote the original, the quality of the texture would degrade as it got blurrier and blurrier from being filtered over and over again.

    3D uses UV mapping on a per-vertex or per-triangle basis in general, for starters, so it's not even close to comparable. In fact, it's a bit like comparing apples not to oranges, but to, say...a polar bear. I'd be happy to PM you a few links on the subject if you're interested in learning how different it is. I think a couple books I wrote on the subject that were published by actual book publishers might still be in print. They're kind of old, but the theory is the same.

    Also, doesn't C2 use quads for drawing in canvas2D? In which case, it's WAAAY different than 3D.

    *EDIT: It does: https://www.scirra.com/blog/58/html5-2d ... e-analysis

    Maybe you were thinking of projection mapping? That's sorta-kinda stamp-like.

    Also, when not using webgl, canvas2d is used which is still hardware accelerated, just not as efficiently. Even software rendering such as chrome uses still doesn't need to use more image data in memory to rotate a sprite because it emulates the real time process hardware acceleration uses.

    As I think I said somewhere in a previous post, that depends on what kind of rotation we're talking about. And considering the inefficiencies inherent with the 2D canvas, the tradeoff isn't worth it because, again, the savings are minimal memory-wise (and really, who cares about 8MB when even a phone capable of running C2-based stuff from 2 years ago has significantly more memory) and could potentially have a negative impact on the actual, real-world performance of games we make by worrying about other things like sprite rotation in a sprite sheet (aside from the whole power of 2 thing someone else mentioned). If you're THAT WORRIED about performance, maybe look into learning to use the tools that are available, right this second, in a more efficient way. A couple megs on a sprite sheet isn't going to hurt anything. If it is, you're doing something wrong.

    I would wager a majority of performance issues are the result of user error. Every time I've wanted to blame C2 for a framerate drop, it's because I've actually been the one doing things wrong. All it takes is a trip to the manual, or these forums, and a few keywords. People are here to help find solutions, and are almost always pretty friendly about it, but it'd be great if we could steer clear of blaming C2 for not having a feature that isn't completely necessary and may in fact be hurtful to its performance.

  • I paste all tiles with no interactivity (7000+ sprites) into just a few Paster objects, vastly reducing my object count - 6000+ sprites get reduced to 7 Paster objects. On the level in posts above, I end up with, max, 687 sprites, most of which are invisible and are used for collision purposes only (standing on platforms, ladders, etc.).

    Doing it this way lets me use a ton of layers in the Tiled (mapeditor.org) file without having to worry about how many sprites I'm potentially bogging C2 down with, as well as reduce the amount of layers I'm using in C2 for parallax, since in the end the "shadows" on each platform end up as part of the same Paster object as the platforms they're "shadowing." It also means I get to keep the amount of actual art pretty low, because what looks like tile variations is really just multiple layered images that get slapped on top of each other in a single Paster object.

  • czar It's your design. Every sprite sheet must be power of two.

    You should adapt a form as background image in one frame, then use sprite font like YES, NO you could save a lot of memory.

    Or, even better, use a 9-Patch for the button itself with a sprite font on top, which eliminates the need to create differently-sized buttons entirely.

  • Spriter is irrelevant here, it's not related to Construct 2. However Spriter can handle million of animations, but it's not related to sprite sheet.

    Except for the fact that the images attached to a Spriter animation are, themselves, added to a sprite sheet upon export?

    I was also addressing a misunderstanding of Spriter's features made by the OP, so...yes, it's entirely relevant.

  • Spriter is a great tool, but there are some types of animations that spriter is not suitable for, like prerendered 3d. I think that's what Kronar was talking about.

    I never said it was the best way to do it, but it is capable of doing it, with the addition of the ability to define hitboxes and sound triggers in Spriter.

    Rotating an image at runtime does not use more image data in memory than if it was not rotated. Rotating an image at runtime does require more work for the gpu than not rotating it, but requires so little any affect on the framerate will only be noticeable on a weak mobile device.

    That depends on how it's rotated and how often. If it's rotated in-game by rotating the sprite, then it needs to do that, along with resizing the sprite if the images are different sizes, every frame. Saving memory and still ending up with a potential framerate drop is not exactly a positive tradeoff.

    If it's rotated in memory, that makes rotation dependent upon the GPU, and since C2 strives to support non-WebGL accelerated devices as well, chances are it'd have to create a copy of the original sprite, rotate it, then remove the original sprite from memory - which would most likely involve rewriting how C2 handles images in memory, keeping in mind that when not using WebGL it loads all images from the project at once, and the memory spikes that would be caused by rotating images at runtime could push many mobile games over their limit. And that all assumes that HTML5/JS, outside of full hardware-accelerated WebGL, even has the capabilities to do it quickly. Which is questionable.

    If rotating images to fit on a texture reduces two 512s to one 512, it certainly does seem worth it (perhaps rotation could be an option if people didn't want to use it to ensure maximum performance on old mobile devices).

    That's making an assumption in terms of GPU power, and I'm still not buying that there would be any significant memory savings - while not impacting other areas - by doing so.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Kronar

    1. Spriter is an entirely different tool for an entirely different purpose. Please read the entire thread to get a better understanding.

    No, it isn't. It can handle spritesheet-style animation just fine.

    2. 90 degree rotations are standard optimizations when packing spritesheets. Think 'Tetris', where you rotate the shapes to make them fit tighter together.

    No, it isn't, and it's incredibly inefficient to waste time rotating the images at runtime as that would just create MORE image data in memory, not less. We're not talking about 1990's-style hardware-supported sprite rotation, C2 is based on entirely different set of technologies. The amount of space saved is absolutely minimal both in terms of file size and memory footprint. I've NEVER been in a commercial production setting where this was ever considered a good idea, in games or elsewhere.

    3. I took the time to thoroughly explain the problem so that the community and project would benefit. I want Construct 2 to continue to improve, I thinks its a great application. It already supports independent origins with each sprite frame so supporting a third a party application would be pretty easy to implement. This definitely takes priority over less useful new features like Spriter as using a spritesheet is a requirement not an option. Every single Construct 2 user would benefit greatly form this, even Spriter users would benefit.

    Your information is entirely incorrect, and for someone who's attempting to make a point on optimization, you should probably find out what Spriter actually allows you to do and what a spritesheet actually is, especially in terms of how C2 handles them on export.

    4. Let me reiterate by saying that If spritesheets were properly packed, the benefits would be HUGE. This isn't a small gain, or a good gain, this is a HUGE gain.

    Really, there would be hardly gain at all, if any, if you didn't purposely leave a ton of white space around your example images. Even under normal circumstances, without that additional white space, the gains would be next to nothing.

    5. It would not be uncommon to see a large reduction in file size, very large memory requirement reduction and FPS boost. All this without lifting a finger. All Construct 2 games would instantly gain that, no additional work, all done automatically for you.

    Yes, it'd be pretty uncommon, because there's a point where optimization reaches a level of diminishing returns/pedantry that simply isn't useful on modern hardware, from mobile all the way to desktop. There isn't a single reason there would even be single-digit FPS gain. Your beliefs that it would matter seem to come from either a complete lack of how modern hardware functions across platforms or a background in an entirely different form of development than that which C2 subscribes to.

  • BluePhaze It's all about the scaling. During most gameplay, the zoom scale (in Magicam) is set pretty low - 0.1 to 0.175. I THINK I recorded the video at 720p so that the screen capture on Twitch didn't knock on the framerate too hard. Without video capture running, it stays pretty stable at 60fps/1080p on most desktops, though as I mentioned previously on Intel laptop GPUs it seems to have a bit of trouble about 720p unless I drop the Paster resolution to 50% of the level's pixel size. My target is node-webkit, though it seems to run fine in Chrome when I've tried previewing it in Chrome. On Windows 8 on a tablet, IE11 performance is actually better than Chrome's, probably because it's been optimized to run on the newer ARM CPUs and Chrome hasn't (as far as I can tell).

    iceangel Never heard of it, but I'll check it out!

  • Softloulou Thanks!

    Beaverlicious I'll be doing some form of alpha testing starting in a month or so. I'm in the middle of adding in the additional player character choices, now that we have Spriter character map support in C2. I also want to get at least one more stage map in there for testing.

    BluePhaze

    1-Layout size is 640x360, and scales up to whatever monitor resolution. All of the gameplay is based off of the 640x360 size. The actual STAGE size clocks in a bit over 5k, but the camera zooming & scaling keeps most of it contained within the layout.

    2-Magicam. It is such a blindingly awesome timesaver to use.

    3-Final release will allow one player to use a mouse, but the others will be locked to gamepads. Controls are twin stick + a jump button, and that'd be really awkward with lots of people on a single keyboard.

    4-Shaders are WebGL, for the smoke particle effects mostly, so they blend together nicely. There's also some newly-added shader-based distortion effects around the explosions (that's why the ladder is warped in that last screenshot post). Any tile without interactivity is pasted into a Paster object, so that's also pretty WebGL-heavy.

    Interesting (to me, at least) WebGL stuff:

    Loading times still stay pretty low at a few seconds on initial stage load, though loading speed, and pasting a few thousand objects on stage load, seems to be entirely tied to the speed of the GPU, so those with lesser GPUs may see a longer loading time. Testing on a GTX460, loading time increases, but it's still only around 10-15 seconds and performance at 1080p sticks to 60fps. On a GTX770 it's around 3-5 seconds and the fps is whatever refresh rate my monitor is set to, up to the monitor's max res (2560x1440@120Hz). On a laptop-based Intel 4000 loads times are still pretty snappy at 8-10 seconds, but performance drops a bit - 720p is still 60fps but 1080p gets really flaky and varies between 35-45fps. Poor lil fella can't handle it. For those lesser GPUs I'll probably put in some way to turn off some of the eye-candy WebGL effects that don't affect gameplay. Or maybe Ashley will find some magical way to allow us to change the resolution the monitor is running at .

    5-Windows, OSX, Linux. Consoles once C2 has support for them. I've started reaching out to my contacts at MS and Sony to bug them to respond to Ashley's requests on how to go about adding said support. Unfortunately most of my contacts at both places are on the PR side of things, and they can be...less than helpful, let's say...when asked about tech-related questions. At one point I considered Ouya, but so far as I can tell that's pretty much a dead console and I have my doubts as to its ability to run Sombrero at my self-required 60fps framerate, let alone a smooth 30fps.

  • In the middle of more updates like integrating the new support for character maps from Spriter, but in the meantime here's a nice high-rez screenshot of the near-complete "Clampett's Hideaway" stage! Yes, that's the framerate in the corner - C2 is basically locked to my monitor's refresh, even at 2560x1440, and that's with multiple 4k+ Paster objects that the tile sprites are pasted into. That's a heck of a lot of performance there, Ashley!

  • Hey! Looks like Sombrero got a mention in the indie gaming press after last night's playtest: http://www.bliptalk.org/the-best-of-nyc ... est-night/

    Everyone who asked how the game was developed (there were lots of aspiring devs at the event) were pretty surprised when they heard the game was HTML5-based and not Unity3D. Here's hoping my repeated mentions of C2 help more people find out about it!

  • Quick update - we conducted a Sombrero playtest last night with a group called the NYC Games Forum at Microsoft's NYC offices!

    I should've probably mentioned it here sooner, be we also did a live stream on Twitch.TV - you can check out the archived footage here: http://www.twitch.tv/pixelmetal

    Unfortunately we had to kill the stream early since it was dragging the framerate down on the test laptop (normally it's locked at 60fps on most machines). Next time we'll stream on a desktop with a beefier GPU!

    Almost done squashing bugs, then on to new stages! New characters! New gameplay modes!

  • distance / deltatime * time

    ^ That's the equation you're looking for.

  • Ashley Hmmm... It makes me to think about PNG files without big transparency background would not cause performance drop.

    Then don't use PNGs with large areas of transparency. You wouldn't do that if you were keying out any color (there's no reason it has to be magenta), either.

    As Ashley said, it's not a performance issue. Technology has come a long way since there was any real need to key out a specific color for transparency. Your phone is probably 10000x as fast as the computers that were around when that was a thing.