Constantine

nagli Спасибо!

Voted

I logged in manually for several days, tryed checking "remember me", and yesterday the forum remembered me at last. Today I was logged in automatically

Dell has released 22" model with IPS panel at a price of only $300: http://accessories.us.dell.com/sna/product...mp;sku=320-7825 e-IPS panel is specified in the manual: http://support.dell.com/support/edocs/moni...#Specifications I don't know what is e-IPS (and it looks like nobody knows ), but nevertheless I hope it's a variety of IPS panels. Maybe it means "economic IPS" or something. Anyway, $300 for 22" IPS panel is a very interesting offer.

Springheel, have you already bought a monitor?

Everithing works fine for me in pre4! I haven't seen any lockups or crashes.

Is your console window open when you're pressing shift? The lockup never occurs when the console window is in focus. You should click on the main window in this case before pressing shift.

I have a guess why it happens. I think the lower info panel is cause of the lockups. First, it is enough to press shift to make a lockup (without clicking with a mouse on anything). When you press shift, DR tries to display some info on this panel and it stretches in width. Everything goes OK while no default texture selected in the shader clipboard and the panel width doesn't exceed screen width. When some texture is selected, the panel lengthens by a distance depending of shader name length. When you press shift, the panel lengthens some more and its width can exceed screen width. In this case the lockup happens. The probability of a lockup depends of screen resolution, system font size (96 or 120 dpi), and the shader name length you currently selected. The lockups happen only when DR window maximized. Try to unmaximize the window and press shift and you can see how the window stretches and it can exceed the screen bounds (in lower resolutions and when some material with a long name selected). In this case, maximize the window and you can get the lockup by pressing shift.

The viewports die after loading a map and selecting any primitive as they did before.

Yes, the viewports hang.

I've tried it. DR works OK with this GTK version.

Exact reproduction steps? Is this related to the "Viewport lockup" issue as described in the other thread? Yes, it looks like it's the similar problem, although the steps to reproduce it on my PC are a bit simpler: 1. Start DR 2. Open any existing map 3. Click on any brush/model/entity with Shift 4. Nothing changes in the viewports, they don't react to the mouse, but the menu is still working (for example, I can open another map). 5. I've noticed also that If I minimize DR window and maximize it again, the viewports return to life, I see the map with selected primitive, I can manipulate it and everything goes OK until I try to select another primitive again. I've tried using package with GTK 2.14.6 and had no luck. EDIT: greebo, could you please resurrect the link to DR with GTK 2.10.8? I'd like to try it.

I installed DarkRadiant 0.9.9.1 today (after reinstalling WinXP) and found that it hangs when I load an existing map and try to select something (nevertheless, when I create a new map, I can create and select objects rightly, but until I save and load it). After that I had to revert to DR 0.9.8.1 - it works properly.

squill is right, you should pay attention to LCD panel type if you work with graphics. S-IPS and SA-SFT panels provide the best color quaity comparable with good CRT monitors and are used for professional graphic works, but they are rather expensive. PVA/MVA panels are the compromise between quality and price. They have good color quality, but also have color shift effect (dark places of a picture become brighter when you view the screen at angles different from 90 degrees). It's rumored that this defect was fixed in S-PVA panels, but I still haven't seen monitors with guaranteed S-PVA panel (I examined my friend's Samsung 215TW yesterday and found the same color shift as the common PVA panels have). Anyway, *VA panels are the good choise for graphic works if you don't want spend too much money. Anyway, don't buy a monitor with TN panel - they are unfit for serious graphics work. Pesonally I'm waiting for NEC Multisync P221W with S-PVA panel http://www.necdisplay.com/Products/Product...e5-880367d76bfa (It's the new model and doesn't sell in Russia yet) (but, if I had more money, I'd buy NEC 2190UXi with SA-SFT http://www.necdisplay.com/Products/Product...a4-516428de1779 )

Thank you! It seems to me that there are enough brickwall textures in TDM However, I have a couple of unfinished ones, and now I don't know when I'll be able to upload them.

A couple of new textures. Sand (texture 1024*1024, normalmap 1024*1024) http://hedonism.nm.ru/images/darkmod/sand_a.jpg Rock (texture 2048*2048, normalmap 1024*1024) http://hedonism.nm.ru/images/darkmod/rock_a.jpg Link (betamapper repository) https://darkmod.homelinux.com/contributor/b...es/texdemo1.pk4 (The pack includes the "texdemo1" map for seeing it in game)

And what are these reasons?

By the way, RXGB compression looks much better then DXT1/3/5.

Well, It has finally started working! It turned out, that 1) The texture must be compressed in RXGB format 2) The variable image_usePrecompressedTextures must be set in 1 (already was) 3) The variable image_useNormalCompression must be set in 2, otherwise D3 tryes to load a TGA version (was 0). The difference in the quality between the compressed and uncompressed versions in the given concrete textures is vanishingly small. But image_useNormalCompression=2 enforces all the normal maps to be compressed when loading, even if they were stored in TGA (to disable this, highquality/uncompressed/forceHighQuality keywords must be inserted in the bumpmap stage of a material). In this connection I have a question: are the TDM developers going to compress normal maps into DDS or they will be retained in TGA? On the one hand, compressing most of the normal maps can noticeably reduce the mod size, prevent waste of video memory, and allow to use big normal maps of size 2048*2048 without some negative consequences. On the other hand, not every normal map can be compressed without loss of quality, so the materials with such mormal maps must reworked (by inserting highquality/uncompressed/forceHighQuality keywords in a bumpmap stage).

I think it's a bug, or, at least, an incompleteness of the D3 renderer. I tried convert normal maps to DDS and the surfaces became lit up absolutelly wrong (as if all the light sources have moved in other positions). EDIT: Hm, may be, in fact, it's a bug of my hardware?

I think, it can be noticeable on large surfaces. Later I'll upload a couple of wall textures. To make tiling less noticeable, I made so as the tile size was quite big, but to save sharpness nearby, I had to keep 2048*2048 resolution. It wouldn't cause anxiety if Doom 3 processed DDS normal maps correctly, but it doesn't. For example, UT3 uses 2048*2048 textures, normal maps are stored in DDS and don't take too much place. OK, I'll try not to abuse big sizes in future

Thank you What about 2048*2048 size? Is it too big?

Here are 4 high-quality ground photo textures (from photos I made this summer in Crimea, Ukraine) http://hedonism.nm.ru/images/darkmod/ground_a.jpg http://hedonism.nm.ru/images/darkmod/ground_b.jpg http://hedonism.nm.ru/images/darkmod/ground_c.jpg http://hedonism.nm.ru/images/darkmod/ground_d.jpg I've uploaded them into the betamapper repository in Constantine\textures folder (texdemo.pk4 pack). https://darkmod.homelinux.com/contributor/b...res/texdemo.pk4 To see them in the game, install the pack and execute "map texdemo" command. PS. Two of them are in 2048*2048 resolution. I know that 12 Mb per one normal map is a bit too much, but, unfortunately, Doom 3 doesn't support DDS compression for normal maps. If it's too large for including in the mod, tell me and I'll think what I can do with them...

Congratulations! I wish you become no less popular than Aerosmith

It's only command line utility. It doesn't display any messages except "Failed to open ASE file" The screenshots I made illustrate how to setup Windows context menu for running this utility. Unfortunately, I have no English Windows on my PC, so I made these pics in Russian Windows.