Skip to main content

News

Topic: Map Engine and Sprite Engine for Sphere v2 - Plan (Read 1974 times) previous topic - next topic

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: Map Engine and Sprite Engine for Sphere v2 - Plan
Reply #105
@DaVince I'd like an extensive test for my systems - just running a map on it's own doesn't really cut it, and I have no significant projects of my own to test it with as most of my projects are a few 1000 lines of code with no graphics that then gets abandoned.

So I'm thinking to test it I should re-factor Kefka's Revenge to use the v2 api and my systems for the map and sprites - this would be a great test BUT I obviously don't own KR, I can't see any license with KR it's just distributed freely, you were involved with its creation, what do you think of me using it for such a purpose? Particularly if I share the finished result (if there is such) as a proof of concept any objections?
That sounds like a huge undertaking and refactoring/redoing a lot of messy code, are you sure about that? :smile:

I mostly did the music and contributed ideas to KR though, so it's really up to wiz (MusashiX09) and tree. I'll ask them about it.

  • Rhuan
  • [*][*][*][*]
Re: Map Engine and Sprite Engine for Sphere v2 - Plan
Reply #106
Brief update, I've had a busy couple of weeks at work which means progress has slowed almost to a stop. :(

That said not much is still needed to make this usable.
- the only major feature the engine still needs is person/map scripts which I will I'm aiming to add today/tomorrow (may drag until Friday/Saturday if things go wrong).
- I also need to fix the sprite drawing order for multiple layers - currently sprite layer is not respected when determining what order to draw them.

Then it will be a case of testing and building out usage examples/documentation for it to be in a usable and sharable state.

Other features I still want to add that may be for a version 2:

