Jump to content


Photo

Getting 2.05-beta To Compile and Run Under Linux

linux 2.05 compile

  • Please log in to reply
33 replies to this topic

#1 NightStalker

NightStalker

    Linux hero

  • Development Role
  • PipPip
  • 146 posts

Posted 19 December 2016 - 10:42 PM

Folks, I've decided to start a new thread on this since the other recent Linux threads are not really the appropriate place (IMHO) to discuss the gory details about fixing the 2.05-beta source code so that it compiles and runs under Linux.
 
Unfortunately, there is already some existing discussion about compiles against 2.05-beta (and "latest SVN") mixed about in these 2 threads:

To start this thread off, I'm replying to this post by duzenko.

As for the memcpy crash.
There is one memcpy in the code I contributed:
void idRenderSystemLocal::CaptureRenderToBuffer(unsigned char* buffer)
Does it crash if you toggle the

if (1)
in there?

 

Good news!

I tweaked the 'if (1)' line (in 'renderer/RenderSystem.cpp') to be 'if (0)' then rebuilt and ran TDM.

Although, IMHO, this is a rather haphazard way to go about things (I'd prefer to run a debugger, with full source code available), it looks like you may have hit the nail on the head, duzenko!

Note: I'm using SVN revision #6642 to run this test since that's the only one I'd gotten to successfully build when I last gave up on this. And I'm running with the 2.04 (not 2.05-beta) PK4 resources, so this test isn't as "pure" as I'd like it to be. But the 2 missions ("Closemouthed Shadows" and "The Outpost") which had been immediately failing (at the 'memcpy()') after the "Press 'attack' to start the mission" point are now running!

Now, be aware that the crashes that Baal experienced appeared to be different than my crashes, so please don't consider this problem solved just yet! But it's an important first step.

I tried to do some further testing, but ran into limitations of my memory of certain SVN commands, so that will have to wait for another day.


  • Bikerdude and Anderson like this

#2 grayman

grayman

    Master Builder, Coder

  • Active Developer
  • PipPipPipPipPip
  • 11620 posts

Posted 19 December 2016 - 11:30 PM

Excellent news!



#3 duzenko

duzenko

    Member

  • Mission Beta Tester
  • PipPip
  • 341 posts

Posted 20 December 2016 - 02:43 AM

Where to from here?

Has the svn access been granted finally?

Should I ifdef this in the mean time?

...

Nightstalker,

you mentioned you have 7600gt as primary and a newer one as secondary.

I'm curious if recent TDM crashes when running on a newer VC monitor?



#4 NightStalker

NightStalker

    Linux hero

  • Development Role
  • PipPip
  • 146 posts

Posted 20 December 2016 - 10:56 AM

Has the svn access been granted finally?

No, but that's entirely irrelevant. I really don't need SVN write access now (but will accept the privilege, as I explained in that other thread). All I really wanted was read-only access (via SVN or any other way) to the actual 2.05-beta source code and given that grayman has already explained how he built the various 2.05-beta releases from SVN, I should be able to replicate that using the public, read-only SVN repository (once I study up on SVN a bit to refresh my aging recall!). To be clear, I have no intention of committing any changes to SVN to fix these 2.04->2.05 transition problems. I'm counting on you, duzenko, to do that, since the changes that aggravated the Linux situation are apparently yours. I'll help anywhere and everywhere I can (testing, etc), but the actual code changes made to SVN for now must be done by you. For the record, I don't understand OpenGL and/or the rendering changes you've made in this area, so I'm incredibly reluctant to mess with any of that, even just to "fix" the build.

Where to from here? [...] Should I ifdef this in the mean time?

That's up to you, IMO. Since I don't understand what's going on with your changes, I have no advice to offer. I hope your question was directed more at grayman and/or nbohr1more than at me.

I will say again that I don't think anyone should consider this issue 100% solved yet. Until Baal "weighs in" on whether his crashes are solved, we cannot celebrate too much.

Also, I want to do a lot more building and testing before even I say, with confidence, that my issues are solved.

Duzenko, I hope you are giving some thought as to why this 'memcpy()' is crashing under Linux (and, conversely, presumably, not under Windows). I took a quick look, but the buffer you're writing to (and presumably overflowing or using a bad pointer to) was passed as a parameter to the routine being called, so I didn't go chasing it any further. I'm counting on you to understand what's happening at a deep enough level that we're not just "wallpapering" a crude fix.

you mentioned you have 7600gt as primary and a newer one as secondary. I'm curious if recent TDM crashes when running on a newer VC monitor?

This may be a bit of the language barrier, but I'm not 100% sure I understand you. What is "VC"? "Video Card"? For now, I'll assume that you're asking if TDM crashes when I use the 2nd video card as the primary. I've never tested that. It's been on my list of "curiosities, to be tested" for about 2 weeks now (EDIT: merely to see if it affects mission load times, not for crash testing), but that's WAY down on my priorities list. And, while the 2nd video card has more video RAM than the 7600GT, it has (IIRC) lower overall performance. And this setup is not for gaming, as some might have assumed, so I'm disinclined to change it. One day this video-card-changeout experiment will happen, but not soon. The only thing I'd be willing to do soon to solve a TDM problem would be to pull the 2nd video card. But I've been running TDM 2.04 (for the last 2+ weeks) with both video cards with no problems at all.


Edited by NightStalker, 20 December 2016 - 11:17 AM.


#5 NightStalker

NightStalker

    Linux hero

  • Development Role
  • PipPip
  • 146 posts

Posted 20 December 2016 - 12:58 PM

Duzenko, it just occurred to me that I have not seen you post in the private "TDM Mission Beta Testing" forum's thread titled "Beta Testing 2.05". If you're not already part of that group, you should be, IMHO.

Since Baal's crash information was posted there, I'm going to replicate his post here, in case anyone who should be seeing it has not:

The segfault occured here:

#0  0x08102ee4 in R_ParseImageProgram_r(idLexer&, unsigned char**, int*, int*, long*, textureDepth_t*) ()
#1  0x08103037 in R_LoadImageProgram(char const*, unsigned char**, int*, int*, long*, textureDepth_t*) ()
#2  0x080fe656 in idImage::ActuallyLoadImage(bool, bool) ()
#3  0x080ef527 in idImageManager::EndLevelLoad() ()
#4  0x081457cd in idRenderSystemLocal::EndLevelLoad() ()
#5  0x080c413e in idSessionLocal::ExecuteMapChange(bool) ()
#6  0x080c4d72 in idSessionLocal::StartNewGame(char const*, bool) ()
#7  0x080c5247 in Session_Map_f(idCmdArgs const&) ()
#8  0x08055903 in idCmdSystemLocal::ExecuteCommandText(char const*) ()
#9  0x080bbb7b in idSessionLocal::HandleMainMenuCommands(char const*) ()
#10 0x080bc05c in T.1593 ()
#11 0x080bc1be in idSessionLocal::GuiFrameEvents() ()
#12 0x080c5ad3 in idSessionLocal::Frame() ()
#13 0x0805c94d in idCommonLocal::Frame() ()
#14 0x082ad83d in main ()
I could investigate further if i had the current source and a debug build.

I see no immediate evidence that his crash was related to the changes you made, duzenko. But if you understand this area of the code at all, could you please trace his crash backwards from the 'R_ParseImageProgram_r()' call (in file 'renderer/Image_program.cpp') to see if you can possibly explain his crash, even a little?

I took a quick look, but this area of the code is "Greek to me". And my testing never resulted in a crash dump that looked anything like his.

Any comments you have are appreciated!

#6 duzenko

duzenko

    Member

  • Mission Beta Tester
  • PipPip
  • 341 posts

Posted 20 December 2016 - 02:23 PM

Can't comment on Baal's error since I don't have access to that forum and Baal is not posting here.

R_ParseImageProgram_r is old code that has not been changed for years. Problem could be in code that executes before that, e.g. idImage::GenerateImage but since neither you nor me can repeat the error then we can't prove it is fixed.

 

VC was short for videocard. I think the 640 you have as secondary output is way newer and more powerful than 7600gt.

My suspicion here is that 7600gt may not fully support the pixel pack feature on the hardware level.

So running TDM on 640 would tell us if TDM maybe is not properly checking if the driver/hardware supports the required feature before using it.

 

I will be traveling for the next 7 days and will be AFK most of the time. I hope it's not going to be a big inconvenience for you. I just want you to know that Linux build is priority #1 right now for me when it comes to TDM.



#7 NightStalker

NightStalker

    Linux hero

  • Development Role
  • PipPip
  • 146 posts

Posted 20 December 2016 - 02:47 PM

Can't comment on Baal's error since I don't have access to that forum and Baal is not posting here.

R_ParseImageProgram_r is old code that has not been changed for years. Problem could be in code that executes before that, e.g. idImage::GenerateImage but since neither you nor me can repeat the error then we can't prove it is fixed.

OK, many thanks for looking into it. I agree that we're sort of at the mercy of awaiting more info from Baal. He hasn't logged in in several days. Let's proceed for now without his input.

I think the 640 you have as secondary output is way newer and more powerful than 7600gt.
My suspicion here is that 7600gt may not fully support the pixel pack feature on the hardware level.
So running TDM on 640 would tell us if TDM maybe is not properly checking if the driver/hardware supports the required feature before using it.

OK, thanks for the clarification. I will investigate this issue while you are away.

I will be traveling for the next 7 days and will be AFK most of the time. I hope it's not going to be a big inconvenience for you. I just want you to know that Linux build is priority #1 right now for me when it comes to TDM.

That's unfortunate, but I'll do my best to proceed while you're away. Hope your travel is for pleasure and that you have a good trip! Come back well-rested -- we'll probably have some questions for you! ;) :D



