VOGONS

Common searches


Request for better texture pack management

Topic actions

  • This topic is locked. You cannot reply or edit posts.

First post, by Gambit37

User metadata
Rank Oldbie
Rank
Oldbie

My working folder for Glidos has textures for three levels. It's already getting unmanageable as I can never find anything; in particular it's tricky finding which folders relate to which level.

Would it possible to improve the texture management? here's a couple of suggestions in order of preference:

1) Read textures directly from a zip file -- so you could have one zip per level -- nice and compact and easy to manage. Games like Doom3 and Thief do this (although the extensions are not ZIP)

2) Use a subfolder based on the name of the level for each set of textures

3) Also, for development (or indeed generally) would it possible to specify the root texture folder as somewhere other than in the Glidos folder? It's a pain having to copy stuff from my development drive into my Program Files folder all the time, especaiily as I try and keep *all* data separate from programs and am running out of space on C:\ anyway! My dev drive has tons of space free and it would be nice for Glidos to be able to read my dev folder directly....

In fact, I just thought of something else that would be really cool. In conjunction with (3), it would be really handy to change the interface of Glidos for Tomb Raider/UB so that users can choose a set of texture packs to load or stick with the original graphics. That way, users won't have to mess with INI files and they could easily switch between texture packs designed by different people (I have been sent some things by other designers for other levels). It would work just as well with either implementation of (1) or (2) -- you just install graphics into a sub folder off the root textures folder, named GAMBIT for example, then within that are either subfolders for each level or the zip files.

What do you think Paul?

Reply 1 of 57, by Glidos

User metadata
Rank l33t
Rank
l33t

I'll give it some thought. Its a completely different thing to things like Doom. With Doom the source of the game was released so the code that loads the textures for a level has the incredible advantage of knowing what level it is dealing with. With Tr1, all that Glidos can see is the texture; there is no extra info as to what the texture is for. There's no way we can get rid of the strange names for the folders or the coordinates in the file names. Those pieces of info are all that Glidos has at its disposal. They could perhaps be used in different ways, but they have to be used in some way.

We talked before about having link files, so that the strangely named files in the strangely named folders in turn refer to files with more sensible names.

Reply 2 of 57, by Glidos

User metadata
Rank l33t
Rank
l33t

Thinking a bit more about this: at the moment I look fot strangely named folders inside the folder "Textures"; I could look at folders two levels down from "Textures". It would be meaningless to Glidos, but it would allow you to collect things according to level.

Reply 3 of 57, by Gambit37

User metadata
Rank Oldbie
Rank
Oldbie

Eh? Glidos obviously generates folder names based on some key value -- once all the levels have been captured (which obviously I will have done at some point), we will know what folders relate to each level. Can't you use that information somehow?

I must admit I don't really understand how the whole wrapper thing works -- I can't get my head around how Glidos gets information back out from the TOMB.EXE to even do *anything* let alone the cleverness that it achieves. Does it somehow intercept the video output from the TOMB.EXE before it's sent to screen? I only have a small brain when it comes to such things...

Reply 4 of 57, by Kaminari

User metadata
Rank Oldbie
Rank
Oldbie
Glidos wrote:

Thinking a bit more about this: at the moment I look fot strangely named folders inside the folder "Textures"; I could look at folders two levels down from "Textures". It would be meaningless to Glidos, but it would allow you to collect things according to level.

Ah yes, subfolder scanning would be very handy.

Two levels: does it mean Textures> Mansion> 00AE19...?

Reply 5 of 57, by Glidos

User metadata
Rank l33t
Rank
l33t

Yes Textures\Mansion\00AE19. That could be done, but Glidos will scan the lot ever time you start TR1 or load game. There is no way it will
be able to guess which subfolder a texture folder might be in.

Glidos just interprets Glide graphics commands. All it sees i

Here's a texture
Here's a texture
Here's a texture
.
.
.
Use the nth texture
Draw a triangle using a particular part of that texture
Draw a triangle using a particular part of that texture
Use the mth texure
.
.
.

Reply 6 of 57, by Glidos

User metadata
Rank l33t
Rank
l33t
Gambit37 wrote:

Eh? Glidos obviously generates folder names based on some key value -- once all the levels have been captured (which obviously I will have done at some point), we will know what folders relate to each level. Can't you use that information somehow?

