One chip I'm throwing in for discussion - could cEngine and sEngine allow you to include an arbitrary number of hitboxes relative on a single entity? One of the things I've found difficult to work with is that sprites are limited to a single hitbox square for native implementation. As an example, trying to implement something like a semi-circle sword swing could do with a bit of accuracy by changing one large hitbox into two or three smaller ones, without needing to split it up into that many sprites and make sure they are all coordinated.

I was planning on any given sprite having a collision shape that would be any polygon you chose to define.

I assumed that there would be no need to have multiple boxes if each box you have can be any shape you like?

Though with the current piece I've written the polygon would be tied to the sprite, so if you had two entities on screen with the same sprite and changed one of their polygon's it would change the other one too, I'm guessing you don't want this? I'll change it so you can change the poly for an entity.

In fact what may work well for a hack and slash is being able to have specific frames implement polygons that go with them, I could do that.

I note that you'd potentially still need to split the person from their sword otherwise you won't know whether the player bumped into someone or hit them with a sword - cEngine will be able to tell you which entities are hitting which other entities but if the person and their sword were one entity it would not be able to distinguish them.

I suppose I should add a simple way of hooking two or more entities together to enable systems like that to work smoothly.

If you look at a game like Smash Bros., there are some attacks characters can do that have multiple rectangular hitboxes, and you can't represent those as a single polygon because they may come out at different times and/or do differing amounts of damage.  So I definitely see where mezzo is coming from here.

Hmm so instead of a singe hit-poly include an array of them and then for collision detection return -1 for not collided or an id for the collided poly if collided?

Originally I was only considering hitboxes and not hit-polys for speed, since that's how I'm used to things working with other engines. Having hit-polys would fix that, but the later conversation about having individual polygons for individual frames is even better. Having the hitpoly id(s?) returned on collide would save the trouble of having two individual entities, since one entity can, at that point, do all the important things I can think of that a composite entity would, since you can have one script manipulate them both.

Originally I was only considering hitboxes and not hit-polys for speed, since that's how I'm used to things working with other engines. Having hit-polys would fix that, but the later conversation about having individual polygons for individual frames is even better. Having the hitpoly id(s?) returned on collide would save the trouble of having two individual entities, since one entity can, at that point, do all the important things I can think of that a composite entity would, since you can have one script manipulate them both.

Well, let's see if I can make this run at a decent speed....

Interface indecision...

So for queuing movement commands what should the interface be?

There will be a function that will pathfind to a specific location and then queue movement to follow the path.

But what about an interface for directly queuing specific moves?

My current method is this:

Code: [Select]

SEngine.entity_Id["Jeff"].queue.push({direction:"west",ticks:10});

Is that sort of approach good or should there be a function of some kind - I just can't see what value the function would add.

Edit: Generalising the above point I'm thinking about how much store I should set by making the engine have nice function interfaces, e.g. I added the following earlier:

Code: [Select]

SEngine.prototype.Idle = function()
{
  return (this.waiting == this.entities.length);
}

Which is a function some people would probably find helpful BUT - if I explain some of the systems internal variables that sort of check can be in-lined very easily without the function overhead, thoughts?

Did some performance testing on what I've got so far; my script can process movement for about 1,600 entities before dropping below 60FPS - only had about half on screen at a time rest were updating off screen.

I added some timing code - the update code processing where everything is was using about half the time and the rendering code the other half; hopefully the galileo speed improvements in 4.7 will make this a bit better, but also hopefully most games shouldn't need to process over 1,000 entities at once.

I also note that my update script currently calls an array.sort once per frame which may be a key cause of slow down that I could cut.