#8 NightStalker

NightStalker

    Linux hero

  • Development Role
  • PipPip
  • 146 posts

Posted 20 December 2016 - 04:58 PM

My suspicion here is that 7600gt may not fully support the pixel pack feature on the hardware level. So running TDM on 640 would tell us if TDM maybe is not properly checking if the driver/hardware supports the required feature before using it.

I've just run 'glinfo' on the machine in question, with the 7600GT video card still in use as the primary card:
Spoiler
For clarity, I've split the huge line showing all the GL extensions into multiple lines, but you can see that the list includes this:
GL_EXT_packed_pixels
So I suspect that my 7600GT video card and/or the nVidia 304.132 driver is not the issue. But if there's something else I should try, please let me know.

Frankly, I really hope that nobody has been installing little "GL time bombs" in the code over the years, i.e. using a feature without checking for it being supported. I suspect that that could result in a lot of complaints about TDM not running on someone's PC (Windows or Linux) whereas a graceful degradation in the code would have avoided that.

#9 NightStalker

NightStalker

    Linux hero

  • Development Role
  • PipPip
  • 146 posts

Posted 22 December 2016 - 08:18 PM

OK, after a few days of slow, careful, investigation as time was available, I think I've finally got a reasonable handle on the Linux crashes I've been seeing when running TDM 2.05-beta (and, as it turns out, when trying to run the hacked build I'd made from "latest SVN").

TLDR: Duzenko's "lightgem" patch (added via SVN rev #6635, specifically the portion that went into 'renderer/RenderSystem.cpp', BugTracker #4395) needs "hardening".

The consistent crashes I've been seeing right after pressing "attack" on the "Press 'attack' to start the mission" screen is indeed coming from the performance-enhancing "lightgem patch", but it's not where we were assuming. That is, it's in a 'memcpy()' call, but not the one that's directly in the patch. It seems to be in a 'memcpy()' call being executed as a result of a call made by the patch to this OpenGL library routine:

qglReadPixels(rc->x, rc->y, rc->width, rc->height, GL_RGB, GL_UNSIGNED_BYTE, 0);

This is based in part on evidence from examining the source code from the Mesa implementation of OpenGL.

But the reason TDM is crashing in that routine is because of one of several undetected 'GL error' conditions in a few of the earlier GL-related calls added by the patch, with 'qglBindBufferARB()' being the 1st of several that actually fail.

(This all took me a while because I had to learn enough OpenGL to make sense of things. I've never been a "GL guy" and hadn't even looked at any OpenGL code in over 13 years!)

Gory details: The failure of the initial 'qglBindBufferARB()' call, because of the use of the 'GL_PIXEL_PACK_BUFFER' enumeration as the 1st parameter, means that the 'qglReadPixels()' call's last parameter (0 in this patch's case) is NOT representing what the patch author thinks it is! Without the earlier GL calls succeeding, this call basically tries to pass a buffer location 0 (rather than the expected offset of 0) to the 'qglReadPixels()' routine which tries to 'memcpy()' using that bad pointer, resulting in the segmentation faults that I'm seeing.

