Skip to main content

News

Topic: neoSphere 5.9.2 (Read 522455 times) previous topic - next topic

0 Members and 12 Guests are viewing this topic.
  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: minisphere
Reply #75
The big window test is notoriously difficult on the graphics because it tiles a 1x1 pixel background image (in practice you won't see this). Compare to Standard32 Sphere 1.5 and SphereGL. I think SphereGL bottoms out at 2fps, or some other horrendously low number (even on my Nvidia GTX 970). In practice, try a windowstyle with a 16*16 or greater background image. Now, that said, if you are batching the image I'm really curious why you only get 30fps. Allegro must be doing some pretty naive graphics processing, despite the fact you can tell it to "defer" the drawing. I say this because you can totally do better with surfaces.
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
Reply #76
Standard32 Sphere manages 415 fps in the big window test (AMD A10-6800K), 13 with sphere_gl.  Note that on the same machine, this (13fps) is identical to minisphere's result.  I wonder if Allegro is using OpenGL under the hood?

No idea how SSFML pulls 3000fps in this test.  You must have one hell of a sprite batcher.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: minisphere
Reply #77
There are, I suspect, two reasons that the SphereGL driver sucks at this. The first is that sending so many vertices takes a lot of time, and bandwidth is the main limiting factor for doing hardware graphics. This is just a general issue with older OpenGL, and why using a newer version like 3.3 or 4.1 is better, because it makes doing that impossible.
The second issue is that SphereGL decides to unbind textures and disable texturing at the end of every call. This was the main place I saw for improvement when I wrote FJ-GL. There I do this lazily, just binding what ever texture I need at the start of every call, and using a 1px white texture for primitives.

I would suspect that with SphereGL, almost all of the time is spent binding, unbinding, enabling, and disabling texturing. Even if that wasn't happening, it's still deluging the GPU with vertices, which is generally not what you want to do.

An alternative would be to actually use UV coordinates to do hardware tiling of the texture, but the Sphere graphics driver API doesn't have that feature. Before I moved windowstyles to script in TS, this is what I did.
  • Last Edit: February 19, 2015, 02:13:03 pm by Flying Jester

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere
Reply #78
Hm, allegro lets me draw textured triangles via al_draw_prim().  I use this for my implementation of GradientRectangle.  I should test that later...

Oh, also abysmally slow in minisphere: GrabImage.  The SSFML image test runs at around 15fps.  Sphere 1.5 and SSFML both handle this test with aplomb.  Allegro must not like me using the backbuffer as a blit source...

Edit: I tried out the U/V hardware tiling, it seems to work pretty well, except for the SSFML Big Window test.  This is what I got.  Does the hardware not like tiling 1x1 textures?
  • Last Edit: February 19, 2015, 04:25:22 pm by Lord English
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

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

Edit: I tried out the U/V hardware tiling, it seems to work pretty well, except for the SSFML Big Window test.  This is what I got.  Does the hardware not like tiling 1x1 textures?


Yes. I was not sprite-batching that 1x1 pixel, I was U/V wrapping it. Essentially I'm letting the gpu do the tiling rather than physically inputting the coords of the tiles, so I'm really only sending 4 vertices to the gpu while the rasterizer does an excellent job at tiling it. I apply this technique for the sides as well, don't forget those! That Big Window test should run really fast if done right. I'd love to use the U/V method to speed up my tile maps but it assumes it's the same image being repeated, and for tile maps the tiles change.

As for your error, are you sure you are tiling it correctly? It seems to tile at 16x16 rather than 1x1, don't use the corner size for the background image size.
  • Last Edit: February 19, 2015, 05:01:00 pm by Radnen
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
Reply #80
Yeah, I got it to run at 1k+ fps, but it's not being tiled correctly.  The normal window test it tiles file, but the 1x1 background... See above.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: minisphere
Reply #81
ooops, you got me mid edit. I did a double check, and maybe you are tiling with the wrong parameters?

As for your lower than mine FPS, it might just be duktape?
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
Reply #82
Code: (c) [Select]
vertex_color = al_map_rgba(255, 255, 255, 255);
ALLEGRO_VERTEX v[] = {
{ x, y, 0, 0, 0, vertex_color },
{ x + width, y, 0, width, 0, vertex_color },
{ x, y + height, 0, 0, height, vertex_color },
{ x + width, y + height, 0, width, height, vertex_color }
};
al_draw_prim(v, NULL, bitmap, 0, 4, ALLEGRO_PRIM_TRIANGLE_STRIP);


Coord order is XYZ, UV.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: minisphere
Reply #83
And width and height are 1 here? I see single variables here, something has to tell it tile a 1x1 sized object in a WxH sized area.
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

Re: minisphere
Reply #84

And width and height are 1 here? I see single variables here, something has to tell it tile a 1x1 sized object in a WxH sized area.


How does Allegro do it? In OpenGL, you would just use a UV that is the number of times you want it tiled horizontally and vertically, respectively. You never need to specify the source texture's size in any way, because it's 'size' is normalized to 1.0fx1.0f before the texturing stage.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere
Reply #85
The code samples I've seen you specify pixels in the range of (0,0)-(w, h) for UV.  Maybe just because Allegro is designed for 2D or perhaps a remnant of its all-SW-rendered days.  I'll experiment more later.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere
Reply #86
https://www.allegro.cc/manual/5/ALLEGRO_VERTEX

Quote
u, v - Texture coordinates measured in pixels


So yeah, Allegro uses direct pixel offsets into the image for UV.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: minisphere
Reply #87
Ah, so it's 100% in raster coordinates, no normalization at all.

In that case, I'd expect your code to work. Maybe an Allegro issue with 1x1 textures?

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: minisphere
Reply #88
Raw JS benchmark on my machine, in milliseconds, lower is better, in fps, higher is better (rounded to nearest ten just to look pretty):

Code: (javascript) [Select]

function game() {
var t = GetTime();

for (var i = 0; i < 10000000; ++i) {  }

Abort(GetTime() - t);
}


Sphere 1.5: 1090
MiniSphere: 472
Sphere SFML: 23

Code: (javascript) [Select]

function game() {
var fps  = 0;
var tfps = 0;
var t2   = GetTime();

while (t2 + 5000 > GetTime()) {
fps++;
Rectangle(0, 0, GetScreenWidth(), GetScreenHeight(), red);
FlipScreen();
}

Abort(fps / 5);
}


Sphere 1.5: 3000
Minisphere: 11500
Sphere SFML: 7900

Code: (javascript) [Select]

function game() {
var fps  = 0;
var tfps = 0;
var t2   = GetTime();

while (t2 + 5000 > GetTime()) {
fps++;
f.drawText(0, 0, "Hello World! Hello World! Hello World! Hello World! Hello World!");
FlipScreen();
}

Abort(fps / 5);
}


I will say minisphere draws shorter strings much faster, but it slows down longer the string. SSFML never slows down on almost any string length.

Sphere 1.5: 4900
Minisphere: 6250
Sphere SFML: 7250

Edit:
I'd say I'm rather pleased with the speed of minisphere. It draws things much faster than I had ever anticipated. I've NEVER seen an fps higher than 8500 on this machine in SSFML, but on my Win7 I can get to 10,000 with SSFML (weird, huh). So, it's awesome to see minisphere get 11,500+.

Edit 2:
In terms of space, to load the demos above:
Sphere 1.5: 3.8MB
minisphere: 8.9MB
Sphere SFML: 39.8MB (!!)

Crazy how C/C++ programs utilize so little space!
  • Last Edit: February 19, 2015, 11:00:16 pm by Radnen
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
Reply #89

In terms of space, to load the demos above:
Sphere 1.5: 3.8MB
minisphere: 8.9MB
Sphere SFML: 39.8MB (!!)

Crazy how C/C++ programs utilize so little space!


I assume this is RAM usage?  But yeah, I'm happy see that, outside of memory footprint (which is still tiny, let's be honest here :) ), minisphere soundly kicks Sphere 1.5's ass.  That was one of my main goals with the project, since Sphere 1.5 was really starting to show its shortcomings performance-wise with Specs, especially on less powerful machines.  Somehow, some way, Duktape, even being all-bytecode with no JIT to speak of, is STILL more than twice as fast as 1.5's Spidermonkey.

It's also good to see that you got it to build.  I was going to include the Allegro binaries in the repo, but decided it wasn't necessary since I'm just using pre-built binaries that are, at present, readily available on the web.  It's just a matter of unzipping them to the proper location.  I tried to make it as painless as possible other than that, as long as you're using Visual Studio anyway!

At some point I'm going to have to try to build minisphere on Linux.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub