Plan for Melv May
by Melv May · 06/16/2004 (12:38 pm) · 7 comments
Not got any screenies yet but progress is excellent.
Got a really solid collision system down almost identical to the one in TGE e.g. a configurable container-bin system. This is used for view-culling as well as trivial collision rejections.
Not going to say much more other than I'm really enjoying putting this together and I'm hoping to be doing some screenshots fairly soon as well as a tech-demo. The tech-demo will probably only take a day or so.
I'm really addicted to 2D at the moment.
My next plan will have nice pictures. :)
- Melv.
Got a really solid collision system down almost identical to the one in TGE e.g. a configurable container-bin system. This is used for view-culling as well as trivial collision rejections.
Not going to say much more other than I'm really enjoying putting this together and I'm hoping to be doing some screenshots fairly soon as well as a tech-demo. The tech-demo will probably only take a day or so.
I'm really addicted to 2D at the moment.
My next plan will have nice pictures. :)
- Melv.
About the author
#2
Glad to hear you are making progress, Melv! I'm curious, are you entirely replacing the SceneGraph? Or will it be possible to mix 2D and 3D?
06/16/2004 (12:50 pm)
Things like GIDs are fun! Even if Melv decides to pass, I am tempted to give his code a workout myself for a future game project. ;)Glad to hear you are making progress, Melv! I'm curious, are you entirely replacing the SceneGraph? Or will it be possible to mix 2D and 3D?
#3
Really lookin' forward to this :-)
06/16/2004 (8:45 pm)
Please say "Sure - you can have a 2D display and a 3D display in the same game..." ;-)Really lookin' forward to this :-)
#4
Oh, you meant Melv :(
Heheh. I just wanted to see someone say it ;)
06/17/2004 (1:21 am)
Sure - you can have a 2D display and a 3D display in the same game...Oh, you meant Melv :(
Heheh. I just wanted to see someone say it ;)
#5
*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.
You sure can have 2D/3D in the same game! You can have as *MANY* 2D games running as you care to manage. By this I mean that the SceneGraph and container system is a single object (a high-performance object nothing to do with the existing 3D scenegraph of torque) that you create in the scripts. You can then immediately start creating 2D scene objects in the scripts (backgrounds/aliens/crosshairs) and add them to that scenegraph and everything is automagically handled from there. This scenegraph can then be displayed in a specialised GUI control which I've created. You can have an unlimited number of these GUI controls viewing the same scenegraph or multiple ones, pretty unrestricted. You can obviously annotate these with other gui controls for displaying scores etc.
I've also added preliminary networking support but I don't intend to pad this completely out immediately; I want to work single-player for the moment.
All objects can have all their settings set by selecting a datablock but I don't enforce it in-case you don't want to. This is a change from what the TGE typically preaches. Create a standard datablock as specify it when generating the object or not, it's up to you. If you do use a datablock, you can still changes the settings that you originally set with the datablock, it's not fixed. This is pretty flexible and again, is not typical for the TGE.
// Create a single scene graph.
$SceneGraph2D = new fxSceneGraph2D()
// Make my Scene Window GUI render my scenegraph.
// In this case it's come from a standard GUI but I could've created it dynamically if I wanted.
sceneWindow2D.setSceneGraph( $SceneGraph2D );
// Setup the part of the world I want to see for now. Top-Left, Width/Height.
sceneWindow2D.setCameraWindow( -1000, -1000, 2000, 2000 );
// Or do it this way... (Center X/Y, Width/height)
sceneWindow2D.setCameraWindow( 0, 0, 2000, 2000 );
// Change the zoom just for fun ... extreeeem close-up!
sceneWindow2D.setZoom( 2.5 );
// If you haven't already noticed, you can have as many of these screens viewing as many scenegraphs as you like. You could have defender/space-invaders running at the same-time. You could have a whole arcade running and windows simply 'looking' at different ones dynamically, it's up to your imagination. :)
// Let's add some sky without using a datalock.
%backObj1 = new fxStaticObject2D();
// Set it up.
%backObj1.setPosition(-320,-240);
%backObj1.setSize(640,480);
%backObj1.setTexture("phase/client/images/skyback1");
// Add it to the scene graph.
$SceneGraph2D.addToScene(%backObj1);
// That was too hard so, let's generate a scrolling mountain but
// this time do it datablock-style...
datablock fxStaticObjectDatablock2D(staticMountainBack1)
{
position = "-320 -240";
size = "640 480";
textureName = "phase/client/images/back2";
repeatMode = true;
repeatX = 1;
repeatY = 1;
layer = 31;
};
// Let's create the sucker...
// Note the 'scenegraph' field. All objects have this ability that means I don't have to explicitly add them to the scenegraph.
new fxStaticObject2D()
{
datablock = staticMountainBack1;
scenegraph = $SceneGraph2D;
};
// Any of the datablock fields can be omitted, it's really flexible. For instance, you probably won't want position but you might for a set of layered backgrounds.
// Let's tell the mountain to start scrolling horz 0.5 pix/sec & 0 vert. True/false enable/disable it.
%backObj1.setScrollMode(true, -0.5, 0)
// Let's add an alien with all the trimmings....
// FullConfig is a compressed form of *all* the initialisation parameters. Each parameter has it's
// own function but this is easier. Some parameters here are position, layer, size, group, pivot point.
// Some of these are obvious some are not. The layer allows you to specify which rendering layer the object
// is rendered to. Layer-0 is always in front. This allows you to render to discreet layers. You can move
// objects between layers at any time. You can also use them to restrict collision to specify layers if you
// want. The pivot allows you to specify horz/vert alignments for the pivot point. This means that the
// position you specify is not necessarily the top/left but can be aligned horz as left/center/right and vert
// as top/center/right. When specifying a rotation, this is used as the pivot point. This can be handy for
// different types of games. A car would be best with the pivot in the center. A shoot-em-up might be best
// with the ship controlled from the center/bottom etc.
// setCollisions allows you to do just that. You can specify which collision groups/layers you want
// to collide with. You can specify which group(s)/layer(s) can be collided with. Other options force the
// object to only allow a single collision, automatically turn-off collision detection upon a collision etc.
// addToScene This is the explicit form of adding to a scenegraph.
// collisionsOn You can tell the object to be interested in collisions. There's also a collisionsOff.
%obj2d = new fxStaticObject2d();
%obj2d.fullConfig( 0, 0, 0, 64, 64, 0, "FX_PIVOT_LEFT", "FX_PIVOT_BOTTOM", 0 );
%obj2d.setupCollisions( BIT(0), 0XFFFFFFFF, false, false, false );
$SceneGraph2D.addToScene(%obj2d);
%obj2d.collisionsOn();
Alright, that's enough for now. I've finished with all the core functionality with the exception of networking. I'm
now working on the more useful objects based upon the core object for support such as animated sprites, path objects, tile-
support etc.
Hopefully this is a good taster in the absence of screenshots. :)
- Melv.
06/17/2004 (12:31 pm)
The GID will be a great proving ground but I'm not there yet but 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.
You sure can have 2D/3D in the same game! You can have as *MANY* 2D games running as you care to manage. By this I mean that the SceneGraph and container system is a single object (a high-performance object nothing to do with the existing 3D scenegraph of torque) that you create in the scripts. You can then immediately start creating 2D scene objects in the scripts (backgrounds/aliens/crosshairs) and add them to that scenegraph and everything is automagically handled from there. This scenegraph can then be displayed in a specialised GUI control which I've created. You can have an unlimited number of these GUI controls viewing the same scenegraph or multiple ones, pretty unrestricted. You can obviously annotate these with other gui controls for displaying scores etc.
I've also added preliminary networking support but I don't intend to pad this completely out immediately; I want to work single-player for the moment.
All objects can have all their settings set by selecting a datablock but I don't enforce it in-case you don't want to. This is a change from what the TGE typically preaches. Create a standard datablock as specify it when generating the object or not, it's up to you. If you do use a datablock, you can still changes the settings that you originally set with the datablock, it's not fixed. This is pretty flexible and again, is not typical for the TGE.
// Create a single scene graph.
$SceneGraph2D = new fxSceneGraph2D()
// Make my Scene Window GUI render my scenegraph.
// In this case it's come from a standard GUI but I could've created it dynamically if I wanted.
sceneWindow2D.setSceneGraph( $SceneGraph2D );
// Setup the part of the world I want to see for now. Top-Left, Width/Height.
sceneWindow2D.setCameraWindow( -1000, -1000, 2000, 2000 );
// Or do it this way... (Center X/Y, Width/height)
sceneWindow2D.setCameraWindow( 0, 0, 2000, 2000 );
// Change the zoom just for fun ... extreeeem close-up!
sceneWindow2D.setZoom( 2.5 );
// If you haven't already noticed, you can have as many of these screens viewing as many scenegraphs as you like. You could have defender/space-invaders running at the same-time. You could have a whole arcade running and windows simply 'looking' at different ones dynamically, it's up to your imagination. :)
// Let's add some sky without using a datalock.
%backObj1 = new fxStaticObject2D();
// Set it up.
%backObj1.setPosition(-320,-240);
%backObj1.setSize(640,480);
%backObj1.setTexture("phase/client/images/skyback1");
// Add it to the scene graph.
$SceneGraph2D.addToScene(%backObj1);
// That was too hard so, let's generate a scrolling mountain but
// this time do it datablock-style...
datablock fxStaticObjectDatablock2D(staticMountainBack1)
{
position = "-320 -240";
size = "640 480";
textureName = "phase/client/images/back2";
repeatMode = true;
repeatX = 1;
repeatY = 1;
layer = 31;
};
// Let's create the sucker...
// Note the 'scenegraph' field. All objects have this ability that means I don't have to explicitly add them to the scenegraph.
new fxStaticObject2D()
{
datablock = staticMountainBack1;
scenegraph = $SceneGraph2D;
};
// Any of the datablock fields can be omitted, it's really flexible. For instance, you probably won't want position but you might for a set of layered backgrounds.
// Let's tell the mountain to start scrolling horz 0.5 pix/sec & 0 vert. True/false enable/disable it.
%backObj1.setScrollMode(true, -0.5, 0)
// Let's add an alien with all the trimmings....
// FullConfig is a compressed form of *all* the initialisation parameters. Each parameter has it's
// own function but this is easier. Some parameters here are position, layer, size, group, pivot point.
// Some of these are obvious some are not. The layer allows you to specify which rendering layer the object
// is rendered to. Layer-0 is always in front. This allows you to render to discreet layers. You can move
// objects between layers at any time. You can also use them to restrict collision to specify layers if you
// want. The pivot allows you to specify horz/vert alignments for the pivot point. This means that the
// position you specify is not necessarily the top/left but can be aligned horz as left/center/right and vert
// as top/center/right. When specifying a rotation, this is used as the pivot point. This can be handy for
// different types of games. A car would be best with the pivot in the center. A shoot-em-up might be best
// with the ship controlled from the center/bottom etc.
// setCollisions allows you to do just that. You can specify which collision groups/layers you want
// to collide with. You can specify which group(s)/layer(s) can be collided with. Other options force the
// object to only allow a single collision, automatically turn-off collision detection upon a collision etc.
// addToScene This is the explicit form of adding to a scenegraph.
// collisionsOn You can tell the object to be interested in collisions. There's also a collisionsOff.
%obj2d = new fxStaticObject2d();
%obj2d.fullConfig( 0, 0, 0, 64, 64, 0, "FX_PIVOT_LEFT", "FX_PIVOT_BOTTOM", 0 );
%obj2d.setupCollisions( BIT(0), 0XFFFFFFFF, false, false, false );
$SceneGraph2D.addToScene(%obj2d);
%obj2d.collisionsOn();
Alright, that's enough for now. I've finished with all the core functionality with the exception of networking. I'm
now working on the more useful objects based upon the core object for support such as animated sprites, path objects, tile-
support etc.
Hopefully this is a good taster in the absence of screenshots. :)
- Melv.
#6
I'm even more excited about this than I was already. (Which was pretty excited!) Aside from making kick-butt 3D-accelerated 2D games in Torque, this means we can completely script a new, custom GUI interface to overlay on top of your 3D. Just imagine, having status screens or maps slide in and out of view smoothly, without having to write new GuiControl objects! Just drop one of Melv's GUI controls over your play GUI, set the parameters, create a 2D scene graph and drop some objects into it. Then drive them with your inventory/map/etc. scripts!
Or what using this for puzzles, like in an 3D adventure game? When you use the "interact" key on an object, the game client smoothly brings up a 2D screen overlaying the 3D view and displays some sort of intricate lock/puzzle that you must solve. Or maybe you've got an arcade machine sitting in a building in a FPS. Click on it, and you can play a 2D asteroids right then and there. :)
Or what about an Einhander-style game? The backgrounds are scrolling 2D fields, movement is constrained in a 2D manner, but your spaceship and enemies are fully-3D objects. Explosions and whatnot are just 2D sprites using fxSceneGraph2D().
There's tons of things I can think to do with this!
06/17/2004 (12:53 pm)
Holy frell! That's a ton of great info, Melv!I'm even more excited about this than I was already. (Which was pretty excited!) Aside from making kick-butt 3D-accelerated 2D games in Torque, this means we can completely script a new, custom GUI interface to overlay on top of your 3D. Just imagine, having status screens or maps slide in and out of view smoothly, without having to write new GuiControl objects! Just drop one of Melv's GUI controls over your play GUI, set the parameters, create a 2D scene graph and drop some objects into it. Then drive them with your inventory/map/etc. scripts!
Or what using this for puzzles, like in an 3D adventure game? When you use the "interact" key on an object, the game client smoothly brings up a 2D screen overlaying the 3D view and displays some sort of intricate lock/puzzle that you must solve. Or maybe you've got an arcade machine sitting in a building in a FPS. Click on it, and you can play a 2D asteroids right then and there. :)
Or what about an Einhander-style game? The backgrounds are scrolling 2D fields, movement is constrained in a 2D manner, but your spaceship and enemies are fully-3D objects. Explosions and whatnot are just 2D sprites using fxSceneGraph2D().
There's tons of things I can think to do with this!
#7
Absolutely. You could easily use a 2D scene window as a backdrop for 3D. You can actually have as many as you want, there's technically no limit.
I never really thought about using it as a more sophisticated 2D overlay system but it would work a charm like that. Someone adept with the scripts could even do FLASH for torque, seriously! Create some primitive objects from the core and you can have filled-shapes, bitmaps, text, whatever. Anything based upon the core can get rendering within minutes, it's not complex at all.
I'd like to see someone do a mock 'SouthPark' setup, hey I might even do it myself. :)
Anyway, time for bed. Back on this on Friday evening.
I'll be sure to keep everyone up to date, especially when a release is looming.
- Melv.
06/17/2004 (12:59 pm)
David,Absolutely. You could easily use a 2D scene window as a backdrop for 3D. You can actually have as many as you want, there's technically no limit.
I never really thought about using it as a more sophisticated 2D overlay system but it would work a charm like that. Someone adept with the scripts could even do FLASH for torque, seriously! Create some primitive objects from the core and you can have filled-shapes, bitmaps, text, whatever. Anything based upon the core can get rendering within minutes, it's not complex at all.
I'd like to see someone do a mock 'SouthPark' setup, hey I might even do it myself. :)
Anyway, time for bed. Back on this on Friday evening.
I'll be sure to keep everyone up to date, especially when a release is looming.
- Melv.
Torque 3D Owner Tom Bampton
Yeh, 2D stuff is damn fun. I've gotten addicted to it too.
The next Game in a Day event is on Sunday at 3PM BST, come along and see how your 2D stuff holds up to developing a real game. Phil and I have both proven our 2D engines via GIDs, seems fitting that yours should be proven the same way ;-)
We'll be on the GG IRC in #gameinaday, actually we're there all the time so drop by whenever you want.
T.