Skip to main content ↑ ↓
Topic: Sphere SFML v0.90 (Read 1565389 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

Re: Sphere SFML v0.75alpha

Reply #196 –
Jest: you may not need it. SSFML and I hope your v8 engine have JSON in them already. I know SSFML's JSON is faster than loading up Crockford's JS library.

I don't know about the speed of json3, though, it might be faster, it might not.
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: Sphere SFML v0.75alpha

Reply #197 –
Quote from: alpha123 – on

Quote from: Flying Jester – on

Do you have a link for json2.js?

json2.js (GitHub), although I recommend json3.js (GitHub).


Just updated json2 to json3 in Spectacles due to your recommendation, but is there any difference outside of under-the-hood changes? e.g. New features?

Re: Sphere SFML v0.75alpha

Reply #198 –
Json3 is in fact slower than json2, and all I see is it parses dates differently and increases support for particularly older browsers. Oh, it also detects cyclic structures, which if you know you are not using (mainly since you want to serialize straight-up data), then I wouldn't bother. That said, they do a good job with it, but for a closed system like Sphere I'd choose the fastest one that works any day, it is after all, not the web so it's not like standards change or environments change overnight.

Though I'm not sure about the correctly serializes primitive wrapper objects part, it might be beneficial, I dunno, but I've had no problems with Json2.
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: Sphere SFML v0.75alpha

Reply #199 –
I've been tweaking with things and I wanted a good benchmark for speed, so I took to drawing things. Here are the results. The numbers are the amount of items drawn before the FPS dips below 60. I eyeballed them, so it's not "scientific" by any means, but it should show you the general trend, at the very least.

Code: (text) [Select]

+--------+------+-------+-------+
|Version | Game | Draw  | Cull  |
+--------+------+-------+-------+
|v1.5 32 | 3300 | 7400  | 6400  |
|v1.5 GL | 4000 | 8800  | 7000  |
|v1.6 32 | 6000 | 11000 | 12000 |
|SSFML   | 7000 | 8600  | 14200 |
+--------+------+-------+-------+


Game: A test in which items are drawn in a game environment (separate update and render loops).
Draw: Items are drawn on screen and stay on screen (single update/render loop).
Cull: Same as draw, but items allowed to leave screen.

It turns out SSFML has really good culling, but in the end of the day is no faster than a software driver. WTF? I think hardware acceleration isn't that fast. In fact I think it has to do with Sphere's API. Because you can't do a lot of tricks in Sphere, you nerf the maximum potential that "hardware acceleration" gives you. You have an API such that you draw things in order as they appear, so sprite batching is harder to achieve. You have methods like blit() and blitMask(). And you can't tell Sphere to put things into texture atlases. I could get away with fonts, but not for general images. So Sphere forces you to use unique textures each time something is drawn to screen, caising many GL state changes and making it perform not as fast.

In a general game environment, SSFML it is faster, but it has to do with both culling and the fact, generally, the JS executes faster so game calculations happen faster. Yes, the JS environment can be more of a bottleneck than rendering in Sphere, and obviously, it shows.

But I do have an idea. SSFML could generate atlases for you behind-the-scenes. It might be possible to cache all loaded textures into a giant texture. If that giant texture is filled up, it then creates another giant texture to use. An image, behind the scenes, then only encodes where it's base texture is, and what atlas to use. This might just work.

I did implement a sprite batch, but at the end of the day, it drew things out of order, and was only like 15% faster (if you were lucky and it happened to draw everything in the same order you blitted them in).
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: Sphere SFML v0.75alpha

Reply #200 –
I am going to add automatic atlasing to TurboSphere (the spritebatcher already provides the API for me). In TurboSphere, all images used in a spritebatch are all in the same GL texture.

In the end, the Sphere API is not well suited to hardware acceleraton. I certainly wouldn't want to remove the graphics API that Sphere exposes, because it's extremely approachable. But this is why the addition of a batching API is important, since you just cannot get full performance from an immediate API. Not without losing some speed in software lookup and cacheing, and using a lot of system RAM.

Re: Sphere SFML v0.75alpha

Reply #201 –
The important test, I think, is the cull test since it's advantageous to those making their own tile engine in Sphere, and not worrying about rendering stuff off screen.

Also, "immediate API" is a great way of putting that, I should remember that term for Sphere. :)

Also a texture atlas only helps when you draw many different items on screen. My draw tests used only a single graphic, so atlasing that image for the test wouldn't actually help.

New Test:
Code: (javascript) [Select]

	var nums = 0;
	var items = [];
	var image = LoadImage("star.png");
	
	function Item() {
		this.x = 0;
		this.y = 10;
	}
	
	Item.prototype.update = function() {
		this.x += 2;
		image.blit(this.x, this.y);
		if (this.x > SW) return;
	}
	
	for (var n = 0; n < 10; ++n) {
		var time = GetTime() + 1000;
		
		while (time > GetTime())
		{
			items.push(new Item());
			for (var i = 0, l = items.length; i < l; ++i) items[i].update();
			FlipScreen();
		}
		
		nums += items.length;
		items = [];
	}
	
	Abort(nums / 10);


