Commit graph

13 commits

Author SHA1 Message Date
Christoph Oelckers
0c4fc385cc - User definable dynamic lights
This hasn't been tested yet!

# Conflicts:
#	src/g_shared/a_dynlight.h

# Conflicts:
#	src/g_shared/a_dynlightdata.cpp
2019-07-17 17:51:28 +02:00
Christoph Oelckers
4daa256e2f - fixed: RecreateAllAttachedLights must activate the lights it creates.
This also removes the gl_attachedlights CVAR because with the new management this doesn't really work anymore.

# Conflicts:
#	src/gl/system/gl_cvars.h
#	wadsrc/static/menudef.txt
2019-04-27 13:20:44 +02:00
Christoph Oelckers
8fecfb8f85 - properly handle passing of the light flags.
Since these can be changed on the placed light actor they have to be read from there, so this is now a pointer in FDynamicLight, just like the other properties that can be user-changed.
Also did some cleanup on the interface so that external code doesn't need to dereference the lightflags pointer but can use utility functions for all flags.

# Conflicts:
#	src/hwrenderer/dynlights/hw_dynlightdata.cpp
#	src/swrenderer/line/r_walldraw.cpp

# Conflicts:
#	src/g_level.cpp
#	src/gl/compatibility/gl_20.cpp
2019-04-26 00:42:05 +02:00
Christoph Oelckers
f261ec7d53 - rewrote dynamic lights to not use actors for the internal representation and made DynamicLight a purely scripted class.
This should be less of a drag on the playsim than having each light a separate actor. A quick check with ZDCMP2 showed that the light processing time was reduced to 1/3rd from 0.5 ms to 0.17 ms per tic.
It's also one native actor class less.

# Conflicts:
#	src/g_shared/a_dynlight.cpp
#	src/g_shared/a_dynlight.h
#	src/hwrenderer/dynlights/hw_dynlightdata.cpp
#	src/hwrenderer/dynlights/hw_dynlightdata.h
#	src/hwrenderer/scene/hw_renderhacks.cpp
#	src/namedef.h
#	src/scripting/thingdef_data.cpp
#	src/swrenderer/line/r_walldraw.cpp

# Conflicts:
#	src/d_main.cpp
#	src/g_levellocals.h
#	src/g_shared/a_dynlight.cpp
#	src/g_shared/a_dynlight.h
#	src/gl/dynlights/gl_dynlight.h
#	src/gl/dynlights/gl_dynlight1.cpp
#	src/gl/scene/gl_spritelight.cpp
#	src/gl/scene/gl_walls.cpp
#	src/hwrenderer/dynlights/hw_shadowmap.cpp
#	src/hwrenderer/dynlights/hw_shadowmap.h
#	src/hwrenderer/scene/hw_flats.cpp
#	src/p_setup.cpp
2019-04-26 00:19:03 +02:00
Christoph Oelckers
bc8af1cab8 Fixed initialization issues with dynamic lights.
Actors get initialized from their defaults so anything done in the constructor or some explicit member initialization will be overwritten.
They must use their properties for setting up configurable fields and do the rest in BeginPlay.
2019-04-25 20:59:06 +02:00
Christoph Oelckers
b3a8dcdbd4 store shadow map index in the light actor instead of a separate TMap
This frees another file of a direct renderer dependency and generally also should be faster
2019-04-25 20:14:00 +02:00
Christoph Oelckers
c0e9530fd0 - fixed: The light defaults were not fully deleted on an engine restart. 2019-04-18 13:12:55 +02:00
Christoph Oelckers
b03c329ec6 - moved all GLDEFS parsing into a dedicated source file.
- split gl_postprocessshader.h in two so that the hardware independent part can be used by GLDEFS without pulling in all of OpenGL.

# Conflicts:
#	src/CMakeLists.txt
#	src/gl/dynlights/gl_glow.cpp
#	src/gl/renderer/gl_postprocess.cpp
#	src/gl/textures/gl_texture.cpp
2018-08-19 20:56:49 +02:00
Magnus Norddahl
5f36b86013 - Add dynamic spot lights 2018-01-04 17:58:11 +01:00
Christoph Oelckers
3b024c347b - use a dedicated flag word for the dynamic light flags instead of piggybacking on some flags4 bits. 2017-06-18 10:15:31 +02:00
nashmuhandes
99d1581c27 Added "DontLightActors" flag for dynamic lights. Actors will not be illuminated by lights that are given this flag. 2017-03-28 21:33:16 +02:00
Christoph Oelckers
1031481167 - added some checks to exclude dynamic lights from being subjected to shadowmapping if they do not touch any one-sided lines from the back side. This condition is a requirement for a 1D shadowmap to even have an effect. 2017-03-20 00:34:19 +01:00
Christoph Oelckers
ef3421eee5 - moved dynamic lights out of the GL code into the common game code.
Since the true color software renderer also handles them there is no point keeping them on the GL side.
This also optimized how they are stored, because we no longer need to be aware of a base engine which doesn't have them.
2017-03-12 19:57:06 +01:00