Building gzdoom in linux with cmake
Moderator: Graf Zahl
- GuntherDW
- Posts: 117
- Joined: Sat Nov 12, 2005 1:53
- Location: Belgium, Antwerp
- Contact:
Building gzdoom in linux with cmake
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
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
especially since there weren't any yet
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
- Graf Zahl
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
- Contact:
- GuntherDW
- Posts: 117
- Joined: Sat Nov 12, 2005 1:53
- Location: Belgium, Antwerp
- Contact:
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][/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
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][/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.
- Agent ME
- Posts: 229
- Joined: Mon Jan 02, 2006 12:39
- Contact:
- GuntherDW
- Posts: 117
- Joined: Sat Nov 12, 2005 1:53
- Location: Belgium, Antwerp
- Contact:
is a clean r139 not new enough?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.
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.
- Agent ME
- Posts: 229
- Joined: Mon Jan 02, 2006 12:39
- Contact:
r132 and above have the fixes for 64-bit mostly; at least one problem remains.
- GuntherDW
- Posts: 117
- Joined: Sat Nov 12, 2005 1:53
- Location: Belgium, Antwerp
- Contact:
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
(AMD X2 4800+, 2GB ram DC & GF 8600GT)
could it be because of the massive (?) use of 3d floors?
for ex
/me = happy
edit: altough i get no problem whatsoever in ACSrcade, even after playing for 5-10 mins
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
(AMD X2 4800+, 2GB ram DC & GF 8600GT)
could it be because of the massive (?) use of 3d floors?
for ex
/me = happy
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.
- Agent ME
- Posts: 229
- Joined: Mon Jan 02, 2006 12:39
- Contact:
- GuntherDW
- Posts: 117
- Joined: Sat Nov 12, 2005 1:53
- Location: Belgium, Antwerp
- Contact:
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 ) 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][/spoiler]
i'll also see if i can make it go through gprof to see what's slowing it down
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 ) 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][/spoiler]
i'll also see if i can make it go through gprof to see what's slowing it down
- GuntherDW
- Posts: 117
- Joined: Sat Nov 12, 2005 1:53
- Location: Belgium, Antwerp
- Contact:
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)
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)
- Agent ME
- Posts: 229
- Joined: Mon Jan 02, 2006 12:39
- Contact:
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?
@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?
- GuntherDW
- Posts: 117
- Joined: Sat Nov 12, 2005 1:53
- Location: Belgium, Antwerp
- Contact:
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
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
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.
- GuntherDW
- Posts: 117
- Joined: Sat Nov 12, 2005 1:53
- Location: Belgium, Antwerp
- Contact:
actually graf said to wait, because he was updating the source, so i didn't change anything further than i already hadAgent 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.
- Agent ME
- Posts: 229
- Joined: Mon Jan 02, 2006 12:39
- Contact:
That sounds like you're using a gzdoom.pk3 file that doesn't match its version of gzdoom.GuntherDW wrote:to start wine doesn't like the svn build of zdoom and crashes, gzdoom just crashes with a script error in the pk3Code: 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.
Anyway the cmake fix is now in the svn (r147), so if you upgrade it will work with cmake like with zdoom.
- GuntherDW
- Posts: 117
- Joined: Sat Nov 12, 2005 1:53
- Location: Belgium, Antwerp
- Contact:
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][/spoiler]
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