host_maxfps be left at 72? 

per-entity alpha doesn't work on sprites?

what if a setting != 1 (or 0) would change blending mode on sprites to additive and then, depending on the alpha variable, multiply the sprite's pixel colours by a shade of gray corresponding between 0 and 1?

or just make it do what you did for brushes and models? :P 

it can be done with alpha blending, and will probably make it into a future version. The reason it's not in there now is it seemed less important than the other entity types and i was trying to wrap up that version so i could actually Ship It. 

that's cool. it's not like it's a huge problem or anything. brushes and models are more important, as you said.
still, it was odd that alpha wasn't supported for all types of entities, which is the only reason i brought it up. :) 

just a question, in the fq085 readme, it says:
fixed sliding around while standing on solid entities' bounding boxes (monsters, players, etc)

but it's not actually fixed. was this a planned feature or something that was scrapped? 

That was fixed in a really early version (like 0.60 or something)and later reverted when I realized it had side effects. I am now more cautious about changes that affect gameplay. Plus I think thus can be fixed in qc instead. 

yeah, i can be. i was only wondering if it was going to be re-added and if it was worth skipping the qc fix. 

I think i'd have to be convinced that it would be a good idea to re-fix it in the engine, since it seems like that would just lead to inconsistent behavior across engines. Probably better to fix in in qc so that it works in all engines. 

in runequake its fixed so u don't slide on players heads

leads to great towers of players now and then 

Players standing on monsters and the like as if standing on the ground is a potential gameplay changer. Players can use such entities as platforms to reach places more easily or are otherwise inaccessible.

I would rather see the "fix" either left out, or included as an option, with the fix turned off as default. One reason why I play FitzQuake is it has useful features such as frame interpolation and increased limits while retaining the behavior and feel of the original engine. 

with this fix 

i think, if i ever revisit some of this stuff, i will follow the Darkplaces method of having a seperate cvar for each gameplay-changing "fix" so that you can turn them off as you wish. 

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