I had originally thought to make a scene an object and contain everything inside of it. But then I figured it probably wasn't as effective as modifying already initialized objects. So instead, scene is currently just an ID, and managing the scenes is done via a procedure which checks the current scene ID and makes appropriate update calls.
I know it's not in DM, so I apologize in advance if something might not make any sense.
BlitzMax is kind of good for being self-expressing with commands.
Function switch_scene(n:Byte)
scene_set_id(microrpg.scene, n)
'' Logo Scene
If (n = microrpg_scene_id_logo)
znlogo_init(microrpg.znlogo)
znlogo_set_tileset(microrpg.znlogo, microrpg.tilesets[0])
EndIf
'' Main Menu
EndFunction
Everything is declared (memory allocated) before this is ever called, and contained in the "microrpg" object. A scene switch essentially flushes out whatever is being used at the current point in time and re-initializes (calls their init() function which sets the variables to their initial state) the objects necessary to compose the scene. No objects are created again on a scene switch, and current objects are recycled.
Most of the event handling is done using global functions. They essentially serve as convenient wrappers for the microrpg object, because it can sometimes be annoying to call functions that always start with "microrpg_".
The project's essential building block functions are made up of these:
- Commands: Global functions which work on the project as a whole.
- Events: Commands which are called at specific points during runtime (draw/update/init)
- Functions/Methods: Object methods which work on a particular type and are prefixed with the type name
A conceptual approach to these specific categories of procedures:
Commands are functions which are supposed to manipulate the global microrpg object. They simply do not have "microrpg_" prefixed for convenience reasons. The microrpg object is a house for all of the components the project is going to use, to keep things organized. It's meant to have the same name as the project.
Events are specific functions which are called during key points in the code: Initialization, Drawing, and Updating. The entire project's entry point starts with "event_main()". Components within the project that deal with drawing and updating are usually prefixed with "event_draw_" or "event_update_", and always have "event" as its first prefix.
Functions/Methods belonging to a particular type (which simply serves as a collection of different types of data) are always prefixed with the type name (like "mouse_" or "controller_"). These functions can only work on the fields that the type contains. For example, a module which contains the "point" module will contain this:
Type t_point
Field x :Float
Field y :Float
EndType
Function point_create :t_point (x:Float, y:Float)
Local r :t_point = New t_point
r.x = x
r.y = y
Return r
EndFunction
Function point_set(p:t_point, x:Float, y:Float)
p.x = x
p.y = y
EndFunction
Function point_add(p:t_point, x:Float, y:Float)
p.x :+ x
p.y :+ y
EndFunction
Function point_mul(p:t_point, x:Float, y:Float)
p.x :* x
p.y :* y
EndFunction
Function point_to_string :String(p:t_point)
Return "(" + p.x + "," + p.y + ")"
EndFunction
BlitzMax allows you to hold these functions as methods inside of the type, but I usually don't do it that way out of personal preference. The functions are always prefixed with the type name, so function duplication collisions are usually never an issue. BlitzMax does not allow a type's New method to contain parameters, so that was my initial drive to keep an object's methods global. I also sort of took the idea from Game Maker which does the same thing, as well as PlayBASIC which initially didn't allow object methods inside of user-defined types.
-Footer-
I was thinking of putting this project on Github as a means of sharing my code as well as a nice backup measure.
Here is a current snapshot of the project, which simply loops the logo. You can pause it with F2 and turn off the debug display with F1.