DRD Team

There are two families of variables you can change:
1) vid_brightness, vid_contrast, gamma
2) gl_tonemap, gl_exposure_base, gl_exposure_min, gl_exposure_speed, gl_exposure_scale

There are two families of variables you can change:
1) vid_brightness, vid_contrast, gamma
2) gl_tonemap, gl_exposure_base, gl_exposure_min, gl_exposure_speed, gl_exposure_scale

It should be noted that the ambient level was pretty efficient at destroying a map's lighting setup. Essentially it cut off at a light level of 90. Everything below was the same level.

Sorry to be a pain, but I have already noticed some bugs. There are also some fixes I am happy to see.

The good news is the sprites reappeared after I updated my video driver.

More good news is the secret walls in DeiMWolf, which are controlled by fragglescript as a holdover from Legacy, work correctly again. Each of the sectors disappears instantly instead of lowering at turbo speed. Thank you for fixing that.

And now for the bad news ...

A number of my sprites in DeiMWolf are now mysteriously buried in the floor, something that has never happened before.



The keys in T.U.C.Q. no longer work. The text message tells me I am picking them up, but the keys do not appear in my statusbar, and will not open the doors. The keys and locks are defined in DECORATE and LOCKDEF, so GZDooM might no be playing nice with them.

The weapons in T.U.C.Q. can be picked up and used, but I can no longer be switched between. The keys in DeiMWolf do appear to work however, so it may be something I can fix myself.

Since I updated my video drivers, some of my lights have disappeared. Strangely, others are not affected.

I hope most of these problems are simply bugs in my mods, rather than GZDooM, but I thought I would pass word of them on to you.

Hard to say what's at fault without seeing the maps . Can you also check with 2.2.0, to see if the problems appeared before or after?

It appears the sunken sprites are sprites using the same names as DooM.

For example, the plant in the pics above was using COL2A0, which is the short green pillar in DooM.

I suspect GZDooM is somehow using the sprite offsets from the original DooM sprites instead of the replacement sprites' offsets . I noticed in one animated sprite series that started with ELECA0 (the same as the tall tech column in DooM) had fouled up offsets for ELECA0 only, while the other two sprites in the animation were unaffected. Renaming the sprites eliminated the problem.

However ...

Because nearly all older mods reuse the same sprite names, I suspect this will be a major problem when playing older mods. Therefore this should definitely be considered a bug.

BTW: The good news is a friend of mine managed to figure out what was wrong with the weapons and the keys, and got them working again.

A note of long overdue thanks to the creators of the ZDoom and GZDoom sourceports.

I recently had the opportunity to try the DOSBox versions of the original Doom games being offered by GoG.com. The experience made me realize that over the past few years I've forgotten what the original games are like without any enhancements and that I've become a bit complacent playing them with ZDoom and GZDoom, that I've taken the sourceports a bit for granted and never actually thanked their creators.

Thus I'm taking this opportunity to stop by the forums of both sourceports to say thank you to Randy Heit for ZDoom and to Graf Zahl for GZDoom, as well as to the DRD Team and everyone who has made these projects successful. Thank you all for all the work you've put into these sourceports that allow us to continue to enjoy Doom with functionality and visuals that keep the game a pleasure to play even on the newest of computers.

Thank you all!

Hello. I'm interested in getting GZDoom, but i don't know how to find the link. Your assistance would be greatly appreciated. Thank you.

Have you tried https://gzdoom.drdteam.org/page.php?page=download ?

New features:
- mods can define items globally for precaching in addition to per-map definitions

Are there any information how to do this? Didn't found this on the wiki

The syntax is the same as for any other string array from MAPINFO/GameInfo:

Awesome, thanks for the updates! Though, I am extremely late to the party

_mental_ wrote: ↑Wed Mar 01, 2017 9:17 The syntax is the same as for any other string array from MAPINFO/GameInfo:

Code: Select all

precacheclasses = "<actor>", ...
precachetextures = "<texture>", ...
precachesounds = "<sound>", ...

is it possible in future to implement next possibility:

precacheclasses = ALL
precachetextures = ALL
precachesounds = ALL

(or maybe add some options to ingame menu, like "precache all actors = on/off" for example)

because it's pain in ass to copypaste all actors to such lists (especially when you adding new actors/textures/sounds to mod and should remember that you have to add it to precache lists)

Also, I tried precachesounds and GZDoom crashed, because I have a lot of randoms and aliases in my mod, so if you are interested to investigate and fix those crashes, I can report bug and attach a testmod

In addition, I found that precacheclasses doesnt work for 3d models (they still lag after such precache)

Also, as I understand, those precaches doesn't work when you load a savegame?

theleo_ua wrote: ↑Sun Mar 19, 2017 2:12 is it possible in future to implement next possibility:

precacheclasses = ALL
precachetextures = ALL
precachesounds = ALL

(or maybe add some options to ingame menu, like "precache all actors = on/off" for example)

How will the engine figure out what textures/classes/sounds belong to your mod? Or do you want to load just everything?

theleo_ua wrote: ↑Sun Mar 19, 2017 2:12 Also, I tried precachesounds and GZDoom crashed, because I have a lot of randoms and aliases in my mod, so if you are interested to investigate and fix those crashes, I can report bug and attach a testmod

You should always do this. It's better to have duplicate bug report than to do not have one.

theleo_ua wrote: ↑Sun Mar 19, 2017 2:12 In addition, I found that precacheclasses doesnt work for 3d models (they still lag after such precache)

Also, as I understand, those precaches doesn't work when you load a savegame?

Don't know about those honestly, need to check.

Precaches are done on map load. For each savegame load, first the map needs to be loaded, so it should be precached as normal.
Regarding models, that's not going to be a quick fix, because the models exist somewhere outside the system. Refactoring the model subsystem to be better integrated is on the to-do list but not with the highest priority.