Trying to understand darkplaces source code

[vibok]

Replaced all global_hInstance with (HINSTANCE)0x400000, they are all in vid_wgl.c

[vibok]

I'm getting this warning:
warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]

in vid_wgl.c/AdjustWindowBounds()
int workWidth = workArea.right - workArea.left;

Not sure how to get rid of it. Adding -std=c99 didn't help. Don't want to rewrite too, it's just fine as it is.

Here is the full compiler log. Strange that compiler error shows up after linking, but who knows what went wrong, maybe it's just my ide being buggy.

gcc.exe -std=c99 -Wold-style-definition -Wstrict-prototypes -Wsign-compare -Wdeclaration-after-statement -Wmissing-prototypes -fno-strict-aliasing -fno-math-errno -ffinite-math-only -fno-rounding-math -fno-signaling-nans -fno-trapping-math -D_FILE_OFFSET_BITS=64 -D__KERNEL_STRICT_NAMES -DCONFIG_MENU -DCONFIG_CD -DSVNREVISION=- -DBUILDTYPE=release_sure -g -D_WIN32 -DWIN32  -c D:\games-outside\quake-extra\clients\darkplaces\vid_wgl.c -o ..\darkplaces-obj\debug\vid_wgl.o
g++.exe  -o _darkplaces_debug.exe ..\darkplaces-obj\debug\bih.o ..\darkplaces-obj\debug\builddate.o ..\darkplaces-obj\debug\cap_avi.o ..\darkplaces-obj\debug\cap_ogg.o ..\darkplaces-obj\debug\cd_shared.o ..\darkplaces-obj\debug\cd_win.o ..\darkplaces-obj\debug\cl_collision.o ..\darkplaces-obj\debug\cl_demo.o ..\darkplaces-obj\debug\cl_dyntexture.o ..\darkplaces-obj\debug\cl_input.o ..\darkplaces-obj\debug\cl_main.o ..\darkplaces-obj\debug\cl_parse.o ..\darkplaces-obj\debug\cl_particles.o ..\darkplaces-obj\debug\cl_screen.o ..\darkplaces-obj\debug\cl_video.o ..\darkplaces-obj\debug\clvm_cmds.o ..\darkplaces-obj\debug\cmd.o ..\darkplaces-obj\debug\collision.o ..\darkplaces-obj\debug\common.o ..\darkplaces-obj\debug\conproc.o ..\darkplaces-obj\debug\console.o ..\darkplaces-obj\debug\crypto.o ..\darkplaces-obj\debug\csprogs.o ..\darkplaces-obj\debug\curves.o ..\darkplaces-obj\debug\cvar.o ..\darkplaces-obj\debug\dpsoftrast.o ..\darkplaces-obj\debug\dpvsimpledecode.o ..\darkplaces-obj\debug\filematch.o ..\darkplaces-obj\debug\fractalnoise.o ..\darkplaces-obj\debug\fs.o ..\darkplaces-obj\debug\ft2.o ..\darkplaces-obj\debug\gl_backend.o ..\darkplaces-obj\debug\gl_draw.o ..\darkplaces-obj\debug\gl_rmain.o ..\darkplaces-obj\debug\gl_rsurf.o ..\darkplaces-obj\debug\gl_textures.o ..\darkplaces-obj\debug\hmac.o ..\darkplaces-obj\debug\host.o ..\darkplaces-obj\debug\host_cmd.o ..\darkplaces-obj\debug\image.o ..\darkplaces-obj\debug\image_png.o ..\darkplaces-obj\debug\jpeg.o ..\darkplaces-obj\debug\keys.o ..\darkplaces-obj\debug\lhnet.o ..\darkplaces-obj\debug\libcurl.o ..\darkplaces-obj\debug\mathlib.o ..\darkplaces-obj\debug\matrixlib.o ..\darkplaces-obj\debug\mdfour.o ..\darkplaces-obj\debug\menu.o ..\darkplaces-obj\debug\meshqueue.o ..\darkplaces-obj\debug\mod_skeletal_animatevertices_generic.o ..\darkplaces-obj\debug\mod_skeletal_animatevertices_sse.o ..\darkplaces-obj\debug\model_alias.o ..\darkplaces-obj\debug\model_brush.o ..\darkplaces-obj\debug\model_shared.o ..\darkplaces-obj\debug\model_sprite.o ..\darkplaces-obj\debug\mvm_cmds.o ..\darkplaces-obj\debug\netconn.o ..\darkplaces-obj\debug\palette.o ..\darkplaces-obj\debug\polygon.o ..\darkplaces-obj\debug\portals.o ..\darkplaces-obj\debug\protocol.o ..\darkplaces-obj\debug\prvm_cmds.o ..\darkplaces-obj\debug\prvm_edict.o ..\darkplaces-obj\debug\prvm_exec.o ..\darkplaces-obj\debug\r_explosion.o ..\darkplaces-obj\debug\r_lerpanim.o ..\darkplaces-obj\debug\r_lightning.o ..\darkplaces-obj\debug\r_modules.o ..\darkplaces-obj\debug\r_shadow.o ..\darkplaces-obj\debug\r_sky.o ..\darkplaces-obj\debug\r_sprites.o ..\darkplaces-obj\debug\sbar.o ..\darkplaces-obj\debug\snd_main.o ..\darkplaces-obj\debug\snd_mem.o ..\darkplaces-obj\debug\snd_mix.o ..\darkplaces-obj\debug\snd_ogg.o ..\darkplaces-obj\debug\snd_wav.o ..\darkplaces-obj\debug\snd_win.o ..\darkplaces-obj\debug\sv_demo.o ..\darkplaces-obj\debug\sv_main.o ..\darkplaces-obj\debug\sv_move.o ..\darkplaces-obj\debug\sv_phys.o ..\darkplaces-obj\debug\sv_user.o ..\darkplaces-obj\debug\svbsp.o ..\darkplaces-obj\debug\svvm_cmds.o ..\darkplaces-obj\debug\sys_shared.o ..\darkplaces-obj\debug\sys_win.o ..\darkplaces-obj\debug\thread_null.o ..\darkplaces-obj\debug\utf8lib.o ..\darkplaces-obj\debug\vid_shared.o ..\darkplaces-obj\debug\vid_wgl.o ..\darkplaces-obj\debug\view.o ..\darkplaces-obj\debug\wad.o ..\darkplaces-obj\debug\world.o ..\darkplaces-obj\debug\zone.o  ..\darkplaces-obj\debug\resource.res -mwindows -static-libstdc++ -static-libgcc -static  -lws2_32 -lwinmm -luser32 -lgdi32
D:\games-outside\quake-extra\clients\darkplaces\vid_wgl.c: In function 'AdjustWindowBounds':
D:\games-outside\quake-extra\clients\darkplaces\vid_wgl.c:1363:3: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
   int workWidth = workArea.right - workArea.left;
   ^~~
