here i am again... :P

this bug (at least, i believe it is a bug) is very strange. specifically, i experience a large performance drop (1ms frames become 20ms frames and the pentagram icon appears) in start.bsp when the light_flame_large_yellow in those 2 big braziers next to the start point are in the pvs on the first loadup of the map. they also, sometimes (depending on your position and view angle), appear partially black except for a few pixels.

if you walk to the end where the normal skill teleporter is (but don't take the teleporter), the light_flame_large_yellow entities disappear out of the pvs (from vis) and performance goes back to normal.

if you restart the map (either by suiciding or restart command), two things happen.
1. the wall torches on the dividing pillars facing the start point turn black, but only on that last frame as the map is reloading. (you see it as the frame is displayed while loading, i mean)
2. the performance drop goes away as does the black pixels problem. (which i am guessing are linked?)

now, here's the complicated part. this happens in a mod, and doesn't happen in stock progs.
this performance drop is a recent developement though, afaik.

so, onto some more weirdness:
the mod allows you to spawn a 'pet' fiend. now, if you load start.bsp (performance drop now) then reload the map (performance drop is gone) and then spawn the fiend, the performance drop is back!
now, if you walk back to the normal skill teleporter and the light flames disappear from the pvs, the performance drop is gone!
also, if the pet fiend goes out of the pvs, while the flames are in the pvs, the performance drop also goes away.

some final info, as it may be relevant:
the player model is also custom with above average vertices and faces and gl_nocolor is 1.

finally, the 'pet' fiend uses a new movetogoal function:
void(float step) movetogoal_ext =
{
local float stepIncrement, stepRemain, tempYaw;

if (step > 10)
stepIncrement = step / 10;
else
stepIncrement = 1;

stepRemain = 0;
tempYaw = self.angles_y;
while(step > stepRemain)
{
movetogoal_builtin(stepIncrement);
stepRemain = stepRemain + stepIncrement;
}
self.angles_y = tempYaw;
ChangeYaw();
}
(movetogoal_builtin is the original function)
so you can see, multiple calls to movetogoal are happening in a single frame.

if you replace this with the old movetogoal, the performance drop doesn't happen when spawning the pet fiend, but the performance drop is still present when first loading start.bsp.


any ideas? o.0 i know this is technically my fault as it's a mod, but the occurrence is so strange and unique, i felt i should post about it. :P 

as always happens when i post about some bug or whatever, i figure out what was wrong. o.o

my heapsize was too small. 9_9 

Why isn't heapsize init-ed to something bigger by default. I know FitzQuake is conservative in some ways, but couldn't this be done ? 

I guess i could; in the past i've just assumed that my users are people that switched from glquake, so they already know how to configure settings that were present in glquake (heapsize, gl_flashblend, etc.) On the other hand, maybe that's not true and maybe many people don't know about those types of settings. If they don't, then I guess i need to figure out the best way to have defaults for those settings which satisfy the most people possible. 

I think defaulting to values that the average machine these days can handle is smart. I hate whenever I have to pass in -heapsize. It irritates me because I can't believe I'm still doing it in 2009. :) 

64 MB heapsize seems reasonable these days, and should be enough to handle all but the most extreme cases. 

Especially considering that machines these days come with a few GB of RAM standard. Seriously, jack the default up to 128MB and be done with it. :) 

for me, i never even thought about it because i never actually run the executable itself.

i always have my fq.bat file which does things like -particles 10000 -heapsize 64000 -bpp32 etc etc.

if you wanted to make the stuff standard, that's cool, but it doesn't bother me either way. :) 

I was thinking about adding permanent parameters to the next version of fitz sdl on mac. There would be a preferences dialog where you can set some permanent parameters, and then add other parameters using the standard launcher dialog. 

Well it's not DOS anymore, even a 32-bit OS will be able to address ~4GB of virtual memory, irrespective of how much actual physical memory you have. Using a heapsize of 128MB is enough to run warpc with quite a bit of headroom (you can squeeze it into 64MB if your engine is careful enough about what it allocs), so I'm wondering is there any requirement for this command-line option to even exist any more? My own engine got rid of it a good while back, but then I use my own custom allocators which are NOT a trivial thing to write. 

Who doesn't have 128MB oF RAM? Seriously, it's time to just set it to something huge and move on. :) 

is there a way to dynamically set it?

i mean, it would be pretty bad ass if the engine just reallocated everything if it ran out of room automatically... ^_^; 

writing a whole new memory system would solve this :P 

Has some code IFDEF'd labelled "DarkPlaces memory manager" that dynamically allocates memory as needed. 

Oh, dynamically allocating as needed is easy. Keeping track of what memory you have allocated, freeing it in the correct places, keeping contiguous blocks where needed, ensuring nothing gets stomped, and transitioning from Quake's cache/hunk/zone system - that's hard.

It's the kind of thing where - unless you *REALLY* need it, or unless it scratches some particular itch you have - you might be better off just upping the default Heapsize. 

I forgot "...and doing it all efficiently..." :) 

The ezQuake #IFDEF DARKPLACES_MEMORY_MANAGER code -- if it works -- is rather simple.

Shockingly simple, actually. 

Does FitzQuake support external textures for alias models?

/Btw ... FitzQuake is about the only non-DarkPlaces engine that renders a skybox when submerged in a liquid with r_wateralpha < 1. I never had a doubt ;) 

I thought this was added in 0.85 

Is there any particular reason why things like -heapsize aren't automatic and dynamic? 

Yes, check 5 posts above yours. 

On september 16, year 2000, 'maiden' posted the #237 message on the infamous thread at Qmap, called:

- - - - - - - - - - - - - - - - - - - - - - -
QuakemapDesigner... Err Designs Quake Maps.
Posted by Shambler [194.112.32.102], 31/08/2000 09:13 GMT
" The modestly named QuakeMapDesigner has been shouting about the Quake maps he's, err, designed at his QuakeMapDesigner site. They look like deathmatch and/or CTF maps to be (though I can't be sure), and QMD is after some reviews, so be sure to pick up some maps and give him an honest appraisal of their quality.
P.S. He's French apparently - any relation to you, Bal?? =) "
- - - - - - - - - - - - - - - - - - - - - - -

So just for you to remember the " good old days " folks and congrats on this thread, because it has a higher number of posting message.

Cheers!

QMD
"Where imagination means, levels!"
P.S.: QMD stands for "QuakeMapdesigner" and not " Quick Masturbation Discharge ". 

When that message was posted I was running around, truant from 6th form, popping magic pills and sleeping in every day. 

"FitzQuake is about the only non-DarkPlaces engine that renders a skybox when submerged in a liquid with r_wateralpha < 1."

No it isn't. ;) 

i'm not even sure why any engine would fail to draw the skybox when underwater, unless they specifically added code to do it. Otherwise you'd think that "if sky polygons are visible, draw skybox" is the most obvious logic. Or even the more dumb and simple "always draw the skybox" approach.