Jump to content
The Dark Mod Forums

peter_spy

Member
  • Content Count

    2309
  • Joined

  • Last visited

  • Days Won

    81

Everything posted by peter_spy

  1. To play Devil's Advocate a bit, you can say similar thing in catholic countries in Central and Eastern Europe, especially in rural areas and near borders. Conservatism usually goes hand in hand with any religion it can use.
  2. First of all, don't expect to get Wiki editing privileges the moment you register on the forums. Typically, knowledge base is updated by experienced users.
  3. Nah, it's not the problem of TDM not having alpha planes; it's just that it won't or doesn't need to have too many of them, even with the shadow maps implemented. That's because for surfaces that are close to the player you will use geometry anyway. And you don't need super complex geometry either, as e.g. for iron fences you can fake details and soft edges with normalmaps. As for grass and bushes on alpha planes, this is another dead end due to massive performance problems caused by overdraw. It's actually cheaper to make leaves on simple polygons than to have a whole area made of transparent cards; this is a thing known for many years now in realtime rendering. I'd rather say that soft shadows, when done right with proper optimisation, will be just more beneficial in general for all the stuff that's already being done by stencil shadows, not because the added benefits are so important.
  4. It's not only with search engines, they do it with their default system system apps too. E.g. I'm used to the good old IrfanView for image browsing and some basic quick editing, but every now and then win10 sends me a message that Irfan "crashes too often" and it had to be replaced by the system app for image files. Yeah, right.
  5. Not that I'm defending stencil shadows too much, but IMO alpha shadows are not as groundbreaking as they seem to, at least in TDM context. It's not like you'll be doing modern chain link fences with lights behind them. And for stuff like windows you can use actual geometry, the engine will take it just fine, as long as you don't go overboard with something (lights, materials, etc.).
  6. 8192, to be precise. 1/8th of the former Thief Deadly Shadows limit, although we don't have to worry about managing that stuff too much. Only what's spawned is what counts.
  7. Which foglight do you use? I typically use delta1_fog for both skybox and playable area. Also remember to declare a value in shaderParm3 property (Doom units) to define where the fog ends. Typically I use large values, like 3200.
  8. About that white wall, I think that the material tiles too often. Either break it up with more details on geometry, or decrease texture scaling.
  9. I can only guess that's because we need more efficient method for cascading / splitting shadow maps, not sure how it's done now. To the end user the shadow type doesn't matter, as long as it looks good. It makes a difference for asset makers though, as stencil shadows are cast from the back faces, while shadow maps are cast from the front faces. That influences model building techniques and optimisation tricks.
  10. Maybe it's something with older users' migration to newer version of the forums? At least that's the first thing I'd look for. Edit: btw. I can't change profile picture either.
  11. The wall / window piece is now complete:
  12. I think so, IIRC engine devs would like to switch to shadow maps as primary method of rendering shadows in the future.
  13. Actually, looking by the MSI Afterburner stats, current TDM soft shadow implementation eats up a lot of GPU performance, not only GPU memory. At this point stencil shadows with soft shadows option are more performance efficient than shadow maps with decent quality/resolution.
  14. Stencil shadows is the original shadowing method used in the engine. Shadow maps were implemented by TDM team quite recently. Both types have their advantages and disadvantages.
  15. You can e.g.: https://quixel.com/megascans/library/collections/nature/CastleRuins
  16. I've played this for a few hours. The game looks beautiful, especially for a fairly small dev team. It looks like object and material libraries like Quixel can be of huge help when you don't have a AAA studio. And I'd love to see at least a few of these objects in TDM The story and setting are interesting, although nothing game-breaking so far. As for gameplay, it's... very gamey. While the environments look very organic, the movement, player abilities, and key item placement feel rather rigid. Btw. if you don't plan to use a gamepad, you're in for quite worse experience. M+KB controls are awfully stiff.
  17. Iron trees? Not in my part of... oh. Great stuff buy the way
  18. Actually, you do have to remember about killing "threads" in DoomScript, even though they're not threads in the usual sense (as they're queued in a single line, not assigned to CPU cores or anything). And it's not like process or memory management is a disadvantage of either DoomScript or full C++; this is what languages suited for realtime applications should do. But, for first language it's better to choose something simpler. You'll have to learn tons of new stuff anyway, and thinking about too many things at once is rather overwhelming. And it's not like writing e.g. in Java doesn't require or encourage discipline; at least if you do courses (or even use it at work), you'll get familiar with good coding practices.
  19. Still, it's easier to pick up Python, Java, or other high-level language as a first one, so you don't have to worry about performance optimisation and memory management stuff.
  20. Btw. as in other languages, sys.print should print text and stay on the same line after printing, and sys.println should go to the next line after printing, nothing more
  21. I get the feeling, as it's basically having to learn C++ fundamentals (which is not a good first programming language, according to 100% of the devs I talked to ). Just bear in mind that S/R is more for stuff like your explosive barrel class listening to fire stim and exploding upon receiving. That said, I was thinking the other day about something like GUI scripting system in Thief 3, where you used clauses, conditions, and actions. You could get something similar with Gherkin syntax. Such framework is very non-coding user friendly, and the code itself has to be written in such way that's highly reusable. It's probably too big of a task for a single person though.
  22. Obviously that's up to TDM team to decide, but IMO things like that make the whole ban thing look like a joke. And about the content of the bugs he submited, he just copypasted bits from his message, despite Greebo's request to be more descriptive.
  23. I'm not sure if the above is a good application of a stim-response system. The idea behind this was to create a coherent system of reactions that would work every time on certain classes of objects, so the world feels immersive, consistent, and responsive to player actions. These seem like singular examples that are used once, so it's probably better to use scripts for that. Edit: in Thief implementation, stims and responses are actively "listening" to each other, so this is creating a certain load on your CPU. Not sure how big of an impact this means in TDM and on modern systems, but I guess that too many custom stims and responses can be a performance problem.
  24. IMO just adding an HR (and with better cursor snapping) will let users know that you can easily drag and resize this area.
×
×
  • Create New...