Page 1 of 8

Building gzdoom in linux with cmake

Posted: Wed Jul 30, 2008 23:55
by GuntherDW
since Graf zahl wanted us to create a new thread because of the make->cmake move, i decided to do so
especially since there weren't any yet :P

graf zahl says the cmake part for zdoom (wasn't?) done,
while i could make zdoom & play it with only 2-3 patches
(one huge bug is still in zipdir though)

i'm going to attempt to make a patch so i can build it with the new cmake build system
shouldn't take long though

Or should i wait untill graf zahl decides to implent the final (?) version of the cmake defs?

edit: damn smilies

Posted: Sat Aug 02, 2008 11:29
by Graf Zahl
Please wait. I'm updating right now.

Posted: Sat Aug 02, 2008 21:05
by GuntherDW
i know this is not the "right" thread to tell it in, but i finally got around to compiling a 32b binary (used my "older" pc which is still running behind me in my room ^^)

and it seems to work, so i think it must be a rounding error somewhere or so

(spoiler for image, top left -> 64b build, bottom right -> 32b build)
[spoiler]Image[/spoiler]

also, what i forgot to mention (but i don't think it's going to put you right to the point of "ow right, there's the bug") is that in the 64b build any splat on the wall looks black, even blood
EDIT: don't note this, it was gl_glsl_render

Posted: Sat Aug 02, 2008 21:38
by Agent ME
Wasn't this threat about updating gzdoom to work with cmake? I've nearly finished that in my other thread.

About the problem above - that's been fixed already - you're using an old svn version. Newer 64-bit builds work fine mostly.

Posted: Sat Aug 02, 2008 22:03
by GuntherDW
Agent ME wrote:Wasn't this threat about updating gzdoom to work with cmake? I've nearly finished that in my other thread.

About the problem above - that's been fixed already - you're using an old svn version. Newer 64-bit builds work fine mostly.
is a clean r139 not new enough?
but in the previous thread i went on about the problems i had with my 64b install :)
(but the 32b version is @ r129 atm though)

edit: graf, can you merge the 2 threads together? it would be a bit easier i guess

edit: the 64b build is at r130, my bad, since r131 it seems like it wants to use a mingw file (gdtoa.h)

edit3: don't note my prev note about "mingw", it seems to compile fine on linux ( http://netlib2.cs.utk.edu/fp/gdtoa.tgz )
it needs some simple tweaking to the makefile & adding of files to the src dir though,
i'm about to see if it runs correctly now :p

Posted: Sat Aug 02, 2008 23:05
by Agent ME
r132 and above have the fixes for 64-bit mostly; at least one problem remains.

Posted: Sun Aug 03, 2008 0:42
by GuntherDW
the last version i got to compile & play correctly atm is r137 (as a 64b binary)
also, most of the bugs i mentioned while i was on 32b mode are gone
(the *freeze* for a couple of seconds for which i even created a vid to prove my point)
altough there are still some speeddrops, altough i don't know if it's just unoptimised linux code
zpack, the secret map of E1 (E1M0), when you're outside running & keeping watch of the rockets flying all around, the vid seems get jerky
i don't suppose it would be my system :P
(AMD X2 4800+, 2GB ram DC & GF 8600GT)
could it be because of the massive (?) use of 3d floors?
for ex
/me = happy :D

edit: altough i get no problem whatsoever in ACSrcade, even after playing for 5-10 mins

Posted: Sun Aug 03, 2008 1:00
by Agent ME
Is the 32 bit version jerky in the same way? Also, could you try acsrcade (linked to in my other post) and see if that has slowdowns too for you?

Posted: Sun Aug 03, 2008 1:07
by GuntherDW
the 32b seems to be jerking in the same way yes
i should get a good framerate, but in that map, when looking outside or when the engine has to render the building in the middle (with lots of 3dfloors?) it crawls to 10-20fps

i'm going to see if zdoom itself also has this

edit: (yes i make a lot of edits :P) zdoom also doesn't like this particular area
(but zdoom's software mode is slow in linux, and the difference isn't THAT huge, altough noticable enough)

i've added a screenshot of this particular area which (g)zdoom doesn't seem to like, can anyone with windows see if this also applies for him/her?

[spoiler]Image[/spoiler]

i'll also see if i can make it go through gprof to see what's slowing it down

Posted: Sun Aug 03, 2008 1:43
by GuntherDW
owkey, i've run it through gprof (thanks for showing me there is a program like that Agent ME :))
this is the result : http://guntherdw.be/private/zpack.e1m0.slow.txt.zip

(while playing a little and looking at that particular point in that screenshot a couple of seconds)

Posted: Sun Aug 03, 2008 3:36
by Agent ME
Ontopic considering the title: I've finished adding in proper cmake support for gzdoom. If there's any problem with it, please post in the topic.

@above: I never did manage to get anything useful out of my profiling information when trying to debug the one slowdown - I might try to take a look at yours and try the level myself. Does the slowdown also occur in the windows version of gzdoom (or the windows svn version under wine)? Does it happen in zdoom or software renderer too?

Posted: Sun Aug 03, 2008 10:29
by GuntherDW
i don't have a windows install nearby so i'll have to test it with wine

to start wine doesn't like the svn build of zdoom and crashes, gzdoom just crashes with a script error in the pk3