1. Custom formats that load faster + cell script to produce said format (note these formats will likely have a larger file size but we're not on dial up anymore)
2. Animated tiles, you can fake it with a sprite, but I'd like sphere v1 style tiles that animate to be able to be set in a map, my current rmp loader will ignore this information - it won't be hard to add a handler for it though.
3. Zones - again these are currently ignored - won't be too hard to implement though.
4. HUD/interface system - as far as I know sphere v2 has no api for .rws or any equivalent BUT further than that there should be system a system that lets you design an interface/HUD that then draws every frame if wanted, this system should set up the shapes and textures it needs (including pre-drawing any fixed text to a surface and turning that to a texture) then should just draw them every frame.
5. Extensive Tiled Support, my current Tiled loader is rather limited, it works for maps with tile based collisions only and doesn't load entities or scripts or custom properties
6. Repeating maps - currently the map scrolling locks nicely at the edge of the map, I need to write the algebra for an alternate mode where the map and the sprites and the collisions repeat
7. Re-factored ES6 codebase, I wrote all of this in ES5 as I wanted it to be includable at run time and miniSphere was on Duktape at the time, it would probably make sense to re-factor it with ES6 now miniSphere uses Chakra, but I'm going to put this at the bottom of the list for now.

Other Note
The current plan is to initially test/build out features by porting Kefka's Revenge - no guarantees on how successful this will be but :P

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: Map Engine and Sprite Engine for Sphere v2 - Plan
Reply #107
I think you've put forth an amazing effort with this in a short amount of time, great work! :D

  • Rhuan
  • [*][*][*][*]
Re: Map Engine and Sprite Engine for Sphere v2 - Plan
Reply #108
Sorry for the slow down in progress/updates, work was busy for a while and then more recently I got somewhat addicted to speed profiling the new ChakraCore version of miniSphere, hopefully will get back on track with this now.

One key update today - courtesy of ChakraCore - I can now load rmp files and rss files significantly faster by loading the image data as Uint32Arrays and adjusting it into the right layout (tiles into layers, frames into spritesheets) by manipulating those Uint32Arrays without needing to use any graphics functions - this is a significant change to my previous method where everything was drawn onto surfaces with render functions to load it. (I note that the plan is to put these steps into a cellscript anyway which will reduce the relevance of the time they take - but the old method couldn't go in cell as Shapes/Shaders/Textures and Surfaces aren't available in cell - whereas this method can go into cell)

Uint32Arrays are used because I believe they provide the most efficient way to move 4 bytes arund at a time,

The two key functions for this new way of doing it are:
Code: [Select]
//convert a Uint32Array comprised of tile data where the tiles are written sequentially into an image
function tileBufferToTexture(buffer, t_width, t_height, width, height)
{
  var length = t_width * t_height * width * height;

  var output = new Uint32Array(length);
  for(var i = 0, x = 0, y = 0, t_x = 0, t_y = 0, c = 0, j = 0; i < length; ++i)
  {
    x   = i % t_width
    y   = Math.floor(i / t_width)  % t_height;
    t_x = Math.floor(i / (t_height * t_width)) % width;
    t_y = Math.floor(i / (t_width  * t_height  * width));
    j = (x + y * t_width * width + t_x * t_width + t_y * (t_width * t_height * width));
    output[j] = buffer[i]
  }

  return new Texture(width * t_width, height * t_height, output);
}


//write tile to position target in m_buffer
function setTileInBuffer(t_buffer, m_buffer, t_width, t_height, tile, target)
{
  var t_size = t_width * t_height;
  var m_start = t_size * target;
  var t_start = t_size * tile;
  //note uses a loop for moving the data rather than set and slice intentionally
  //due to large number of times this is called set and slice incur a larger overhead
  //due to related memory management issues
  for(var i = 0; i < t_size; ++ i)
  {
    m_buffer[m_start + i] = t_buffer[t_start + i];
  }
}
  • Last Edit: September 16, 2017, 08:28:23 pm by Rhuan

  • Rhuan
  • [*][*][*][*]
Re: Map Engine and Sprite Engine for Sphere v2 - Plan
Reply #109
After having given it some thought decided to update this whole project to ES6 style - it will make it a lot easier to understand and follow I think - shouldn't take too long either, lets see if I can have it ES6'd for tomorrow and will try and share a beta version at that point (may be more of an alpha, but we'll see).

  • Rhuan
  • [*][*][*][*]
Re: Map Engine and Sprite Engine for Sphere v2 - Plan
Reply #110
Unfortunately my effort over the last two days to make a cell script to convert rmp files into the format I want has proved to be a total failure - the initial version of my planned format is totally useless, back to the drawing board with that, in the mean time I'll work on sprites.

  • Rhuan
  • [*][*][*][*]
Re: Map Engine and Sprite Engine for Sphere v2 - Plan
Reply #111
I'm sorry for the further delays - I've had a lot of important refactoring to do and also been testing miniSphere v5.

The attached shows a little test of 1400 sprites walking around with collisions disabled.

Multi-layer rendering is now working - the 700 Celes are on a higher layer than the 700 Arvis.

It also shows some windowstyles drawn with my new (draft) HUDSystem script - another piece to add to this package.

It allows you to assemble a HUD comprised of multiple shapes then move that HUD around as a unit and draw it with a single command - it also includes helper functions to simplify adding various shapes and object types to the HUD include windows using .rws files (and images and text etc). I'd like to add a few more helper functions then will be sharing it.

But for now the next goal has to be fixing the refactored map engine - I broke it when I converted it to ES6.

  • Rhuan
  • [*][*][*][*]
Re: Map Engine and Sprite Engine for Sphere v2 - Plan
Reply #112
OK updates:

1. Everything is written in ES6 style now pretty much
2. It works again
3. I've added handling for person scripts
4. I've added an extensible input handler

2 key things I still need before I can release a working demo now:
1. A method for loading person scripts from a file
2. A decent talk function to show how it works... :P

One further thing before I can publish this as ready for use:
- documentation

  • Rhuan
  • [*][*][*][*]
Re: Map Engine and Sprite Engine for Sphere v2 - Plan
Reply #113
Alpha version of MapEngine and associated scripts available for download - I need to write some documentation and clean up a few things but I think this now counts as a usable system.

Note the graphical resources used to demo this are not mine and they are from Kefka's Revenge, please don't use them in any other public project without permission from their original authors.

The demo in this download allows you to walk around and talk to two people that is the extent of it - it's meant to demo a map engine and sprite system which I think it does.

Requires miniSphere 5 beta 2 at least also needs the latest version of the pact.js system module - this was updated today 30/09/17 so you maybe need to visit the miniSphere github for that.

edit by Fat Cerberus: Or just use beta 3 ;)

https://www.dropbox.com/s/y5r93nq23nftvfn/dist.zip?dl=0

EDIT: link updated - I fixed a bug where collision checks between sprites would sometimes fail.

EDIT2: the first fixed version wasn't actually fixed, should be fixed now

EDIT3: re-uploaded again.... Sorry about this, found and fixed more bugs, I guess I should have tested more before posting the first time.
  • Last Edit: October 01, 2017, 01:50:42 pm by Fat Cerberus