![]() |
Lightmap performance drop
This has been bugging the hell out of me, for some reason the Half-Life engine chokes when there are no lightmaps to be drawn.
I had an idea for nightvision that wouldn't have to rely on dynamic lights but disable the lightmaps which would make the world fullbright and then I could draw over the screen for the nv effect. I'm able to disable the lightmaps fine but the engine takes a very noticable performance hit of anywhere between 10-30fps, I thought the engine would have LESS to do... And after the world has been made fullbright it won't go back, even after the surfaces have been restored the world stays the same. Any ideas why this is happening? Note: Thrown together code Code:
#include <windows.h> |
Re: Lightmap performance drop
ouch... client code.
I know nothing about client-side code :( anyway, that code itself shouldn't make the client slow down... I suppose these are one-time call functions ? Make sure you're not calling DisableLightmaps() each frame, that would rather sound like it to me... |
Re: Lightmap performance drop
Nah, DisableLightmaps is being called once only.
I'm trying to get this on the HL2SDK but I can't find the model_t definition! Its driving me up the wall! Thats the good thing about the hl1 sdk, soo much more organized lol. I guess I just have to get used to it :/ I'm still bothered by the slowdown though, it does the same thing when r_fullbright is set to 1 so my code ( should ) be fine. |
Re: Lightmap performance drop
I guess that's really because you already know that old code for years.
really strange, since that would save one texture stage. maybe there's just something strange inside the HL engine, which hasnt been touched for years, since nobody used it and thus it's unoptimized. and btw : // TODO: // Unroll this loop... i'd suggest you don't care about that and let the compiler decide :) |
Re: Lightmap performance drop
Hehe, if only I had an optimizing compiler :)
I still think its a better idea to hand optimize things since you can see things the compiler can't. [Quick rant] BAH! There is no model_t definition, its just used as a pointer so the engine can give you various bits of information from a model. That really sucks since this lightmap method of illuminating the world cannot work now. |
Re: Lightmap performance drop
Maybe it has to do with disabling and reenabling multitexturing.
|
Re: Lightmap performance drop
I was thinking that might have something to do with it but I do not know enough about OpenGL to re-enable it ( If it's even possible without the engine code ).
|
Re: Lightmap performance drop
Even so, it would still be disabling and renabling.
Anyway, that probably isn't it, because the HUD doesn't cause a slowdown like that. |
Re: Lightmap performance drop
Slightly off topic:
=============== I'm trying some things to prevent certain commands from being used, the only problem is that some are handled completely by the engine and cannot be blocked or changed. I found this in the QuakeWorld client source... Code:
typedef struct cmd_function_s The question is how do I find it in memory? If I were to get some memory reading tool I could look for "rate" or something and find the start of the command list by working backwards. Can you reccommend any memory searching tools? I looked for memory dumping programs but only found pages relating to the windows blue screen physical memory dump. |
Re: Lightmap performance drop
The only memory search tool I can recommand is TSearch, because it's the only one I know (and I wouldn't be surprised if it was the only one existing). It was originally a tool to search for cheats for console games running in emulators (like in UltraHLE, I believe the Zelda cheats were discovered with that tool).
More on topic, I know nothing like the code you posted in the HL engine... I was thinking that all client commands were going either through client commands or impulses, or through usercmd_t's. |
All times are GMT +2. The time now is 05:39. |
Powered by vBulletin® Version 3.8.2
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.