(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:
  1. Make an image in your favorite editor (gimp) and export the sprite to a .raw format (RGB888)
  2. Create a .ss file (script - sprites) with references to the images
  3. 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.
  4. Create a .sp (script - pack) that creates tiles, defines animations (?), properties, etc.
  5. 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.
  6. 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.
  7. Setup the renderer with the addresses returned by the reader. The reader is no longer needed.
  8. Tell the renderer to draw when needed. (Currently being worked on)

Example of the .ss
; 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

0 smile
1 smile2

Generated as [id] [human-readable ID]

Here is the .sp

; 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 smile

A GUI editor is being made for the file format, but it is application-specific :-\ unless the engine's scope is changed
That would be amazing, but, for Prizm, to should optimize like a beast...
The engine allows rendering of tiles from map data. i have added, but not tested, collisions against the map and other objects, a particle system, object control, and layered tile rendering. Animations, transparencies, and mirrored sprite code will be added later.

i have plans to add huffman compression to the sprite files in order to ease up on filesystem space, not ram space.

i promise that once the game actually begins to work after stress testing on the engine, actual images will be posted.
I have been bogged down with things to do, but layered rendering works. I still need to find time to draw things for testing. Animated tiles will be done next
So, I have moving parts done, but the engine is getting slow. I should go back and rewrite/optimize, but as of now, I am prizmless and should return to working on GlassOS...

Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are UTC - 5 Hours
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum