Quake 3


If the hardware can handle it, i wouldn't bother downscaling.... Use a supported compressed format instead. PVRTC will get a ~8x compression ratio and won't slow down rendering.... probably improve it since the texture cache will be more effectively used (+ smaller bandwidth usage).

The SGX driver should do the compression automatically.
 
It's best to gimp the textures if the dev or dev's gimp has time.

The auto resizing of the textures would be useful if you had some dynamic code that would know the entire load on memory for each level and dynamically resized based on that. Also if there are mods or any kind of user added textures.

I guess texture compression is just assumed these days.

Can the DSP access memory that has been allocated to the SGX?
 
I would not assume texture compression is used to full extent. Looking at the sourcecode, only RGB non-lightmap non-greyscale textures have the possibility of being stored as S3TC (if its enabled in glConfig). Not sure, but this is probably because the DXT1 format only supports RGB textures and maybe the DXT3/5 formats weren't widely supported at the time? Anyway these problems dont apply to PVRTC, it can deal with RGBA textures fine.
 
I used to be an S3 fanboi in the old days. There was a few s3tc levels released by ID just for S3 users. they looked awesome.

I guess that means that atleast the engine supports it even if it is used on a level by level manner. I never considered that lightmaps or anything with trancparencies woiuld be compressed with a non-lossless manner.
 
Talking about resizing textures. Asumming game files are not included - IMO it will be good to release some tool wich will process user's game files on your PC automatically when you want to install the game. Using for example gimp libs. Just unpack, batch resize (or whatever is neccesary), and pack it again (maybe even in one file for usability). Then you just uplod it to you sd card and have fun. I bet it's really pretty easy to implement and it will help saving ram and whatever you want to save xD
 
Adventus said:
The SGX driver should do the compression automatically.

It won't. PVRTC compression takes a lot of time and should be done off-line on a PC.
 
Last edited by a moderator:
I have seen Quake 3 running onto a Iphone, how was the Texture-Size Problem solved there? 1:1 Files from the PC or size-reduced Textures?
 
fusion_power said:
I have seen Quake 3 running onto a Iphone, how was the Texture-Size Problem solved there? 1:1 Files from the PC or size-reduced Textures?
People were discussing requirements for some derivative works such as World of Padman. System requirements for the original Q3 are 64 MB :)
 
Last edited by a moderator:
QUOTE
It won't. PVRTC compression takes a lot of time and should be done off-line on a PC.
Oh OK. I guess you would have to use TexLib and cache the results then. Not sure about the legal concerns....
 
I don't think anyone doubts that the Pandora will not run Quake3. Heck, it even ran on the XGP. The camera was zoomed in because the CPU was not up to stratch. It looks amazing there and we will have better texture compression to make it all the more amazing on the Pandora.

Urban Terror is more questionable, as it requires many times moor RAM.

EDIT: ah Laurent already said that.
 
The Quake3 engine(or rather, OpenGL) can resize textures on the fly. In Quake3, just issue the r_picMip cvar. r_picMip allows you to force the highest resolution mipmap levels. higher values force lower-res mipmaps as the max size. Mipmaps are generated as textures are loaded so there's no need to do any manual resizing. Just set the default r_picMip level to something sane like 2, or 3. Then, users can risk lower values(higher-res) if they want.

Another thing to look out for:
Look in code/qcommon/common.c. You'll notice these:
CODE
#define MIN_DEDICATED_COMHUNKMEGS 1

#define MIN_COMHUNKMEGS 96

#define DEF_COMHUNKMEGS 256

#define DEF_COMZONEMEGS 32

HUNKMEGS is the amount of RAM(in megabytes) that quake3 will allocate for game data. Each hunk will be the value of the com_hunkMegs cvar, in megabytes. Quake3 allocates hunks progressively as it uses RAM. With an estimated RAM usage by the OS of 32MB(roughly), you only have 96MB of RAM to work with(unless you're using a swap file), so you'd need to lower these amounts accordingly. If you are in fact using a swap file, you won't need to worry because Quake3 would just allocate more hunks and you wouldn't notice any difference.
I would recommend setting MIN_COMHUNKMEGS(this is the minimum value com_hunkMegs is allowed to be) to 32, and DEF_COMHUNKMEGS(this is what com_hunkMegs defaults to) to 64. I am not sure what DEF_COMZONEMEGS is used for. It has a cvar(com_zoneMegs) but it does not do anything. Proceed with caution.
MIN_DEDICATED_COMHUNKMEGS is for the dedicated server. Since it hardly uses any memory at all, 1 is a good value.
 
Thanks for that Megatog.

Is there anyway to check how much combined video, physical and virtual memory is used on an app? It would be a good way to test what settings result in what memory consumption to determine if the settings apply to video ram and then system ram, and does it consider VRAM has free, and not associated to the defined values.

EDIT: PandoraOS should not need to use any memory if the OS is deallocated on execution on the application. craigix has said that you will have the ability to set this.
 
icurafu said:
Thanks for that Megatog.

Is there anyway to check how much combined video, physical and virtual memory is used on an app? It would be a good way to test what settings result in what memory consumption.
If you use Linux, top(or htop, my favorite). On Windows, the task manager can tell you how much it's using. Keep in mind a memory usage test on x86 might not be reliable since the Pandora is not x86.
 
Last edited by a moderator:
This is probably a very stupid question, due to the fact that I've never played Quake 3 and I'm a piss-poor programmer, but will multiplayer be device-specific, or will we be playing with people on PCs?
 
QUOTE
Is there anyway to check how much combined video, physical and virtual memory is used on an app? It would be a good way to test what settings result in what memory consumption to determine if the settings apply to video ram and then system ram, and does it consider VRAM has free, and not associated to the defined values.
I generally use RivaTuner for this stuff. You can moniter (and log) a graph of VRAM, RAM and Page file usage (amongst many other things).

QUOTE
This is probably a very stupid question, due to the fact that I've never played Quake 3 and I'm a piss-poor programmer, but will multiplayer be device-specific, or will we be playing with people on PCs?
Really depends on how the programmer implements it. As far as i know, There's nothing stopping us from connecting to PCs running Quake 3.
 
Yeah, that's what I was thinking, too. I just hope the servers are easy to distinguish. I'd hate going up against people on PCs simply because of their distinct advantage over those of us who will end up playing with the analog nubs.
 
Xmas said:
Adventus said:
The SGX driver should do the compression automatically.
It won't. PVRTC compression takes a lot of time and should be done off-line on a PC.
There is a lot of R&D into realtime DXTC and it is perfectly possible (although most of the code for it is x86 only). The published realtime methods so far are not very high quality, but hopefully that will be changing soon... ;)

Vanilla DXTC doesn't work well for lightmaps, but for most other Q3 textures it's very good. With the tight dot pitch on the Pandora I'd have thought you could also drop a mip level without hurting image quality badly (and losing one mip level reduces texture memory footprint by 66%).

I know Simon Fenney of Imagination has done a lot of research into PVRTC in the past, including realtime, but I don't know what his more recent results are. I would have thought there's a good chance that it would be in any SDK that is provided for the chip.
 
Last edited by a moderator:
Back
Top