(I note that I don't currently have any collision detection in this so it will get slower)

If your test ran at ~60 FPS with 1000 entities on screen, then that's quite a bit better than what we currently have already. Sir Boingers started slowing down on my previous second-gen i7 when I added more than ~50 cupcake sprites in a single map.

Speaking of collision detection and performance; would such an element be toggleable so that entities that don't need that feature won't waste their time on it? (And the same for some other components, perhaps?)

If your test ran at ~60 FPS with 1000 entities on screen, then that's quite a bit better than what we currently have already. Sir Boingers started slowing down on my previous second-gen i7 when I added more than ~50 cupcake sprites in a single map.

Speaking of collision detection and performance; would such an element be toggleable so that entities that don't need that feature won't waste their time on it? (And the same for some other components, perhaps?)

i am using a fairly powerful MacBook Pro so it may not be a fair test but seriously slowdown from 50 entities is bad.

Everything should only happen if needed but you still have to loop through the whole list of sprites and st least check if it's needed or not or do you.... I may have just thought of another optimisation.

So today I have:
1. Written a short piece of code to convert an rss file into what this system needs to work with. It's unfortunately v1 code - as being able to a) use LoadSpriteset and b) use surface_object#save is almost invaluable - note the v1 functions are used to read and convert the rss it's then v2 only to load the converted data and work with it.

2. Written a potentially unnecessary optimisation (double indexed fixed length movement queues instead of using array#push and array#shift) - it's not really fixed length in that it will extend if it runs out of room, but that shouldn't happen often.

Couple more points to consider for optimisation:
1. maintain an array of refs to currently moving entities to avoid needing to loop down the whole list and check for the ones that are moving -> optimisation for situations where there are a large number of stationary entities.

2. Consider replacing array#sort - this is currently called once whenever the update script runs, this is to allow for overlapping entities e.g. if a sprite is two tiles tall; the sort orders the render array so that that entities are drawn in order of increasing y value (i.e. lower down the screen = drawn later) (may need to allow for alternate sorting criteria later) -> to optimise could I replace the sort with a check only when an entity's y value changes that moves that one item forward or backward in the render array. This would be faster for situations where not many items move above/below each other BUT it could be slower for situations where large numbers of sprites move above then below. I note also that a negative feature of array#sort is that it's not stable - this means if you have 2 sprites with the same value they keep swapping order in the draw queue - if they're overlapping this leads to a flicker.


Next order of business:
I need a break from SEngine, time to start MEngine. Now, should a map be an array of shapes, each one representing one tile so I can clip the ones that don't need to be on screen OR should it be a single shape which is just the whole map - with this method I'd load the map by drawing it all out onto a surface then convert that to a texture and texture a single shape with it - I could use my shader to have the shape only be the size of the render window and move the texture around as needed. The only problem with this would be if there is a limit to the size of a surface or a texture (or is there is a size above which they become unworkable).

Nice work on this! I don't think anyone minds your use of v1 code for the conversion process, since it's compatible after all.

Everything should only happen if needed but you still have to loop through the whole list of sprites and st least check if it's needed or not or do you.... I may have just thought of another optimisation.

Well, to be fair, every single entity was sending out COMMAND_ANINATE commands every single frame, but yeah, the frame rate got diminished quite quicky. It would be kinda nice if auto-animation could be part of the map engine itself, I suppose.

Well, to be fair, every single entity was sending out COMMAND_ANINATE commands every single frame, but yeah, the frame rate got diminished quite quicky. It would be kinda nice if auto-animation could be part of the map engine itself, I suppose.

At the moment with my system the best you can do is queue an action but say to do it 10,000 times or something rather than re-queuing over and over which would get slow fast, I'm intending to add a feature to auto-repopulate empty queues though I'm not sure how best to do it yet - the most obvious method would be to add a function to an entity to be called when a queue is empty though that could be slow if I don't do it carefully - if I have it call just once when the queue runs out that would probably be ok; whereas if it's called every update when the queue is empty that could be a lot of extra function calls.

Put in a feature to queue an action forever - set an action to happen 0 times or (any negative number) and it will repeat until/unless you manually remove it. (previously actions were cancelled when they had <1 times to go, I've changed it to 0 times to go specifically)

Also set up the basics of the map engine, it needs a lot of work still:
- no current support for animated tiles (I probably want to make it generate entities for the sprite engine to animate but be able to do it based on data in the map file)
- render function currently draws all layers - should change to drawing a range (so you can control which ones you want pre-sprites and which ones after)
- need to add support for moving layers

Other points:
- Need a collision engine...
- need to build a standard input mechanism
- should build an rmp loader
- should come up with file formats to use (the needed data for a sprite is a png spritesheet and then a "template" object, the needed data for a map is currently a Tiled JSON file and a tileset png)

Just a note, I've had a lot on and am going to be away for a bit, my plan is to have version 1 of this ready around the 1st September, sorry that it's taking a while, real life has got in the way...

I note that if this works as well as I'm planning it should be able to be a drop in replacement for the Sphere v1 map engine (though you would have to replace all related function calls, I could make a helper script to edit any function calls within persons in the map files to make that process easier).

The hope is that transitioning to this new system will be relatively painless and add flexibility and better control to a project as well as better v2 integration.

So... Considering that miniSphere's Sphere 1.x compatibility has now reached to the point that I'm emulating bugs, I definitely think it's time for a new map engine.