Search the Community

https://en.wikipedia.org/wiki/Mipmap Mipmaps are lower resolution versions of textures that are used by your graphics driver when objects are further away. Uncompressed textures typically don't include them because the default uncompressed formats don't support them ( not designed for 3D game engines ). DDS textures can include them in either uncompressed or DXT \ BC compressed formats and we typically do "generate mipmaps" when encoding DDS. How do uncompressed textures get their mipmaps ? We auto-generate them on mission load. ( That used to be painfully slow until stgatilov changed the mipmap generation code to use SIMD instructions and multi-core. ) What does the texture quality slider do? For uncompressed textures, it downscales the images before uploading to the GPU. For compressed images, it simply omits loading higher mipmap levels. It works perfectly as long as you properly encode your DDS with mipmaps.

What are mipmaps and what does the texture quality setting do? I mean, when you use a texture in your mission you don't have different quality versions of those textures.

64 bit msys2 version is done and up on the sourceforge site. currently building the mingw-w64-ucrt32 compiler toolchain. it will not have a gnat compiler to start with since it requires a working gnat compiler to start with, but there are plans to use the same method as was used for ucrt64 to have one. a TDM based version will also be supplied which is geared more towards building standalone programs on windows without needing the gcc runtime dll's.

Actually, it is even more interesting. It is not just a force field. It is looks like a sliding door which pushes the player: "classname" "atdm:mover_door_sliding" "name" "launcher" "accel_time" ".1" "decel_time" ".1" "translate" "-40.185 0 335" "translate_speed" "15000" I must admit I don't know how to compute the velocity, and why it depends on frame rate. Perhaps better somehow record the initial velocity, while using capped FPS mode? Or just use binary search to find experimentally which velocity is good.

Hmmm: Could those textures not be a power of two, or use a special type of compression or encoding? I always use the highest setting and find even that low-res these days so I wouldn't notice it then, but it's the only thing I can immediately think of.

More insight on what I meant earlier with definitions being hard to attribute: Suppose you have a definition of the form... atdm:something { "a" "1" "b" "2" "c" "3" } I decide to reimplement it. I open a text editor to do so. Given its simplicity, I end up writing the exact same thing by hand since that's what makes the entity work. I can't prove or disprove that I didn't copy it since no one knows what I did on my machine. Even if I did, the result is the same anyway... would it even make a difference if I retyped it from memory? What I could do is change a few of the parameters so it's more original; Say a = 3, b = 2, c = 1. Or I remove c. Or I add d = 4. Or write them in reverse as c, b, a. What counts as good enough? There's no clear line that I can think of! Not unless it's a long definition with a lot of parameters, so it has a clear structure attributed to someone writing it... in which case one could just shuffle them, change a few values, add or remove some parameters, use original code comments and it can't be traced back via any specific elements. Other assets can be attributed as they have much more complexity and chances at being different. Like if I draw over an existing texture to change a few pixels, you can tell it's the same texture and I used large parts of it without making them myself. Of course if my texture was just a single color (1x1) I could post a copy and believably claim I made it myself and just happened to get the same one color, as it would be silly for anyone to copyright any value within the range 255x255x255 that's already been used by someone somewhere countless times.

That's a pity, and rather an oversight in my opinion (although not very surprising, most of the licensing stuff wasn't really thought about very much until far too late in development). A couple of possible ways around it: Anything that came directly from vanilla Doom 3 would be covered by the id software license, which might be GPL for everything. In this case, the license cannot legally be changed by TDM and must be the original GPL license. For example, the func_static entity def has obvious references to "demonic" which suggests it is based on the original D3 definition. In many or most jurisdictions, purely functional elements which do not contain any creative or original content, or are needed for interoperability, are excluded from copyright protection altogether. This is how WINE is allowed to implement the Win32 API without permission from Microsoft, for example. This might make it possible to use certain entity definitions by stripping them down to the bare bones, and removing all original content such as documentation. Some entity definitions might not be as important as you think: atdm:entity_base, for example, only contains editor documentation for the various spawnargs (which could be re-written from scratch using original language, or just left out altogether).

