Building gzdoom in linux with cmake

Advanced OpenGL source port fork from ZDoom, picking up where ZDoomGL left off.
[Home] [Download] [Git builds (Win)] [Git builds (Mac)] [Wiki] [Repo] [Bugs&Suggestions]

Moderator: Graf Zahl

User avatar
GuntherDW
Posts: 117
Joined: Sat Nov 12, 2005 1:53
Location: Belgium, Antwerp
Contact:

Building gzdoom in linux with cmake

Post 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
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Post by Graf Zahl »

Please wait. I'm updating right now.
User avatar
GuntherDW
Posts: 117
Joined: Sat Nov 12, 2005 1:53
Location: Belgium, Antwerp
Contact:

Post 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
Last edited by GuntherDW on Sat Aug 02, 2008 22:07, edited 1 time in total.
User avatar
Agent ME
Posts: 229
Joined: Mon Jan 02, 2006 12:39
Contact:

Post 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.
User avatar
GuntherDW
Posts: 117
Joined: Sat Nov 12, 2005 1:53
Location: Belgium, Antwerp
Contact:

Post 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
Last edited by GuntherDW on Sat Aug 02, 2008 23:18, edited 1 time in total.
User avatar
Agent ME
Posts: 229
Joined: Mon Jan 02, 2006 12:39
Contact:

Post by Agent ME »

r132 and above have the fixes for 64-bit mostly; at least one problem remains.
User avatar
GuntherDW
Posts: 117
Joined: Sat Nov 12, 2005 1:53
Location: Belgium, Antwerp
Contact:

Post 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
Last edited by GuntherDW on Sun Aug 03, 2008 1:02, edited 1 time in total.
User avatar
Agent ME
Posts: 229
Joined: Mon Jan 02, 2006 12:39
Contact:

Post 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?
User avatar
GuntherDW
Posts: 117
Joined: Sat Nov 12, 2005 1:53
Location: Belgium, Antwerp
Contact:

Post 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
User avatar
GuntherDW
Posts: 117
Joined: Sat Nov 12, 2005 1:53
Location: Belgium, Antwerp
Contact:

Post 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)
User avatar
Agent ME
Posts: 229
Joined: Mon Jan 02, 2006 12:39
Contact:

Post 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?
User avatar
GuntherDW
Posts: 117
Joined: Sat Nov 12, 2005 1:53
Location: Belgium, Antwerp
Contact:

Post 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
User avatar
GuntherDW
Posts: 117
Joined: Sat Nov 12, 2005 1:53
Location: Belgium, Antwerp
Contact:

Post 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 :)
User avatar
Agent ME
Posts: 229
Joined: Mon Jan 02, 2006 12:39
Contact:

Post 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.
User avatar
GuntherDW
Posts: 117
Joined: Sat Nov 12, 2005 1:53
Location: Belgium, Antwerp
Contact:

Post 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]
Locked

Return to “GZDoom”