So, the proper fix for this is to "harden" this patch's code by replacing the useless "if (1)" check with a check for GL 'pixel pack' capability. For optimal speed of execution in the area of the patch, there should be some code added to the part of the TDM code (presumably in 'R_CheckPortableExtensions()', in file 'renderer/RenderSystem_init.cpp') that checks for GL capabilities once, at GL initialization. Then that flag should be used in place of the existing "if (1)" check.

I've been running with this part of the patch disabled and have not encountered a single crash under Linux (using mostly 32-bit Slackware 14.2 but also testing briefly, both compiled and running, under 32-bit Slackware 13.1). I want to do more testing (with more missions than just "Closemouthed Shadows" and "The Outpost"), but so far, all has been fine, so I'm reasonably confident in my recommendations here.

For the record, I've seen no crashes like Baal has seen, so I still think that we must be prepared for that to be a different issue.

In retrospect, this patch should really not have gone into SVN. It was exactly the sort of "GL time bomb" that I mentioned in my previous post, awaiting an innocent victim with the right hardware+driver combination to come along. I wonder if there are other such 'GL time bombs' in the code. I hope not. :(

Some additional thoughts: As mentioned in my previous post, my GeForce 7600GT video card and 32-bit nVidia 304.132 driver advertise (via the 'glinfo' app) what appears to me (maybe naively) to be the necessary capability ('GL_EXT_packed_pixels') to successfully implement a call like this one in the patch:

qglBindBufferARB(GL_PIXEL_PACK_BUFFER, pbo);

And yet it consistently fails on that call with the GL error "GL_INVALID_ENUM", meaning that the use of 'GL_PIXEL_PACK_BUFFER' is not a valid case on this hardware+driver setup! So I don't think that the "GL capability" check that gets added to the GL initialization process should use the presence of 'GL_EXT_packed_pixels' as a "green light" to make such calls. I think it's far safer to do a sample, 1-shot "qglBindBufferARB(GL_PIXEL_PACK_BUFFER, pbo);" call and check the GL error condition, setting the "packed pixel capability flag" accordingly.

As an aside, I also tested with the same exact hardware, but using 2.05-beta under Windows XP. It runs fine there, which tends to make me suspect a video driver issue rather than the video hardware. Regardless, the patch needs hardening.

So, if you folks can wait for duzenko to return and harden this patch, then I'll move on to looking into Baal's crashes (to the extent possible, with relatively little information). If not, I could try to come up with a patch to harden this "lightgem" code myself. Just let me know.

For anyone who's made it this far, sorry for the lengthy explanation. But I like to be thorough and I like to have things well documented.

If I've missed anything, please let me know.


  • duzenko likes this

#10 grayman

grayman

    Master Builder, Coder

  • Active Developer
  • PipPipPipPipPip
  • 11620 posts

Posted 22 December 2016 - 10:07 PM

Brilliant. I suggest waiting for duzenko. Bring him up to speed so he knows the fix, and let him fix it, since it's in his code. Verify the fix, check in the changes to the trunk, post the rev number(s).

You should move on to Baal's problem when you have the time.

Excellent analysis.

#11 NightStalker

NightStalker

    Linux hero

  • Development Role
  • PipPip
  • 146 posts

Posted 22 December 2016 - 11:12 PM

Brilliant. I suggest waiting for duzenko. Bring him up to speed so he knows the fix, and let him fix it, since it's in his code.

Wilco.

Verify the fix, check in the changes to the trunk, post the rev number(s).

As far as I know, I only have read access to the private SVN. Taaaki hasn't told me otherwise. He said he'd grant me write access if you were OK with it.  I told him I'm OK with whatever you folks decided to grant (read-only or read/write). I've verified that I can read, but have never tried to write.

You should move on to Baal's problem when you have the time.

Wilco.

Excellent analysis.

Glad you liked it. :)

 

