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
unused precached files
Re: unused precached files
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.
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.
Re: unused precached files
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.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
Re: unused precached files
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.mh wrote: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.
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).
The night is young. How else can I annoy the world before sunsrise? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Re: unused precached files
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
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
i should not be here
Re: unused precached files
FTE's vid_restart purges everything. All maps, models, textures, shaders, are reloaded from disk. The entire renderer is restarted.Baker wrote:Although I haven't looked, I'd bet FTEQW may use those for a renderer switch (OpenGL <--> Direct3D).
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.
Re: unused precached files
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.Spike wrote: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.
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.
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.)Baker wrote: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.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
Re: unused precached files
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 wrote: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.
Leave others their otherness.
http://quakeforge.net/
http://quakeforge.net/
Re: unused precached files
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.taniwha wrote: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 wrote: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.
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.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for