Developing a Sphere-compatible engine - Revision history

Flying Jester: /* Complete or in-progress */

2014-07-27T09:13:37Z

‎Complete or in-progress

Flying Jester: /* Complete or in-progress */

2014-07-27T09:10:48Z

‎Complete or in-progress

Flying Jester: /* Complete or in-progress */

2013-10-31T00:14:10Z

‎Complete or in-progress

Flying Jester: Added SDL input section.

2013-07-27T10:15:36Z

Added SDL input section.

Apollolux: /* Other input handlers */ rename heading

2013-07-22T21:58:19Z

‎Other input handlers: rename heading

Apollolux: /* Sphere-format file loading */ endian note

2013-07-20T21:22:55Z

‎Sphere-format file loading: endian note

Apollolux: /* Input */ reorg

2013-07-20T21:13:55Z

‎Input: reorg

Apollolux: /* Key Constant Mapping */ cleanup

2013-07-20T21:07:18Z

‎Key Constant Mapping: cleanup

Apollolux: added file loading gotchas

2013-07-20T02:19:03Z

added file loading gotchas

Radnen: /* Complete or in-progress */ clarified sfml version

2013-07-18T20:51:27Z

‎Complete or in-progress: clarified sfml version

@@ Line 142: / Line 142: @@
 |TurboSphere<br/>[https://github.com/FlyingJester/TurboSphere source], [http://forums.spheredev.org/index.php/topic,13.0.html thread]
 |Win x86/64, OSX, Linux x86/64, Solaris 10 amd64
-|0.3.5a
+|0.4.0
 |[https://code.google.com/p/v8/ V8]
 |OpenGL via SDL2

@@ Line 141: / Line 141: @@
 |-
 |TurboSphere<br/>[https://github.com/FlyingJester/TurboSphere source], [http://forums.spheredev.org/index.php/topic,13.0.html thread]
-|Win x86/64, OSX, Linux x86/64
+|Win x86/64, OSX, Linux x86/64, Solaris 10 amd64
 |0.3.5a
 |[https://code.google.com/p/v8/ V8]

@@ Line 142: / Line 142: @@
 |TurboSphere<br/>[https://github.com/FlyingJester/TurboSphere source], [http://forums.spheredev.org/index.php/topic,13.0.html thread]
 |Win x86/64, OSX, Linux x86/64
-|0.3.0
+|0.3.5a
 |[https://code.google.com/p/v8/ V8]
 |OpenGL via SDL2

@@ Line 34: / Line 34: @@
 ===SDL===
-(TODO)
+If you want to use SDL, it will be helpful to set up an event filter to catch application close events. Since the main function that needs proper access to events is GetKey, you can disable mouse movement, mouse button, and key-up events so that the event queue will be filled with just keydown events. This simplifies the implementation of the GetKey function, as it is the only function that needs the queue to contain a specific kind of event. Be sure to pump or poll for events whenever input is requested. This also keeps the engine responsive during calls to getkey, and tending the event queue keeps the engine responsive in general.
 ===SFML===

@@ Line 41: / Line 41: @@
 For the key queue, just use a queue data structure. Enqueue keys on the released state, and dequeue keys with [[API:GetKey|GetKey]].
-===Other input handlers===
+===Other input libraries===
 (TODO: list possible input handling libraries and gotchas)

@@ Line 79: / Line 79: @@
 ==Sphere-format file loading==
-Sphere uses five custom file formats, all containing bitmap data in some form or another: [[API:Font|bitmap fonts]], [[API:Spriteset|spritesets]], [[API:WindowStyle|stylized window frames]], [[API:Map|maps]], and [[API:Map|map tilesets]]. Some of them have metadata interspersed with the bitmap data, others have a dedicated block that contains all the metadata for the file in one section regardless of the bitmap data. Maps in particular have the option of choosing to embed its tileset within its file or to point to an external tileset file. All have fixed size headers that are trivial to read.
+Sphere uses five custom file formats, all containing bitmap data in some form or another: [[API:Font|bitmap fonts]], [[API:Spriteset|spritesets]], [[API:WindowStyle|stylized window frames]], [[API:Map|maps]], and [[API:Map|map tilesets]]. Some of them have metadata interspersed with the bitmap data, others have a dedicated block that contains all the metadata for the file in one section regardless of the bitmap data. Maps in particular have the option of choosing to embed its tileset within its file or to point to an external tileset file. All have fixed size headers that are trivial to read. All integer values are stored in [[wikipedia:endianness#Little-endian|Intel order/little-endian]] and unless otherwise noted all pixel values are 32-bit and stored in the order RGBA.
 ===Fonts===
-Pretty straight forward. Version 1 Sphere fonts only allow 8-bit grayscale pixels and are deprecated in favor of version 2 fonts. Version 2 fonts use bitmaps containing 32-bit RGBA pixels. There are reserved bytes to be aware of, otherwise no metadata.
+Pretty straight forward. Version 1 Sphere fonts only allow 8-bit grayscale pixels and are deprecated in favor of version 2 fonts. Version 2 fonts use bitmaps containing full 32-bit RGBA pixels. There are reserved bytes to be aware of, otherwise no metadata.
 ===Spritesets===

@@ Line 33: / Line 33: @@
 ==Input==
-GetKey() must be able to block the sphere engine. If your key queue is zero, go into a loop that just updates the game screen.
+===SDL===
-=== SFML ===
+===SFML===
 If you are using SFML, you need to handle the key pressed and released events. It's a good idea to use a static array for all of the keys, mouse, and joystick buttons. The array's index corresponds with a key, mouse, and joystick code with a true/false value indicating IsPressed. In order to support more than one joystick you may need to bump up that joystick array to a 2D array, where 'x' is the joystick id and 'y' is the button code.
-For the key queue, just use a queue data structure. Enqueue keys on the released state, and dequeue keys with GetKey.
+For the key queue, just use a queue data structure. Enqueue keys on the released state, and dequeue keys with [[API:GetKey|GetKey]].
-===Key Constant Mapping===
+===Other input handlers===
-In SDL, SFML, and other game libraries the key codes offered in source may differ from Sphere's. In order to map keys correctly you might need to implement a very large structure that is basically a "this key" = "that key" list. Such a technique is optional if you keep to the same key naming conventions, but what this will do is allow other Sphere engines to use those same codes if you saved a game with key mappings from vanilla Sphere.
+===Handling keyboard input notes===
 See Sphere's [[list of keycode constants]] for the official list, also at https://github.com/sphere-group/sphere/blob/v1.6/sphere/docs/development/keys.txt
 ==Output==

@@ Line 65: / Line 65: @@
 Audio is split between sounds and music. They have the same API, but music streams intrinsically.
 Volume however takes a range of 0 to 100. Treat that as a percent of the 0 to 255 range Sphere uses. You might need to cache the volume into a private variable and get set from that, making sure to set the underlying volume as a percent of whatever you used.
 ==The map engine==

@@ Line 128: / Line 128: @@
 |0.65 alpha
 |[http://jurassic.codeplex.com/ Jurassic]
-|OpenGL via SFML
+|OpenGL via SFML 2
-|libsndfile via SFML
+|libsndfile via SFML 2
-|SFML
+|SFML 2
 |-
 |web-sphere<br/>[https://github.com/sphere-group/web-sphere source], [http://forums.spheredev.org/index.php/topic,154.0.html thread]