Tomb Raider Forums  

Go Back   Tomb Raider Forums > Tomb Raider Level Editor and Modding > Tomb Raider Level Editor > Software Development

Reply
 
Thread Tools
Old 22-06-16, 12:36   #1981
Koldman
Member
 
Joined: May 2016
Posts: 5
Default

Nice to see some news
Koldman is offline   Reply With Quote
Old 22-06-16, 14:05   #1982
Nickotte
Member
 
Nickotte's Avatar
 
Joined: May 2010
Posts: 256
Default

Quote:
Originally Posted by Gh0stBlade View Post
You have to link zlib if you're getting inflate/deflate related undefined references. https://sourceforge.net/projects/min...ib/zlib-1.2.8/

I'm linking libpthread_s.dll.a C:\TDM-GCC-32\lib
Apparently the libz.a file I had was different and I didn't have the libz.dll.a, now it compiled perfectly, yay! Well I mean, with 802 warnings, but who cares
Nickotte is offline   Reply With Quote
Old 22-06-16, 14:52   #1983
Cochrane
Golden
 
Cochrane's Avatar
 
Joined: Apr 2006
Posts: 16,751
Default

Quote:
Originally Posted by vvsgh View Post
I think there should be a policy that every new feature should go in its own folder with its own project file. Thus it won't cause new conflicts and would allow for earlier integration. That's how Facebook recommends to lay out feature development for painless integration. Otherwise it will cause big breakage after merging all at once (remember C++ re-factoring?)
What's a feature in that context? If it's a new file that has a clearly defined interface and consumes clearly defined interfaces, that approach can work, but in practice most things that are "features" affect code all over the place and require changes to existing functions. The approach you describe works well, but almost only, for very independent modules.
Cochrane is offline   Reply With Quote
Old 22-06-16, 15:17   #1984
vvsgh
Member
 
Joined: Jun 2015
Posts: 138
Default

Quote:
Originally Posted by Cochrane View Post
Getting this thing cleaned up was and remains a very important effort. It's not that important whether it's C++ or C99 or whatever (but not Java. And I'm saying this as a professional Java developer), as long as it clearly separates concerns, splits things into their own files with clear interfaces, and gets rid of all the duplication in so many parts of the code.

In retrospect, that's probably where we should have started,
Quote:
Originally Posted by Cochrane View Post
What's a feature in that context? If it's a new file that has a clearly defined interface and consumes clearly defined interfaces, that approach can work, but in practice most things that are "features" affect code all over the place and require changes to existing functions. The approach you describe works well, but almost only, for very independent modules.
Isn't that what we actually want? I'd say we should do even more. Not only we should separate modules, but we should define an API as well. But it's not a priority right now.
Quote:
Originally Posted by TeslaRus View Post
Who works with new feature have to regular make git pull master, git merge master (from master to feature_branch); After branch is tested and reviewed it merged with head;
That depends on cooperation from different developers. Nobody has access to all platforms for testing. Sometimes it's desirable to be able to work on new features early, even if those features are not ready for GA. But working with separate repositories makes it unnecessary hard for many developers.

Last edited by vvsgh; 22-06-16 at 15:54.
vvsgh is offline   Reply With Quote
Old 22-06-16, 16:18   #1985
Cochrane
Golden
 
Cochrane's Avatar
 
Joined: Apr 2006
Posts: 16,751
Default

Quote:
Originally Posted by vvsgh View Post
Isn't that what we actually want? I'd say we should do even more. Not only we should separate modules, but we should define an API as well. But it's not a priority right now.
To some degree certainly. But if a developer decides to implement, say, better logging of engine events, then that's something that will affect code all over the place.

For things that are clearly separated new features, I fully agree with what you propose. I just think there are a lot of cases that aren't that.

Quote:
Originally Posted by vvsgh View Post
That depends on cooperation from different developers. Nobody has access to all platforms for testing. Sometimes it's desirable to be able to work on new features early, even if those features are not ready for GA. But working with separate repositories makes it unnecessary hard for many developers.
I don't think so. What TeslaRus proposes is basically the default model for which both Git in general and Github in particular were built and optimized, and I think it's an approach that works really well.

The idea is not that everyone has to test on all platforms before making a merge request. But going with merge requests means people have a chance to look at the code, see what it's doing and how it's written, and propose changes where necessary before adding it to the master tree.
Cochrane is offline   Reply With Quote
Old 22-06-16, 16:46   #1986
Gh0stBlade
Member
 
Gh0stBlade's Avatar
 
Joined: Dec 2010
Posts: 2,773
Default

I created a slack team for OpenTomb a while ago. I'd appreciate it if everyone who has contributed to the project joins if possible. This will make communication a lot easier. Just PM me your email address and I'll send an invite to it.
Gh0stBlade is offline   Reply With Quote
Old 22-06-16, 16:51   #1987
Nickotte
Member
 
Nickotte's Avatar
 
Joined: May 2010
Posts: 256
Default

Quote:
Originally Posted by Gh0stBlade View Post
I created a slack team for OpenTomb a while ago. I'd appreciate it if everyone who has contributed to the project joins if possible. This will make communication a lot easier. Just PM me your email address and I'll send an invite to it.
Ohh, I think I remember that. It's like that Discord/IRC for devs, right?
I'd love to participate! PM sent
Nickotte is offline   Reply With Quote
Old 22-06-16, 16:52   #1988
stohrendorf
Member
 
stohrendorf's Avatar
 
Joined: Jul 2015
Posts: 145
Default

I highly suggest joining it. We're using it at work, and it is pretty awesome for communication. (There even exists a GitHub integration which I'd like to see activated.)
stohrendorf is offline   Reply With Quote
Old 22-06-16, 16:57   #1989
Gh0stBlade
Member
 
Gh0stBlade's Avatar
 
Joined: Dec 2010
Posts: 2,773
Default

Quote:
Originally Posted by stohrendorf View Post
I highly suggest joining it. We're using it at work, and it is pretty awesome for communication. (There even exists a GitHub integration which I'd like to see activated.)
Yeah, I use it for work too

I did not know there was a github integration! That is awesome
Gh0stBlade is offline   Reply With Quote
Old 22-06-16, 17:03   #1990
vvsgh
Member
 
Joined: Jun 2015
Posts: 138
Default

Quote:
Originally Posted by Cochrane View Post
The idea is not that everyone has to test on all platforms before making a merge request. But going with merge requests means people have a chance to look at the code, see what it's doing and how it's written, and propose changes where necessary before adding it to the master tree.
That's certainly true. But it doesn't work that well in practice. Remember how it was with Steffen's PR? And it wasn't exception. That's why GitHub implemented CI and protected branches. But it won't protect us from breakage that can't be discovered by an automatic test suite. So, in the end it still depends on a manual testing that require building many different branches in developer's workspaces. And this is more difficult if you have to test it separately from the main branch. That's why PRs are not getting enough attention which results in a poor quality.
vvsgh is offline   Reply With Quote
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off



All times are GMT. The time now is 06:13.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.
Tomb Raider Forums is not owned or operated by CDE Entertainment Ltd.
Lara Croft and Tomb Raider are trademarks of CDE Entertainment Ltd.