stgatilov

Hmm... yes, perhaps you are right. I had some weird blackness on the first test of the new beta, but could not reproduce it after that.

False alarm. Duzenko has removed archivable flag from this cvar. That's a good way to force users to a new value. I'm not sure he will restore multidraw in 2.08, but if he will, he can return archivable flag back, along with default "1" value.

beta208-05 has been released. The list of changes is provided in its usual place. Remember that you must download tdm_mirrors.txt again from the link in the original post before running tdm_update.

No. If you use this "feature" (BTW, I guess this was never supported by idTech4), then live with warnings As far as I remember, all func_static-s in a map produce a single warning, with up to 10 names listed in it. So the spam is very limited. But if you have bad rotation on anything else, then every entity is reported individually. We have some discussion on a design of embedded model transformation (including scale and skew), but did not come to conclusion yet. Be prepared that in some future bad entity rotations will be forbidden completely. By that time there should be some convenient replacement.

A temporary solution would store information about replaced surface and material in some separate place, e.g. in cvar. You can only replace one surface at a time: if you decide to replace another one, the first surface will be reset to normal. In your proposal, the surface under cursor is always replaced, and if you move cursor, then it will be reset to normal, while another surface under cursor will get replaced, etc. A persistent solution is possible with a command. You say "replace the material of this surface", and we change the material pointer in the memory of the model. So the old material would be lost, and the new material would take effect. Until you do something to reload the model (I guess needs TDM reboot or reloadModels command). Saving/loading game does not reload models, so the change will persist, I guess. Of course, you can apply the command as many times as you want, and replace as many surfaces as you need, using different materials if needed.

The cost of bloom itself is pretty low, but the cost of HDR is not so evident. It increases size of framebuffer color image by 100%, size of the whole framebuffer by 50%, and total memory consumed by framebuffers by 33% or 25%. If a particular scene is limited by memory bandwidth or size on particular hardware, it might be noticeable. Don't forget about integrated GPUs, which use ordinary RAM. I don't think fake bloom has considerable performance cost. Moreover, you don't need to create particle for the halo, a transparent func_static is enough. I thought light flares are created like this. UPDATE: Also you should take into account that some people won't want to enable bloom in its current form, regardless of whether HDR is enabled or not.

I have a question about shader. How does this work and why is it needed: //--------------------------------------------------------- // Tone Map to convert HDR values to range 0.0 - 1.0 //--------------------------------------------------------- draw_Color.xyz = color.xyz / (color.xyz + vec3(1.0));

Could someone tell me please if these problems were fixed or not:

TDM 2.06, 2.07, 2.08: none of them requires installing OpenAL. TDM 2.08 has it embedded into exe file, and TDM 2.06 and 2.07 had it embedded into ExtLibs.dll. TDM 2.05 and before: as far as I know, they used software sound mixing by default. I guess it was possible to switch to OpenAL via cvar, in which case user had to install it himself somehow.

What pieces of it exactly are needed for TDM to run?

VC++ redistributable not needed again for 2.08. I don't know what is "Open Audio Library", but I guess it is not needed either.

Looking at the code: Look at the "origin" spawnarg of 'AAA' --- this point belongs to the area 53. Search for "_area53" in the .proc file, it gives you the surfaces of the area. You can use the coordinates or materials to see where it is. Use r_showSurfaceInfo 1 to see which surface it in front of you. It should say "_area53" when you find the proper one. There is also cvar to draw only one entity, but it accepts a renderEntity id, so it becomes a bit complicated.

I think I fixed it. Could you please check this build and say whether it dmaps properly or not?

I can give debug symbols to you, so that you could look at stack trace in gdb. Or you could create a memory dump when it hangs, and send it to me. Uploaded debug symbols for beta208-04 here, in case someone wants to use them.

The tdmsync prototype should work OK with downgrades up to 2.05. I think it is much easier and less error-prone than downloading 2.0 and updating it. I'm going to concentrate on new differential update immediately after 2.08.

According to this page, it only has OpenGL 2.0 and 256/512 MB memory. The 2.08 beta requires OpenGL 3.1. Earlier versions have less requirements. It is quite likely that it does not support FBO and GLSL shaders. Try to set cvars r_useGLSL 0 and r_useFBO 0. These settings are no longer supported, so they'll probably be buggy. Use 2.07, 2.06 or 2.05 version. Make sure to use all default settings (no antialiasing, stencil shadows, no soft shadows, etc.). Try some simpler map, e.g. Closemouthed Shadows. Enable logFile and look at game console.