I think it's good to make sure it's only happening in 2.13 and not also in 2.12. If it also happens in 2.12 it's probably just an (lod related) mission bug that the missionmaker (bikerdude) has to fix. I already send your post info to him (he's not on the forums)

currently building the gcc cross compiler because it needs to be built before the rest of the toolchain. afterwards ill start building the rest of the cross toolchain so i expect it will be done by tomorrow. for those who might not want to wait for the changes to the msys2 filesystem you can use this guide. in /etc find the msystem file and open it with notepad++, you will see a large block of text with settings for the different compilers so scroll down to ucrt64 and make a copy of the block from UCRT64) to the two ;; at the end of the block. now paste it below the ;; in the UCRT64 block and change x86_64 to i686 and ucrt64 to ucrt32 and prefix to /ucrt32. now open makepkg_mingw.conf and do the same copy of the ucrt64 block and paste it below the ucrt64 block. CFLAGS change -march=nocona -msahf -mtune=generic to -march=pentium4 -mtune=generic and MINGW_PREFIX to /ucrt32 save the two files and done. now comes the hard part you need to modify the msys2_shell.cmd file as otherwise theres no way to start a shell for the new compiler so here we go. find this block if "x%~1" == "x-ucrt64" shift& set /a msys2_shiftCounter+=1& set MSYSTEM=UCRT64& goto :checkparams and copy it off and paste it below. then change x-ucrt64 to x-ucrt32 and MSYSTEM=UCRT64 to MSYSTEM=UCRT32. now this block -> else if "%MSYSTEM%" == "UCRT64" ( set "CONTITLE=MinGW UCRT x64" set "CONICON=ucrt64.ico" ) copy it off and paste it below so it becomes else if "%MSYSTEM%" == "UCRT64" ( set "CONTITLE=MinGW UCRT x64" set "CONICON=ucrt64.ico" ) else if "%MSYSTEM%" == "UCRT32" ( set "CONTITLE=MinGW UCRT x86" set "CONICON=ucrt32.ico" ) and this part echo -mingw32 ^| -mingw64 ^| -ucrt64 ^| -clang64 ^| echo -msys[2] ^| -clangarm64 Set shell type make it echo -mingw32 ^| -mingw64 ^| -ucrt32 ^| -ucrt64 ^| -clang64 ^| echo -msys[2] ^| -clangarm64 Set shell type save and make a shortcut to the batch file then in properties put -ucrt32 after the batch file name (remember to make a space between the batch file name and the variable). now the shortcut will open the ucrt32 compiler when it has been built. the launcher executables will do that part when im done editing them. EDIT: you also need to add the ucrt32 toolchain to /usr/bin/makepkg-mingw

for those interrested the ada or gnat compiler is not currently buildable but we might be able to use the same hack to get it going as was used to build ada for the ucrt64 version of mingw-w64. Fortran C and C++ should be bootstrappable without any problems, ada however needs its own seperate ada compiler since it cannot be built with C / C++ alone.

by request i have made a ucrt32 version of the msys2 mingw cross compiler for bootstrapping a mingw-w64-i686-ucrt32 compiler. this version can be used to make 32 bit ucrt versions of current mingw packages for use on vista and greater os versions. since this is a by request build it might not make it into the official msys2 repo's but ill make it avaliable for developers to add to the existing msys2 toolchain.

These changes sound really good. Are there any more planned changes to gameplay and tools for thieving for 2.14? I know new tools are a big task for a team, but the game could use more ways of dealing dampening sound, gushing out lights, or slowing a enemies pursuit once we are caught. Like Stink bomb as and Adhesive bomb, which is to prevent multiple enemies from pursuing a player, and flash arrows to blind a enemy on the lookout from afar. More ways to get out of a sticky nasty situation would be realistic and add extra ways to flat out stall multiple pursuing enemies. And Throwable Playcards would be used to momentarily distract a guard to behind get past nearby lookout. Cards can also be used to mark doors we've been through in large heists. A Flash Arrow or two also would make it easier for some big missions.

Yeah, I tried it in 2.12 and it was fine. The next version, dev16996-10665, drops me slightly short when I use the catapult chair.