Output file is _darkplaces_debug.exe with size 17.80 MB
Process terminated with status 0 (0 minute(s), 5 second(s))
0 error(s), 1 warning(s) (0 minute(s), 5 second(s))

Maybe full recompile will help, but that's too long.

Inteeresting how there are a lot of qboolean variables in darkplaces code. When quake was made, C99 standard didn't exist yet, and it introduced bool type and allowed creating variables in the middle of the code.

Difference between C99 and C11 isn't that clear to me. Doesn't seem that useful.

[vibok]

what's "darkplaces.opt"?

fs.c/FS_Init_SelfPack()

[vibok]

Curious how different engines handle transition to 64bit processors. The difference is only in types used, or there is difference in logic too?

what I found so far:

quakespasm-source/Quake/q_stdinc.h

/* NOTES on TYPE SIZES:
Quake/Hexen II engine relied on 32 bit int type size
with ILP32 (not LP32) model in mind. We now support
LP64 and LLP64, too. We expect:
sizeof (char) == 1
sizeof (short) == 2
sizeof (int) == 4
sizeof (float) == 4
sizeof (long) == 4 / 8
sizeof (pointer *) == 4 / 8
For this, we need stdint.h (or inttypes.h)
FIXME: On some platforms, only inttypes.h is available.
FIXME: Properly replace certain short and int usage
with int16_t and int32_t.
*/

[vibok]

Looks like you just specify int64_t type, and gcc compiler will use 64bit arithmetics automatically. Didn't knew it was this smart. It's I think 4 times slower though? No idea.

Not sure if there is other 64bit specific code anywhere. I guess I'll just read everything, and eventually I'll stumble on it.

