Jump to content
The Dark Mod Forums

Leaderboard

Popular Content

Showing content with the highest reputation on 04/08/21 in all areas

  1. It sounds like you need the additive lit window texture to give the appearance of a glowing window, and an upward-pointing light to provide the actual light which shines into the room (including its shadows). Remember that this is a game engine not a ray-tracer, and certain physical-based effects that would happen in the real world need to be simulated by hand. Translucent materials in this engine just allow you to see through them, they do not provide full light transmission, caustics or any other effects that a raytracer might simulate.
    3 points
  2. Since it already has been mentioned in the forums, I'd like to announce a small project of mine. A few weeks ago I was playing Legend of Grimrock and it struck me that their level design is extremely simple and modular, and yet, the player can spend quite a lot of time in the game. And it looks pretty, too! So I wondered if it wouldn't be possible to create a modern "Dungeon Crawler" (solve puzzles, fight monsters, collect loot, progress your character, upgrade your equipment) type of game inside the TDM engine. The engine already supports a lot of things one needs for this, and the overal structure and assets work, too. And with prefabs, one might get the level layout done quickly. However, building a few test prefabs in DR is easy, but creating a full mission out of them is quite painful. Not only needs it a lot of planning, but you can also spend a lot of time "upgrading" things later on. For instance if you later want to add a grime decal to the walls, you have to revisit the entire map. Even worse is if you find out later that your block size must be bigger or smaller. So the idea was born to create a sort of framework that can assemble missions from prefabs. Preferable while getting the description of the mission from a text file. So far, this has been a lot easier than I thought. Here is what I got working so far: Overview: You can describe your mission in a (Unicode) text file. This contains overall options, different locations (each location can have its own ambient light, music,name, fog), and the connections between the locations. Each location can have multiple "floor levels", these are stacked on top of each other. The config file also specifies which symbol means "use this prefab". It is also possible to specify links (per location), which means you can say "this lever with the symbol A opens the door with the symbol D". The framework reads the prefabs, and then positiones them in the map. It also glues all the locations together, adds location_info entities, a player start, an exit, and an objective to reach the exit. The resulting map is then enhanced with script objects (all nec. assets are bundled together), and automatically dmapped via TDM. Everything then is packaged together into a working .PK4 file. My demo map takes about 20 seconds, where 15 are dmap. In addition to the "basic" stuff I also managed to get a few things working, like a pressure plate, portcullies, and also made some puzzles. Oh, and per location fog (fading from location to location). Different difficulty levels are also supported, one can specify "this prefab appears only on easy" etc. You can find more info and screenshots and demo here: http://bloodgate.com/swift/ There is also a developer diary where I will be posting interesting entries from time to time. Here is an DR shot of a sample level, consisting of small modular prefabs and one large (the large hall on the lower left): The next steps will be to add more randomness (either static at map generation, or at runtime, so the map is slightly different each time you replay it). Also, while it is already possible to "overlay" prefabs (e.g. "for this location, look first here before falling back to the default"), it is not yet possible to "reskin" prefabs. This would be something which is impossible in DR (you cannot really reskin worldspawn brushes, unless you live with the fact that it is all manual For now I'm quite excited!
    1 point
  3. could also be the result of the massively inflated prices on newer gfx cards we have experienced lately, still not possible to get an RX6800 in denmark which is anywhere near the retail price. Not that the idea is bad with VR i just think it needs to be a little more refined before it really catches on, then maybe the prices on them will fall to a reasonable stage.
    1 point
  4. The data doesn't seem to support that.
    1 point
  5. guess someone will newer figure out the boat is about to sink VR has mostly been a massive flop and i can understand why... it is (a LOT) more expensive than a decent lcd monitor and most headsets still feel like you have a box over your head, not to mention the hilarious things that sometimes happen when you do infact forget that you are wearing this riduculous box and try to rest against a virtual fence only to land on your ass xD
    1 point
  6. Valve must have been high up in the ivory tower when they didn't add simple controls to play Half Life Alyx instead of VR gimmicks.
    1 point
  7. half life alyx can be played with standard mouse and keyboard now due to https://github.com/r57zone/Half-Life-Alyx-novr but it looses some immersion due to lacking the vr plays more detailed handling also it is hell to set up still if youre just in it for the story it is quite possible.
    1 point
  8. @datiswous I guess this has to do with rendering order. First of all are solid surfaces are rendered. Everything that is more complex, because it is translucent for example, gets rendered afterwards. I barely remember that the water shader uses the currentRender image as base for its calculation, that is the image containing the solid stuff rendered. The translucent window texture is not part of that image, so it gets ignored and does therefore not been rendered. Question: You wrote that you want the window/glass material to be light up by the light behind it. So you don't really want the actual lamp to be visible, but more the effect of light shining through the glass. Is that correct? In that case, your setup in unneccessary complex. Instead of a translucent window texture you can make an additively blend texture. There are lit window textures where you can check how this is done.
    1 point
  9. Does it work if you have a small layer of air between the glass and the water?
    1 point
  10. Set r_useBindlessTextures 0 in the console and restart TDM
    1 point
  11. Been working on/off for more than a decade on this one. An Msys2 CodeBlocks cross development environment with all the bells and whistles, the windows compilers were previously based on the TDM patched gcc builds but as we hit gcc-10 i ran into a snag as the compiler now defaults to hardening (ASLR / DEP) it turned out the TDM patches no longer worked (crashes and segfaults galore). As a result the compiler is now more like the standard, you can still link to the static runtimes but it requires a bit more work now. putting -static-libgcc in LDFLAGS if building with the Msys2 bash shell will link to the static gcc runtime and normally adding -static-libstdc++ would link to the static libstdc but there is a catch... libstdc is a C++ library so if you use gcc to link in features from it it will allways link to the shared library and your project will depend on both the libgcc and libstdc++ dll's. You can get around this by renaming libstdc++.dll.a to say libstdc++_s.dll.a but its a bit of a letdown. If you feel comfortable using an older gcc like 9.3.0 the TDM patched version of that still works but it has no hardening. CodeBlocks was modified by me to support both the 32 and 64 bit mingw-w64 compilers as well as the msys2 cross compiler and also supports the mingw clang compilers. I defaulted the windows compilers to use sjlj exceptions as sjlj exceptions are the only format compatible with msvc for linking. The environment is huge and contains pretty much all the packages from the Msys2 mingw package database plus a few that i added myself like openjade's sgml based docbook format. There is a ton of game related tools and libraries included like ogre irrlicht godot blender allegro SDL1 SDL2 vulkan openscenegraph etc. so it is quite a collection. The packaged size of it is around 29GB unpackaged it expands to several hundred GB's, that should be telling and i just uploaded it to sourceforge. https://sourceforge.net/projects/cbadvanced/files/CB Msys2 Dev Environment/ lots of other things i built over the years on this site to.
    1 point
  12. Well the old bootstrap compiler finally enabled me to port the TDM patchset for use with gcc-10.2.0 and some major changes have followed. The TDM compiler is now a plugin to the msys2 shell in fact all compilers currently runnable with it are clang to ;). The nice things about this is that you can pretty much build anything the standard version can with the only difference being that the TDM version defaults to linking to the static gcc runtime libraries. The bad thing is that things using clangs libunwind will most likely barf a lot because the gcc unwinder is linked into every library so you will see multiple definition errors in those cases, though not insurmountable -> can just do LDFLAGS+=" -Wl,--allow-multiple-definition" and it will happily compile again it might cause some trouble down the road. The full package is here -> https://sourceforge.net/projects/cbadvanced/files/Msys2 TDM final/ but i suggest waiting a bit until i get my package server online since even solid compressed it is 46GB :S so its a rather hefty download. When the package server is online you can just get the features you want and nothing else which would be more manageable.
    1 point
  13. For some inspiration, visit Bruges and Gent in Belgium. And at night-time: https://www.youtube.com/watch?v=Kl6e32sdNFo Gent: At night-time:
    1 point
  14. How is this building still standing? Amazing!
    1 point
  15. And with a lot of work i actually managed to get gcc-10.2.0 building with the tdm patchset ... sheesh. The compiler uses the last compatible binutils version without hardening so no ASLR or DEP you can still enable crt hardening but that would cause all your executables to depend on libssp ;). I use it in my ass old bootstrap compiler now which originally used gcc-7.3.0 so if youre in for a blast from the past im actually packing it up now hehe. The neat thing with this old version is that it contains some hard to get windows versions of some not so windowy things like webkitgtk2,3 and devhelp which is a local help server intended for gimp and inkscape which is no longer buildable with msys2 since it relies on the old python2 and several other deprecated features that have since been removed. Also it contains my initial work on this dev environment with a lot of tools that where originally broken in msys2 patched and fixed. You can use it to create packages that are linked to the static gcc runtimes and libraries created with it can even be used by visual studio since it uses sjlj exceptions (atleast the C based libraries can). Atm im using it to create packages for use with my current compiler (yes the one above). This version is probably the last publicly avaliable one with dual python version support (python2.7 and 3.7) it also sports ruby ocaml an older clang and mono .NET. The build tools have been updated so you can use meson ninja cmake and bsd make with it and they are all included. Sadly like the previous package it is rather large :S but that is the price for a huge collection of tools and libraries, in case this is to much im also packaging the compiler linker and as many libraries as i can build as seperate packages. These can then be installed with pacman and you can pretty much construct your own version from the packages.
    1 point
  16. P.s unzip it to this path only C:\Msys64 or some tools like python might break because they rely on absolute windows paths. You can also update the Msys2 packages from the main repository the mingw-w64 packages cannot however as they use a different exception model so are incompatible with this version and the default update path for those have been disabled. Over time i intend to have my own repository where users can update from as of now it is safest to just build and install packages locally. There are also quite a lot of build tools like cmake meson ninja and bsd make as well as scons so it might even be possible to toy with darkmods scons build. There is a pretty complete Qt5 build included as well as FLTK Fox gtk2 gtk3 and it is even possible to build ada gui program as the gprbuild frontend is also included.
    1 point
×
×
  • Create New...