I cannot promise the same for Baal's issue, though. That one might be tough since I cannot duplicate it. But we'll see. I'll PM him for more info. He's been on the forum, but hasn't said anything recently about his crash(es).



#12 grayman

grayman

    Master Builder, Coder

  • Active Developer
  • PipPipPipPipPip
  • 11620 posts

Posted 22 December 2016 - 11:41 PM

I PMed taaaki to give you write permission
  • Bikerdude, duzenko and NightStalker like this

#13 New Horizon

New Horizon

    Mod hero

  • Active Developer
  • PipPipPipPipPip
  • 13731 posts

Posted 23 December 2016 - 09:35 AM

Not to clutter up the discussion, but a very informative read.  Thanks for the detail.  I'm not a coder, but I do love reading and understanding what is going on behind the scenes.


  • NightStalker likes this

#14 duzenko

duzenko

    Member

  • Mission Beta Tester
  • PipPip
  • 341 posts

Posted 23 December 2016 - 06:04 PM

As an aside, I also tested with the same exact hardware, but using 2.05-beta under Windows XP. It runs fine there, which tends to make me suspect a video driver issue rather than the video hardware. Regardless, the patch needs hardening.

So in the end it's what appears to be a driver bug.
Is your driver the latest for this GPU?
What is the reported opengl version? I think it should be 2.1 for pixel pack.
I absolutely agree that there should have been more checks on glGetError.
I will fix that when I'm back unless someone fixes it before.
...
What happens if you replace GL_PIXEL_PACK_BUFFER with GL_PIXEL_PACK_BUFFER_EXT?