Yes, diii4a would need to merge our latest code changes to their fork. Otherwise they might need to use scripts, defs, materials, etc from 2.12

I think you could use a better mediawiki theme. But if it's temporary I guess it's ok. There's loads of cms's and site generators out there. Since it's mostly static you don't need something like Wordpress. Btw. I see in your articles that you are critical of Prey 2006. I personally think it's an awesome game. One of the best games I ever played. Maybe your experience is a bit personal and I think it's better to give examples of games that are actually bad. https://www.henry-ym.org/index.php?search=prey+2006&title=Special%3ASearch&go=Go (I mostly disagree with your criticism)

im a bit ambivalent on the jupiter source code as it is pretty messy and relied on some old ass f... compilers. the unmodified source is buildable with msvc 6.0 and msvc .net 2003/2008 but newer compiler versions requires a massive rewrite of the build system and an even massiver rewrite of the source code to adhere to newer cxx standards. bibendovsky has made a ton of changes to make this happen and replaced some troublesome parts that wreak havoc on newer windows. he added a compatibility layer as a library that gets comiled in (spul) which also handles some of the cross libraries such as openal and ffmpeg. you can still build it with the old dsound / dinput but it might not work to well on say win10 and up. compared to the mess you needed with msvc 6.0 which needed stlport to even build, his version does build on even the latest msvc compilers. only downside is that the tools source code still needs porting. msvc .net 2003 still works even on win11 with some compatibilitiy settings applied (fullscreen optimization disabled admin and ignoring high dpi) and it's free to download. it supports upto XP and as low as win.311 directx support is a bit more shaky but you can actually use directx9 with it with some dummy headers or get this https://archive.org/details/dx90_vs2003_full.

This reminded me of something I kept forgetting, I think this is why I ran with capped FPS: The main menu still doesn't provide an option to fully disable the cap, only to set a higher value for it. There's no unlimited value for the "Max FPS" field, you can go up to 300 then it loops back to 30. Shouldn't that option be provided, or does the engine not allow fully disabling capped FPS and still requires a limit? Actually why not mix the "Uncap FPS" and "Max FPS" settings? It might reduce clutter to have one field. Options would be Capped, Uncapped, then all the different numbers. Even more so, why not mix Uncapped and 60? Technically it should be the same thing, feels redundant to have both under different names. Unless of course there's an important technical distinction between the two modes that shouldn't be removed from the engine; Do "com_fixedTic 1" and "com_maxFPS 60" practically do anything different, any reason not to remove the legacy var entirely and use maxFPS to get the capped FPS of the old days?

