Ashley - Right, that makes sense. One more question, if you don't mind - I wonder if there's a way to generate mipmaps by isolating each animation frame to its own texture when creating the mipmaps (by either cropping the rest off or copying/pasting that singular animation frame to a new texture, then resizing it, then pasting it back to the spritesheet)? Then it wouldn't average pixels from adjacent images because there wouldn't be any.

Since the problem only happens on export, and sprite sheets only happen on export, having the textures isolated solves the issue, so I'm basically wondering if you can make that isolating behavior happen from a spritesheet at mipmap generation time.

Or, as newt said, perhaps giving us an option to turn sprite sheets off would be optimal for some users? Or would that essentially make no difference by resulting in the same amount of memory used as putting them all in power of 2 locations? I guess if that's the case then the only difference would be more file requests which is a disadvantage.

Ashley - I assume it's already been considered, but I'm curious for technical reasons, why doesn't an extra few pixels width invisible border added between textures on a spritesheet solve the problem? Why does it need to go all the way up to power of two padding and waste so much space? I realize 1 pixel wouldn't work because it's averaging the space from multiple pixels.

Shards update

So I wanted the player to have the ability to run from an incoming attack, and hide behind an enemy to have that enemy get hit instead. It seemed like a good idea at first, until I realized that when enemies are bunched up they can be significantly more dangerous to each other than the player is, especially when they're using area affect attacks. So dangerous that it's too significant of an advantage for the player as they blow themselves up.

To negate this, I'd have to at least implement line of sight for the enemies, which isn't a problem, but it would still be a pretty 'stupid' check because I'm not good enough of a coder to write an ai that'll check what units will be in the way by the time the attack gets there (especially since units change their minds about what they're doing frequently), so I'm thinking that's one feature the game is going to have to go without.

The combo mode is implemented!

You can now string attacks together, unpause the game and watch them play out. Alternately you can leave combo mode off and input them one at a time for one click command input and resuming of action (I've been trying to reduce the number of clicks needed to as few as possible to streamline the ui).

In a lot of RPGs, there are abilities you can select from a list which are essentially a string of attacks that play out exactly the same each time. That doesn't give the player any interesting choices other than the initial choice of using that combo rather than another.

There are games out there that let you make your own combos, but in the ones I've seen there isn't much difference between which attacks the player uses. A punch will do damage, and so will a kick.

In Shards, you get to make your own combos, and each move has its own advantages and disadvantages. Normal attacks are quick but weak. Spin slashing hits in 360 degrees, but uses more sp and has a higher recovery time, which isn't good if an opponent blocks it. Hitting harder causes more damage and knocks the enemy back, but isn't as quick to hit with, uses more sp and has a higher recovery time.

Advantages and disadvantages to each, and no one move is always superior. Interesting choices!

Next step

I think I'm getting close to the point where the game is ready for a first video, I just need to fix a few bugs and make some animations so the characters aren't performing all their actions in the same pose.

Please do not create multiple topics for the same question.

Oh right, good point. I didn't think about tiles with transparency.

Ashley - I realize this isn't an optimal solution, but what about having an option for 'two pass' rendering, one pass being the tile map offset by 1 pixel on each axis, the second pass the tile map is rendered again in its normal location?

It would double the pixels to draw so wouldn't be a good choice for low powered mobile devices, but desktop graphics cards are so powerful these days, it might be worth it for some people.

Although I suppose people could do that manually already, so maybe it's not worth implementing.

—

Pixel shaders are intensive even on desktop gpus. There are some differences you should be aware of:

Mobile gpus use a fixed structure where a shader processing unit can only perform one task. On desktop gpus, they can perform multiple tasks. This means that mobile devices have even weaker pixel shader performance than you'd expect comparing the GFLOPS, and 3dmark, as I understand it, isn't a good measure for just comparing pixel shader performance alone.

Tegra 3 has 12 shader units, 8 are for pixels, 4 are for vertex (12 GFLOPS, 1.04 gigapixels per sec pixel fill rate)

Tegra 4 essentially has 72, 48 are pixel shaders and 24 are vertex units (43.2 GFLOPS, 2.68 gigapixels per sec pixel fill rate)

iPhone 5s - couldn't find number of shader units, but performs at 76.8 GFLOPS

My 9800gt has 112 multipurpose units (504 GFLOPS, 9.6 gigapixels per sec pixel fill rate)

This means that even top level mobile gpus still don't even come close to my 9800gt, which is basically a rebranded 8800gt, that was released in 2007. A tegra 4 has less than 9% of the GFLOPS, compounded by the fact that 1/3 of its shader units can't be used for pixel shaders. They might seem powerful lately, but mobile gpus are really still quite weak.

As I recall, my 9800gt can't even handle somewhere around 50 small sprites with the tint effect applied to them at 60 fps. Pixel shaders are crazy intensive, so it's no surprise that mobile can't handle them all that well.

Yeah, it could potentially be running out VRAM, for example. I was getting pauses for a while when I didn't realize I had accidentally asked my computer to use more VRAM than it actually has, and so node webkit had to pause to swap data from disk whenever something it didn't have in VRAM came on screen. Once I fixed that, I haven't had a pause since.

Yes, c2 uses v8 and garbage collection, there's no way for html5 games to not use it on chrome and node webkit.

Aurora Australis

Yeah, as mentioned above I'm pretty sure I can get it as I imagine it on my computer. I was saving it for the next monthly update, but I might as well mention now that I've got a dynamic system set up that enables and disables physics based upon units' proximity to each other, and that plus other optimizations has saved a bunch of CPU time, so I think I might be able to leave physics in.

Either way, I decided that it wasn't important for the proof of concept demo, so have moved on to getting the other parts of the game done instead.

luisgmolina thanks, no demo yet, got a ways to go before it's ready. Most of the character and enemy abilities are done, most of the remaining tasks are animations, the level editor, putting the level together, dynamic level loading and the interactive level pieces themselves (doors, etc). This is a pretty complex part of it so I don't know how long it will take.