Not logged in, Join Here! or Log In Below:  
 
News Articles Search    
 

 Home / 3D Theory & Graphics / So many textures.. Account Manager
 
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
 
morgar

June 24, 1999, 01:13 PM

I've seen PLENTY of sites that talk about how to Texture Map a polygon and how to get texture
coordinates and I've seen some sites mention a 'Texture Cache' but haven't explained it at
all. I'm just about finished implementing my portal/bsp and am about to go into lighting and
texturing but I've never been able to figure out HOW games get SO many textures into a level
at once? Can somebody point me in the right direction? And what is this texture cache does it
have something to do with it? My apologies if this has been asked before but I didn't see
anything in the forums that answer these questions.. Thanks in advance..

 
john shield

June 28, 1999, 11:07 AM



morgar wrote:
>>I've seen PLENTY of sites that talk about how to Texture Map a polygon and how to get texture
>>coordinates and I've seen some sites mention a 'Texture Cache' but haven't explained it at
>>all. I'm just about finished implementing my portal/bsp and am about to go into lighting and
>>texturing but I've never been able to figure out HOW games get SO many textures into a level
>>at once? Can somebody point me in the right direction? And what is this texture cache does it
>>have something to do with it? My apologies if this has been asked before but I didn't see
>>anything in the forums that answer these questions.. Thanks in advance..

When they talk of a texture cache what they mean is
the data cache on the 486+ processors.

I'm not right up on the old cache but at www.intel.com
there is alot of info on the pentium and intel processors
including optimization rules and data caching.

Most of the info is aimed at asm code but c++ compilers
do optimize code (supposed to).

Hope that helps

 
john shield

June 28, 1999, 11:08 AM



morgar wrote:
>>I've seen PLENTY of sites that talk about how to Texture Map a polygon and how to get texture
>>coordinates and I've seen some sites mention a 'Texture Cache' but haven't explained it at
>>all. I'm just about finished implementing my portal/bsp and am about to go into lighting and
>>texturing but I've never been able to figure out HOW games get SO many textures into a level
>>at once? Can somebody point me in the right direction? And what is this texture cache does it
>>have something to do with it? My apologies if this has been asked before but I didn't see
>>anything in the forums that answer these questions.. Thanks in advance..

When they talk of a texture cache what they mean is
the data cache on the 486+ processors.

I'm not right up on the old cache but at www.intel.com
there is alot of info on the pentium and intel processors
including optimization rules and data caching.

Most of the info is aimed at asm code but c++ compilers
do optimize code (supposed to).

Hope that helps

 
Led aka Lennart E. Denninger

July 02, 1999, 05:03 AM



john shield wrote:
>>When they talk of a texture cache what they mean is
>>the data cache on the 486+ processors.

John, hate to bug you, but you're totally utterly completely wrong.

What Morgar is talking about is the way modern games cache their textures in-game;
'cause it's not-done to load 120 Megabytes of textures into memory at load time.
So there needs to be a texture-cache that loads required textures from disk into memory, and releases textures from memory that haven't been used for quite a while.

A common cache-algorithm will do - take a buffer for let's say 16, 32 or 64 textures (or whatever) and flag their last use. when a new texture is needed that's not in this cache, remove a texture from the cache that hasn't been used for the longest time, and replace it with the new texture.
One of the important things is how to determine wether a texture is in the cache or on disk(stringcomparing names isn't really speedy, a CRC-Identification-code might help or something).

Hope this deconfuses Morgar after the 486-cache-blabla John was talking about :)
(Sorry John, you are right about 486+ cache, but it's not relevant here :))

Led / OrangeGames

 
john shield

July 02, 1999, 12:24 PM



Led aka Lennart E. Denninger wrote:
>>
>>
>>john shield wrote:
>>>>When they talk of a texture cache what they mean is
>>>>the data cache on the 486+ processors.
>>
>>John, hate to bug you, but you're totally utterly completely wrong.
>>
>>What Morgar is talking about is the way modern games cache their textures in-game;
>>'cause it's not-done to load 120 Megabytes of textures into memory at load time.
>>So there needs to be a texture-cache that loads required textures from disk into memory, and releases textures from memory that haven't been used for quite a while.
>>
>>A common cache-algorithm will do - take a buffer for let's say 16, 32 or 64 textures (or whatever) and flag their last use. when a new texture is needed that's not in this cache, remove a texture from the cache that hasn't been used for the longest time, and replace it with the new texture.
>>One of the important things is how to determine wether a texture is in the cache or on disk(stringcomparing names isn't really speedy, a CRC-Identification-code might help or something).
>>
>>Hope this deconfuses Morgar after the 486-cache-blabla John was talking about :)
>>(Sorry John, you are right about 486+ cache, but it's not relevant here :))
>>
>>Led / OrangeGames

Cheers!!!

I wondered what texture caching was. It seems like a good idea to to use virtual
memory for textures.

When the Commodore Amiga came out it had only a 3.5 inch drive on it and 512k RAM.

I wish we could use our RAM as significantly.

Cheers!!!

John Shield






 
morgar

July 09, 1999, 01:50 AM



Led aka Lennart E. Denninger wrote:
>>A common cache-algorithm will do - take a buffer for let's say 16, 32 or 64 textures (or whatever) and flag their last use. when a new texture is needed that's not in this cache, remove a texture from the cache that hasn't been used for the longest time, and replace it with the new texture.
>>One of the important things is how to determine wether a texture is in the cache or on disk(stringcomparing names isn't really speedy, a CRC-Identification-code might help or something).

Sorry I haven't gotten back to this list in so long i've been vacationing :). Well one of our
biggest problems is we are trying to figure out how to cache surfaces more than textures. We
are trying to gain as much information as possible before actually writing any code :) It is
my understanding that a surface is lighting (lightmap) + the actual texture. If this is the
case then for each of the polygons in the scene we would have a different surface. Am i on
the right trail? I have michael abrash's graphics programming black book but it talks with
respect to software mode and individual pixels which right now I'm not concerned with :) So
assuming this is correct I guess we'd do it the same way except with surfaces yes?

 
This thread contains 6 messages.
 
 
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.