nbohr1more

Officially it's June 1st but, as with previous contests, I will be sending out a note to ask if any entrants need an official extension. Other mission authors will be free to revise their missions until the last extension date is over. A word of advice: It is better (from a voting perspective) to beta-test with more people and get it right at first than to release and discover flaws then release again. While I applaud any author who returns to a released mission to refine it further , the time to complete the missions and vote is limited. So the chance to replay a fixed version of an already release mission may not be there (unless you're Sotha and you can release 3 missions in the span of a contest ) and many folks will not do the courtesy of retracting their vote for the revised version. In short, at least half of your votes will likely be for the quality of the original release. (Well... I suppose you could create a new thread for the revised version and ask that any votes in the original thread be discarded )

You want to check the box that says "Disable Catalyst AI". Catalyst AI is known to be a problem for The Dark Mod. Also, please verify whether Doom 3 itself starts properly. (If not post the error as well).

Have you disabled Catalyst AI? Do you have ROE installed? Are there any other mods in your Doom 3\base folder? Re-run your TDM Updater then verify that these settings are correct in your DoomConfig.cfg seta image_usePrecompressedTextures "1" seta image_useNormalCompression "2" seta image_useAllFormats "1" seta image_useCompression "1" seta image_preload "1"

Don't let LEGION see a statement like that...

It's quite simple really, AluminumHaste is a profession level developer for Broken Glass Studios. Obviously the pay is pretty good

Since ROE is just a bunch of override pk4's couldn't you move them to sub-directory of the Doom 3 install and have the game treat them like a mod? That might resolve ROE compatibility issues folks have with TDM and other Doom 3 mods

If you are willing to donate, then I think it would be fair for you to choose the theme for the next contest AH. I suppose you could still throw some preferences up for a vote then take the highest vote but the real fun of these contests is seeing what happens when mappers are painted into a corner and have to come up with creative ways to make their mission match their own vision. So a contest with every arbitrary preference of the prize-donator would be a perfect obstacle course for mappers to navigate. If players want more missions of a certain type, they can follow-suit and setup contests with their own donations for the prize to coax mappers to make their preferred mission style.

Please verify that these texture compression settings are correct in your DoomConfig.cfg seta image_usePrecompressedTextures "1" seta image_useNormalCompression "2" seta image_useAllFormats "1" seta image_useCompression "1" seta image_preload "1"

When you look a mobile GPU's you have to keep in mind that they are usually half as powerful as the desktop versions with the same name. So an X1600 mobile is going to perform like an X1300 So an X1200 mobile is pretty low on the performance scale... I would say that the minimum is a GPU with 120 shader processors if you go by current ATI measurements, or 32 "stream processors" \ "CUDA Cores" for nvidia. Currently, for ATI I would go for either a mobility 6700 or 5700 series. For nvidia, I would go with a GTX525M or GTX425M series. I am currently leaning nvidia because of ATI's driver issues for current hardware.

So why would these images be reliable enough to feed a fragment program that must get redrawn depending on view yet not be reliable enough as a material stage input? If "_scratch" is useless in a material it must also be useless for a fragment program. There must be a way to fill "_scratch" predictably either for fragments or materials or it has no use ?

I probably won't make the cut Processor: P4 3.0Ghz RAM: 2GB PC3200 (DDR 400) Video: HD4650 AGP

There is no 2048 limit, I just baked a 16kx16k texture using the Megagen tool but it is 1.33GB So there's no size limit other than your hard-drive capacity (and the limits of common sense). Sure the sizes are something to balk at... OTOH how would this compare to creating large texture sheets with DDS? You could potentially merge large swaths of various textures and have nearly all materials in a scene call the same megatexture. For me, it's just another opportunity to ring the promotional bell shouting "Hey, The Dark Mod now has Megatexture support!" You could make it available to mappers on the stipulation that their missions would be too large to host and only one or two missions with megatexture might be good enough to make an exception. And I'm sure almost nobody would use it to add their own custom megatextures because of how cumbersome the baking process is. But it would be there in your Glprogs folder not harming anyone so you could claim to have megatexture support. Even when Doom 3 goes GPL it's hard to say if anyone will be able to add "true" megatexture support as I don't think that it's an open format. The compression\encoding would have to be reverse engineered. It's more likely, if anything, that an alternate version of megatexture would be created.

