#1 2017-08-28 17:08:23

mbitsnbites
Member

git, code cleanup etc

It's been a few years since I last played with Tesseract, but yesterday I gave it a try again: checked out the svn repo, installed libsdl2 and ran make. So far so good, but then I started looking at the code, and one thing led to another...

Now I have made a git repo (actually two: code and data), converted the project to CMake and started cleaning up some code style thingys (include paths, clang-format, ...).

Time permitting I might have a go at switching from SDL to GLFW, make some UI improvements (more integrated help for instance), but I have not researched the code enough yet.

Currently I have no specific goals other than to toy around with the code, but as it is now it's a fork and if I continue it will be impossible to upstream any changes.

So my question is: Have there been any similar plans for refactoring the build system, version control (move to git) and/or do any code cleanup, so that it made more sense to coorinate these thimgs with mainline Tesseract?

Offline

#2 2017-08-29 01:39:48

chasester1
Member

Re: git, code cleanup etc

I know there is maybe 3 mods at the moment.

Tempris (the guy behind ironfist) is making a mod to suport some game ideas hes using for his brand cure interactive

Me + hypernova (and some help from tempris) are helping on a project called rival.

Ragaza (i miss spelled this idb) is working on some config level (cubescipt) mods to help improve the editor and other functions of the engine.

And as far as I know that the only people using the tesseract base directly.

I know Re (red esclipse) made some changes to include some real time lighting like in tesseract and improved shaders, but I hear their code base is very different.

Inxoer ran by teamate (and some others idr) is making a mod based off of cube 2 but idb they have fast light maps (though not sure if thats real-time lighting or just an improvement to the light calc formula).

R+R (revolade revolution) ran by ed and coded by void, pops up every once in a while with updates, but I do believe they are still working off of the cube 2 code base.

I think those are all the active mods at this moment either directly or indirectly using the tesseract engine. All of them are open source and on git, if you want to look at them.

As for mine, im not good at remembering to update git with the code base, so ive got a lot of extra stuff im working on even though it looks inactive. But currently we have a scenegraph, bullet physics, angelscript (a c++ pased coding language), serialization (of the script code), new binding system (that alows various bind stats (or actions, if youve looked at the base code). We are looking to make it more of an engine, where angel script (as) runs most of the main code and the c++ code is only used as an assistant so you can create almost any style game with out ever having to touch the c++ code.

As for your mod, it sound more or less in hypernovas expertise, in that it involves cmake build scripts and the like. But I have been doing major refactors to the code, and probably have elminated and rewrote (using c++ class based oo style methods) a good 7k-10k worth of lines, and ever time I add a new feature its mostly a complete rewrite of most of the curent code base. This is in an effort to make the code less open (everything public) and add more controls on the base classes so entry and exit points can be more controled. Also comments cuz :p cube hase like 10 line of comments :p
</endplug type=shameless>

chasester

Last edited by chasester1 (2017-08-29 01:41:34)

Offline

#3 2017-08-29 06:10:10

mbitsnbites
Member

Re: git, code cleanup etc

Thanks for all the info. It sounds to me like Rival is the right way forward - will check it out!

In the meantime I will continue toying w my fork.

Offline

#4 2017-09-02 18:14:50

SniperGoth
Member

Re: git, code cleanup etc

Red eclipse doesn't support real time lighting, you may be thinking of "RE: Horizon", a project that qreeves started, but got cancelled in the end.

Revelade Revolution is being ported onto tesseract as we speak, the cube 2 version stopped development by early 2015, and was revived some months ago. We have the guns and some player models implemented already, but it's still a far road to completion.

Offline

#5 2017-09-04 07:03:00

chasester1
Member

Re: git, code cleanup etc

LOL ya I just hear things I hardly check out these things, so i probably just miss heard. And yes I heard that R+R was booting back up :)

Offline

#6 2017-09-18 12:34:11

a_teammate
Member

Re: git, code cleanup etc

Inexor is not just me, its a community effort :)

there exists plans to port it to tesseract (https://github.com/inexorgame/inexor-core/issues/477), but its not top priority atm (0.9 aims on going rolling release and 0.10 on the HTML UI fixes and probably more advanced node.js bindings)

but yeah, if you want a solid cmake system you could steal ours :)
no mac support yet, though  (as none made the necessary adjustments to the conan.io packages of our dependencies).

Offline

#7 2017-09-19 12:49:32

chasester1
Member

Re: git, code cleanup etc

I have others looking at cmake (or the like, honestly im not sure about these such things), they seem to have some idea on what they want to do, but it seems mac support is where others are struggling as well. I do believe theyve looked at your code as well, though im not 100% where they are in the process. Though im suprised of your heavy relience on html5 and js (im assuming json), which seems far more complex and slower then something more propitary. Though i have a heavy bias against js and html5 css and the like due to the bloated mess that it seems to be at times. But I guess correct implimentation of the above could make it quiet easy to learn for people with a web background. But i find that many times (espeially in web dev) there are 6 or 7 ways to achieve the same goal where 1 or 2 are good and the others are just very bad and poor design. And it seems that people always pick the worst of the options.

Any way I may look at your html (i assume chromium) port for your menus because this could prove useful in some ways as I do plan at some point to fix the ui and use a more robust system which may support html5 loaded through a new robust gui system (using the angelscript cube script comb). I check out your stuff at times but dont ever see many videos posted which is normally the easiest way to tell what you are up too. Tho your svn mapping does look promising though ive not seen much other than the one video, and using v_command to attach it seems a bit off (not sure if youve changed this). Also loading two maps over eachother could be nice to steal content from another map or see version changes etc, which seems like it would be posible with the subversion you guys wrote.

any way im done ranting

chasester

