duzenko
-
Posts
4149 -
Joined
-
Last visited
-
Days Won
50
Posts posted by duzenko
-
-
What about lightgem? I remember that being major drama trigger. It breaks missions!11
-
2 hours ago, datiswous said:
In the Camera test map camerawiki2.pk4 mentioned on https://wiki.thedarkmod.com/index.php?title=Security_Camera_(2.10%2B) the camera's still don't work, although the issue with the not working (multiple) camera's should be fixed in 2.10 beta, or is the fix not yet implemented in beta 2.10 9702?
Should work in the next beta
In this version I think you can uncomment the materials in tdm_camera.mtr and that should do it
-
1
-
-
12 minutes ago, Dragofer said:
It should give mappers some more freedom with lighting their map without punishing the players for it. It's of course a delicate balance, mappers shouldn't go too far with this so that the mismatch between lighting and lightgem becomes obvious.
We could argue that players seeing the light with their own eyes would assume they will have to stay out of it. I'd say it might be rather frustrating UX to never know if a light is going to tag you or not. I mean, it's the ultimate goal here - to let player through but the player themselves has no way to know if the light in front of them is decorative or not.
-
The logic behind this thing is confusing me
How come visible lights aren't supposed to be affecting LG and AI? Quite counter-intuitive to players as well
-
On 12/16/2021 at 2:58 PM, stgatilov said:
Yes, padding is a problem.
One possible thing is to check every 8 bytes instead of 4 bytes: I guess it is already done like that in 64-bit builds. Of course, it allows the check to miss uninitialized members, but I don't think there is a way around it.
In alternative reality I can parse pdb's and get all type info from there
-
9 minutes ago, stgatilov said:
How did you get away without #define private public ?
As far as I remember, it is required to get member pointers.
I have no idea!11
I can see that text save code calls class methods to get members, could it be it? No idea how it works with sizeof/offsetof though, maybe those are immune to access modifiers?
-
Sorry, reverted that
-
1
-
-
23 minutes ago, datiswous said:
I am curious what the fix was, or is that too specific?
glTexStorage2D/glCopyTexImage2D conflict-
1
-
-
What is more important, how to prevent the uninitialized spam in the console for regular - no type info - builds?
-
It seems that all "uninitialized members" are in fact paddings added for complex members like structs or template parameters
It's easy enough to filter when dealing with simple types, but templates aren't supported by TypeInfo and will have to be assumed always ok.
-
1 hour ago, stgatilov said:
Anyway, the generated typeinfo is wrong.
If you try to compile TDM with it, you'll get a lot of errors.
Most of the are due to not understanding C++11, and it is not wise to eradicate C++11 from headers or trying to #ifdef every little thing.I have put a few more fixes and cut some corners
Revision 9713 seems to work
I am particularly puzzled about the define private public trick, that I had to disable to make the modern compiler happy.
-
8 minutes ago, stgatilov said:
Yes, except for silencing #error directive.
How should it be handled ideally?
-
Hmm, I worked around a few more issues and it now seems to produce something
Not sure if my fixes make enough sense to you?
Svn 9711
-
1
-
-
Yes, it did work in June 2017
There's a number of things that broke since then, the ones I noticed so far
- #error
- include tracy
- sizeof(char) in const declaration
Fixed the first two, but the third is a tough one
-
- Popular Post
- Popular Post
Dear mappers, please be aware of this decorative light option introduced in upcoming 2.10
It aims to highlight the light volume and produces something like the existing fog particle with the intended effect of better speed and arguably better visuals
It looks like this in game
The test map we have been testing recently is courtesy of Bikerdude: download
To enable this effect you will need to mark your light material with the volumetricLight keyword, like this
lights/test_mansion01_window04_vol { description "volumetricLight for mansion01 window04" volumetricLight { map lights/mansion01_window04 colored zeroClamp } }Volumetric lights use projection and falloff textures to generate the volumetric effect. With shadow maps on, they also take shadows in the account.
There's also an optional parameter after volumetricLight that toggles max speed vs decent look mode.
Credits:
- @peter_spy for the original test map and direction
- @Bikerdude for great support during the reintroduction effort this year
- @stgatilov for taking the implementation on a completely different quality level
- @all for being cool and awesome
-
16
-
1
-
Works in D3, but not in any TDM versions I have tried so far
-
You mean you were able to run it locally with a bunch of changes but never commited those changes to svn?
-
After some history digging, it seems that it did not work as early as 2.0 work began, because idHashTable has a GNUC ifdef added around svn rev ~900 that typeinfo can't handle
-
Tried to suppress directive error
Next stop in idStr.h
Fails to evaluate
const int STR_ALLOC_BASE = 32 - 8 - sizeof(char*);because sizeof and char are not valid integers.
Makes you wonder in what year it was last run successfully
-
Another attempt at running typeinfo.exe
Fails with
Type Info Generator v1.0 (c) 2004 id Software ../darkmod_src/game processing 'C:\Users\a\Documents\tdm\darkmod\..\darkmod_src\game\gamesys\TypeInfo_GenHelper.cpp' for type info... ERROR: file ../darkmod_src/idlib\sys/sys_defines.h, line 148: #error without stringat this line
It does not matter if I define WIN32 in generator's own define list. It seems that it always executes compiler directives, even if they are disabled by an outer ifdef. Is typeinfo so hopelessly broken it cannot be used without major overhaul?
-
2 minutes ago, stgatilov said:
Yes, if you have static reflection.
Did reflection got into C++20 already?
What about our "basic" RTTI? Isn't that separate to typeinfo.lib? I am completely clueless, but the wiki says typeinfo.lib is only needed for memory logs, which kinda implies RTTI is something different?
-
1 minute ago, stgatilov said:
A somewhat cumbersome approach but easier to boot would be to put breakpoint to where this message is printed, then find manually in the debugger which member this offset corresponds to. I.e. binary search by class members in their order... maybe using offsetof macro (if debugger supports it).
Umm... can it be automated by something like
for(auto& property: typeinfo::getPropertiesFor(this)) { if (offsetof(property) == missingPropOffset) { ... } }QuoteOh yeah, that's not good...
Yes, you can use typeinfo lib to see member names, but it will by no means by easy. You will have to surround bad includes with #ifdef smth, replace all #pragma once with old-style include guard, do something with override (e.g. add #define override {empty} as predefined macro under typeinfo), add private: if some members are implicitly private... that's what I remember.
Sounds like a PhD course work
-
26 minutes ago, stgatilov said:
However, the first question is: what are you trying to achieve?
Sorry, I should have started with that
I'm puzzled by these warnings in the xray test map. I'd like to see if the typeinfo lib could be used to debug this
-
1
-
-
@stgatilovCan we fix typeinfo? How do we point it to the right path for this .hpp?
Beta testing 2.10
in The Dark Mod
Posted
Those are for custom GUI's in new missions