www.tombraiderforums.com  

Go Back   www.tombraiderforums.com > Tomb Raider Modding > Tomb Raider Level Editor > Software Development

Reply
 
Thread Tools
Old 22-06-16, 08:04   #1971
Ado Croft
Historian
 
Join Date: Apr 2013
Posts: 270
Default

There is another error when I tried to compile the latest update from today

Ado Croft is offline   Reply With Quote
Old 22-06-16, 08:21   #1972
Nickotte
Historian
 
Nickotte's Avatar
 
Join Date: May 2010
Location: Italy
Posts: 256
Default

I fixed that by adding in inclusion to 3rdparty\LuaState\include and 3rdparty\al\include, but now it's complaining about missing <sndfile.h>
Nickotte is offline   Reply With Quote
Old 22-06-16, 09:00   #1973
vvsgh
Student
 
Join Date: Jun 2015
Posts: 134
Default

Quote:
Originally Posted by stohrendorf View Post
so a task could be to investigate it and implement something that maybe doesn't solve the problem, but makes it less problematic. Don't nail me down on this, it's just some example, but you get the idea.
Yes, it's possible. I just pointed out to the lack of resources. There are too many tasks and too little time
vvsgh is offline   Reply With Quote
Old 22-06-16, 10:41   #1974
Nickotte
Historian
 
Nickotte's Avatar
 
Join Date: May 2010
Location: Italy
Posts: 256
Default

Quote:
Originally Posted by vobject View Post
Hi everybody, nice to see all this new excitement

I was able to build&run the master branch on Windows relatively easy with slight modifications to cbp (rename linked libs) and source files (missing includes). I was using freshly installed CodeBlocks 16.01 (+included MinGW) and had to install SDL2, SDL2_image, and Lua before compilation

I'll look into whether the automated build can be resurrected.
I've tried GCC 4.7.1, 4.9.3, reinstalling C::B from scratch (16.01) with included GCC 4.9.2, and then tried the latest TDM-GCC-64 with GCC 5.1.0, but I'm still getting all sorts of errors, each time a different set of them
TDM-GCC and the included GCC 4.9.2 both complain about 'inflate' and 'compress' functions, 4.9.3 can't find <pthread.h> but if I add it in, it causes redefinition of 'timespec', 4.7.1 complains about the '__sync_' atomics

I'm using the latest commit from upstream/master, by the way. If I try the other branch, it gives an entire different set of errors

Also, git keeps barfing about the project .depend file, can I stop tracking it or is it needed in the source control?

Last edited by Nickotte; 22-06-16 at 10:44.
Nickotte is offline   Reply With Quote
Old 22-06-16, 10:46   #1975
Gh0stBlade
Archaeologist
 
Gh0stBlade's Avatar
 
Join Date: Dec 2010
Posts: 2,268
Default

Quote:
Originally Posted by Nickotte View Post
I've tried GCC 4.7.1, 4.9.3, reinstalling C::B from scratch (16.01) with included GCC 4.9.2, and then tried the latest TDM-GCC-64 with GCC 5.1.0, but I'm still getting all sorts of errors, each time a different set of them
TDM-GCC and the included GCC 4.9.2 both complain about 'inflate' and 'compress' functions, 4.9.3 can't find <pthread.h> but if I add it in, it causes redefinition of 'timespec', 4.7.1 complains about the '__sync_' atomics

I'm using the latest commit from upstream/master, by the way. If I try the other branch, it gives an entire different set of errors
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
Gh0stBlade is offline   Reply With Quote
Old 22-06-16, 11:03   #1976
TeslaRus
Student
 
TeslaRus's Avatar
 
Join Date: Jan 2013
Posts: 195
Default

static usage of pthread may prevents the errors without using initialization, but I use static version without errors and without initialization... (-static flag for linker);

The first part of TODO and doc's (have a little time):

* - high priority bug / task;

The main plan:
first we need to implement TR1 gameplay, so TR1 functions tasks are more priority than TR4 / TR5 functions; let us made simple, but stable and working version and next step by step extends functionality;

Build configuration:
1. *add lua and SDLImage to extern folder (TeslaRus task);
2. *add build extern libs script ( -> *.a), update c::b project (TeslaRus task);
3. make good autobuild system;

