SteveL

Agreed, this is an annoyance. Does anyone know how to fix it? And is it the same on Linux?

1. Glowing symbols (permanently visible) Nothing special needed for this use case. We just use "blend add", and they won't taint the underlying surface where they are black, but they'll add brightness where they are white, and the mapper can control the colour and brightness using the "_color" spawnarg. 2. Graffiti (stains on the wall) We just need to invert the colours (no need to change the image, it can be done in the material file) then use blend filter. The black areas of your images will do nothing; the white parts will darken the surface behind, again controllable by the "_color" spawnarg. 3. Secret symbols (gleam in only one particular light) We'd need to make them light-interacting for this case, but still be completely transparent in the black parts. We might have to fall back on alpha testing, using your images both as alpha map and diffuse map. We'd lose a bit of the detail where they fade out, but hey, it's a magic symbol and a rare/special case that'll come with some wow factor built in when the player solves the puzzle. Again we could use the "_color" spawnarg for tinting. I'm not convinced that my suggestion for (3) is the best possible solution. Others might have better suggestions

Fantastic! I reckon they'd be best used as stains on the background. Just thinking through the material configuration...

I've always wondered whether anyone had found a use for "spectrum". Both the light and the surface are limited to the special spectrum, and I couldn't think of a use case. But this would work. You'd have the spectrum light in the same place as your moonlight, so they share a shadow, and it would look like it was moonlight only that could reveal the secret sign. You could put other lights around, and neither those nor your ambient light would show the secret mark.

Could some kindly person please provide a translation of the earliest ones (2nd pic)?

I just checked my copy of BFG to see if I could get at the scripts, but I can't, unless someone here knows how to open one of its '.resources' archives. 7zip doesn't know how. Is the code you need to see definitely in the script files? I think you can step through the BFG c++ code in a debugger, as long as you have a copy of the game resources to go with the released code. For that matter, you could use the released code to open and unpack the .resources files if you're really determined

I do like the idea. It'd need some research or imagination. A quick google image search for medieval graffiti is mostly carvings in stone for obvious reasons, which isn't right for us. It tends to be too small scale, and anyway we'd need something that looked right as a decal on existing wall textures -- i.e. the kind of graffiti that'd been painted on, not scratched into stone.

It's a big code base. TDM has about 650 lines of code in the main projects, not including comments and whitespace. Fortunately it's very modular so it's fairly easy to find stuff once you get used to the modules. You can download the original doom3 or the BFG edition source code easily enough. Or is it specifically the scripts you need? I'm not sure off-hand whether they are included but it's worth looking.

Thanks for all the hard work! I'm looking forward to seeing them in game.

I'm a relative newcomer to the project, so almost anyone else on the team would be able to give a better-informed answer :-) But I haven't heard of any of it having been paid for. I think the entire project has has been built purely by voluntary work. We do use external open-source code of course. The principle of paying for stuff has been discussed a couple of times in the last year. In general, we're against it. Firstly, there's no need. Top quality work is already being done, and offering money wouldn't necessarily increase the amount of output. Plus, it could demotivate volunteers. Who's going to join and donate 100s of hours for free when someone else is getting paid for doing the same work? And make no mistake, between mappers, modelers, and coders, there are 100s of hours of work going into the project every week right now. When we get close to the next release (not scheduled yet), we'll need play testers to donate 100s of hours too. Paying for the odd 12 hours freelancing here and there won't significantly alter the output. Lastly, on the coding side, imo this project is too mature to benefit from quick freelancing anyway. Changes have to be backwards-compatible with 80-odd maps. A freelancer would have to spend at least a month familiarizing themselves with the game full time, else they'd end up submitting broken code that an unpaid volunteer would have to fix. The project work I mentioned is on TDM. DR has had a lot of recent development too -- it's not long since greebo released the last version, and not long since he single handedly ported the entire project to wxwidgets. But I'm sure he'd appreciate another pair of hands picking up some bug reports, if you guys were thinking of offering :-)