Offline

#8 2017-09-19 22:20:37

a_teammate
Member

Re: git, code cleanup etc

chasester1, thats not ranting, you have valid points. I really appreciate that. Honesty is the very first rule of development. Bugs and results do not care about lies, they only reflect the quality of your decisions.

And our decisions weren't that easy, I admit. Especially the javascript decision was a particulary hard one, and there we're good arguments on each side (before that decision we already had working python and lua implementations). JS hasn't ever been an optimal choice (for anybody ever). but our arguments were: not another language (we already have settled on HTML UIs), easy for beginners (js and HTML have tons of tuts) and especially it should allow a system making as much as possible easily scriptable (as much as possible == everywhere where performance should not be the highest goal but flexibility).

Ofc we we're lucky that ECMA 6 arrived and did make that language much less ugly. And of course by that time we did not even choose node.js as the way to go for that system. we thought: 'yeah maybe v8 or so integrated in this or that direction', we tried "atom shell" (today its called "electron").
But srsly.. node.js gives you a shitload of stuff. It is in no way comparable to a simple integrated scripting API.
Today we think of InexorFlex (the node part) as our controller of everything. InexorCore (the C++ part) is just the high performance component of it.
I can understand your skepticism, because the idea of node.js to do everything in "modules" (often very tiny) gives away not only control, but it also often leads to very deep dependency graphs.

It is said that the structure of code mirrors the structure of communication in the dev team. And I think that becomes particularly apparent for dependencies and modules: you use that module, but you give up control of it. You trust on someone else doing shit right and its okay if he trusts 10 other modules.

We do have a community fork with an old non-modular structure.. we needed that refactored and we needed it to be doable by multiple persons and in a clean way. Now with InexorFlex we are able to just remove stuff from the legacy codebase having all the management logic in a clean flexible system in node.js.
Yes: there are open issues even regarding that architecture (e.g. a nodejs plugin-system) and yes: as its new, it might be more buggy. But really the iteration speed is not compareable.

You had good reasons to choose angelscript (fast, free, similar to C++, hence not so many languages to learn). I like your approaches.
In your place I probably wouldn't choose HTML UIs, but something simpler. As that is your concept: straight forward. And it should be (!) as that is often the fellow dev friendliest way to do stuff: you see what you get.

Videos: We mostly posted proof-of-concepts (in various iterations) to show sauer people that "no, no its perfect as it is, just needs some advertisement" is missing the point (it wasn't a plan, but looking backwards I would kinda interpret the vibes in that direction).
Currently we do not post shiny videos. because that is not what we are developing on: We try to create a solid backend to allow all this shiny stuff to be plugged into it in a clean, easy and flexible way afterwards.

Sorry, this is already longer than planned, so finally back to topic:
nah the CMake mac part is not really that complicated, mac is just not really rich on desktop devs (at least in the Inexor team; and why should we want to try support sth when we are not able to debug and fix it?).
However looking at @mbitsnbites' blog I think he has more expertise in optimizing CMake systems than I have (or mapc, who also wrote big parts of ours). So you probably already have solid templates by hand.

Offline

#9 2017-09-24 11:49:41

chasester1
Member

Re: git, code cleanup etc

In your place I probably wouldn't choose HTML UIs, but something simpler. As that is your concept: straight forward. And it should be (!) as that is often the fellow dev friendliest way to do stuff: you see what you get.
-a_teammate

I dont plan on html, but rather just having the ablity to use html through chromium, (so you can build nodes once, say like a news feed from your website, or other stuff of that nature). Also this will give you the power to allow for loading webpages in side of your ui, rather than rebuilding the same web page inside the other system etc. So it would be probably slower, and maybe more complex to add to an extent but it essentially would give you the power to use your web modules either locally or from a server (weither that is a independent server, or the same page that loads in a browser)  inside the engine so it is much easier to have quick updating info. (I mostly see this useful in say a newfeed on your home screen, or like a welcome screen when you join a server [so communities can show off there clan info] like say tf2 does. So more useful for active info then stuff that remains passive. Of course ui info could be send from the server to the client and rendered but this probably would be no faster and you would have to build a webpage version and an engine version which would be very unuseful and a poor design.)

and thanks for the cmake advise, again im not working on it atm some one who is a mac user is, but I know hes hours are very limited, and he maybe trying to hammer a nail with the bummper of a car so to speak, but I know hell come up with something very solid, even if its much more compicated than it needs to be :)

chasester

Offline

#10 2017-10-05 00:19:57

Hypernova^
Member

Re: git, code cleanup etc

...some one who is a mac user is, but I know hes hours are very limited, and he maybe trying to hammer a nail with the bummper of a car so to speak, but I know hell come up with something very solid, even if its much more compicated than it needs to be :)

Hello, Hypernova here :)
@Chase the main problem is that our codebase isn't compatible with Mac/Linux. A build system such as CMake is a secondary concern, as we have a Makefile that works. On the side, I am working on some more general-purpose build automation tools, but again our blocking issue with crossplatforming comes down to this. We can chat more on Slack :)

Last edited by Hypernova^ (2017-10-05 00:22:22)

Offline

#11 2017-10-05 02:44:06

chasester1
Member

Re: git, code cleanup etc

alright :p

Offline

#12 2017-10-05 17:25:33

RaZgRiZ
Moderator

Re: git, code cleanup etc

I like how my name ended up being Regaza. Where did you even get that :P

Anyway, i'm just doing UI and cubescript backend work, but tesseract itself is pretty much stale so i'm focusing with RR right now.

Offline

#13 2017-10-09 14:00:55

chasester1
Member

Re: git, code cleanup etc

lol i nv know any ones name, and im to lazy to look it up ;P

Offline

Board footer