In Lazarus, but the only way to make it really work visually was to trap the player in a lift whilst it interpolates. 

I have just finished doing a round of benchmarking using the Windows 7 RTM.

1680x1050x32:

FitzQuake: timedemo demo1: 1227 fps

:O

Curiously, on Windows Vista SP2, I was getting roughly 400-500fps using the same config and same hardware and was thinking that the engine plain doesn't scale any further anymore. But apparently you can squeeze a fair bit out of it with new underlying OS tech.

Specs:
Core 2 Duo E6600 2,4 Ghz, 4gb ram, NVIDIA 8800 GTS 

I am seeing a 3-10% performance increase in Windows 7 compared to Vista across the board, depending on the game. However, Quake and Quake 3 stand out in an absurd fashion.

FitzQuake: 400-500 fps => 1227 fps
Quake3: 380fps => 775 fps 

does 0.85 support external textures for sprites? couldn't find it in the documentation, so it probably doesn't, but on the off chance it does..? 

no, it doesn't. 0.90 maybe :) 

about external textures though...

why do they seem to be lit in a slightly different way from embedded textures? it's hard to describe, but they seem universally darker and don't seem to get over-lit like embedded textures. they seem to be like old glquake where lighting caps out at 100% light.

any chance 0.90 could help smooth out those differences to make embedded and external textures more similar in game? 

that's suprising to me, the lighting should be the same on both types of textures.

If you're using idgamma, then that would explain it, since it alters the appearance of all quake image files without affecting any external replacement images. 

Any chance you could run that test on XP too? The cynic in me suspects that the speed boost has less to do with Win7's improvements than it does with Vista's (how to put this delicately?) crapiness. 

No, I am not going to be install XP on this machine :) 

On my Pc I have some problems that only appear at high framerates, with 120fps it starts and with 500-700fps it gets really really anoying.

so host_maxfps is set to 999
vsync=off

When walking on a ramp like in E1M1 with those buttons the movement becomes really strange I simply can't move forward I have to jump down those ramps. This happens only at high fps rates like 500+, but at 200 fps at the start of the downward ramps there is a little bit of lag. at 60fps everything runs fine.
I noticed another problem in sm155_ankh, it seems that I get hurt by the elevators when standing on them, in fact it becomes unplayable, the problem does not occur with vsync=1 /60fps.
Those problems seem to happen with aglquake too. However with darkplaces it runs fine even at higher framerates.
Testet on vista32 and Ubuntu 9.04 32
gfx card 9600gtgreen driver 190.38win 185.18.36lin 

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 ?