#15 NightStalker

NightStalker

    Linux hero

  • Development Role
  • PipPip
  • 146 posts

Posted 23 December 2016 - 07:44 PM

@grayman: Taaaki has now granted me SVN write access.  I appreciate your input to him on that.

So in the end it's what appears to be a driver bug.

It seems to be. But it also seems unlikely, but certainly not impossible, that such a major bug would go undetected. I suppose it could also be a difference between Linux's use of Mesa to implement OpenGL and whatever Windows uses, but that would start to quickly exceed my expertise.

Is your driver the latest for this GPU?

No. I'm running 304.132 (circa 26 Sep 2016). The latest is 304.134. I'd already downloaded it 2 days ago but haven't installed it because the changelog between 304.132 and 304.134 has only 2 entries, neither of which seemed to be relevant to this issue. At some point, I will upgrade the video driver, but I didn't want to do that in the middle of testing. Something I did do (but failed to mention) -- I removed the 2nd video card (the 640GT), but it offered no improvement. I left it out for now anyway.

What is the reported opengl version? I think it should be 2.1 for pixel pack.

Already reported ("GL_VERSION: 2.1.2 NVIDIA 304.132") in my post #8, above.

 

I should have mentioned it in my earlier post, but I'd already researched the necessary OpenGL version(s) needed for the various calls from your patch.  I thought I had it all in my browser still, but cannot seem to find it now.  But my recollection was that my reported GL version number was adequate in all cases.

I will fix that when I'm back unless someone fixes it before.

Sounds good... IIUC, the 2.05 release has been delayed until January. So our current plan is still the one shown in grayman's post #10, above.

What happens if you replace GL_PIXEL_PACK_BUFFER with GL_PIXEL_PACK_BUFFER_EXT?

Thanks for the suggestion. I will try that at my next opportunity and report back.



#16 duzenko

duzenko

    Member

  • Mission Beta Tester
  • PipPip
  • 341 posts

Posted 24 December 2016 - 05:44 AM

GL_EXT_packed_pixels

I'm no OpenGL guru but I think that's something else.
I think we should be looking for one of these: ARB_pixel_buffer_object and EXT_pixel_buffer_object.
Apparently your Linux driver is not advertising any of these even though the hardware is probably capable so technically it's correct and the fault is in my code.
My excuse is
1 - none of the pixel pack examples on web are doing the ext check
2 - 7600gt is really old
3 - windows driver supports this ext and 7600 gt is known to be 2.1 compatible
4 - most of people with dual card system run their 3d games on the newer card
But it's still my fault of course.
Here's how it looks for me (intel 515)

Attached Files



#17 duzenko

duzenko

    Member

  • Mission Beta Tester
  • PipPip
  • 341 posts

Posted 24 December 2016 - 05:58 AM

No. I'm running 304.132 (circa 26 Sep 2016). The latest is 304.134. I'd already downloaded it 2 days ago but haven't installed it because the changelog between 304.132 and 304.134 has only 2 entries, neither of which seemed to be relevant to this issue. At some point, I will upgrade the video driver, but I didn't want to do that in the middle of testing. Something I did do (but failed to mention) -- I removed the 2nd video card (the 640GT), but it offered no improvement. I left it out for now anyway.
...
Thanks for the suggestion. I will try that at my next opportunity and report back.

Probably not worth trying.
They have stopped supporting 7600gt years ago, so Sep 2016 is as good as any other.
And EXT_pixel_buffer_object is not in the ext list either.
...
I wonder how many people run TDM on gt7000 generation gpu's.
I used to own one and it was great until it burned.
Happy for them if they run TDM under windows so that the pixel pack thingy is functional.
I wish there was a way to enable it under Linux but regret nVidia decided to screw the Linux guys on this one.