This runs 10 trials of the 1 second test: Draw things for one second. Here are my results:
Code: (text) [Select]

1.5: 488 items drawn
1.6: 800 items drawn

GL:
1.5  : 1141 items drawn
SSFML: 1065 items drawn


If you want to run it go ahead. :) (have a 3px*3px image though). Oh, and 1024*768 screen
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: Sphere SFML v0.75alpha

Reply #202 –
Quote from: Radnen – on

Also, "immediate API" is a great way of putting that, I should remember that term for Sphere. :)


I didn't come up with it. I call it that because the Sphere API is pretty much 1:1 with the OpenGL immediate mode.

In Linux, 1.6, using the system arrow and a 480x640 screen:

SphereGL: 504
FJ-GL: 538

With a 1024x768 and a 3x3 image:

SphereGL: 442
FJ-GL: 486

Re: Sphere SFML v0.75alpha

Reply #203 –
You can't do that demo in TS? Your FJ-GL is not bad though! (We can't compare my results to yours since computers vary, but between Sphere drivers it's not bad certainly).
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: Sphere SFML v0.75alpha

Reply #204 –
I could (in fact, that's one of the few demos that the new VAO code will work perfectly for), I just am not on a machine with TS right now.

FJ-GL should always be at least as fast as Sphere-GL. It will certainly be a lot faster with primitives (which are pretty fast anyway, so not too much overall gain there), image creation, deletion, and cloning (which is very cheap  with the new OpenGL extensions). FJ-GL also does simple software occlusion testing for the current clipping rectangle, although OpenGL's scissor test is really pretty fast anyway.

We also can't directly compare since, as I've found out recently, a lot of Sphere is exclusive to each platform.
 

Re: Sphere SFML v0.75alpha

Reply #205 –
Jest, how are you doing surface.rotate? My surfaces look strange when not rotated at perfect PI increments.

Ok, I figured it out. It was a directional thing. I had to find the colors from the source to the destination. In this way I assure every color is mapped - even if some are mapped twice, which is how Sphere does it. :)

Here's the code to rotate the x and y points:
Code: (csharp) [Select]

        private static int RotateX(int x, int y, double rad, int m_x, int m_y)
        {
            return (int)(Math.Round((x - m_x) * Math.Cos(rad) -
                     (y - m_y) * Math.Sin(rad)) + m_x);
        }

        private static int RotateY(int x, int y, double rad, int m_x, int m_y)
        {
            return (int)(Math.Round((x - m_x) * Math.Sin(rad) +
                     (y - m_y) * Math.Cos(rad)) + m_y);
        }
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: Sphere SFML v0.75alpha

Reply #206 –
I don't yet. For that and transformBlitSurface, I plan on using OpenGL and framebuffers to dump the change back to software. It's just so much simpler, and either as fast or faster as doing it in software.

At that point, I plan on surfaces being mirrored in hardware, so if they do need an update in hardware it will also prime them for being blitted directly to the screen anyway.

I may even change zoomBlit and stretchBlits (if those still work, there have been a lot of changes to the graphics code recently) to do that too. I was having issues similar to what you are seeing in your rotate with my zoomBlits when I first tried to do them. But if all surfaces are, at some point, mirrored in hardware anyway to allow them to easily be changed in Images or to be blitted directly, it makes as much sense to me to just have the GPU do these kinds of transformations.

Re: Sphere SFML v0.75alpha

Reply #207 –
Quote from: Flying Jester – on

I don't yet. For that and transformBlitSurface, I plan on using OpenGL and framebuffers to dump the change back to software. It's just so much simpler, and either as fast or faster as doing it in software.


I don't find it that simple... Maybe it's because there are certain things I want control over. Some thing are indeed easier: primitives, image blits, etc in hardware. But in SFML I have no access to masks like ADD or SUBTRACT etc. nor can I control the more pixel-perfect details to try and emulate Sphere.

Though what I may do is get around to writing a shader that will do the blend mode stuff really fast, especially when compositing two images. And I haven't figured out a good way of resizing images for rotation besides putting them into a buffer large enough to support a fully rotated version of it or something like that.

Anyways I made enough progress to bump the version number and release an updated version. This newer one has now played tenfold more games than the v0.75 I have listed here. :) (the surface.rotate was a large part of that.... surprising how often it gets used).
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: Sphere SFML v0.75alpha

Reply #208 –
You can't use glBlendFunc or glBlendEquation, and the -Separate variants? With those, you can do every blend mode in Sphere except Invert and Average. You'd need shaders for those (I think?).
Plus, there is the NV Square blend mode (which every card in existence seems to support), and several others that could easily be added that way.

Re: Sphere SFML v0.75alpha

Reply #209 –
I could, but SFML doesn't give that access to you since it does a lot of wrapping around GL. I'll have to use an actual C# GL wrapper, by using OpenTK or something like that, SFML is completely compatible with ditching it's main features for a real GL environment (and I can still continue to use input, sounds, and even things like it's sprites and primitives too).

Maybe I can at some point convert completely over to OpenTK. But I'll need to take time to learn it's API, but it seems to have quite a lot of good stuff packed in.

http://sourceforge.net/projects/opentk/
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