Ok... Megatexture is a broken-record topic around here but I've never heard that it just requires "ONE vfp file" !!! (and megatexture editing experience of course). I was under the presumption that this was a HEAVY amount of hacking and SDK work and would take months to integrate into TDM (if at all). So I decided to crack open the PK4 and low there was indeed really just one distinct vfp file in Glprogs. The Megatexture.vfp doesn't seem to have any relation with the test.vfp that was included and indeed replacing the contents of Glprogs with JC Denton's \ Ruiner Mod's HDR-Lite the mod still works. Meaning that you don't have to modify the Interaction.vfp to integrate it, it is a standalone vfp. I guess the possible objection is that it's 42 more shader instructions but these seem to run outside the "unified interaction" framework. It really didn't seem to have any detrimental performance from what I could tell either. You could simply plop this megatexture.vfp into glprogs inside tdm_base01.pk4 and be done with this recurring "megatexture topic" as far as I'm concern. Of course the texture size can be astronomical for inclusion with missions but even smaller "mega"textures could be useful. Enterprising authors could use it if desired. What am I missing here, there doesn't seem to be any big technical hurdles, Id and this mod-team already did the work?

Thanks Fieldmedic. I hope that this turmoil is worth it ~~~~~ It'd be cool to have you aboard Biker. The number boost would help. But I understand that you already have a couple of projects brewing so there's no need to pressure yourself. ~~~ Good luck to all contestants.

This appears to be the current standing: Sotha (Released!) Jesps Carnage Ocn Shadowhide With a couple of "maybe" entrants: Fieldmedic (unless your back in for sure)? Midnight moneyobie Bikerdude???????

Obviously we know what the color ones do. These two I can only imagine that they are used in Fragment programs to normalize specular. Though any "good" specular shader replacement would not use a lookup table... "_specularTable" "_specular2DTable" This is probably our old friend the "Normalization Cubemap" (again only good for a Fragment program). "_normalCubeMap" This one is VERY intriguing: "_accum" This one was used to create Prey style portals in Doom 3: remoteRenderMap Just some thoughts... I will have to try some of this when I get a chance...

June 1st (with extension exceptions of course... like usual... )

Congrats Shadowhide. Thank you for the progress report.

More Crazy talks... I was thinking that a kind of "mega-texture lite" could be made by having the SDK code create a virtual file-system that is referenced by dummy material definitions. You could stitch several textures together into a texture sheet in memory then move it to the virtual file-system location referenced by the dummy material definition. In this way you wouldn't need to make tons of texture sheets for different scenes using different varieties of textures and you could save on draw calls by referencing only a few materials per scene... Like a SEED combine for textures. I suppose that would be a bit intensive on the Dark Radiant side... You'd have to have a way to UV map the virtual sheet consistent with the system that renders it in-engine...

That is a bit boggling though... Why go through the trouble of creating this accessible buffer structure yet have the content be too unstable for practical use. After reading further, thus far the camera and mirror can be relied on to populate their respective buffer state reliably. My premise is that you might be able to put "something" in your material shader that reliably fills "_scratch" every time that shader is processed. I am presuming that for every call of the material it is re-processed otherwise dynamic alpha-sort images behind the material would not be blended properly?

Added this as a link in the "Normal Maps: Making Good Ones" wiki. http://wiki.thedarkmod.com/index.php?title=Normalmaps%2C_How_to_Make_Good_Ones

Welcome to the forums Lomondtaffer!

Might work: Lots of patrols Lots of archers Eccentric king who has a high-profile prisoner about to be publicly executed in the court-yard... Rescue mission? (yes loads of work to get it into shape though...)

Happy birthday GDG!!!!

Right... Except some of those images hint at much more interesting capabilities than "_white". Since we know that "_scratch" will capture a mirrorRender operation, what else can be dumped into "_scratch"? And how? (other than mirrorRender)?