Torque Retro 2D!
by Melv May · in Torque Game Engine · 06/17/2004 (9:58 pm) · 24 replies
This is an extract from my plan that's quite informative regarding the 2D engine stuff so I thought I'd post it here for those who are interested and may have missed it.
The (game-in-a-day) will be a great proving ground for this but I'm not there and it won't be an age before I am so watch this space. I'm running a line between hacking bits in just so I can move onto the tech-demo and doing it correctly and stable and deferring the demo for the last possible second.
*ALL* the code is independant of the standard running of the TGE and doesn't require a single byte of modification to stock code ... not one bit. This has been a guiding principle of what I've done, simple and easy to integrate. Add the C++ files and you're ready, that's it, nothing more, nothing less. ;)
Let me explain some of the details to clarify; Let's start with some names...
fxSceneGraph2D - A 2D SceneGraph that you create in the scripts. Create as many as you want and add as many objects as you like. Treat these as the 2D stage.
fxSceneObject2D - A 2D object that can be added to a fxSceneGraph2D. This is the base object that the more specialised objects such as scrolling-backgrounds are based upon. This object contains physics, spatial orientations, pivot points, networking blah blah blah. Again, no limit other than memory.
fxSceneWindow2D - A customised GUI control based upon the standard GuiControl class. You can place this as normal on the canvas with the editor and associate them with a specific fxSceneGraph2D. The world has an unbounded coordinate system and is only limited by the range of a F32. The camera is part of the actual fxSceneWindow2D itself. You can specify your view of the world really easily and in many ways. One way is to specify a rectangular area to view and the other is to specify a centered-point and the camera-view width/height. When you've set this view window (which can be changed dynamically in scripts for panning effects) you can then use the pan/zoom script functions which use this initial reference point to pan/zoom-in/out. Really easy and only a few lines of script.
The scenegraph handles the collision detection and is really fast. The way it works is similar to the container system within the TGE. Collisions are only checked on objects that are updated in anyway. Each object automatically manages a non-AA clip rectangle which is used for trivial collision rejections after the container system has decided there is a potential collision. The system then promotes the check to the core fxSceneObject2D itself whose base virtual onCollision function does an AABB check. Any objects based upon this object can call the parent for the AABB check and then decided to do a more comprehensive check if needed. A tiled-map object would want to do a fairly complex check dependant upon the tiles it contains for example.
... (cont..d)
The (game-in-a-day) will be a great proving ground for this but I'm not there and it won't be an age before I am so watch this space. I'm running a line between hacking bits in just so I can move onto the tech-demo and doing it correctly and stable and deferring the demo for the last possible second.
*ALL* the code is independant of the standard running of the TGE and doesn't require a single byte of modification to stock code ... not one bit. This has been a guiding principle of what I've done, simple and easy to integrate. Add the C++ files and you're ready, that's it, nothing more, nothing less. ;)
Let me explain some of the details to clarify; Let's start with some names...
fxSceneGraph2D - A 2D SceneGraph that you create in the scripts. Create as many as you want and add as many objects as you like. Treat these as the 2D stage.
fxSceneObject2D - A 2D object that can be added to a fxSceneGraph2D. This is the base object that the more specialised objects such as scrolling-backgrounds are based upon. This object contains physics, spatial orientations, pivot points, networking blah blah blah. Again, no limit other than memory.
fxSceneWindow2D - A customised GUI control based upon the standard GuiControl class. You can place this as normal on the canvas with the editor and associate them with a specific fxSceneGraph2D. The world has an unbounded coordinate system and is only limited by the range of a F32. The camera is part of the actual fxSceneWindow2D itself. You can specify your view of the world really easily and in many ways. One way is to specify a rectangular area to view and the other is to specify a centered-point and the camera-view width/height. When you've set this view window (which can be changed dynamically in scripts for panning effects) you can then use the pan/zoom script functions which use this initial reference point to pan/zoom-in/out. Really easy and only a few lines of script.
The scenegraph handles the collision detection and is really fast. The way it works is similar to the container system within the TGE. Collisions are only checked on objects that are updated in anyway. Each object automatically manages a non-AA clip rectangle which is used for trivial collision rejections after the container system has decided there is a potential collision. The system then promotes the check to the core fxSceneObject2D itself whose base virtual onCollision function does an AABB check. Any objects based upon this object can call the parent for the AABB check and then decided to do a more comprehensive check if needed. A tiled-map object would want to do a fairly complex check dependant upon the tiles it contains for example.
... (cont..d)
About the author
#22
Not hard at all. Doing standard animated GUI controls is also fairly simply so you'd probably have to choose which is best for you; not sure if there are any existing resources though.
The system has got methods to allow for interactive mouse control e.g. picking etc of the objects within the scene. You can use this for selection, drag/drop, whatever you like basically.
As long as your objects inherit from the core, you can create a whole class of objects that do whatever you like. I never really thought about the applications for GUI overlays so I may put some time in after the demo to think about a core GUI control based upon the core object.
- Melv.
06/20/2004 (10:44 am)
Keith,Not hard at all. Doing standard animated GUI controls is also fairly simply so you'd probably have to choose which is best for you; not sure if there are any existing resources though.
The system has got methods to allow for interactive mouse control e.g. picking etc of the objects within the scene. You can use this for selection, drag/drop, whatever you like basically.
As long as your objects inherit from the core, you can create a whole class of objects that do whatever you like. I never really thought about the applications for GUI overlays so I may put some time in after the demo to think about a core GUI control based upon the core object.
- Melv.
#23
06/20/2004 (10:56 am)
Keith, Realm Wars has a scripted animated (sliding) menu.
Torque 3D Owner Keith Johnston