This setting would do nothing except that disable HRTF. And we already have a setting to enable/disable HRTF, so why adding another one for the same purpose? Well, this is possible... I wonder if there is any old cvar for this. EDIT: Although I think almost all sound assets are 44100 Hz, so using 48000 would mean resampling...

Glad that it worked. The sound is only set up when TDM is started, so any changes during runtime have no effect. Of course, the cvar has to already be set when game starts up. I doubt it ignores the file. More probably, the device option in alsoft.ini only affects "default choice", but does not override device if application chooses it explicitly. That's what I was warning you about

I don't know how alsoft.ini interacts with application settings like s_devide. Most likely one of them overrides the other one. So setting both at once would probably cause confusion when you try to change one of them. Did you try setting s_device to HDA Intel PCH, ALC1150 Analog (CARD=PCH,DEV=0) (as printed in console log), so that it is marked as "(ACTIVE)" ? Does "ALSA default" device works properly for you in other applications? Could you try to enable OSS backend in alsoft.ini instead of ALSA (which I guess is default)? Same applies to JACK and PortAudio / PulseAudio. Could you run TDM with environment variables ALSOFT_LOGLEVEL=3 and set ALSOFT_LOGFILE=openal_log.txt, and post openal_log.txt after start? It contains OpenAL-Soft logs.

beta208-04 has been released. The list of changes is provided in its usual place. Remember that you must download tdm_mirrors.txt again from the link in the original post before running tdm_update. This version includes a fix in AAS. Please dmap your maps and pay a bit of attention to AI pathfinding.

It's probably better to add layer textures as separate maps. This way we can have e.g. 4 layers, with possibility of enabling/disabling them, and one shader which supports all the cases. On the other hand, the front side is unused. Perhaps it should serve as hardcoded front layer on plane depth = 0. Then the outside look can be imbued into the cubemap, along with the shape of the window.

I believe depth pre-pass is done once per frame, and does not depend on number of lights. Also, I bet there is a material flag which disables all light interactions with the surface, so that only ambient rendering is left. Hence, we are reduced merely to initial depth fill, which is pretty cheap, as far as I remember (we have a line for it in r_glProfiling). By the way, there is no depth fill overhead when player looks directly into the room, it only kicks in if he looks from the side.

If you had audio in previous version without configuring anything, then it might be caused by OpenAL update. Unfortunately, there are so many sound options and backends, that every version of OpenAL has some issues Bu the way, alsoft.ini is one place where you can switch backends and probably devices too. Anyway, I suggest posting config and condump. P.S. Speaking of choosing a sound device, the most problem is that sound devices use localized names encoded in UTF-8, which looks like garbage in game console.

I think the hardest is to create the texture with everything properly aligned and oriented. I have very little DR experience, but I think cubicles can be done this way: Create a brush. Set texture coords "to-fit" (in surface inspector?). Set texture lock (in brush menu?). Select sides one-by-one and apply interior textures to them. Move the brush along solid house and use CSG subtract to create a new cubicle. Not too hard, it seems. The approach with cubicles described above is also "interior mapping" in some sense. Because you still have to bake textures and apply them to the cubicle walls. The difference is that you physically create all the walls, instead of faking them with custom shader. So you have 12 triangles per room instead of 2 triangles, but you don't need custom shader. The only performance hit here would probably be shadow volumes casted by outside lights from internal walls. The benefit of cubicles are: it is simple, it works in any TDM version, and you can even add some simple models of big furniture into the room, so that it looks more believable.

Meanwhile, I have a question to everyone who wants to use interior mapping: Why can't you just make a real cubicle for every room? The thing is, interior mapping is usually used for huge modern cities, where every skyscraper has hundreds of windows, and there are many skyscrapers in the view. In this case people render 5 quads per skyscraper with every quad hosting hundreds of rooms. In TDM, we have steampunk setting. We don't have skyscrapers, and typical houses have at most 10 windows. Wouldn't it be cheap enough to add 5 quads per every window and texture them normally without any shader? You can even put a real 3D model into such rooms (e.g. a big table) to make it look even more three-dimensional. Speaking of further work, here are some possible directions: Add diversity to rooms. When you have hundreds of rooms on a skyscraper, it looks a bit too regular when all of them are the same. So it is possible to support setting several cubemaps, so that a random cubemap is used on every room. I guess this does not make much sense for TDM (just as the whole interior mapping probably does not) for the reasons described above. Support additional layers inside rooms. Basically, that would allow mapper to add alpha-textured planes inside the room, parallel to the back wall. Such planes can contain various objects like tables or cupboards. They will be flat of course, but will look closer than the back wall when player moves.