Leaderboard

I really have to ask, though - why not Unity or Unreal? Or Godot, if open source is important? All three of them are much more modern engines and probably a lot easier to work with, in general. You'd have to find a very specific advantage in using idTech4 to justify that route, imho. And as stgatilov pointed out, TDM is a very specific derivative of idTech4, so even if you absolutely do want to go idTech4, there are probably engine clones that are better suited for it.

Hint:

Well good luck to you, but don't underestimate how much programming time will be required, and how much this is likely to cost. A competent programmer working alone might be able to produce a reasonably decent game in six months. Based on average programmer salaries in the UK, this would cost in the region of £20,000. You could try a site like Freelancer.com and find some delusional guy in Delhi who hasn't actually read the brief telling you he can do it for $150, but that's not going to work out well for you.

v 0.75 cubic / non-cubic branching added back to common/direct lighting (guess I removed it when sorting out diffuse vs specular light color.. realized it was broken when playing a level and the tiffany-style desk lamps made the room super bright) called rimlight boost "rimshine" (rimlight is the soft fresnel while rimshine is the bright, crisp edgy part) added rimshine to ambient lighting, but there it enhances all not just following specular trail up wall (had to make it enhance more than just the specular trail, b/c the specular trail going straight up becomes too over-powered with specular + rimlight + rimshine) In ambient, ditched the sqrt() part in the lightdot*X+Y linear algorithm. Valve's half-lambert style was meant for light dots in -1 to 1 range, so sqrt(dot*0.5+0.5) was boosting it to 0.7 to 1 range. AMBIENT_HALF_LAMBERT #define lets you decide if you want to do NdotL*X+Y half-lambert, or full-lambert with NdotL. When doing full-lambert, it will create a final, constant ambient light to add to total light at the end (basically diffuse texture * diffuse light color * constant value to create a constant light not impacted by light direction.. this keeps NdotL = 0 surfaces from being pitch-black). Changed linear lightdot*X+Y formula to minBrightness & mulBrightness ... minBrightness is the additive (Y) part, and is used to see if u_minLevel exists (which it will use as an override). mulBrightness is the multiplier (X), which gets calcualted as (1-minBrightness). (it's basically reverse of how I was doing it with p/q, b/c I realized u_minLevel needed to be the additive, not the multiplier .. d'oh). surfaces in specular light color area that don't have a specular texture (it comes back pitch-black) get the fake specular diffuse brightness boost now. (which my previous post was discussing). So, that dark reddish-brown gate door is speculared, but via diffuse dot enhancement. added a test if specular texture does exist after it's pulled, and that flag is used going forward to do real spec parts. This may or may not help performance much, but it's purpose is to skip more specular math on parts that don't have real specular textures. ripped out phong specular from ambient... it's blinn-phong again, but still uses double-speculars to cover both floors & ceiliings and such. (Phong specular is just too hit or miss.. it looks good in some places, then awful the next. Blinn-phong has more consistent look and quality). added #define to switch ambient light back to original TDM specular style. glprogs.stages.interaction.075.zip

@Jedi_Wannabe, could you please check something about this issue? As written above, the problem depends on r_glCoreProfile cvar, which must be set in darkmod.cfg before starting TDM. We know that "r_glCoreProfile 2" does not work for you, but "r_glCoreProfile 0" does work. Does "r_glCoreProfile 1" work for you? Or you get black screen?

v 0.71 fake spec diffuse light enhancement boosted a bit to be more noticeable added the direct light rimlight boost back in Fake Spec Boost Fake Specs enhance diffuse lighting overall, creating subtle specular shines on things that don't normally have specs, and enhancing stuff that does. When I'm working on them, I'm hyper-focused on them, and notice very subtle amounts. But, regular players are going to be blowing through areas, and won't notice anything that is barely noticeable by me when I'm hyper-focused on them. So, I boosted the amount a bit. The idea isn't for it to be "in your face", but just to add detail that the player might actually notice every now and then as it enhances the scene. Direct Light Rimlight Boost Default TDM shaders have a wonderful effect where the rimlighting in direct light would brighten the more direct line-of-sight the player had with the light source, and the closer the player's eye level was to the surface the light source lit up. When tearing the shaders down and testing each variable to figure out what was doing what, I omitted this, b/c the two parts of it, when tested individually, don't seem like they do much. (one part super-dulls the shine while another part super-brightens). But, going back and looking at default TDM shaders to see what I've missed or did differently, I noticed that when those two var's combine, they create the great rimlight shine boost. So, I added it back in.. but did so by treating rimlight like a two-step light as well. Base rimlight is done, then it's used to create a specular rimlight that gets added into base rimlight.. and then, that all gets added into specular lighting if the surface has a real specular texture map, or diffuse lighting if it doesn't (and shaped by the fake spec map before doing so). So, the nice, bright edge is back on the direct rimlighting... If you're wondering why my rimlighting wraps around more... The normal map intensity has been boosted, making detail pop out more. I don't know I know the normal map adjustment will create more detail to pop out, which means things stick out further and thus get hit by light more. But, other than that, I'm not sure why it wraps more. But, it acts like light bouncing off one pillar onto the backside of the other to extend the rimlight range. I like the effect, so keeping it. glprogs.stages.interaction.071.zip

The latest dev build dev16238-9330 includes dmap diagnostics for location separators and location entities. The goal is the same as for visportals: to make sure that 1) mapper knows that there are problems with locations, and 2) he knows where to look at and what to fix. While looking at issues on released maps, I noticed two surprising issues First of all, locationSeparator applies to visportal if their bounding boxes intersect. This is not a problem for axis-aligned visportals, but if a visportal is under some angle, then the locationSeparator may apply to it even though they don't intersect in DR. Even if it intersects another visportal, it can still get applied to this "angled" visportal instead. The outcome of this problem is that such locationSeparator doesn't work as intended. This problem is especially bad if you decided to put a large non-axis-aligned visportal in outdoors map. The second problem is about visportals spanning over several areas/visleafs. I mean e.g. when visportal is split by opaque geometry into "indoors" and "outdoors" and separates different visleafs indoors and outdoors. It might be counter-intuitive, but such a visportal brush generates two visportals in game. These visportals have same rectangle, so if you enable r_showPortals, you won't understand there are two of them (one of them overdraws another one). Interestingly, such situation is explicitly supported by dmap, and renderer supports it properly too. However, when you put locationSeparator onto such portal, there is no way to learn/control which of the two portals is affected --- the random one is. Even if it is clearly visible that locationSeparator is outdoors, it can still get applied to the part of visportal which is indoors. The outcome is the same: such locationSeparator doesn't work as intended. While it sounds like this problem is easy to spot, I have seen cases where it is very hard: second "piece" of visportal is very small and covered by model.