Skip to main content ↑ ↓
Topic: **Calling all game devs: tech demo material** (Read 118477 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

**Calling all game devs: tech demo material**

WARNING: LONG BUT IMPORTANT POST

With the development of Flying Jester's TurboSphere, casiotone's sphereclone, alpha123's 1.7 development, Metallix's three.js-based and Radnen's pixi.js-based Sphere-compatible web engines, Radnen's Windows editor Sphere Studio, and my eventual contribution to the web engines and some upcoming desktop apps as well as my recent de facto takeover of project management, the Sphere engine is finally seeing its first definitive expansion in years! Now while I'd love to see engine development continue to move forward on all fronts, the engine is nothing without Sphere projects to test, demo, and showcase its abilities.

If we go all the way back, we have a fair amount of projects made for Sphere with varying degrees of completeness, but some are lost with the last site reset and some of the recovered projects are apparently just too old to work with Sphere's API since 1.5. We need one or two definitive projects to demo and test as much of Sphere's capabilities as possible and the last attempt at it, the Sphere Community Game Esphera, ended in failure for numerous reasons.

First and foremost, I am NOT advocating we create a new community game or even attempt to continue the old one. I would expect attempts at that would produce similarly failed results unless something fundamental in circumstance has changed with those last involved.

What I AM advocating is a master suite of API tests and/or tech demos. With Sphere-compatible engines being built with vastly different libraries and coding methodologies, we need something that will make sure there is as little fragmentation as possible with regards to output; a Circle needs to blit the same size and color no matter if it's on the web or on the desktop, etc.

Let me make clear: I don't care how you as an individual code. You can put braces on new lines or put them on the same line as the statement blocks they accompany. You can use spaces instead of tabs or vice versa. You can use a while loop instead of a for loop or vice versa. I don't care. What I DO care about is that a Circle is a Circle is a Circle, MapEngine aborts at the same line of code on the web as on the desktop and obstructions are handled the same everywhere, and the engine isn't slowed down by five separate statements doing what could be done in two.


  • I am not asking for unit tests. If you have unit tests even better, but they only go so far before the human element comes into play.
  • I am not asking for complete games. If you have complete games great, but they're clearly meant to be played fully and completely and expect a finalized engine.
  • I am not asking for demonstrations of complex maths. We can come up with timing benchmarks later.


I want tech demos. I want API tests. I want things we can put into a single project and let the engine step through them one at a time to make sure engine output matches expected output. My Wave Editor doesn't belong in it, but my old particle flame demo (updated to use the 1.6 ParticleEngine) would. Radnen's Hold the Line and Jump! wouldn't belong, but his chatroom demo (modified to be automated) would. Flying Jester's, casiotone's, and Metallix's personal test scripts for their engines would be right at home, even though Majestic, standard, and Aquatis would be out of the scope of what I'm asking for.

Visit the Functions list to see what we should have for API (even if articles aren't finished), and I'll start compiling a list of submitted demos/tests for engine devs to use when testing for completeness. The managers of the Downloads will eventually host them on our Drive account and hopefully each section of API gets at least two fully functional demos; I recommend some of the newer or more obscure bits of API first so that the easy stuff like images or surfaces doesn't get saturated with demos immediately.

Re: **Calling all game devs: tech demo material**

Reply #1 –
I support this message.

I for one have hit many, many points, especially since so much of the wiki is now lost, where I don't know exactly how things are supposed to work in TurboSphere. Usually I test in Sphere 1.5, sometimes I just choose the most logical choice.

But it would be a very good thing to have definitive tests. For instance, is a line supposed to blit GL style, with each end point centered at the edges of pixels, or the way I do it in software and always have the endpoint pixels filled? Are circles perfect, or are their edges bound by ceil or floor distances from the center point? (In Sphere 1.5, it's floor'ed. That one caught me by surprise).

Re: **Calling all game devs: tech demo material**

Reply #2 –
Quote from: Flying Jester – on
For instance, is a line supposed to blit GL style, with each end point centered at the edges of pixels, or the way I do it in software and always have the endpoint pixels filled? Are circles perfect, or are their edges bound by ceil or floor distances from the center point? (In Sphere 1.5, it's floor'ed. That one caught me by surprise).


Exactly the kind of things I want to make sure stay consistent throughout all the implementations of the Sphere engine; hit the nail on the head, dude!

I myself will probably take up writing demos for Sound and maybe SoundEffect. Definitely Bezier curves, tho, as I'm the reason kyuu put them in to begin with.

Re: **Calling all game devs: tech demo material**

Reply #4 –
@DaVince: Just giving it a quick look (without actually opening the files), I know that I like the idea of testing some of that stuff on TurboSphere and on Sphere and comparing the results. I'm especially interested to see the mode7 demo, that sounds like a good test for the Map Engine.

Re: **Calling all game devs: tech demo material**

Reply #5 –
Oh, that Mode7 demo is nothing more than me grabbing the backbuffer or whatever's on the map and then transformBlitting that on top... Perhaps it's a good test for not only the map engine but also screen grabbing and special blitting, though...

Re: **Calling all game devs: tech demo material**

Reply #6 –
Just a note... Using some of my old tests seems to have served TurboSphere and Sphere SFML pretty well. Maybe it's an idea to include some of them in the testing procedures?

This file contains a bunch of those old tests. These might be particularly useful:

DaVince-3dtest1 - drawing simple lines; SetFrameRate (to something above 60); test IsKeyPressed
DaVince-AnimTest - load and display a sequence of images; creating and using Color objects realtime (20 FPS); font.setColorMask and font.drawText. Also does a useless RequireScript.
DaVince-Bubblez - performance test on quickly drawing many image objects at once. IsAnyKeyPressed.
DaVince-Drawtest - display gradients, windowstyles and fonts. font.setColorMask. Test IsKeyPressed and GetKeyString.
DaVince-Hmm - image.rotateBlit; IsAnyKeyPressed.
DaVince-MultiTrackMusic - Try IT module playback; sound.setVolume.
DaVince-SoundTest - Try IT module playback; sound.setPosition; sound.pause; sound.play.
DaVince-TextDemo - doing a ton of font.setColorMask and font.drawText calls; drawing a coloured rectangle; SetFrameRate.

Re: **Calling all game devs: tech demo material**

Reply #7 –
No matter how simple, tests are a good thing--and we can always use more!

I for one am going to see how they run in TurboSphere.

Re: **Calling all game devs: tech demo material**

Reply #8 –
Can you define me what type of testcases we need? I still have a unittester. I used to blit in different modes (openGL, 8bit and 32 bits), then write the blit to file, and use Sphere to diff the images. We found that way that sometimes, the OpenGL was blitting one pixel off. It'll be fun (and useful for me) to redo some unittest work. So, what needs to be checked?
 

Re: **Calling all game devs: tech demo material**

Reply #9 –
As far as what I know would help...

Tests for ByteArrays and RawFiles, Files, surface primitives, and surface and image cloing and conversion would be useful.

Re: **Calling all game devs: tech demo material**

Reply #10 –
+1 on surface stuff. I have noticed things are implemented differently for surfaces than for screen: rotations for example go the other way, and certain parameters are in a different order. I know this from creating SphereSFML and noticing the quirks.

Also a lot of map engine checks would be nice. It's good to get a good test suite of the thing that's hardest to code and maintain.
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: **Calling all game devs: tech demo material**

Reply #11 –
Kyuu fixed the .dll for OpenGL to fix the offset a long time ago when I started a topic. I have it on my PC at home

Re: **Calling all game devs: tech demo material**

Reply #12 –
Was that actually fixed in 1.6?

If not, it would be good to have a fixed library at least.

I noticed what looks like a fix for that in the source on Git Hub (there's a call to glTranslate by a very small amount).

Re: **Calling all game devs: tech demo material**

Reply #13 –
This is what I had back in 2014. I have not done any work on it. I will delve into surfaces (Radnen request), and isolate/remove all 1.6 tests so that it works in classis Sphere 1.5, to serve as a testbed. Unfortunately, it uses a few complex functions, and I am not sure all Sphere derivates can handle them... we will see...

Log opened: Sat Sep 27 17:50:10 2014
Sat Sep 27 17:50:10 2014 -- COLOR(toJSON()):assertEquals OK
Sat Sep 27 17:50:10 2014 -- COLOR(read red component):assertEquals OK
Sat Sep 27 17:50:10 2014 -- COLOR(read green component):assertEquals OK
Sat Sep 27 17:50:10 2014 -- COLOR(read blue component):assertEquals OK
Sat Sep 27 17:50:10 2014 -- COLOR(read alpha component):assertEquals OK
Sat Sep 27 17:50:10 2014 -- COLOR(clamp alpha createColor()):assertEquals OK
Sat Sep 27 17:50:10 2014 -- *COLOR(clamp red assigned):assertEquals FAIL: (new Number(0))!=(new Number(255))
Sat Sep 27 17:50:10 2014 -- *COLOR(COLOR):NOTE FAIL: No good assertion results, rewrite either the test or the code! false
Sat Sep 27 17:50:10 2014 -- COLORMATRIX(toJSON()):assertEquals OK
Sat Sep 27 17:50:10 2014 -- COLORMATRIX(assign rn):assertEquals OK
Sat Sep 27 17:50:10 2014 -- COLORMATRIX(assign negative rg):assertEquals OK
Sat Sep 27 17:50:10 2014 -- FLATE(bytearray length):assertEquals OK
Sat Sep 27 17:50:10 2014 -- FLATE(convert back to string):assertEquals OK
Sat Sep 27 17:50:10 2014 -- FLATE(deflate actually compresses):assertTrue OK
Sat Sep 27 17:50:10 2014 -- FLATE(deflate to correct object):assertEqualType OK
Sat Sep 27 17:50:10 2014 -- FLATE(inflate to same ByteArray):assertEquals OK
Sat Sep 27 17:50:10 2014 -- FLATE(inflate to same string):assertEquals OK
Sat Sep 27 17:50:10 2014 -- FLATE(reflate):assertEquals OK
Sat Sep 27 17:50:10 2014 -- FLATE(reflate 9):assertEquals OK
Sat Sep 27 17:50:10 2014 -- FLATE(reflate 8):assertEquals OK
Sat Sep 27 17:50:10 2014 -- FLATE(reflate 7):assertEquals OK
Sat Sep 27 17:50:10 2014 -- FLATE(reflate 6):assertEquals OK
Sat Sep 27 17:50:10 2014 -- FLATE(reflate 5):assertEquals OK
Sat Sep 27 17:50:10 2014 -- FLATE(reflate 4):assertEquals OK
Sat Sep 27 17:50:10 2014 -- FLATE(reflate 3):assertEquals OK
Sat Sep 27 17:50:10 2014 -- FLATE(reflate 2):assertEquals OK
Sat Sep 27 17:50:10 2014 -- FLATE(reflate 1):assertEquals OK
Sat Sep 27 17:50:10 2014 -- FLATE(reflate 0):assertEquals OK
Sat Sep 27 17:50:10 2014 -- FLATE(bytearrays):assertEqualType OK
Sat Sep 27 17:50:10 2014 -- FLATE(reflate too small buffer):assertNotEquals OK
Sat Sep 27 17:50:10 2014 -- FLATE(not equal bytearrays by data):assertNotEquals OK
Sat Sep 27 17:50:10 2014 -- FLATE(ByteArray clone):assertEquals OK
Sat Sep 27 17:50:10 2014 -- FLATE(length read-only):assertEquals OK
Sat Sep 27 17:50:10 2014 -- FLATE(not equal bytearrays by length):assertNotEquals OK
Sat Sep 27 17:50:10 2014 -- FLATE(not equal bytearrays):assertNotEquals OK
Sat Sep 27 17:50:10 2014 -- SPHERE16(Sphere 1.6):assertEquals OK
Sat Sep 27 17:50:10 2014 -- SPHERE16(Sphere v1.6):assertEquals OK
Sat Sep 27 17:50:10 2014 -- SPHERE16(GVS() is string):assertString OK
Sat Sep 27 17:50:10 2014 -- GetGlobalConfiguration(GetGlobalConfiguration 0):assertNumber OK
Sat Sep 27 17:50:10 2014 -- GetGlobalConfiguration(GetGlobalConfiguration 0):assertInteger OK
Sat Sep 27 17:50:10 2014 -- GetGlobalConfiguration(GetGlobalConfiguration 1):assertNumber OK
Sat Sep 27 17:50:10 2014 -- GetGlobalConfiguration(GetGlobalConfiguration 1):assertInteger OK
Sat Sep 27 17:50:10 2014 -- GetGlobalConfiguration(GetGlobalConfiguration 2):assertNumber OK
Sat Sep 27 17:50:10 2014 -- GetGlobalConfiguration(GetGlobalConfiguration 2):assertInteger OK
Sat Sep 27 17:50:10 2014 -- GetGlobalConfiguration(fraction not integer):assertString OK
Sat Sep 27 17:50:10 2014 -- GetGlobalConfiguration(fraction not integer):assertBoolean OK
Sat Sep 27 17:50:10 2014 -- SFXR(test type):assertEquals OK
Sat Sep 27 17:50:10 2014 -- SFXR(Same):assertEquals OK
Sat Sep 27 17:50:10 2014 -- SFXR(not same):assertNotEquals OK
Sat Sep 27 17:50:10 2014 -- SFXR(toJSON):assertEquals OK
Sat Sep 27 17:50:10 2014 -- SPRITESETS(isbase):assertType OK
Sat Sep 27 17:50:10 2014 -- SPRITESETS(setpersonbase):assertEquals OK
Sat Sep 27 17:50:10 2014 -- APROX(assertAprox):assert OK
Sat Sep 27 17:50:10 2014 -- APROX:passed OK
Sat Sep 27 17:50:10 2014 -- TOTAL goodfunctions:1
Sat Sep 27 17:50:10 2014 -- TOTAL badfunctions:1
Sat Sep 27 17:50:10 2014 -- TOTAL totalRequiredFunctions:0
Sat Sep 27 17:50:10 2014 -- TOTAL totalgoodRequiredFunctions:0
Sat Sep 27 17:50:10 2014 -- TOTAL coverage:NaN%
Sat Sep 27 17:50:10 2014 -- TOTAL succeeded:52
Sat Sep 27 17:50:10 2014 -- TOTAL fails:2
Log closed: Sat Sep 27 17:50:10 2014
fbnil@sphere:~/Documents/mygame/sphere/Sphere16$ cat dotest.sh
wine engine.exe -game auto_test
cat games/auto_test/logs/unittest.log