Skip to main content ↑ ↓
Topic: Map Engine and Sprite Engine for Sphere v2 - Plan (Read 1059622 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

Re: Map Engine and Sprite Engine for Sphere v2 - Plan

Reply #75 –
I haven't managed to test anything yet, but I'm quite certain that the shimmers are indeed an optical illusion. The original game suffered from this too, might be something with the pixel art.

Anyway, really looking forward to first release. You're making wonderful progress on this, nice work!  :D

Re: Map Engine and Sprite Engine for Sphere v2 - Plan

Reply #76 –
Trying to test polygon based collision detection using albrook, something seems horribly wrong with the collisions not sure what yet, I think I'm going to add a debug feature to draw all the collision polys on the map so I can see what's going on.

Other thought: I think I should revert to my previous method of map drawing, (where a shape is created the size of the screen and the image used as a texture atlas) this made it easy to do sliding transitions or suddenly have the map shrink to half of the screen or the like - whereas the current method which simply draws the whole map translated by appropriate x and y so the right part is on the screen means if you want the map to slide off or do anything else weird like that you'll need to bring in a surface and a surface.to Texture step which is super slow.

Side note, SSj.log may be the best function ever created.

Other side note: collisions in albrook don't work correctly running Kefka's Revenge in miniSphere, though they do appear to under Sphere 1.5; -> I think there's something wrong with miniSphere's handling of v1 map collisions.

Re: Map Engine and Sprite Engine for Sphere v2 - Plan

Reply #77 –
Yeah, collision is weird in Albrook on miniSphere but I never thought it was something with how collision is handled by the engine itself - KR breaks so easily I thought something very specific about the way it's coded made it not work well. Even in 1.5 KR likes to have other random issues. That game is one hell of a clusterfuck.
 

Re: Map Engine and Sprite Engine for Sphere v2 - Plan

Reply #78 –
Quote from: DaVince – on
Yeah, collision is weird in Albrook on miniSphere but I never thought it was something with how collision is handled by the engine itself - KR breaks so easily I thought something very specific about the way it's coded made it not work well. Even in 1.5 KR likes to have other random issues. That game is one hell of a clusterfuck.
How could collision detection go wrong when the obstructions are set in the tiles?

Are you frequently changing layers or something weird like that?

Re: Map Engine and Sprite Engine for Sphere v2 - Plan

Reply #79 –
I wasn't the one who coded the madness, but I do remember layer switching being present. I believe it's how it handles lower and upper floors, so you can be either on top of or under a bridge, for example. I think it's supposed to switch layers right between going from the dock into town too, but I'm not sure.

There has been collision funkiness or issues in random versions of Sphere between 1.10986 (the original Sphere version it came with) and 1.5 as well, but it hasn't been particularly predictable as far as I remember.

Re: Map Engine and Sprite Engine for Sphere v2 - Plan

Reply #80 –
Quote from: DaVince – on
versions of Sphere between 1.10986... and 1.5 as well
1.10986... Good memories, I think I remember 1.10988 being the version I switched to after discovering spheredev and realising that 1.1 which I'd downloaded from sphere.sf.net wasn't the right version to be using.

Quote from: DaVince – on
I wasn't the one who coded the madness, but I do remember layer switching being present. I believe it's how it handles lower and upper floors, so you can be either on top of or under a bridge, for example. I think it's supposed to switch layers right between going from the dock into town too, but I'm not sure.
Hmm OK I'll take a look - may be that there's some odd feature used to decide which layer it's on that isn't always working.

Why is its code base such a nightmare?

Re: Map Engine and Sprite Engine for Sphere v2 - Plan

Reply #81 –
tree (the coder) didn't know how to code when he started, learned as he went along, and he never seems to have refactored any of it, so it became what it became. It's almost kind of endearing though, with all the silly variable names and eval() hell everywhere.

There was one point where I wanted to try doing the scripts from scratch but there's actually so much to the game that's a huge undertaking all by itself. Refactoring anything would probably have broken more than it fixed. Unfortunately.

If I remember correctly, layer switching caused issues with the couch moving scene as well. Obstruction issues were plaguing that scene depending on what Sphere version you used and whether or not you were lucky enough to have all variables align just right.

Re: Map Engine and Sprite Engine for Sphere v2 - Plan

Reply #82 –
And the problem wasn't albrook, the problem was that I'd drawn my sprite scaled at 50% but not scaled it's collision polygon.

Hmm, so I'm including debug features behind a this.DEBUG_MODE flag which is a property set at the top level of MEngine and SEngine, but there is aqutie a bit of code behind it - here's where I wish I could use cell and have a preprocessor macro equivalent set up as a tool to determine whether to include the debug code and possibly some other features - in general the code base is somewhat bloated by providing multiple ways of doing things when any given implementation will only use on of the paths - as another example there'a s lot of code to support a tile based system that's not used if SEngine.tile_movement is set to false.

And it all just feels like bloat - though when the mode is swapped suddenly it's needed and a lot of the code you were using before turns into bloat.

Re: Map Engine and Sprite Engine for Sphere v2 - Plan

Reply #83 –
Quote from: Rhuan – on
And the problem wasn't albrook, the problem was that I'd drawn my sprite scaled at 50% but not scaled it's collision polygon.

Fun fact: SetPersonScale() doesn't scale the sprite base in Sphere 1.5 but does in miniSphere.  This was a case where I felt fixing the bug was more important than perfect compatibility.

As for Albrook, a lot of the collision weirdness happens for me in the same places in Sphere 1.5.  For example at one point a pirate blocks you on the stairway... except you can walk right through him.  For a long time I thought this was a bug in miniSphere's obstruction code, but then found out the same issue is present in legacy Sphere too.

But hey, because KR is so terrible and prone to break at the slightest touch, it makes a really fun regression test!  And I don't mean "fun" sarcastically either, I genuinely enjoy trying to make it work.  The best compatibility hack I ever wrote was because of KR:
https://github.com/fatcerberus/minisphere/blob/v4.8.4/src/minisphere/vanilla.c#L1275-L1310

I'm still proud of that bit of clever hackery to this day. :D

Re: Map Engine and Sprite Engine for Sphere v2 - Plan

Reply #84 –
So currently working on sorting collision polygons into a series of segments so collision detection has less to check for each movement - trying to walk around albrook and checking every collision poly for every step is just a tad horrible (it manages between 20 and 45 FPS), all blocked tiles have several different collision polys so all in all it likely adds up to 1000s of polys to check every step.

Couple of questions/thoughts:

1. One thing I've half added but not finished is support for multiple instances of SEngine to interact with each other and collide with each other in one CEngine instance - is there any point in this? it would mean you could have sprites in distinct groups that could choose to draw one group only then suddenly change to drawing both groups AND these different groups would be able to collide with each other etc. BUT it will be a total pain to finish implementing this everywhere as it needs extra levels of checking and referencing in several places. Thoughts on value of such a feature?

2. Load times - for large maps (e.g. albrook) there are noticeable load times, (if you run the test you'll see this) - I'm going to try and optimise this by only require shape#draw call to render each layer whereas the current method requires one shape#draw per tile per layer - which I assume is why it's so horrendously slow. (Fat Cerberus planning to pinch the method I saw you discussing in the miniSphere thread years ago where you use 5 vertices per tile - I note that this will only be to initially create each layer, the humongous many vertices'd shape will be drawn to a surface and then the surface will be saved as a texture)

3. I keep wanting to stop and re-factor everything... BUT I must resist until I have a usable release done.... Urge to refactor rising... Ideally at some point I think I'd like to re-write it all in ES6 typescript with the same logic and same interface just with strict typing and a few optimisations, but yeah that must wait.

4. Are there any other features that are particularly wanted?

Re: Map Engine and Sprite Engine for Sphere v2 - Plan

Reply #85 –
Hopefully you'll have a lot more performance headroom to do collision detection and such once I get CC working.  That said, you don't need to check every single polygon every frame, only the ones you know are in range.  See miniSphere's tile collision code:
https://github.com/fatcerberus/minisphere/blob/v4.8.4/src/minisphere/map_engine.c#L1284-L1304

Re: Map Engine and Sprite Engine for Sphere v2 - Plan

Reply #86 –
Quote from: Fat Cerberus – on
Hopefully you'll have a lot more performance headroom to do collision detection and such once I get CC working.  That said, you don't need to check every single polygon every frame, only the ones you know are in range.  See miniSphere's tile collision code:
https://github.com/fatcerberus/minisphere/blob/v4.8.4/src/minisphere/map_engine.c#L1284-L1304
Interesting, if I'm reading that correctly you work out what tile you're on and then specifically check the the polys of the 9 tiles around you?

I haven't got the structure in place to do that, I could add it, but I want to allow for other types of obstructions not just the ones on the tiles without too much extra code.

So my optimisation plan (which I'm half way through implementing) is to divide the map into a series of segments then allocate all collision polygons to one or more segments (more if they overlap).

It will have a slightly longer loading time but should be super flexible and have speedy execution time anyway if I do it right.

EDIT: change of plan I am going to put in a tile based look up for collision polys that originated on tiles, as a tile based lookup is probably a feature that people will want exposed in the API anyway, and it will be even faster than the segment map I was going to implement (that said I will still do the segment map for other polys, anything not from a tile)

Re: Map Engine and Sprite Engine for Sphere v2 - Plan

Reply #87 –
It figures out how many tiles to check based on the relative size of the tiles and the collision base.  If the collision base is smaller than a tile, then it only checks 4 tiles (2x2) max.  If the person is entirely inside a tile then it only needs to check one.

Re: Map Engine and Sprite Engine for Sphere v2 - Plan

Reply #88 –
OK, I've tried and discarded the idea of rendering the map based on making a massive shape with 5 vertices per tile - it's difficult to get it to draw correctly AND testing with drawing albrook showed it didn't give a speed benefit.

Time (in milliseconds) to render each layer of the map:

1. With each layer being one massive shape:
log: time to render 218
log: time to render 255
log: time to render 225
log: time to render 219
log: time to render 211
(note this includes time to create the shape as well as draw it, if I was to continue drawing with one of these methods this may be better - but the time taken to create these shapes is horrible)

2. With one shape being used but it's the size of one tile only - shader used to make it draw the correct tile for each location in turn, many many more draw commands but only 4 vertices (i.e. what I was already doing)
log: time to render 83
log: time to render 119
log: time to render 77
log: time to render 77
log: time to render 81

Almost 3 times the speed - I've discovered that the super slow part of my code was the debug stuff not rendering the map.

Re: Map Engine and Sprite Engine for Sphere v2 - Plan

Reply #89 –
And I've implemented a system similar to that used by miniSphere for collisions with obstructed tiles, all slow down has vanished :).

Currently only testing with one sprite though, need to implement collision segments for sprites then test with multiple people.