To be honest, I don't even know what these flares are supposed to be.
CheapAlert: did you really mean "Lens Flares"?
As a matter of fact, I've seen a cool Lens Flare implementation already using the normal Quake3 engine, namely in the WoP mod.

Quote (Thilo @ April 10 2006, 8:12 pm)

already using the normal Quake3 engine, namely in the WoP mod.

Really?  I used to play that mod all the time, but never really saw a lens flare set...  Where abouts was that?

I might compare it to my cheesy lensflare implementaion in RPG-X lol...

Hrmm, he was referring to the 'flares' that appear over lights and other bright sources in EF.  Whilst they're not called 'Lens Flares' in the game iteslf (The closest is 'Light Flares' ), they fit the criteria for my definition of Lens Flares.

If you set r_flares to 1 in HM and then walk around the flag areas in the map CTF_Singulairty, you'll see a lot of them in action.

-TiM

CheapAlert: I see that the flare functions are really already included in the Q3 engine, namely tr_flares.c .. The function RB_AddFlare is never called anywhere, though. I could really try fixing this!

TiM: Ah, got it... I see the flares now. Switched them on/off in the original game.

Quote

Really?  I used to play that mod all the time, but never really saw a lens flare set...  Where abouts was that?

It's only in the newer version of WoP on the map wop_padlibrary.
See: http://thilo.kickchat.com/bilder/wop_lensflare.png

Quote (Thilo @ April 10 2006, 7:34 am)

I found out news about the lighting stuff: You may want to try changing  r_mapoverbrightbits and r_overbrightbits both to "1". I think lighting looks more close to the original then.

I didn't have r_mapoverbrightbits "1" in my hmconfig.cfg, so I added the line. Now it looks more close to the original.

I spent the evening playing around with this engine.  It certainly is fun.

There's only one shortcoming though.  Due to a small change in the Q3 engine since EF was made, that controls player movement, this engine doesn't allow trench-jumping (ie in maps like voy1 + voy2 ) by default.

There's a fix to this, but it requires creating a new set of QVMs.  I'm hoping it may may be possible to somehow add a fix to this inside the engine that won't need QVMs, but I hear that could cause compatibility issues...

In any case, with this engine, I think a whole lot more potential for EF modding just opened up.

-TiM

Quote (71M @ April 10 2006, 1:30 pm)

this engine doesn't allow trench-jumping (ie in maps like voy1 + voy2 ) by default.

I was never able to trench-jump, even when set to the proper setting BTW I spent from 12:30am to 2:30am playing with the engine, and it is fun.

There's actually a bunch of q3 mods with flares, but these are nothing more than cgame side hacks. Engine flares are much more efficient imo.

Note that there are about 2,000 flares existing in stock Q3A, ending up "disabled" engine-side in the final release. :P

oh and note q3a's flares (Q3Test anyway) perform almost exactly the same way as elite force's - they suddenly dissappear on clipping, etc...

I have done some work on the flares and got them to work... crudely. When you enter ctf_singularity they dance and float around happily in the air.. as soon as I fire a weapon the flares go to the places they are supposed to go to. That behaviour is very strange and I need to do some more debugging before I can fix it... not today though.
I was only doing a "quick hack" anyways.
On a sidenote, when firing the phasers and the flares are at the places where they're supposed to be they *did* fade in and out on clipping like it was originally intended.

btw.. cheapalert: i bet you were that Gargoylol guy on the icculus.org forums?

I also fixed all of the bugs that have been mentioned in this thread. There'll be a new beta release sometime next week.
I did some research about the skybox bug and found out that the bug has only been fixed in the SDL OpenGL backend, not the windows native one. As Windows does not yet use SDL (will be done in the next versions of icculus.org) the bug was still present. I tried some kind of a workaround but am not sure yet whether it works as I haven't prepared any new windows builds yet.

yeah im' gargoylol

i think the flare fading code is the problem here, as q3test 1.05 didn't have it and the flares had no problem there, and elite force's renderer may be originally based on the older q3 engine code (it seems to have different environment mapping too)

also a fun note... q3test 1.05 has broken gamma in 2k/xp, just like elite force :P

There are two different ways flares are generated. One that goes over the R_AddDrawSurf code that is generally used for all type of surfaces (Models, map structures, etc). I guess that was an older implementation for testing purposes, that will yield exactly the clipping behaviour you described. And then there is another implementation in the tr_flare.c file that doesn't use the normal path surfaces take in the rendering process but is only added in the last rendering step and is somewhat independent from all the other surface types. I will try to take that one, I haven't been too deeply involved with the code yet, a couple of hours but that's not enough for really understanding how it works. I also have very little experience with 3d rendering and OpenGL in general, so this may still take a while.