Err, you all lost me. Which isn't hard to do.
All this code does is store a seperate array of id numbers, right?
What I am trying to do is come up with a way to store the physical 3d objects in an array object. Umm, that made no sense...let me see if I can rephrase it.
Here we have my array object:
LevelArray
Inside the array object I want to store the bricks/decor/floors/walls/ect of a level. So if I made a wall, I'd store the object, or whatever memory reference dbpro is using to store all it's values for where and what the object looks like, inside my array, like so:
LevelArray(1[or any number]) = The 3d object in memory.
That way, to save the whole level, I can simply dump the array to a file, and to restore it, I can load the file back into the array. Doing so would also restore the 3d objects to the world, in theory, since it's all just objects in an array anyway.
Err, right?
From what you are telling me, it sounds like DBpro can't store it's 3d object type inside arrays, even though they all clearly have ids and such like normal array entries. If so...this is going to get way too messy.
Then again, it's all geek to me.
What I am trying to do is get a system of level storage like what Super Mario 64 uses. SM64 stores each level as a list of objects, that's why each spinning platform or falling block looks the same in game, because they actually are all just number X object as far as the physics and code is concerned. This system makes designing new levels and areas much less memory intensive, because instead of modeling the whole physical level, the designers simply store "lists" of objects needed to build the level. Instructions for assembly, if you will.
Of course, this is only helpful if I can somehow actually store the physical 3d objects properties in the array in the first place. If I have to make my own types just to fill the array with the object's properties DBpro is storing, I might as well be coding all the 3d object physics and display code from scratch. It doesn't make sense to store the numbers/values for each object twice in memory if only one is visible anyway.
Maybe I'm just too confused by all this code stuff. I just don't understand why I need all the above just to store an object that is already in DBpro's 3d memory space in an array instead of in DBpro's raw id values.
Is there a tutorial on how to go about making a basic 3d platformer, you know, with basic collision, camera, and level pickups that can easily be placed instead of being hard coded into the system? Every tutorial I've found has either had the level prebuilt(with no interactivity), or built hard coded into the app. It's really hard to grasp how to build a system for a 3d platforming game without any examples.
I took the fps tutorial in the book, but it didn't really help explain things, as my outcome had certain differences to what the tutorial said should happen. (my player is like, an inch high, for example, and I still have no idea how to spawn multiple objects, as the example only allows one bullet and such.)
Sorry for rambling, it's just I've been at this for over two months now and still have not been able to code even a simple grid based FPS game control without getting rather unhelpful "Invalid code" errors, and the documentation isn't very clear on how to use the commands together. It tells what the command does, but not how to use them with others, except for it's rather bloated examples that do something with random values or whatever(they don't explain any of the stuff that is actually running them, so I don't know how it's supposed to help with the commands themselves.)
In flash actionscript, I can declare an array and store movie clip objects inside that array, creating and deleting them as needed, and then by deleating the whole array I can clear all of the movie clips out of memory as well. I guess I just don't understand what's different with the DBpro arrays, or why the creating object commands don't actually pass back the object they just spawned to anywhere.