have you tried actually talking to Lord Havoc about the rain effect?

I can second FTE, it is an awesome engine and Spike is an awesome guy. IIRC FTE recently had its renderer rewritten and should also run more stable now than in old times. Give the nightly builds a try.

otherwise you can always use func_emitter from extras with a rain sprite you make yourself (e3m1rq did this, but the raindrop model sucked).

Maybe DP's effectinfo.txt allows you to alter rain drops? 

have you tried actually talking to Lord Havoc about the rain effect?

no, and, i don't want to. not really interested in having to chase after someone else for personal changes (and likely bug them too).

as for fte, i was told it wasn't really a modding engine, so i didn't invest too much time into trying to figure it out.
also, it turns off mouse accel in windows and doesn't re-enable it when the engine closes, which... i don't know, why does it even disable it in the first place? just needlessly annoying.

anyway, yeah, my foray into fancy custom engines was not a fun one, so i hope FQ stays close to what it is currently. even after all this time, i still consider it perfect (except for that multicore timing problem, which is easily fixed). 

I quickly searched through the thread and didn't find threw answer. :x 

no idea, personally. but from what i recall when the problem first surfaced, it has something to do with the timing function (or whatever) used, and replacing it with a newer function fixes it.
quakespasm has this fix, which is what i use.
i believe baker may have made a version as well? but i have no idea where to get that. 

No texture transparency support of any kind? TGAs alpha chan dosent work, couldnt find anything about it in the radme either. (((
Any hope of getting texture transparency for fitzquake at all? 

Yeah, there's hope. How do other engines do it? Any tga with an alpha channel gets rendered with transparency no matter what model or brush it's applied to?

The main work in implementing it is creating a sorting algorithm for transparent objects (and maybe for individual triangles) a nd then rendering them in the right order. I assume most engines either don't bother or they do it per-object only. 

This is not solved in, for example, darkplaces*: polygons with alpha transparency do not render properly against triangles from the same model behind those polys. You end up seeing the background behind the model rather than the rest of the model geometry as expected.


*At least last time I bothered checking... 

I solved this in DirectQ but it does involve sorting everything on a per-poly basis (rather than per-model, which would be standard for most). It's not hard but it is messy. You should probably also sort particles, water surfaces, sprites, MDLs (which I left sorted per-object rather than per-tri for performance reasons), and possibly other stuff into the same list.

(Aside: There is still a case where 3 or more triangles could partially overlap each other, and which no sorting algorithm could solve. That needs proper order-independent translucency, at which stage you've raised the hardware requirements for the engine so high that few enough people would be able to run it.)

What I did not do was allow for any TGA (or other type) with an alpha channel to have transparency. There are a lot of other BSP format-related problems with this, and ultimately Q1 BSP is just not set up for it. If nothing else, these polys would need to be treated the same as water for visibility determination/portalization, but still be able to generate clipping hulls, which I believe Q1BSP just does not allow at all.

You would need to make them "*" models which is one potential workaround. It would probably also make sense to have a texture naming convention for them, so that you're not slowing down load times by scanning every TGA for alpha (although some engines already do that anyway). 

"Any tga with an alpha channel gets rendered with transparency no matter what model or brush it's applied to?"

Yes, apparently thats what they all do.
DP has no problem sorting huge number of bmodels with alpha. But slapping the translucent tex on the entire ground caused some minor sorting issues.
http://imgur.com/a/Zto3F#5 

Very nice screenshots, pretty dark though. Good to see you're working on a town map - I don't have to feel bad for not finishing mine then. 

sv_main.c world sub models models > 999 can overflow string buffer.

szo fixed this in Quakespasm:

http://forums.inside3d.com/viewtopic.php?f=3&t=4458&start=15 

good catch, thanks for the info 

I noticed that Willem's White Room map hard locks fitzquake085 (have to ctrl+alt+del) but not fitzquake080. Happens for Negke also, I've got no idea why just giving a headsup :) 

http://celephais.net/board/view_thread.php?id=60277&start=93&end=97 

Ok its a known issue, I missed that! 

Fixed in quakespasm since version 0.85.4. See here for the fix, which is actually from quakeforge:
http://quakespasm.svn.sourceforge.net/viewvc/quakespasm?view=revision&revision=359 

FitzQuake 0.85 on Windows: Shambler's lightning attack animation not smoothed, even with r_lerpmodels and r_lerpmove enabled and r_nolerp_list cleared. Not a big deal, but still. 

That's intentional; Fitz doesn't interpolate when an entity goes into a muzzleflash frame. 

i think it might be something else (or the muzzle flash no lerping is linked to .owner in some way?) because checking the 106 progs, the muzzleflash is played on the shambler, not the lightning entity. 

Just a quick brainfart, thought I would post it to see if anyone else found it interesting. No idea if its even possible or easy to implement! :)

A worldspawn key for map specific colour grading / tinting.

Something like _colourmod R G B that will tint the screen image to the mappers preference. So if you have a slime/green themed map you could accentuate the greens/yellows slightly to give a customized final look. Together with fog some interesting visuals could be achieved.

/2 pence 

uhhhh what? you mean tinting the screen like a v_cshift command but automatically? 

I've never heard of this command :) I just tried it but im unsure what values it wants to do anything ;)

A suppose a simple explanation of what im on about would be that you could enter a theoretical "_colourmod" with values of .5 .5 .5 which would desaturate the entire image by removing half of every colour. 

mh is correct: the shambler attack has 7 frames in a row with EF_MUZZLEFLASH enabled. Fitzquake is set up to not lerp frames that have that effect, because usually it's accompanied by muzzle flare geo poking out of the front of a gun, which looks bad when lerped (i.e. on grunt, enforcer, and all player weapons.) Unfortunately it is an unnecessary feature for the shambler lighting attack.

If you don't like that feature, you can set r_lerpmodels to 2 instead of 1 and it should ignore those special exceptions. But, this will also disable the r_nolerp_list feature...

Ideally (note to RMQ team), there would be a way for quakec to tell the engine when lerping is acceptable (EF_NOLERP?), and even which frame to lerp to, and how long to spend lerping. This would only work with progs.dat written to provide that extra information, which is why all quake engines have to make various assumptions to try and make lerping look good. For example, Fitzquake uses .nextthink to guess how long to spend lerping, and EF_MUZZLEFLASH and r_nolerp_list to decide when it's a good idea to lerp. 

With DirectQ I decided that if a vertex moves 10 or more units from back to front between frames 0 and 1 then it's not interpolated. It works well with all current content, but of course something is going to break it at some point in time. That's something I accept for now. I didn't bother with enemy muzzleflashes.

For RMQ we're building new content and it can be made interpoaltion-friendly from the get-go. 

this is done per vertex?
like, if a zombie swings it's arm, the shoulder and upper arm are lerped, but the lower arm and hand (since they are moving fast) are not?