Edit: Yep, same issue with the slashes--simply slashing at thin air creates and destroys nearly 100 bitmaps. Sorry to say, this game is VERY poorly optimized.
I'm a bit unnerved, really. I honestly don't know what to say. But I'll get to that in a sec, first an explanation. I'll be gentle, don't worry.
So I have no idea how thin air slashing does that. I mean it's just COMMAND_ANIMATE frames. I mean, I did nothing outside the bounds of the map engine for the action system (except the pixel collision detector). I use Pythagorean distance first to check if there are frames to collide with before this whole hundred-sprite-creation thing begins to happen
Are you saying this, on thin air creates and destroys 100 bitmaps?
// search and return a list of enemies in a 16 pixel radius at the front of the character. This is Attack()
var list = this.getNearest(16, player.xv*16, player.yv*16);
while (i--) {
enemy = list[i];
if (this.check(this.input, enemy.name)) { // call the check method
//...
}
}
Thin air slashing ought to put the sword well away from the nearest enemy sprite. And how on
Earth could it create a hundred to a thousand frames? Look at the code and think about it. I call the attack script only
once on frame change.
// search for and add functions to certain frames.
dir = "attack" + dirs[i];
for (var n = 0; n < 7; ++n) {
if (n == 4)
this.actionmanager.addFrameCall(dir, n, Cut); // frame 4: cut
else
this.actionmanager.addFrameCall(dir, n, Attack); // all others: check collision on Attack (see above)
}
// later on in actionmanager:
// LOOK at it. It only does actions on frame switch: (because a sprite frame can last up to 8 screen frames)
var frame = GetPersonFrame(this.attached);
if (this.frame != frame) {
var index = GetPersonDirection(this.attached) + ":" + frame;
if (this.framecalls[index]) this.framecalls[index]();
this.frame = frame;
}
Technically my code only has to create bitmaps 2 times per frame (your source and the opponent source). I mean, I'm sure it'll create no more than 10 bitmaps max. I think your engine needs some work here. I mean, there are at least 100 to 1000 pixels to zip through on a dead collision check call, if it occurs. Are you telling me that each time I get a pixel your engine must create and destroy a bitmap? You have power over that my friend, not me. Especially if blank calls to COMMAND_ANIMATE does it. Well, technically running in your engine I can try to mitigate that, but at this point I'm not sure what's possible. I can cache the 2 bitmaps, but then I'm saving these 10 creations each time, the enemy constantly changes, mind you. So I could cache the payer. But if it's really each time a pixel is returned...I'm not sure. I don't want to have to lug around huge caches of enemies and players, or heck, maintain a cache pool if I can help it.
The "unoptimized section"
var ss = GetPersonSpriteset(player);
var dir = ss.directions[GetDirectionNum(ss, GetPersonDirection(player))];
var frame = dir.frames[GetPersonFrame(player)];
var image = ss.images[frame.index].createSurface();
// person B:
ss = GetPersonSpriteset(who);
dir = ss.directions[GetDirectionNum(ss, GetPersonDirection(who))];
frame = dir.frames[GetPersonFrame(who)];
var image2 = ss.images[frame.index].createSurface();
Above surfaces are created but only 2. Only 2 new bitmaps are created per call of check. Per the frames it's called on. Which is precisely frames 1 through 6 except 4. So 5 frames, which is no more than 10 bitmaps being created and thrown away. I check in SSFML, and yep, only 10 bitmaps. There is no lag. I usually don't try to optimize if there's nothing too crazy to optimize. The code I use here is also industry standard (using pythos first, then making sure you only check an
intersection of bounding boxes. In fact I doubt more than 256 pixels are ever checked!!). It's really industry leading. It's quite good, my friend of friends. Assuming of course bitmap creation is relatively cheap. If it's not, I can fix this, and you're right about it being unoptimized, but I'd say only slightly so. Because it's either this or cache pooling, and do I really want to do that if this works well enough? I mean each frame the enemy and player changes, and then each direction, for each enemy. There are so many states each bitmap can be in at any given time I'd rather reconstruct than cache, especially if reconstructing like it is in SSFML and Sphere1.5 is as dang fast as it is.
Because...
I only optimize code I've profiled for, looking for bottlenecks.
It's really what any sensible programmer would do. You saying the game is not very optimized kinda stings since I strive for that, but only in areas where I needed it. I say your engine is what's unoptimized here buddy since my SSFML handles this even better than Sphere's. The difference being I've used SW bitmaps. Now, I've moved on to HW sprites and noticed compositing was really fast but simple things like updating and creating new bitmaps as well as getting pixels was really slow. So I'm moving back to SW for good even if it means it's "slower".
Edit:I profiled getPixel in SSFML and between 6000 to 2000 pixels are checked. Which is fine. Worst case scenario is 48*48*10 which is 23000ish pixels. Swinging empty air does nothing. No pixels, no bitmaps, nada.