Although this facility is used only for TR1 at the moment, nothing in its implementation is specific TR1. I wouldn't want to build TR1 knowledge into Glidos. On the other hand, it would be possible to have a single key file in the Textures folder that gave a mapping from the strange names to more friendly and more structured ones. Glidos could use the key file if it
was there and, the old method if not.

Reply 9 of 57, by Gambit37

User metadata
Rank Oldbie
Rank
Oldbie

Just asking if there's any progress on this?

I've been reorgansing all my folders and have started to use the link files which work fantastically -- I can have a folder called passport or lara or whatever and just link to those -- it'll keep file sizes down and makes updating so much easier.

To have the levels in named subfolders would really be a god send if you could implement it...

Reply 12 of 57, by Gambit37

User metadata
Rank Oldbie
Rank
Oldbie

A query about link files:

You can have comments in the filename, which is very handy. What happens if you have two or more link files that have the same coordinates, but different comments, ie:

(0--96)(144--256).PassportCover.txt
(0--96)(144--256).MayanStatue.txt
(0--96)(144--256).AnubisHead.txt

Which gets use? The first one found alphabetically? I haven't tested this yet.

Reply 13 of 57, by Gambit37

User metadata
Rank Oldbie
Rank
Oldbie

I just had another thought about folder management. How about NO IMAGES are stored in the weird numbered folders, but instead we use link files for everything? Then, in the Textures folder there is a control file that contains the line:

MASTER: trx\

The links files in the folders then contain just a folder path relative to the MASTER path. So, for example, in the first caves folder, 6C7FE41E229619C7ACDED8A8538E3F4E, the vines are file (0--64)(192--256).png.

This would become a link file called (0--64)(192--256).CavesVines1.txt or similar. The contents of the file reads something like:

TLNK: level01\vines-large-1.png

So when Glidos starts, it looks in the Textures folder and reads the master file. It then looks in all the weird numbered folders and gets the file paths/names from all the link files. So, for the vines, it now has the information:

trx\level01\vines-large-1.png

Assuming that we made all the link files available, ANYONE creating texture packs would have the same named files and could use the same directory structure. The only thing that would need to change would be the value in the master file. In this way, multiple texture packs could be installed without overwriting each other and it would be easy to switch between each one....

Reply 14 of 57, by Gambit37

User metadata
Rank Oldbie
Rank
Oldbie

In fact, a better option would be to put mappings for the weird numbered folders directly into the master control file. That way we wouldn't need to even put anything in the weird numbered folders and could store whole packs of textures and links independently of other people's work, and wouldn't have to worry about problems with duplicate filenames etc.

Reply 15 of 57, by Gambit37

User metadata
Rank Oldbie
Rank
Oldbie

For more info, my reasoning comes from wanting to do this for better management:

\Glidos\Textures
\trx\common
\lara
\passport
\letters
\enemies
\wolf
\bear
\weapons
\uzi
\pistol
\levels
\level01
\level02

The master file sits in Glidos\Textures and looks something like this:

BASE: trx\

// level folders follow
// Level 1: The Caves

198EC2D38EF00FEA1653750E8B237D7F: levels\level01
203D6ED9632B742A2209637764C375F6: levels\level01
54637C4BF0304439B63F51D3A5EEA382: levels\level01
60812F71A9287004111BA82EF2404371: levels\level01
708171E626AA342A07B8567EA8A1A53D: levels\level01
C0B3E0125D1A1A0FF5DBBCA296F8AD4F: levels\level01
F7EB7D4BB45372D13AF34500AD82B217: levels\level01
6C7FE41E229619C7ACDED8A8538E3F4E: levels\level01
8B4825478FAB43844E3D4CB077E97613: levels\level01

// Level 2: City of Vilcabamba

F17F2EA5FCB70635738A07C173124945: levels\level02
0C4F02769AD92D3F8EF3653283C8DEB0: levels\level02
2B9F6A059344DAE154DAE71FD6FAB95E: levels\level02

//etc..........

Reply 19 of 57, by Glidos

User metadata
Rank l33t
Rank
l33t

Just having a quick think about this now.

The idea to avoid any images in the strangely numbered folders is nice, but can't we already do that with the link files? Obviously there's no way to declare the root folder at the moment, but the rest we can do I think.

I also like the idea of putting the mapping into one flat file, but I don't think it can be quite as you suggest: having several funny named folders mapping onto a single level folder loses information, and Glidos wont know which of the textures within the level folder to pick.