Sorry your browser is not supported!

Before I begin any project, I always experiment with some areas I want to achieve before launching into it, just in case I get half way through (again) and become disillusioned (yes I've been programming for about 30 years, leaving a trail of half finished apps and games behind me).

I am looking for a way to package Objects and their textures so that the contents could not easily be *ahem* borrowed.

I have though about storing the textures for the multi-mesh .x file in a single file using memblocks which seems simple enough, but if I convert the .x object into a mesh for storing in a memblock, it loses all it's textures, and I can see no way of reattaching the textures to it (I'm talking about 100 meshes in these .x files to make up a starship interior, with about 10-15 different textures to apply).

I don't want to fork out the £50 that TGC are asking for their new funky packager so am looking for a way to store all of the related resource files in such a way that they can't be browsed and *ahem* borrowed.

I realise I might have to write a routine to create the package in the first place in order to reload it (I've done it before for DirectX), but don't know how to get around the fact that the only way to use .x files (or 3ds etc) is to have them in plain site somewhere along with the images for thyre textures when you distribute the game.

If you don't have animation with your meshes, you can use memblocks for that. Have a look at the "File" section in the help and you will see how to write memblocks to files. To get arround your texturing problem, you will need to write it yourself (if you don't want to pay for it).
open the file
write the memblock (mesh)
write the strings containing the textures (this can be tricky)* and the info for what to use the texture on
close the file

*here is the tricky part:
First if you trying to use the meshes limb texture to identify the textures, you *may* have to change it to texturing it manually. I don't think dbLimbTextureName(..) works correctly in the update.
You can batch save all your textures using memblocks.
So now you have indexed the textures on the limbs.

I think you can figure it out from here. I think you already knew this solution, but I posted it just in case.

You can package all your things in an encrypted .zip file (or similar) using the free and open source zlib http://zlib.net/.

It is much faster and easier than using memblocks, and much more flexible.

Thanks both of you.

Hawkblood: I've been experimenting withg that solution at lunchtime today but it makes the resourcefile huge because I'm writing memblocks. Plus, I haven't quite got it working right. Might finish it off and post my results later anyway.

Mr Bigglesworth: Thanks, I'll take a look!

Well, I've looked and tried and no joy.

My problem is that I am using a complicated .x file that has frames to group meshes together.

I created a checklist for the limbs which identified 200+ limbs. But when stepping through, all the offsets where 0 etc.

I seem to be able to pull out the limbs, and generate the meshs, but I'm not sure which mesh of the X file DB has used as the first object and why the offsets aren't shown.

And yes, the object works fine with the standard dbLoadObject command.

Any ideas about what might be going on here? I don't fancy trawling though the spec of the .x file to work this out (the documentation I've found is pretty sketchy).

Having used dbLoadObject I then created a text file listing all the available elements of every limb including name, texturee name, position, offset etc.

I am even more confused now with what DBGDK is actually doing (unless it's the DirectX loader command underneath that's doing it). The frames seem to be in reserve order with the last limb being the first listed in the .x file. The only details regarding position, rotation and scale are the global position details. All the rest are zero for each limb (and 100 for scale). I tried using these global positions as offsets put limbs get scattered everywhere (euww!).

I also noticed that some outer frames are classed as invisible limbs.

There has to be a way of doing this. I'll need to look at how to use frame transform matrices although I don't seem to be able to get at them freely within DB, unless I've missed something in the helper.

I did consider what others have thought... unpacking a file, loading the object and then deleting again, but Vista and win7 are more restrictive with writing files on the fly to program folders. Plus, that way just seems wrong.

Aha!!! Think I've got it. The last limb -1 (don't ask me why -1) is being treat as the root limb. If you then step backwards through the limbs and add them back in, using the world locations as offsets, you can rebuild it! Interesting. The deconstruct/reconstruct code is shown below. Need to split and formulate this into pack and unpack function nows. That should simply be a case of semantics though. I'll post it when I'm done....

dbLoadObject(xfilename,900);
dbPerformChecklistForObjectLimbs(900);
int maxlimbs = dbChecklistQuantity();
int limb=0;
char text[256];
for(int cnt = maxlimbs; cnt > 0; cnt--){
// Obj->limbObj->Mesh->Memblock->file
dbMakeObjectFromLimb(800,900,cnt);
dbMakeMeshFromObject(1,800);
float x = dbLimbPositionX(900,cnt);
float y = dbLimbPositionY(900,cnt);
float z = dbLimbPositionZ(900,cnt);
if(cnt==maxlimbs){
dbMakeObject(1000,1,0);
} else {
if(dbLimbVisible(900,cnt)==1){
limb++;
dbAddLimb(1000,limb,1);
dbOffsetLimb(1000,limb,x, y, z);
}
}
dbDeleteMesh(1);
dbDeleteObject(800);
}