Difference between revisions of "Developing a Sphere-compatible engine"
(created) |
(Added input comments) |
||
| Line 12: | Line 12: | ||
==Input== | ==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. | ||
| + | |||
| + | === 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. | ||
| + | |||
| + | === Key Constant Mapping === | ||
| + | |||
| + | In SDL, SFML, and other game libraries the key codes may differ from Sphere's. In order to get the correct key mapping you might need to implement a very large structure that says "this key" = "that key". This does not have to happen as it is optional so long as you keep to the same key naming conventions. What this will do is fix it so that if you saved a game with key mappings from vanilla sphere, other sphere engines can use those same codes. | ||
| + | |||
| + | See key constants: (<tt>KEY_ESCAPE = 1, KEY_F1 = 2,</tt> ... etc). | ||
| + | https://github.com/sphere-group/sphere/blob/v1.6/sphere/docs/development/keys.txt | ||
| + | |||
| + | |||
(keyboard, mouse, joystick, touch-screen?) | (keyboard, mouse, joystick, touch-screen?) | ||
| Line 25: | Line 41: | ||
===Complete or in-progress=== | ===Complete or in-progress=== | ||
* vanilla Sphere | * vanilla Sphere | ||
| − | * TurboSphere | + | * TurboSphere(!) |
* unnamed Sphere clone in SDL | * unnamed Sphere clone in SDL | ||
* sphere-sfml | * sphere-sfml | ||
| + | |||
| + | (!) Although some engines are listed as compatible they will need a wrapper script to complete Sphere's API. For example, LoadImage may indeed return the correct image format by using a different API such as <tt>return new Image()</tt>. | ||
| + | |||
===Discontinued or abandoned=== | ===Discontinued or abandoned=== | ||
Revision as of 20:40, 16 July 2013
Notice
This article aims to provide a checklist and resources for developing a JavaScript-powered game engine that is compatible with Sphere's JavaScript API.
Contents
Introduction
Throughout this article, the original Sphere implementation shall be referred to as "vanilla" Sphere.
(TODO: list possible media frameworks?) (TODO: more)
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.
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.
Key Constant Mapping
In SDL, SFML, and other game libraries the key codes may differ from Sphere's. In order to get the correct key mapping you might need to implement a very large structure that says "this key" = "that key". This does not have to happen as it is optional so long as you keep to the same key naming conventions. What this will do is fix it so that if you saved a game with key mappings from vanilla sphere, other sphere engines can use those same codes.
See key constants: (KEY_ESCAPE = 1, KEY_F1 = 2, ... etc). https://github.com/sphere-group/sphere/blob/v1.6/sphere/docs/development/keys.txt
(keyboard, mouse, joystick, touch-screen?)
Output
Video
(TODO: more) (TODO: multi-monitor?) (TODO: touch-screen?)
Audio
List of Sphere-compatible engine implementations
Complete or in-progress
- vanilla Sphere
- TurboSphere(!)
- unnamed Sphere clone in SDL
- sphere-sfml
(!) Although some engines are listed as compatible they will need a wrapper script to complete Sphere's API. For example, LoadImage may indeed return the correct image format by using a different API such as return new Image().
Discontinued or abandoned
(TODO)
See also
(TODO)
