unused precached files

[domis4]

in the world.qc i found alot of unused precached files (the quake maps, shareware only things, and weapon models i dont use, also alot of other not needet stuff)
as far as i know, the precached files are loadet, but not needet. So, if i // them out, the usage of ram and CPU will be smaller right?
im modding for PSP, so a few mb's will be like heaven

is this correct? and does this make any effect? i think, big maps will make it faster:D

[Spike]

no.

main() is never called.
those precaches are purely as a hint to the qcc to pull those files into the pak files, hence why maps are listed too.
changing those will do nothing except slightly reduce the size of your progs.dat, and fteqcc strips away calls to precache_file/precache_file2 anyway.

[mh]

Memory savings can be made engine-side in Mod_LoadTextures if you're so inclined: the texels in GLQuake don't actually need to be allocated on the hunk at all. Most modded engines still retain this. A slightly more fiddly and involved saving can be made with vertexes (but it can amount to a significant volume of data with a tradeoff being that you can't use vertex arrays or VBOs with surfaces any more), and I'm fairly certain that neither edges nor surfedges are needed at all after a map has loaded. While you're at it get rid of the static arrays for static entities, efrags, temp entities and beams and just allocate them dynamically (temp entities and efrags can use a std::vector in C++ or a somewhat more fiddly linked list in C, static entities and efrags don't even need to be managed by the engine and you can just pull memory off the hunk as required). That should save a few MB overall.

[Baker]

Memory savings can be made engine-side in Mod_LoadTextures if you're so inclined: the texels in GLQuake don't actually need to be allocated on the hunk at all.

Ah this is a good point, I should check the PSP engines to see if they keep those around. I'm thinking they probably don't, but if they do and they don't use them they should be eliminated.

Boring note: FitzQuake's texture manager does actually use those guys if bpp changes during a video mode switch, it reloads the pixels from memory. Although I haven't looked, I'd bet FTEQW may use those for a renderer switch (OpenGL <--> Direct3D).

[leileilol]

Some unused files that are precached can be dropped

Soldier sattck1.wav can be replaced with the identical weapon/guncock to save a bit of memory

Oldone idle and sight can be dropped

Hknight grunt can be dropped

[Spike]

Although I haven't looked, I'd bet FTEQW may use those for a renderer switch (OpenGL <--> Direct3D).

FTE's vid_restart purges everything. All maps, models, textures, shaders, are reloaded from disk. The entire renderer is restarted.

As mh says, much of the wasted memory is locked up in obscure buffers in the bss.
Though I feel I should add that multiple Hunk_Alloc calls are wasteful, and can be compacted by making a single alloc for all surfaces instead of an alloc for each and every surface. There's a couple of situations where such optimisations will save a noticable chunk of ram.

[mh]

Though I feel I should add that multiple Hunk_Alloc calls are wasteful, and can be compacted by making a single alloc for all surfaces instead of an alloc for each and every surface. There's a couple of situations where such optimisations will save a noticable chunk of ram.

True, this. BuildSurfaceDisplayList is one good example here (just tot up how many polys you need and the size of each in your Mod_LoadFaces and do one single alloc at the end of it) - each surface has additional memory used for the hunk header and padding.

This is another case where switching to shaders is hugely advantageous - you can completely get rid of warp surface subdivision (not that it ever worked right anyway) and just use the original polygons from the BSP. That also enables you to use a static VBO for your water and sky surfaces (can the PSP use VBOs?) - performance, memory saving and higher quality all in one. A rare case where you can get all 3.

Boring note: FitzQuake's texture manager does actually use those guys if bpp changes during a video mode switch, it reloads the pixels from memory.

Fitz actually reloads them from file too. Unfortunately it loads the full PAK file (or maybe it's just the BSP file - same potential end result either way) into memory then jumps to the offset location, where a simpler fopen/fseek/fread would have accomplished the same thing. (That's also a potential crasher if you're already tight on memory, although in this case it will Sys_Error rather than go down in flames.)

[taniwha]

This is another case where switching to shaders is hugely advantageous - you can completely get rid of warp surface subdivision (not that it ever worked right anyway) and just use the original polygons from the BSP. That also enables you to use a static VBO for your water and sky surfaces (can the PSP use VBOs?) - performance, memory saving and higher quality all in one. A rare case where you can get all 3.

Even if the PSP can't do VBOs, shaders still get you the other benefits (NICE turbulence and skys, no subdivision). Shaders even give you hardware interpolation for alias models (makes a huge difference on the arwop maps on my nvidia card).

[mh]

This is another case where switching to shaders is hugely advantageous - you can completely get rid of warp surface subdivision (not that it ever worked right anyway) and just use the original polygons from the BSP. That also enables you to use a static VBO for your water and sky surfaces (can the PSP use VBOs?) - performance, memory saving and higher quality all in one. A rare case where you can get all 3.

Even if the PSP can't do VBOs, shaders still get you the other benefits (NICE turbulence and skys, no subdivision). Shaders even give you hardware interpolation for alias models (makes a huge difference on the arwop maps on my nvidia card).

Agreed. Basically if you're not using a shader for water and sky you're beating on a lost cause. You can get something that looks mostly OK, but you've a ton of special cases to handle and restrictions to deal with, quite a lot of messy code to integrate, and the final quality is still nowhere near as good (and it will run slower). With a shader it's just: make your shaders active, send your uniforms (cl.time for water, r_origin for sky), draw stuff, and maybe 2/3/4 lines of code in each shader.

Hardware interpolation for MDLs is another useful one. There was a GL_ARB_vertex_blend extension that could have done it in the fixed pipeline, but it seems to be not very widely supported.