Skip to main content

News

Topic: neoSphere 5.6.4 (with Cell, SSj) (Read 445853 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 3.0.4
Reply #1155
Actually could you do that?  Build 3.0.4 against the Allegro PPA and do that huge map test again.  Also run the map engine with framerate = 0 so we can get a good benchmark. :)
neoSphere 5.6.4 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: minisphere 3.0.4
Reply #1156
Oh, I didn't know I could make the framerate unlimited in the map engine too. On it!

On self-compiled 3.0.2: approximately 205 FPS.
On self-compiled 3.0.4: still ~16 FPS.

I'm using the Allegro unstable PPA, which still seems to be at Allegro 5.1.13, compiled in January. I guess this is too old? Should I be getting Allegro the old-fashioned way (i.e. messing with the source tarball)? Could you maybe include an Allegro 5.2 in your PPA, or is that too much hassle? :(

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 3.0.4
Reply #1157
No, 5.1.13 should have the vertex buffers.

I can probably statically link against Allegro.  However I suspect in this case it might be that your graphics card doesn't support VBOs and I'll have to add a fallback.  Is this the P4 machine with OpenGL 1.3?  If so that's probably the issue.
neoSphere 5.6.4 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: minisphere 3.0.4
Reply #1158
No, the P4 would never ever support that or get any high framerates. :P I'm back in possession of my ~4 year old laptop (that nonetheless still serves me fine), which uses an NVIDIA GT540m. From what I can tell, that... should support VBOs? I'm not sure how new of a feature that is... GPU definitely supports OpenGL up to 4.5 though.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 3.0.4
Reply #1159
Yeah, that should definitely be supported.  Minimum should be GL 3.0, the 450M says it supports OpenGL 4.5.  If this is occurring on modern hardware, I can probably reproduce it locally on my laptop's GTX 950M.  Thanks for testing, looks like 3.0.5 is in the offing. :P
neoSphere 5.6.4 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 3.0.4
Reply #1160
@DaVince
So I did some experiments.  On my laptop, I can create the VBOs successfully, and then even the 500x500 map is rendered fast (= literally no difference in CPU usage between that and 50x50).  If I artificially disabled vertex buffer support, the framerate drops to 10-20fps.  So what it looks like is, for whatever reason minisphere is failing to create the vertex buffer for you, and falling back on storing the vertices in system memory.  So now you're sending 1M+ vertices to the graphics card every frame (for the 500x500 map), which is very slow.

That said, turning vertex buffer support back on still only got me to 40fps for a 500x500 map in Sir Boingers.  In that case the animated tiles were to blame--every time a tile changes the map needs to be recalculated.  But I think I have a clever way to get around that.