Code: Select all

G_ParseMapInfo: Load map definitions.
S_InitData: Load sound definitions.
TEAMINFO_Init: Load team definitions.
LoadDecorations: Load external actors.
Script error, "gzdoom.pk3:actors/nativeclasses.txt" line 181:
The function 'A_Feathers' has not been exported from the executable.
the version that i got to work under wine (GZDoom 1.1.0 - 2.2.0 (r748)) also didn't seem to like that area with (almost) the same settings as with the linux build

Posted: Sun Aug 03, 2008 20:07
by GuntherDW
Agent ME wrote:Ontopic considering the title: I've finished adding in proper cmake support for gzdoom. If there's any problem with it, please post in the topic.
actually graf said to wait, because he was updating the source, so i didn't change anything further than i already had :)

Posted: Mon Aug 04, 2008 4:37
by Agent ME
GuntherDW wrote:to start wine doesn't like the svn build of zdoom and crashes, gzdoom just crashes with a script error in the pk3

Code: Select all

G_ParseMapInfo: Load map definitions.
S_InitData: Load sound definitions.
TEAMINFO_Init: Load team definitions.
LoadDecorations: Load external actors.
Script error, "gzdoom.pk3:actors/nativeclasses.txt" line 181:
The function 'A_Feathers' has not been exported from the executable.
That sounds like you're using a gzdoom.pk3 file that doesn't match its version of gzdoom.

Anyway the cmake fix is now in the svn (r147), so if you upgrade it will work with cmake like with zdoom.

Posted: Mon Aug 04, 2008 5:27
by GuntherDW
well the build came from nash's svn dir

what i also find particular is that even though i didn't have any ligth pk3 loaded, is that those levels (also e1m8 in zpack suffers from this) lose a lot of time on the dynamic light routines :s

[spoiler]

Code: Select all

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls   s/call   s/call  name    
 12.38     80.95    80.95  7959442     0.00     0.00  ADynamicLight::CollectWithinRadius(subsector_t*, float)
  8.07    133.70    52.75 449156031     0.00     0.00  AddLightNode(FLightNode**, void*, ADynamicLight*, FLightNode*&)
  6.97    179.30    45.60  7965131     0.00     0.00  ADynamicLight::LinkLight()
  4.52    208.89    29.59 379599510     0.00     0.00  ADynamicLight::DistToSeg(seg_t*)
  2.44    224.87    15.98 73326962     0.00     0.00  FThinkerIterator::Next()
  2.30    239.89    15.02 62119058     0.00     0.00  AActor::UpdateWaterLevel(int, bool)
  2.28    254.83    14.94 16735232     0.00     0.00  DThinker::TickThinkers(FThinkerList*, FThinkerList*)
  2.02    268.07    13.24 62063886     0.00     0.00  AActor::Tick()
  1.65    278.83    10.76 490392089     0.00     0.00  R_PointOnSide(int, int, node_t const*)
  1.38    287.86     9.03 250885749     0.00     0.00  SightCheck::P_SightCheckLine(line_t*)
  1.25    296.06     8.20                             dicmp(void const*, void const*)
  1.11    303.32     7.26 254935496     0.00     0.00  TArray<F3DFloor*, F3DFloor*>::Size() const
  1.07    310.29     6.97 46415020     0.00     0.00  gl_RecalcVertexHeights(vertex_t*)
  1.01    316.90     6.61 1400099132     0.00     0.00  DMulScale32(int, int, int, int)
  0.98    323.31     6.41 59482457     0.00     0.00  GLWall::Draw(int)
  0.95    329.54     6.23    82403     0.00     0.00  clearbufshort(void*, unsigned int, unsigned short)
  0.92    335.56     6.02 28742640     0.00     0.00  GLFlat::DrawSubsector(subsector_t*)
  0.92    341.56     6.00 23207518     0.00     0.00  GLWall::Process(seg_t*, sector_t*, sector_t*, subsector_t*)
  0.89    347.37     5.81 245482840     0.00     0.00  AInventory* GC::ReadBarrier<AInventory>(AInventory*&)
  0.86    353.02     5.66 200353121     0.00     0.00  AActor* GC::ReadBarrier<AActor>(AActor*&)
  0.84    358.50     5.48    63278     0.00     0.00  FInterpolator::UpdateInterpolations()
  0.83    363.90     5.40    83303     0.00     0.00  FInterpolator::DoInterpolations(int)
  0.79    369.09     5.19 527665939     0.00     0.00  P_PointOnDivlineSide(int, int, divline_t const*)
  0.67    373.50     4.41 50967574     0.00     0.00  AddLine(seg_t*, sector_t*, subsector_t*)
  0.67    377.85     4.35    83305     0.00     0.00  FInterpolator::RestoreInterpolations()
  0.66    382.15     4.30 19667357     0.00     0.00  R_PointInSubsector(int, int)
  0.60    386.11     3.96    61803     0.00     0.00  P_RunEffects()
  0.55    389.70     3.59 101736149     0.00     0.00  side_t::GetTextureXOffset(int) const
  0.53    393.16     3.46 43588532     0.00     0.00  DWallScrollInterpolation::Interpolate(int)
  0.53    396.59     3.44 122354376     0.00     0.00  PClass::IsAncestorOf(PClass const*) const
[/spoiler]