Trying to understand darkplaces source code

[vibok]

who cares about quakec, it's 2017

[Baker]

He doesn't want to the QuakeC tutorials. He thinks the engine contains the game logic. He also thinks the key behaviors are hardcoded in the engine, he doesn't seem to understand what a config.cfg is.

Anyway, I pointed this all out super, super early. Usually within 3 replies, I can sort out winners from the hopeless.

Fair or not fair, this guy has lots of bad habits like not listening and bad plans --- plus seems to not value his own time.

But you have to understand people that don't value their own time ---
1) Don't value yours either.
2) Don't expect results
3) Don't adapt -- stick with plans that don't pay off.

Perfect storm of fail. And it's all his choice too. It is nice to see he is using an IDE.

Since this guy doesn't value your time (because he doesn't value his own), he isn't interested in something like doing the QuakeC tutorials --- the one thing that would set him on the right track.

Anyway, nice to see that my predictions are so on the mark. I called this out for a train wreck super early, which was kind because it offered this fellow an opportunity to read a wake up call full of good advice -- which didn't help and I knew it wouldn't --- but I gave him a couple of loud and clear opportunities to right his ship. Additionally, he can't claim no one didn't tell him loud and clear what he was doing wrong, hahaha ;-)

Baker: Told him the right thing to do in an early post (QuakeC tutorials)
Baker: 2 very rude loud and clear "here is why it isn't working" posts (you can't say no one didn't tell him)

Baker +100 points!!! I can identify train wrecks far faster than other people.

Today: How many QuakeC tutorials has this guy done? It's still ZERO.

(He doesn't want to do them. The one thing that would help him the most is the thing he is unwilling to do! Anyway, I've known a lot of bad developers and usually if they knew less they would get more done. A middle school kid would achieve more faster than this fellow because this guy thinks -- and then ignores advice ---- where a 10-year old would just follow the advice. Life is funny like that.)

How much time has the guy wasted with nothing to show for it now? I don't think it has been half a year quite yet.

[vibok]

I don't think I should write more code. There already is too much of code around, I should digest and simplify existing one. Why should I grow this thing if it's already this hard to read?

Not going to learn vulkan, I'm targeting cheap and old computers.

manual fixing of z-fighting was made in quakespasm, not darkplaces.It's probably a better solution actually, fixing the levels and level compilers instead of adding something in the engine. I have no idea though.

[MadGypsy]

I think Chaos's post was referring to the same thing that has been said by Spike, Baker and myself... stop reading and start writing. However, at this point I think people should just accept that what you are doing here is what you are going to do, even if you are the only one that doesn't realize that this is never going anywhere. Memorizing an engine is a terrible waste of time, bro. I doubt any engine has ever been made with this method.

This isn't like history or math. Your needs will be solely determined by your method and there are numerous methods. Do you intend to completely rewrite DP? If so, Why? I'm pretty sure all modern engines were originated from outdated engines by understanding a basic Quake system and implementing modern technology within it.

You should be learning like Joe quake or something bare bones like that and on the side learning gl or vulkan or some other rendering solution and merging your understanding of these things.

In short you are using DP to learn everything and nobody said that DP was any kind of way definitive in the first place. By observation it would seem you have to write ents just to fix zfighting. If that is how it seems then you are memorizing an engine that doesn't even have a decent solution to a very old and we'll understood problem. Manually moving every fight by 1 unit is nonsense. I mean really, fixing z fighting by reprogramming every map externally should be at best a last ditch solution to fall back on and you mostly should never have to fall back on it. Maybe it is. I bet you could tell us.

[vibok]

in other words, "work harder"? Working alone isn't very fun.

this guy always talks like that?

[ChaosEsqueEd]

Let me be honest with you:

You do not try.
You do not understand.
You do not try to understand.

You do.
And you do.
and you DO.
and you do.

Then you understand.

[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.

[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.

[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.

[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.

[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"

[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]

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.

[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]

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