(Disclaimer) This post has missing information - It will be completed a due time. Expect additions and changes to this post over time.
So, I have been working on a concept for an engine for a game (will be posted about later on once the engine is finished. I am trying to hold back what game will be using the engine. Sorry for any lack of specific information, either due to not knowing what the engine will do or from not giving away the game details). Now, strictly on the topic of the engine and what it is doing and possibly will do, the extent of the engine is tentative, but here is what I am working towards:
The engine will allow a game to load in a map along with the needed sprites and put them into a buffer in the RAM. What is in the map data can be changed by the game as it sees fit.
Right now, the engine is making use of the map data as a hybrid tile array. This is not the same as a normal tile map. A normal tile map would be a 2D array with references to a set of tiles. This engine takes X,Y coords and a tile ID and draws it, clipping to the window as needed. For example, you can have 2 tiles, a 384x216 tile (ID 0) and a 24x72 tile (ID 1). The map data can place tile 0 at 0,0 and tile 1 at 60000,12345.
The engine will also provide basic physics, made of collision and particle code. Serialized collision shapes of a map could be loaded with the map data.
A nice example of what could be done with the above info: Mario. The worlds would be stored in individual files. Each world has similar textures and share a single sprite pack. The game would load the level and the sprites, tiles, and physics layout will be loaded into ram. The game has only to implement character movement and AI. The engine will provide functions to test for collisions on world objects, provide gravity/falling and walking on surfaces, and other functions needed for helping run the game, but not actually run it by itself.
Right now, the engine could do everything above, be stripped down to simply loading data, or not work at all if the stack's size isn't the right size (hence why I am not sure what the purpose of the engine will do as I don't know what the prizm will let me do).
<addition> Resources
The resources for the engine are provided as individual files in a folder on the prizm. As of right now, here is how a map is made:
Example of the .ss
Code:
The .t file generated looks like
Code:
Generated as [id] [human-readable ID]
Here is the .sp
Code:
A GUI editor is being made for the file format, but it is application-specific :-\ unless the engine's scope is changed
So, I have been working on a concept for an engine for a game (will be posted about later on once the engine is finished. I am trying to hold back what game will be using the engine. Sorry for any lack of specific information, either due to not knowing what the engine will do or from not giving away the game details). Now, strictly on the topic of the engine and what it is doing and possibly will do, the extent of the engine is tentative, but here is what I am working towards:
The engine will allow a game to load in a map along with the needed sprites and put them into a buffer in the RAM. What is in the map data can be changed by the game as it sees fit.
Right now, the engine is making use of the map data as a hybrid tile array. This is not the same as a normal tile map. A normal tile map would be a 2D array with references to a set of tiles. This engine takes X,Y coords and a tile ID and draws it, clipping to the window as needed. For example, you can have 2 tiles, a 384x216 tile (ID 0) and a 24x72 tile (ID 1). The map data can place tile 0 at 0,0 and tile 1 at 60000,12345.
The engine will also provide basic physics, made of collision and particle code. Serialized collision shapes of a map could be loaded with the map data.
A nice example of what could be done with the above info: Mario. The worlds would be stored in individual files. Each world has similar textures and share a single sprite pack. The game would load the level and the sprites, tiles, and physics layout will be loaded into ram. The game has only to implement character movement and AI. The engine will provide functions to test for collisions on world objects, provide gravity/falling and walking on surfaces, and other functions needed for helping run the game, but not actually run it by itself.
Right now, the engine could do everything above, be stripped down to simply loading data, or not work at all if the stack's size isn't the right size (hence why I am not sure what the purpose of the engine will do as I don't know what the prizm will let me do).
<addition> Resources
The resources for the engine are provided as individual files in a folder on the prizm. As of right now, here is how a map is made:
- Make an image in your favorite editor (gimp) and export the sprite to a .raw format (RGB888)
- Create a .ss file (script - sprites) with references to the images
- Serialize the .ss into a .s file with a .t template. The .s file contains all of the included raw images converted to RGB565 format along with the size and a transparency color. The template file associates image names to their IDs for ease-of-use.
- Create a .sp (script - pack) that creates tiles, defines animations (?), properties, etc.
- Compile the .sp into a .p, using a .t if used. The .p is sent to the calc, along with the .s. The pack contains serialized data of the tile map.
- Make a program that creates a reader and renderer. The reader will take in the name of the pack and will automatically parse the pack and the needed sprite file and load it into the RAM.
- Setup the renderer with the addresses returned by the reader. The reader is no longer needed.
- Tell the renderer to draw when needed. (Currently being worked on)
Example of the .ss
Code:
; Example Sprite script
; smile.raw is in the same folder as this script
Picture 50 50 ffff smile.raw
Picture 100 100 ffff smile2.raw
; [width] [height] [Transparent color] [filename]The .t file generated looks like
Code:
0 smile
1 smile2Generated as [id] [human-readable ID]
Here is the .sp
Code:
; Sample Pack
; Limits of the pack
Size 384 9001
; Internal name, not needed
Name sample
; Ties a .s to this pack
NeedsS sample.s sample.t
; tiles - smile2.raw with animation set as itself 4 times
Tile 0 0 1 1 1 1 1
; Same, but using the .t defines and without the animation (implied)
; Tile 0 0 smile2
Tile 334 8951 smileA GUI editor is being made for the file format, but it is application-specific :-\ unless the engine's scope is changed