I'd like to fix that, if I had the slightest idea where to start. You can minimize and resume fullscreen TDM without problems or delays using the task manager, so it feels like it should be possible with alt+tab, but I don't know how to tackle it.

He's around, just not checking in daily by the look of it. He was here earlier this week, fixing the updater.

AH reported the same problem in a status update on the 16th. I don't get forum notifications so don't know. I think taaaki hosts the forum now.

I prefer learning that way too, but most people prefer to start with something that works and build up experience from there. Both ways equally valid of course. Python makes it incredibly easy to get going and make a little program that works, but it's so high-level it will make your head hurt if you're the type who needs to know the mechanics before they feel they understand something. c++ on the other hand is so flexible that you can write code at any level of abstraction. You can use libraries to do all low-level tasks, and use references instead of pointers, and feel like you're in a scripting language. Or you can get down and dirty with the void*s and program like you're making a complex and beautiful tiny mechanism, that does the job in as few processor operations as humanly possible. I love it That said, I do use python a lot. For small jobs where processing speed is not the limiting factor, it's usually the right tool. If I need to write a standalone file converter or parser, I'll always write 10 lines of python where I can see the results of each line of code as I write it instead of 200 lines of c++ that I need to debug in a special debugging environment.

Like Springheel said, this does work. But don't unpack the three tdm_game*.pk4 files. Sorry, forgot to mention that bit. You should end up with around 20 top-level folders in your darkmod folder, beginning with af/ dds/ def/ and ending with /xdata

Yes, that's the seed combine code and it's successfully combining draw surfs into fewer draw calls. Not sure what went wrong with my easriler test (a couple of months ago), but it *is* a bit fiddly to set up so I must have done it wrong.

Oops, my bad. All scripts are in tdm_base01.pk4

Thanks, studying it now

That's right, any of the above causes an extra pass (draw call). Most of our transparent glass textures have 3-4 draw calls built in, even though they are unlit. For worldspawn, it's dmap that does the batching of surfaces, not the renderer. I can't see any evidence of the renderer merging anything. The wiki says that SEED can batch identical models into a single drawcall, but I haven't found the code, and couldn't get it to work in a test map. My watched models all had their own draw call still. I must ask Tels whether it actually got implemented, and if so where. For TDM use though, it might be better to merge same-textured surfaces from adjacent but different static models rather than rely on instancing. That would work well with modelled architecture where you have different models that use the same textures and get hit by the same light. The complication is you'd have to recreate the group's VBO on the fly to apply LOD effects, or alteratively have the entire cluster switch LOD at the same time.

It's in tdm_scripts.pk4. You can unpack all the archives into normal folders and tdm will still run ok, which makes it easier (but still not trivial) to find things. I have a python script that searches inside the pk4s of a standard tdm installation, including inside FM pk4s. I can post it after work.

I'm now thinking of creating a new texture instead of modifying the old one. The old description doesn't actually specify 0,0,0, and it *is* extremely dark. It worked fine for the purpose I mentioned above, for the bottom of pits and holes. The only time it's been a problem is when I've been using it in test maps for transparent textures and particles, where I use it as a backdrop to examine additive shader stages. The dim reflections from matt_black have been a niusance. I should probably just add a pair of opaque textures to the sfx folder, "full_black" and "full_white".

see tdm_moveable_food.def in tdm_defs.pk4 The "eat_it" script that that def references, and that contains the logic, is in tdm_equip_actions.script

Mmmmm that's real! You have a gift for the gritty and interesting.

Fantastic! Thanks for sharing. I would love to learn to use Blender, if ever I get to the end of my renderer to-do list

It won't work in existing maps until 2.04. But if any mappers want to release a map with working food in the meantime, I can tell them how to fix it. It didn't need any game code changes, just changes to a def file and a script, so mappers can package the fix with their map in the meantime if they wish.