[vibok]

vid_wgl.c/VID_InitModeSOFT()

Awesome, I actually needed some stuff from there.

Strange how it still calls GL_Clear() at the end of vid_shared.c/VID_Soft_SharedSetup(), software rendering still uses opengl somehow?

[vibok]

I wonder why is there quakespasm.pak distributed with quakespasm.

It contains these files:

default.cfg
maps
    e1m1.ent
    e1m2.ent
    e1m4.ent
    e2m2.ent
    e2m3.ent
    e2m7.ent
gfx
    conback.lmp

those maps/*.env contain stuff like this:

{
"worldtype" "2"
"sounds" "6"
"classname" "worldspawn"
"wad" "gfx/base.wad"
"message" "the Slipgate Complex"
}
{
"classname" "info_player_start"
"origin" "480 -352 88"
"angle" "90"
}
{
"classname" "light"
"origin" "480 96 168"
"light" "250"
}
...
...
...

conback.lmp is binary

[vibok]

if you want to try out software rendering in darkplaces

vid_soft 1
vid_restart

gives 5 - 15 fps on my machine, in low resolution

vid_wgl.c
VID_InitModeSOFT

GetDC
CreateDIBSection
CreateCompatibleDC
SelectObject
vid.softdepthpixels = calloc
BitBlt
vid.softpixels


dpsoftrast.c
DPSOFTRAST_Init
DPSOFTRAST_Interpret_SetRenderTargets
DPSOFTRAST_Interpret_Draw

What I can say from looking at DPSOFTRAST_Draw_InterpretCommands in the debugger, it looks like darkplaces first creates a buffer (array?) of commands to execute, and then "playbacks" them during rendering. Like mini opengl, or like virtual machine. Wish there was a way to look at what it's doing step by step, visualise the rendering process.

According to svn blame, work on it started in 2011 by havok. Thought it was older.


this probably should be changed:

LATER
dpsoftrast.c/DPSOFTRAST_Init()

dpsoftrast.fb_colorpixels[0] = colorpixels;
dpsoftrast.fb_colorpixels[1] = NULL;
dpsoftrast.fb_colorpixels[1] = NULL;
dpsoftrast.fb_colorpixels[1] = NULL;

why 0 1 1 1, why not 0 1 2 3?


LATER
dpsoftrast.c/DPSOFTRAST_Init()

if (vid_softdibhandle)
DeleteObject(vid_softdibhandle);
vid_softdibhandle = NULL;

replace with

if (vid_softdibhandle)
{
DeleteObject(vid_softdibhandle);
vid_softdibhandle = NULL;
}

[vibok]

fteqw, engine/Makefile
emacs nags me about every tab that have nothing after it. Weird that it dislikes unnecessary indentation that much.

trying to remake Makefile into windows only.

managed to compile quakespasm, and run it in debugger.

[Mugwump]

Conback is the console background. .ent files are external files that can be used to modify things in maps without de/recompiling. Basically it's a text file of everything in the map. This way you can add/remove/alter any entity in the map, whether it be a light, a static model, a monster, environmental effects like fog etc... I didn't know standard QS supported them, I thought only the spiked version did.

No idea why these .ent files are in the pak. To figure it out they would have to be compared with the untouched versions for differences.

[vibok]

@Mugwump
quakespasm ent files

I found those .ent files paired with .ent.orig files in the quakespasm-source\Misc\qs_pak\maps . Here is a list of actual changes, got it with WinMerge but one can just search for "svdijk" instead. All of them have something to do with z-fighting.

I wonder how other engines got around this problem then, they don't seem to change original levels. Probably use a different rendering approach.

e1m1.ent
{
"classname" "func_door"
"targetname" "t4"
"angle" "-2"
"spawnflags" "1"
"sounds" "2"
"model" "*15"
"lip" "7" // svdijk -- added to prevent z-fighting
}


e1m2.ent
{
"classname" "func_door"
"angle" "91" // svdijk -- changed to prevent z-fighting (was "90")
"targetname" "t110"
"wait" "-1"
"model" "*33"
}
{
"sounds" "3"
"classname" "func_door"
"angle" "269" // svdijk -- changed to prevent z-fighting (was "270")
"wait" "-1"
"model" "*34"
}


e1m4.ent
{
"classname" "func_door_secret"
"angle" "0"
"spawnflags" "1"
"targetname" "t91"
"model" "*53"
"t_length" "73" // svdijk -- added to prevent z-fighting
}

{
"spawnflags" "3"
"angle" "0"
"classname" "func_door_secret"
"targetname" "t91"
"model" "*60"
"t_length" "73" // svdijk -- added to prevent z-fighting
}


e2m2.ent
{
"classname" "func_door"
"angle" "-2"
"spawnflags" "33"
"speed" "10"
"sounds" "3"
"wait" "-1"
"targetname" "t16"
"dmg" "100"
"model" "*13"
"lip" "7" // svdijk -- added to prevent z-fighting
}

{
"target" "t40"
"targetname" "t38"
"classname" "path_corner"
"origin" "-15 280 104" // svdijk -- changed to prevent z-fighting (was "-16 280 104")
}
{
"target" "t38"
"wait" "-1"
"targetname" "t39"
"origin" "-15 280 104" // svdijk -- changed to prevent z-fighting (was "-16 280 104")
"classname" "path_corner"
}



e2m3.ent
{
"classname" "func_door"
"angle" "-2"
"spawnflags" "1"
"targetname" "t11"
"wait" "10"
"model" "*25"
"lip" "7" // svdijk -- added to prevent z-fighting
}
{
"classname" "func_door_secret"
"angle" "90"
"spawnflags" "8"
"targetname" "t11"
"model" "*26"
"t_length" "65" // svdijk -- added to prevent z-fighting
}


{
"classname" "func_door_secret"
"spawnflags" "2051"
"targetname" "t36"
"angle" "90"
"model" "*37"
"t_length" "65" // svdijk -- added to prevent z-fighting
}

{
"classname" "func_door_secret"
"targetname" "t36"
"angle" "270"
"spawnflags" "2049"
"model" "*38"
"t_length" "65" // svdijk -- added to prevent z-fighting
}


{
"classname" "func_door_secret"
"angle" "180"
"spawnflags" "2"
"targetname" "t41"
"model" "*66"
"t_length" "65" // svdijk -- added to prevent z-fighting
}



e2m7.ent
{
"targetname" "t119"
"classname" "func_door"
"wait" "-1"
"angle" "-1"
"speed" "30"
"message" "Go for a swim first..."
"sounds" "3"
"model" "*40"
"origin" "-1 0 0" // svdijk -- added to prevent z-fighting
}


i wonder what those mean: "lip" "t_length" "origin" "angle"

[vibok]

Interesting thread about z-fighting, 2016
http://fvfonline.com/forum/viewtopic.php?t=3795

seems like there are much more things to change than just those listed above, there is an example of e4m5 z-fighting.

darkplaces managed to eliminate all z-fighting, i wonder at what cost.

[Mugwump]

Oh yeah, those pesky z-fighting doors! "lip" "t_length" "origin" "angle" are parameters for these door entities, slightly adjusted to prevent the ugly z-fighting glitches found in vanilla. If DP doesn't fix them via .ent files, then LordHavoc must have hardcoded these fixes into the engine.

[Seven]

Hello,

Engines will not fix anything with hardcoded values. Otherwise all other fan made maps would have the issue�
Advanced engines use integrated algorithm/functions and newer GLSL shaders to fix those.
Just recently LordHavoc fixed a shadow flickering bug this way.

Time has elapsed since 1996, so does Quake engines have developed. One faster than the other.
In 2016/2017 Quake engines have merged into each other rather than developed further.
For example, for some people particle rain is something completely new and they look at it with open jaws.
For others it is a quite old feature which was copied from one engine into the other.

When browsing forums it is interesting how limited some peoples view is. Even though they play Quake for several years but never look over the rim of a tea cup.
If we do not look at all possibilities equaly, we might miss some. And never judge a book by its cover or just because others dont like it.
But I digress...

Have a nice weekend,
Seven

PS: Oh, and if you want to have a software look in your DarkPlaces vibok, you should use this.

[vibok]

I'm checking software rendering not for looks, I just heard that there are still people without hardware accelerated graphics somewhere. It's good to know how it's done, I actually used to have a pc whose video card had broken cooler, and whenever I launched something graphic intensive it would overheat and reset computer. I think I played a lot of emulated nes games and knytt stories levels on that one.