Git working:
commits to master may be:
1. merging with feature branch (branch that contains new feature, or big bug fixing);
2. little and clean bug fixes;
3. documentation updating;
4. build scripting updates (may be used feature branch, by autor's opinion);
5. independed resources updating;

creating feature branches and commits to them are free;
extern folder not for editing - it is place for external libraries sources / headers;

src/core folder: only by TeslaRus, make request if you want to change something;
other folders: by merge requests to TeslaRus or after code review (by merge request) by command (more details will be discussed); I will make some commits after merge request too (number of errors will be decreased significantly in review case);

Collision system:
current situation:
1. fixed back / front faced polygons orientation for physics geometry, so there is working Filtered Ray Test (skips back faced polygons) in engine;
2. collision margin == 0, because in other case near edges normales become smooth and Lara slides down or stops in places she should not;

todo:
1. *fix shimmy left / right jamming;
2. *fix mowing while landing on sloping surface (1. find body parts that stops Lara; 2. tune collision form, or disable collision checking for them; bind with 3;
3. *make ghost body parts meshes tunable by config (no more hardcoded boxes);
4. for the future optimazation add switchable single ghost object for character;
5. add long ray test (parces rooms portals and builds room list for collisional checking) needs for long range shooting and AI;
6. make refactoring of Physics_GetCurrentCollisions(...) (mem managment);
7. fix mowing in some floor slant cases in Character_FixPosByFloorInfoUnderLegs(...);
8. *fix jammed (or slows and stopped) rolling stones, where it is critical (optional roll by path(not implemented), or roll by physics (implemented));

Character controller:
todo:
1. *wepon control system needed to be refactored / fixed; (2 handed weapon model switches in wrong frame);
2. *add auto weapon hiding in water environment a.t.c. (simple task)
3. fix case of croaching weapons usage;
4. *implements base state control for TR1 enemies (bat, wolf, bear, first, others - later); - it is needed for simple AI testing / developing;

Last edited by TeslaRus; 22-06-16 at 11:07. Reason: syntax mistake
TeslaRus is offline   Reply With Quote
Old 22-06-16, 11:34   #1977
vvsgh
Student
 
Join Date: Jun 2015
Posts: 134
Default

Quote:
Originally Posted by TeslaRus View Post
3. make good autobuild system;
I'm looking at Steffen's work on Hunter package manager. It has big advantages over the old system:
  • It can resolve dependencies on different OSes
  • It can use local in tree or system out of tree libraries
  • It can cache builds
  • It's compatible with different IDEs (think Xcode and C::B)

Quote:
Originally Posted by TeslaRus View Post
other folders: by merge requests to TeslaRus
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?)

Quote:
Originally Posted by TeslaRus View Post
Collision system:
There was a big problem with simulation model in the old engine. T4Larson worked on improving it and he had some progress in his repo. Some discussion is here.
vvsgh is offline   Reply With Quote
Old 22-06-16, 11:58   #1978
TeslaRus
Student
 
TeslaRus's Avatar
 
Join Date: Jan 2013
Posts: 195
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?)
Merge request from feature branch to master: every one can locally make git pull feature_branch, git checkout feature_branch and check how it works, after git checkout branch_working_before; 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;
+ Merge request may be not only to me (but I have to know about it);

Quote:
Originally Posted by vvsgh View Post
There was a big problem with simulation model in the old engine. T4Larson worked on improving it and he had some progress in his repo.
I need to reread this and study repo, but it takes time... The first I need to update ENGINE.md documentation and continue write to do list (+ extern libs...);
TeslaRus is offline   Reply With Quote
Old 22-06-16, 12:06   #1979
vvsgh
Student
 
Join Date: Jun 2015
Posts: 134
Default

And while you are at it there is another fundamental problem here. It deserves to include it in the TODO list.
vvsgh is offline   Reply With Quote
Old 22-06-16, 12:28   #1980
TeslaRus
Student
 
TeslaRus's Avatar
 
Join Date: Jan 2013
Posts: 195
Default

About some bugs: in most number of cases I prefer to write 10 strings fix code to level fix script for 10 levels instead writing 1000 strings sticks to engine (with adding new bugs); But if engine fixes is not sticky and conceptual correct, than better fix engine;
TeslaRus is offline   Reply With Quote
Reply

Bookmarks

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 15:35.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.