Sphere - Web Edition

Topic: Sphere - Web Edition (Read 82981 times) previous topic - next topic

0 Members and 3 Guests are viewing this topic.

Sphere - Web Edition

July 16, 2013, 04:51:33 pm

The official thread for Sphere - Web Edition.

Repository: https://github.com/sphere-group/web-sphere

For utilities written in JavaScript, visit the Sphere Web Utilities repo.

For casiotone's implementation of the Sphere API in JavaScript, visit this thread.

Sphere - Web Edition has a pixi.js branch and a three.js branch. Possible future implementations may include a Turbulenz branch.

Re: Sphere - Web Edition

Reply #1 – July 16, 2013, 05:28:38 pm

I might have to add primitives to the pixi-branch of Sphere soon.

Re: Sphere - Web Edition

Reply #2 – March 01, 2014, 09:51:07 pm

An (admittedly kinda old) article on "fast sprite rendering" on an HTML5 canvas: http://www.pawfal.org/dave/blog/2012/04/fast-html5-sprite-rendering/

Probably something the more advanced of us here already realized regarding graphics programming, but still useful. IIRC this technique is how the map engine tile rendering in Sphere SFML works, right? If so, this will probably be the technique I use in the reference code for web map rendering.

Re: Sphere - Web Edition

Reply #3 – March 01, 2014, 10:57:35 pm

That technique is shit.

Edit: to add on to what I said, it's shit for quite a few games. Imagine updating every pixel each time the camera moves. I think it worked to the guys advantage since I think he had more of a point and click game where the imagery is primarily stationary and as the player moves from one position to the other only those tiles redraw. This is how .NET winforms draws controls; this is how I did it in my map editor, but not what I did for my SSFML engine. It would bet terrible in an actual camera based game environment, or any game that runs at an fps.

I actually did attempt that style in Sphere; redrawing only things that change - for menus and got good results. The trick is you always render at 0 fps. The problem is that if you have any animations, or need a mouse to move you're kind of back at square 1. He got away with mouse movement since mouse movement is apart from the canvas control (not drawn with it). The trick in sphere is to use a surface and draw on to that surface only the things that update. But surface handling is usually terrible, and even if you draw the mouse separately you'll need at least a solid fps count so the player can move the mouse and click things with precision.

Plus at the end of the day SSFML is using hardware anyways, so why not just go all out and do what your gfx card was designed to do?

Furthermore, it also worked to his advantage since rendering was his bottleneck and drawing anything at all was literally 1000 times more expensive than the code telling it how to draw what to draw. It's not quite that bad in Sphere.

Re: Sphere - Web Edition

Reply #4 – March 02, 2014, 04:04:08 am

Ah, ok. Thanks for clearing that up for me.

Back to the drawing board for map rendering then :/

Re: Sphere - Web Edition

Reply #5 – March 02, 2014, 05:29:05 am

It really depends on the type of game. If you were doing a SimCity like game, the method you found would work quite well. But the game has a camera. However if the camera moves per-tile, you are still n times faster than pixel movement, if n is the size of your tiles in pixels. It'll scroll like my Sphere Map Editor, but at least you get really fast tile drawing results.

I don't know, but would it be too much to toggle that support? Realtime vs. deferred viewport. Where realtime draws everything as fast as needed and deferred only draws when the camera moves or entities update? In that way small games can take full use of the deferred feature while larger action-oriented games can use the realtime setting.

It's just that deferred = realtime if everything updates, but slightly slower since it must make the extra consideration of what to update.