The old "Fixed FPS" ( com_fixedTic 0 ) mode is still as laggy and poorly performing as ever. With the new mode and maxFPS = 60 it's still waaaaaayyy smoother than the old mode. I can try setting it to max between r_displayRefresh and 120 to see whether a perfect double of screen refresh is still viable to remove the artifacts? I was trying to find a good way to query monitor refresh but it seems that the r_displayRefresh cvar is just an alternate to the GLFW mode data that feeds "parms.displayHz" . It seems that we treat that mode data a little differently in Win vs Linux? So I guess these are the paths to improvement here: 1) Try to use parms.displayHz instead of r_displayRefresh and hope the GFLW does a good job of picking the right value 2) Max between r_displayRefresh and 120 ? 3) Keep trying find a way to restrict maxFPS to 60 in the menus ( I got this one partially working but once you leave the game and return it's stuck at 60. I also had the inverse working, starting at 60 in the menu going to 300 then when returning to menu it was at 300 ) 4) Keep trying to find a way to force gameTic sync when entering and leaving menus ( I guess this is the "correct" thing to do... ). ( Thus far, all the glFinish, clear frame data and RunGameTic things I've tried have failed miserably. ) Sadly, r_displayRefresh is a sorta dangerous parameter to play with and thus it isn't archive-able. We could do it, of course but if a user has a legacy CRT and sets something crazy they could damage their hardware etc. Thus to enforce a higher refresh, users will need an autoexec.cfg or will need to constantly invoke the change in the console. Edit: Results thus far Max between parms.displayHz and any value ( 30, 60, 120 ) = artifacts appear Use parms.displayHz directly = artifacts appear Hard-code 120 = one blip artifact only on the first entry into the game Based on the above, and that hard-coding 60 also eliminates the artifacts I can only surmise that parms.displayHz is not picking up the correct value?

That was exactly was confused me from the start. I still don't like the "select/deselect" alternative, because according to Windows standard UI you select/deselect something just by high lighting it in the list or not. Which does nothing as such, which is why I use activate/deactivate instead. Can you use that in the 2.13 final please?

Cheers, can't wait for the release! For @stgatilov@nbohr1more@AluminumHaste and other code devs: With the beta cycle coming to an end and this issue seemingly breaking intended functionality, do you think it's possible for #6565 to be checked out before the release please? I wouldn't poke about small bugs, but this prevents me from designing my entity setup the way I intend it to work, without a fix such FM's won't be playable in the next release. I plan to have interactive items appear after completing objectives. For static objects it's easier to use the hide spawnarg and trigger them to show up, as opposed to using an atdm:teleport which is currently the only workaround besides using a script. Right now anything with "hide 1" doesn't have collisions or become frobable once shown; I suspect the engine doesn't load the collision model and treats "hide 1" as "noclipmodel 1" although the entity is meant to show up later. Example for frobbing: I have a readable journal I want to appear in a room after the player completes an objective. I give my journal the spawnarg "hide 1" so it starts invisible and unfrobable, set the journal as the objective completion target. When completing the objective and triggering the journal, it will become visible as intended but can't also be frobbed so the player can't read it. Example for collisions: I want a large statue to appear after the player explores an area. I add it as a func_static give it the hide spawnarg then have a trigger_once target the statue. Currently the model becomes visible but collisions don't activate, the player will see it but is able to walk through the mesh even if it's not "solid 0" or "noclipmodel 1".

Just like in the inventory grid the item count shouldn't be displayed in the bottom-right inventory for non-stackables ("inv_stackable" set to 0 in the item definition). This is easily fixed by editing [guis/tdm_inv.gui] and removing: visible "gui::Inventory_ItemVisible" From this line: #define INV_TEXT_SETTINGS visible "gui::Inventory_ItemVisible" noclip 1 matcolor 1, 1, 1, "gui::HUD_Opacity" textalign 1 textscale INV_GUI_FONT_SCALE font INV_GUI_FONT forecolor 1, 1, 1, "gui::HUD_Opacity" Each def in the file making use of INV_TEXT_SETTINGS is governed by its own dedicated "visible" variable therefore the issue is solved and nothing else is impacted.

Saw this video and had many questions. The one about the ridable horse was answered; Turns out it's an old definition that's been commented out for years as it was never finished, hope that may change in the future as it would be great to have by default. Would love to know where we can find that werewolf monster though! Is it still available and free to use in other FM's? It looks well polished from what I can tell, but I presume there's a reason why it wasn't added yet. Speaking of which: Are there plans to work more on the werebeast? Apart from lacking some animations I noticed the bones aren't even named, like instead of "head" it's something like "bone18": This may be a problem if it's fixed in the future, in some projects I'm attaching things to the head or back using the existing bone names, if those FM's got finished before then they'd need to be patched or will crash.

Release of gen_lang_plus v 1.0 My new C++ version of gen_lang.pl, called gen_lang_plus, is now available. For a comparison and complete description, as well as downloads, see the new wiki page Gen_Lang Programs. There are some modest improvements and bug fixes compared to gen_lang.pl, which it is hopefully positioned to supersede. In the larger picture, having this code as C++ may facilitate partial re-use, e.g., perhaps as future capabilities within TDM or DR. Thanks, @Amadeus, for providing me with output file samples to compare against.

The one and only time I tried making AIs use an elevator, the chance one of them would fall down the shaft and get squashed by it increased dramatically the longer the play time went on. Then of course all the other AIs would spot the corpse and blame the player for his death.

I might be able to shoehorn a staircase into the design. It isn't necessary for the gameplay to have the AI to move between these floors though. I just thought it would be nice to see them use the elevator.