#18 damiel

damiel

    Member

  • Member
  • PipPip
  • 11 posts

Posted 24 December 2016 - 06:50 AM

Hey,

 

sry for the stupid question but how does one obtain the 2.05 beta branch if you wanna take a look at it? I am not so versed in using subversion but would like to try looking at the issue, i am using Fedora 25 so this might give you some more information on yet another development stack.

 

Greetings,

 

damiel



#19 NightStalker

NightStalker

    Linux hero

  • Development Role
  • PipPip
  • 146 posts

Posted 24 December 2016 - 02:43 PM

Thanks for the suggestion. I will try that at my next opportunity and report back.

OK, I tried this and it offered no improvement, as you predicted. But it was easy enough to test, so I did it anyway just to be thorough. To be clear, I did the test only in a little hacked OpenGL program that I use to implement the same code that your patch does. It's simply way faster to test this way than building TDM, running it, and waiting for a mission to load every time I want to test tweaks to your patch. But, rest assured... my lengthy write-up above was based on many tests using both the OpenGL test app and using TDM.

1 - none of the pixel pack examples on web are doing the ext check

True, but very few of the OpenGL examples I see on the Internet do any sort of error checking, and certainly not in a portion of the code that's continuously executed. I know you're not suggesting as much, but I don't think we should ever use that approach as our guideline or standards. The TDM precedent that we must follow (IMHO) is to check the capabilities once, at GL initialization time, setting flags for later use in the code that's speed-sensitive but dependent on OpenGL version and/or capabilities.

2 - 7600gt is really old

Also true, but it still runs TDM just fine and I think you'd all agree that we should be as inclusive of older but still-capable video hardware as we can reasonably be.

4 - most of people with dual card system run their 3d games on the newer card

