Thanks to all.
Baker wrote:Open source = adding to the pile of knowledge.
This is why I've released it now. The last straw that led me to release it like this is that I've got a new job which is consuming all of my time, so I should be unable to work on this engine for several months.
Keeping the source closed while working on it is good for having no interruptions to our train of thought while developing our ideas, but since my train of thought has already been interrupted and will remain like this for a substantial amount of time, there's no reason to not release this code... while releasing it may still be useful to others.
mh wrote:the particles are a little too large when up close
Yeah, it took me a while to get used to it too, but it's actually more accurate and now the particles seems much more enjoyable to me, since their size is always proportional to the rest of the 3D renderer's space now. Bringing down the console and looking around an explosion with the chase camera turned on is awesome.
I don't know how GLQuake scales them, but the vanilla software renderer clamps the size of the particles at an arbitrary size (which reduces their scale in the 3D space, making them innacurate) without taking the screen resolution in consideration, so particles in it look a lot bigger at 320x200 than they look at the highest resolutions.
Reimplementing the translucent fading should make things better, but the particle emitters' code must be adjusted a bit first, since in some cases it replaces the particles for others of different colors instead of just changing the colors, which makes it impossible to use the particle's time to calculate the intensity of the alpha blending.
By the way, I have no idea why the offset and the width values of the particles' lines must be changed so much just to get memset to replace the inner drawing loop. I've #if'd all the necessary changes in the code to research about this when possible.
Sajt wrote:- menutint ran at < 1fps for me (at 1280x1024). This could partly because of readback from hardware video memory?
Most likely. The best way to check for this in any software-rendered engine is to activate the menus when underwater, because then the engine will read the pixel data from the system RAM instead of reading it from the video RAM.
Sajt wrote:- something in the hard difficulty hallway on startbsp also crippled the framerate now and then. Not sure what... lavabomb dlight?
I'm not sure either. In Quake's software renderer all surfaces lit by dynamic lights are re-cached every frame, and I've added a few things at the beginning of the caching process to implement one of the new features (I can't remember which feature at the moment).
Much of the new code in the BSP renderer is completely unoptimized.