Sorry about the performance regression--this is actually kind of embarrassing. :-[
  • Last Edit: April 09, 2016, 03:16:04 pm by Lord English
neoSphere 5.6.4 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: minisphere 3.0.4
Reply #1161
DaVince, can you test my Sphere-SFML? I know I'm not really developing it right now, but I'm just curious of the performance, seeing if a faster script engine is better when it comes to things like command animate, or if that isn't the bottleneck.
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: minisphere 3.0.4
Reply #1162
Lord English: not sure what's going on on my side, then... By all means it SHOULD make the VBOs. :(

Radnen: I'm not exactly in a position to do that right now, since my Windows install is pretty broken! I'll try once I fix that, though.

Re: minisphere 3.0.4
Reply #1163

That said, turning vertex buffer support back on still only got me to 40fps for a 500x500 map in Sir Boingers.  In that case the animated tiles were to blame--every time a tile changes the map needs to be recalculated.  But I think I have a clever way to get around that.

Sorry about the performance regression--this is actually kind of embarrassing. :-[


My solution to this was to just make shapes for every combination of animations. It avoids the main issue, but I do think there must be a better solution to this.

It also means that once animated tiles start their animations at a non-zero time (such as when SetTile is called) you start to get very large numbers of shapes.

An alternative would be to simply make each animated tile its own shape, but I never really explored that. Perhaps a combination of this and per-animation-frame shapes would work well.

EDIT: I might add that it should not be an unreasonable requirement to use VBOs. This sounds like an issue in Allegro.
  • Last Edit: April 09, 2016, 06:39:55 pm by Flying Jester

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 3.0.4
Reply #1164
My idea was quite different: I have the tileset loader create two images, one for the original atlas, and another which is used as the texture for actual rendering.  When the tileset is loaded, the texture is a perfect copy of the atlas.  When a tile animates I use render-to-texture to update the texture image by blitting the proper tile from the atlas.  This way I can calculate the map vertices once, at map load, without sacrificing animated tile support.  SetTileImage() would of course do the same thing, updating the texture instead of recalculating the map.

SetTile() would still have to recalculate the map, but that shouldn't be a huge issue as a game hopefully won't be calling that every frame!

This approach of course uses more VRAM, but since you can only have one tileset loaded at a time, it shouldn't be an issue.  And for non-animated tilesets I can have a copy-on-write scheme to avoid cloning the atlas unnecessarily.
  • Last Edit: April 09, 2016, 06:51:41 pm by Lord English
neoSphere 5.6.4 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 3.0.4
Reply #1165
My render-to-texture method worked, and improved performance with animated tiles a ton. :)  Now I just have to figure out why it's failing to create the vertex buffer...
neoSphere 5.6.4 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: minisphere 3.0.4
Reply #1166

My idea was quite different: I have the tileset loader create two images, one for the original atlas, and another which is used as the texture for actual rendering.  When the tileset is loaded, the texture is a perfect copy of the atlas.  When a tile animates I use render-to-texture to update the texture image by blitting the proper tile from the atlas.


I do this exact method in SSFML! :D I blit from the original texture map straight to a copy that is the texture to render to screen. The copy was needed since you're always overwriting animated tiles and lose information. I found it helped out by a solid margin.
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 3.0.4
Reply #1167
Hm, I'm starting to question whether the VBO creation is actually failing.  With my laptop set to use the i7's iGPU, if I resize the Boingers tutorial map to 500x500, I can hit around 100 fps.  At its normal size of 100x15, that goes up to 1600+ fps (!).  It looks like if you give the GPU a million vertices, it gets bogged down regardless of whether they're cached in a VBO or not--even though they are not all visible on the screen.  If I had to guess, I would say it's vertex shader overhead and if that's the case, there's not much to be done for it other than avoiding creating huge 500x500 maps. ;)

I guess this is one case where map stitching would come in handy.  You could stitch smaller maps together to create one huge one and just avoid drawing the ones which are off-screen.

edit: Actually... that gives me an idea!  Rather than creating one large triangle strip for an entire map, I could slice it up into screen-sized rectangles and only draw the slices which are actually visible.  If we assume a 320x240 screen with 16x16 tiles (or equivalently, 640x480 with 32x32 tiles), each slice would be 20x15 tiles, or ~1500 vertices.  In the worst case we have to draw 4 of those, so that's 6000 vertices--which remains constant regardless of the overall size of the map and is quite a bit less than a million! :P
  • Last Edit: April 10, 2016, 01:19:42 am by Lord English
neoSphere 5.6.4 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 3.0.5
Reply #1168
I think I'll hold off on implementing that slicing idea until the next release (3.1).  With the changes I've made in the last 24 hours, the map rendering performance should now be acceptable in almost all real-world cases.  The primary bottleneck for sanely-sized maps in 3.0.4 was animated tiles, which I've solved in 3.0.5.
neoSphere 5.6.4 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: minisphere 3.0.4
Reply #1169

edit: Actually... that gives me an idea!  Rather than creating one large triangle strip for an entire map, I could slice it up into screen-sized rectangles and only draw the slices which are actually visible.  If we assume a 320x240 screen with 16x16 tiles (or equivalently, 640x480 with 32x32 tiles), each slice would be 20x15 tiles, or ~1500 vertices.  In the worst case we have to draw 4 of those, so that's 6000 vertices--which remains constant regardless of the overall size of the map and is quite a bit less than a million! :P


I do that too! But for the Sphere editor, and instead of screen sized slices, the slices are much smaller. But think of Google Maps. There are thousands of small panels that stream in as you pan the mouse.

The only other thing I could do for performance is add asynchronous panel loading (adding multi-threading to it).
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here