Undoubtedly true, but remember... this is not a gaming system (and I'm not a "gamer"). Take good advantage of guys like me with older hardware (and, in the rare case where I might fire up Windows [XP], older OSes) to root out any bad assumptions that may have slipped into the TDM code and/or the build process.

At the risk of confusing things, this is what my main PC (with built-in 'GeForce 6150SE' video, using the open-source 'Nouveau' video driver) reports:

Spoiler

Notice that the capabilities list includes both 'GL_ARB_pixel_buffer_object' and 'GL_EXT_pixel_buffer_object'. And, indeed, on this PC, the calls that use the 'GL_PIXEL_PACK_BUFFER' enumeration as a parameter do not generate any errors. So I think you're 100% correct about the need for the "GL_{ARB,EXT}_pixel_buffer_object" capability and I now alter what I said in my earlier post to hereby suggest that we check for that extension rather than implementing my cruder, earlier suggestion of using a 1-shot test-call to "qglBindBufferARB(GL_PIXEL_PACK_BUFFER, pbo);".

Please note that the tests on my main PC with the built-in 'GeForce 6150SE' video were also done with a simple OpenGL test app and not the TDM app (because this PC is running 64-bit Slackware 14.2, without multi-lib [32-bit] capabilities, and cannot build or run TDM).

Most importantly, please don't beat yourself up too much over this, duzenko. While I still don't think the patch should have been put into SVN as it was, we can and will work together to fix this. While I spent more time on this than I would have preferred, I learned a lot in the process and I'll venture a guess that you did too. So let's forget about any "blame" or "excuses" and move forward on this, working together. I'm perfectly happy waiting until you're ready to deal with this, after your travels are over. When the time comes, just let me know how I can help. Whenever you're ready, please develop a patch to test for the appropriate GL capability, set a flag accordingly, and replace the "if (1)" check with "if ({flag-name})". Shoot me the patch, I'll test it out thoroughly, and check it into SVN when it's working. Sound good?

Don't give the issue any more thought or worry -- kick back, relax, and enjoy your time away. I'll be ready when you get back.



#20 NightStalker

NightStalker

    Linux hero

  • Development Role
  • PipPip
  • 146 posts

Posted 24 December 2016 - 03:01 PM

sry for the stupid question but how does one obtain the 2.05 beta branch if you wanna take a look at it?

Hi, damiel... Not a stupid question at all.
 
Given your use of the phrase "development stack", I'm assuming that you actually want to compile, not just run, TDM 2.05-beta under Linux.
 
The 2.05-beta source code is tagged as such in a private TDM SVN repository. Access to it, even read-only access, requires approval from the TDM project leaders. (Personally, I would prefer the 2.05-beta source code to be part of the public repository, but I realize that there are probably good reasons that I'm not aware of for it to be private.)

Having said that, you could always try compiling against a checkout of the latest code from the public TDM SVN repository:

https://svn.thedarkmod.com/publicsvn/darkmod_src/trunk

That should be reasonably similar to 2.05-beta. Be aware that you will most likely need some of the patches published in the various recent Linux-related threads. And even then, you might "hit a wall". Oh, and when it comes time to actually run your build, you'll also be lacking the runtime "resources" (textures, etc) that are new or changed since 2.04. But I would still encourage you to give it a try. You will find help here if you need it.

Another alternative would be to assemble an equivalent of the 2.05-beta code using the public SVN repository, although that's probably ill-advised if you're not already comfortable with SVN.

The source code for the original 2.05 package build was taken at SVN rev. 6684.

Subsequent builds included these merges:

11/26 - 6690-6694
12/2 - 6698, 6707-6710
12/11 - 6718, 6720

I'd be delighted to see another user, especially one using Fedora (since I haven't heard of anyone using it to compile TDM), join the testing and discussion! All comments and questions are welcome, as far as I'm concerned.

One thing that your next post, whenever that may be, should mention is the output of 'gcc --version' and some info about your video hardware, preferably with specifics about the video driver (e.g. version) being used.
 
If you're just looking to run the 2.05-beta without compiling it, then that requires access to a private sub-forum, which also requires TDM admin approval.

Hope to hear more from you at some point!



#21 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 18333 posts

Posted 24 December 2016 - 03:24 PM

sry for the stupid question but how does one obtain the 2.05 beta branch if you wanna take a look at it? I am not so versed in using subversion but would like to try looking at the issue, i am using Fedora 25 so this might give you some more information on yet another development stack.

Evening, drop Taaaki a PM asking for read only access to the SVN..



#22 damiel

damiel

    Member

  • Member
  • PipPip
  • 11 posts

Posted 24 December 2016 - 04:46 PM

Evening,

 

just send the pm to taaki to get access. Here some info about my hardware and soem additional stuff:

gcc (GCC) 6.2.1 20160916 (Red Hat 6.2.1-2)
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

As i said earlier before i am running Fedora 25, 64bit. Hardwarewise, i sport a AMD Athlon X4 640, a AMD Radeon 7850 (1GB memory) and 4 GB RAM. I use the free radeonsi driver and mesa 13.0.2 aswell as Xorg 1.19.0.

 

Yes indeed i intend on compiling the source code for 2.05beta, trying out a couple of the fixes that float around and maybe if i get make some sense out of it, try to come up with some fixes aswell. I have some experience tinkering around with the source code of dhewm3 and rbdoom3bfg.

 

Greetings,

 

damiel

 

EDIT: Forgot something: kernel version is 4.8.14 and libdrm is version 2.4.74


Edited by damiel, 24 December 2016 - 05:11 PM.


#23 duzenko

duzenko

    Member

  • Mission Beta Tester
  • PipPip
  • 341 posts

Posted 25 December 2016 - 03:48 AM

Whenever you're ready, please develop a patch to test for the appropriate GL capability, set a flag accordingly, and replace the "if (1)" check with "if ({flag-name})". Shoot me the patch, I'll test it out thoroughly, and check it into SVN when it's working. Sound good?

OK

#24 NightStalker

NightStalker

    Linux hero

  • Development Role
  • PipPip
  • 146 posts

Posted 25 December 2016 - 12:01 PM

Thanks for the additional info on your hardware.

Yes indeed i intend on compiling the source code for 2.05beta, trying out a couple of the fixes that float around and maybe if i get make some sense out of it, try to come up with some fixes aswell. I have some experience tinkering around with the source code of dhewm3 and rbdoom3bfg.

Excellent! Other than the little bit I've learned in the last 3 weeks, I have no experience with any of the Doom engines, whether original or modified.  Looking forward to having you along with us!



#25 duzenko

duzenko

    Member

  • Mission Beta Tester
  • PipPip
  • 341 posts

Posted 27 December 2016 - 09:45 AM

Don't give the issue any more thought or worry -- kick back, relax, and enjoy your time away. I'll be ready when you get back.

 SVN revision: 6735


  • nbohr1more and NightStalker like this





Also tagged with one or more of these keywords: linux, 2.05, compile

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users