Posted by BitShifter on May 02, 2000 at 20:31:57:
NEED INFO FOR FURTHER TEXTUREASSIGN PROGRAMMATION
In making new levels for our Lara, there will come a time when the conceptor of Her environment will need a totaly new, virgin texture strip for Her.
Granted that a lot has been made and we can recycle Her texture (who would want to change the color of her bodice, really) but if we limit ourselves to recycling old stuff or just dropping new textures that are parcelled in the same way, we are bound to hit a wall.
The idea of TextureAssign is to remove that wall forever.
In making a brand new level, the conceptor will have made a completely virgin texture strip and will need to assign tiles of it to polygons, animations, sprites and meshes.
And here I need some input. I think there are two ways to make it workably.
One is to assemble all texture in *one *strip and work on this, parceling each texture to any objects that need them and make *one* list of coordinates, independant of the bitmap, that could be imported into the level-to-be.
The second is to assemble all textures in separate tiles (256 x 256) each with their separate list (either integrated into or physically separate of the bitmap document itself ... err -leave the cooking to me).
I have listed a possible How-2 and the Pros and Cons of each approach.
I need your feed-back on this as the tool I am now making, I want you to use and I hate coding myself into a corner. When reading this, do not think of the code, think of how easy or hard it would be to use.
So here goes.
=== ONE STRIP APPROACH ==========================================================
Conceptor assemble his textures into one bitmap strip, has his list of moveables,
meshes, rooms and special sprites to drop. He loads the bitmap into TextureAssign
and create a new list, using his prepared list and maybe splurge some and add
some more on the fly.
Late, he will import his bitmaps (8 and 16 bits) and the list into his level .
-------------------------------------------------------------------------------
PRO
One bitmap to manage, one list to manage. Ease of moving and editing.
CONS
Hard to add a new tile to the bitmap.
Updating list complicated.
Extra hard to delete a tile from the bitmap.
One bitmap= one level. Hard to port to different level (especially with different
Lara outfits or enemies)
Forces the conceptor to have all his textures into the bitmap before he actually do his list.
=== MULTIPLE DOCUMENT APPROACH ==================================================
Conceptor assemble his textures into multiple bitmap tiles, one for each "subject",
has his list of moveables,meshes, rooms and special sprites to drop. He of course made a list of what was on which tile just to find his way around.
He loads each bitmap tiles into TextureAssign and create a new list, one for each tile, using his prepared list and maybe splurge some and add some more on the fly.
When he is finished, he uses TexturAssign to weld all texture tiles into one single bitmap tha he saves in 8 and 16 bits and welds all lists into one.
Late, he will import all his bitmap (8 and 16 bits) and the welded list into his level .
-------------------------------------------------------------------------------
PRO
Ease of work reuse: one tile for Lara outfit (omne for each outfit) and maybe all her weapons, one tile for all moveables, one for animations, one or more for sprites, one for skies (TR4).
If the weapons change between level, have the weapon tile separate form the outfit one.
No duplication of work previously done.
Ease of adding a tile: just make it and "recompile" and reinsert/replace into the level.
Ease of edition: just replace a tile with a new one. List would be replaced automatically.
CONS
Document management can turn into something like DLL Hell. Requires discipline.
Easy to get lost in details or outright lose some documents.
Strangely, might lead to tile bloat through sheer number.
===============================================================================
So there.
Which will it be, master ?
I'll let you output for about two weeks (I need the break anyway) then I'll announce which concept and why, let you output some more on that and *then* I will code.
-------------------------------------------------------------------------------