Code reformatting project [DONE]

Development directions, tasks, and features being actively implemented or pursued by the development team.
Post Reply
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Code reformatting project [DONE]

Post by chuck_starchaser »

Excellent!
:D :D :D :D :D :D :D :D :D :D :D :D :D :D :D :D

Good changes; was just browsing them. Except... we seem to disagree on "using std", I really
don't like it, but I can live with it. I think it's gonna bite our asses sooner or later, tho.
http://www.parashift.com/c++-faq-lite/c ... l#faq-27.5
Last edited by chuck_starchaser on Sat Feb 27, 2010 2:05 pm, edited 1 time in total.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: Code reformatting project [DONE]

Post by safemode »

definitely some shader issues going on though. it's as if they're not on at all. My ship looks shaderless, the planet looks like it's bleached in yellow light ...

no other issues other than that though. I tried extreme detail and very high detail. No change.


edit: you mean "using namespace std;" in source files? rather than referring to everything as std::whatever ? I dont see it any more harmful (at least when talking about std) than typedef'ing annoyingly long variable names to something smaller and more easily readable.

If at some point we want to go back and do "using std::cout;" and such all over the place then fine...but it aggrivates the hell out of me to see an entire source file all std::'d up. something about the redundency just angers my eyes.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Code reformatting project [DONE]

Post by chuck_starchaser »

safemode wrote:definitely some shader issues going on though. it's as if they're not on at all. My ship looks shaderless, the planet looks like it's bleached in yellow light ...
Only meshes specifically calling for the new shaders use them, for now. That's the agricultural base and the diplomatic center.
The reason we don't have defaults yet is that I haven't reorganized the techniques into folders yet, which I need
to do first, before specifying defaults, as the pathnames will change.
Also, I'm waiting for Klauss to come up with some kind of interface to the current, hard-coded default technique
logic.
no other issues other than that though. I tried extreme detail and very high detail. No change.
The yellow ships and flickering planets is a bug I'm hunting for. I think I know the cause, now; just need to come up with a way to verify the theory.

R.e.: std:
http://www.parashift.com/c++-faq-lite/c ... l#faq-27.5
"Look, the whole point of namespaces is to prevent namespace collisions between two independently developed piles of code. The using-directive (that's the technical name for using namespace XYZ) effectively dumps one namespace into another, which can subvert that goal."
Last edited by chuck_starchaser on Sat Feb 27, 2010 2:18 pm, edited 1 time in total.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: Code reformatting project [DONE]

Post by safemode »

well, just about everything white is yellow due to the sun ...even the clouds on the planet are turned yellow.

wouldn't it be the job of the shader to modify that lighting....both in magnitude and such ? and since shaders aren't functioning for these things, it's not a surprise that they look all F'd up.


but shaders are definitely not my area. I'm heading to bed now, now that everything is back in order.

edit: btw, notice, the first ones still live :) -r12652
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Code reformatting project [DONE]

Post by chuck_starchaser »

safemode wrote:well, just about everything white is yellow due to the sun ...even the clouds on the planet are turned yellow.

wouldn't it be the job of the shader to modify that lighting....both in magnitude and such ? and since shaders aren't functioning for these things, it's not a surprise that they look all F'd up.
Yeah, the question is WHICH shader is being used for ships, and specially planets, where none is specified.
Right now I don't know. Klauss knows. And I think that single-texture meshes are getting fixed5.vp and fixed8.vp, which are still using spheremap code. I think that's where the problem is.

but shaders are definitely not my area. I'm heading to bed now, now that everything is back in order.
Sleep well; you deserve it :D

EDIT:
edit: btw, notice, the first ones still live :) -r12652
Yeah, I noticed; and the bug he fixed implies he's compiling without cubemaps. Sent him an email; hope he gets it.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Code reformatting project [DONE]

Post by chuck_starchaser »

There was a reason I couldn't compile --with-boost=system... Didn't have it installed :)
Now I've installed it... Well, I installed 1.40 +-devel; and maybe this is my problem. I get,

Code: Select all

In file included from /usr/include/boost/python/object/function_handle.hpp:8,
                 from /usr/include/boost/python/converter/arg_to_python.hpp:19,
                 from /usr/include/boost/python/call.hpp:15,
                 from /usr/include/boost/python/object_core.hpp:12,
                 from /usr/include/boost/python/object.hpp:9,
                 from src/python/python_class.h:25,
                 from src/python/unit_exports.h:1,
                 from src/python/unit_exports1.cpp:3:
/usr/include/boost/python/detail/caller.hpp: In static member function ‘static const PyTypeObject* boost::python::detail::converter_target_type<ResultConverter>::get_pytype() [with ResultConverter = boost::python::to_python_value<const QVector&>]’:
/usr/include/boost/python/detail/caller.hpp:242:   instantiated from ‘static boost::python::detail::py_func_sig_info boost::python::detail::caller_arity<1u>::impl<F, Policies, Sig>::signature() [with F = QVector (UnitWrapper::*)(), Policies = boost::python::default_call_policies, Sig = boost::mpl::vector2<QVector, UnitWrapper&>]’
/usr/include/boost/python/object/py_function.hpp:48:   instantiated from ‘boost::python::detail::py_func_sig_info boost::python::objects::caller_py_function_impl<Caller>::signature() const [with Caller = boost::python::detail::caller<QVector (UnitWrapper::*)(), boost::python::default_call_policies, boost::mpl::vector2<QVector, UnitWrapper&> >]’
src/python/unit_exports.h:91:   instantiated from here
/usr/include/boost/python/detail/caller.hpp:102: error: ‘struct boost::python::detail::caller_arity<1u>::impl<F, Policies, Sig>::operator()(PyObject*, PyObject*) [with F = QVector (UnitWrapper::*)(), Policies = boost::python::default_call_policies, Sig = boost::mpl::vector2<QVector, UnitWrapper&>]::result_converter’ has no member named ‘get_pytype’
/usr/include/boost/python/detail/caller.hpp: In static member function ‘static const PyTypeObject* boost::python::detail::converter_target_type<ResultConverter>::get_pytype() [with ResultConverter = boost::python::to_python_value<const Vector&>]’:
/usr/include/boost/python/detail/caller.hpp:242:   instantiated from ‘static boost::python::detail::py_func_sig_info boost::python::detail::caller_arity<2u>::impl<F, Policies, Sig>::signature() [with F = Vector (UnitWrapper::*)(UnitWrapper), Policies = boost::python::default_call_policies, Sig = boost::mpl::vector3<Vector, UnitWrapper&, UnitWrapper>]’
/usr/include/boost/python/object/py_function.hpp:48:   instantiated from ‘boost::python::detail::py_func_sig_info boost::python::objects::caller_py_function_impl<Caller>::signature() const [with Caller = boost::python::detail::caller<Vector (UnitWrapper::*)(UnitWrapper), boost::python::default_call_policies, boost::mpl::vector3<Vector, UnitWrapper&, UnitWrapper> >]’
src/python/unit_exports.h:91:   instantiated from here
/usr/include/boost/python/detail/caller.hpp:102: error: ‘struct boost::python::detail::caller_arity<2u>::impl<F, Policies, Sig>::operator()(PyObject*, PyObject*) [with F = Vector (UnitWrapper::*)(UnitWrapper), Policies = boost::python::default_call_policies, Sig = boost::mpl::vector3<Vector, UnitWrapper&, UnitWrapper>]::result_converter’ has no member named ‘get_pytype’
Maybe this get_pytype thing got taken out in 1.40?
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Code reformatting project [DONE]

Post by chuck_starchaser »

The problem of yellow and white ships, and flickering planets, is now resolved.
You need to svn up the data folder, as that's where the shaders are.
r12661
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Re: Code reformatting project [DONE]

Post by charlieg »

So

The question is

What is there that needs to be done before a new release? How close is the Windows build?
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
pheonixstorm
Elite
Elite
Posts: 1567
Joined: Tue Jan 26, 2010 2:03 am

Re: Code reformatting project [DONE]

Post by pheonixstorm »

If you check out the win32 r12613 thread you will see that it compiles. Downside is its not reading the units.csv file so it gets some weird texture/shader problems.... I havent tried compiling the latest head. 12613 is the release before cubemaps (at the time no one was sure how to get cubemaps into the win build)

Now that I know it will at least build I need to check on if head will build and pass along w/e errors and warning VC spits out for chuck and safemode to fix, plus I need to get ffmpeg into the win32 build.. somehow it disappeared after .5

If I had some help it might go a little quicker.. doesn't help im also getting my comp ready for a reinstall. Xp, 7, and linux. Also getting a seperate dev machine up running the same config.
Because of YOU Arbiter, MY kids? can't get enough gas. OR NIPPLE! How does that mkae you feeeel? ~ Halo
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: Code reformatting project [DONE]

Post by safemode »

chuck, you need to rebuild your makefile. i fixed the boost m4 file to include the correct cflag or compiling with system boost (not sure why it was removed).

double check you haven't made local changes to it so it will get updated when you sync to head.

-DBOOST_PYTHON_NO_PY_SIGNATURES should be on your command line as a g++ arg. If it's not, your build files aren't being generated correctly.

I tested autoconf on my system using 1.40 and python 2.5 and it worked fine. (python 2.5 is detected by default even though it says 2.4 will be default... it uses whatever boost was compiled against).
Ed Sweetman endorses this message.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: Code reformatting project [DONE]

Post by safemode »

pheonixstorm wrote:If you check out the win32 r12613 thread you will see that it compiles. Downside is its not reading the units.csv file so it gets some weird texture/shader problems.... I havent tried compiling the latest head. 12613 is the release before cubemaps (at the time no one was sure how to get cubemaps into the win build)

Now that I know it will at least build I need to check on if head will build and pass along w/e errors and warning VC spits out for chuck and safemode to fix, plus I need to get ffmpeg into the win32 build.. somehow it disappeared after .5

If I had some help it might go a little quicker.. doesn't help im also getting my comp ready for a reinstall. Xp, 7, and linux. Also getting a seperate dev machine up running the same config.


you will need to specify -DNV_CUBE_MAPS when compiling the source for cubemaps to at least attempt to compile.

i also suggest clearing out your user vegastrike dir after updating to the latest /data .... this should clear out any cruft from sphere maps and such. back it up if you want to attempt to re-use save files.
Ed Sweetman endorses this message.
pheonixstorm
Elite
Elite
Posts: 1567
Joined: Tue Jan 26, 2010 2:03 am

Re: Code reformatting project [DONE]

Post by pheonixstorm »

safemode wrote:you will need to specify -DNV_CUBE_MAPS when compiling the source for cubemaps to at least attempt to compile.
I actually already had that in at one time while I was running 12613 and 12614 (before head went screaming on up to 12650ish) I was running 2 revisions and alternating between the two to get both working. I had 12614 running twice until I started getting a runtime error... 12613 is still a test case since it doesn't change, though my 12614 folder stays at head. I stopped work on the head revision since chuck had a lot of changes going on during his reformat work.
Because of YOU Arbiter, MY kids? can't get enough gas. OR NIPPLE! How does that mkae you feeeel? ~ Halo
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Code reformatting project [DONE]

Post by chuck_starchaser »

safemode wrote:chuck, you need to rebuild your makefile. i fixed the boost m4 file to include the correct cflag or compiling with system boost (not sure why it was removed).

double check you haven't made local changes to it so it will get updated when you sync to head.

-DBOOST_PYTHON_NO_PY_SIGNATURES should be on your command line as a g++ arg. If it's not, your build files aren't being generated correctly.

I tested autoconf on my system using 1.40 and python 2.5 and it worked fine. (python 2.5 is detected by default even though it says 2.4 will be default... it uses whatever boost was compiled against).
What's the command to rebuild the makefile? You mean bootstrap-sh and config?

BTW, I'm close to a commit; been replacing using namespace std with specific, targeted directives, e.g.,
using std::string;
using std::cout;
using std::endl;
using std::pair;
etceteras, only as needed.


@storm: You can go ahead and work with head; the changes going on now are not platform destructive.
No sense wasting time trying to compile old revisions we won't need.


EDIT: The buttocks of the medusa...
navcomputer.cpp: I got rid of using namespace std in it, and it still compiled fine. That means that it's
getting a using namespace std from some header file. Thing is, grep didn't find any I haven't taken out
already from header files. :roll:

Code: Select all

#include "vegastrike.h"
#if defined (_WIN32) && !defined (__CYGWIN__) && !defined (__MINGW32__)
//For WIN32 debugging.
#include <crtdbg.h>
#endif

#include "navscreen.h"
#include "navpath.h"
#include "in_kb.h"
#include "in_kb_data.h"
#include "in_mouse.h"
#include "gfx/cockpit.h"
#include "main_loop.h"
#include "lin_time.h"
#include "gui/modaldialog.h"
#include "gui/eventmanager.h"
#include "gui/newbutton.h"
#include "gui/staticdisplay.h"
#include "gui/textinputdisplay.h"
#include "gui/simplepicker.h"
#include "gui/groupcontrol.h"
#include "gui/scroller.h"

vector< unsigned int >nav_keyboard_queue;
.............................
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Code reformatting project [DONE]

Post by chuck_starchaser »

Committed. r12662


EDIT:
@charlieg: One more thing that should get done before a release is a reorganization of the shaders. Klauss already implemented the engine side of it, so the ball is in my court. Namely, the problem is that, currently, vssetup gives you a choice between Nicest shader, Average shader, Simple shader, and No shader. The obvious intent is to select a level of sophistication, rather than a particular shader. But the current implementation is mapped to a particular shader; which is not good because opaque things use opaque shaders, transparent things use transparency shaders, etceteras.
So, what Klauss did, on the engine side, is to create a grid system:
All the sophisticated shaders can be put in one folder; all the medium in another; all the simple in another; and the vssetup setting maps to a folder. The shaders in each folder have identical names to those in other folders; --i.e. each folder has opaque.fp and transparent.fp.
Then, a mesh specifies a type of shader, such as opaque or transparent. And the engine then picks a shader of the right type, from the folder specified in vssetup.
So, the code is done; I just need to implement the folders and organize the techniques and shaders into them. Probably today, if I encounter no problems; or by tomorrow otherwise, I predict.
pheonixstorm
Elite
Elite
Posts: 1567
Joined: Tue Jan 26, 2010 2:03 am

Re: Code reformatting project [DONE]

Post by pheonixstorm »

chuck_starchaser wrote:@storm: You can go ahead and work with head; the changes going on now are not platform destructive.
No sense wasting time trying to compile old revisions we won't need.
I was actually refering to the changes you made during the uncrusty trial. That is what I was waiting to be done since so much work was being done with units.h/units.cpp The current changes arent an issue
chuck_starchaser wrote: EDIT: The buttocks of the medusa...
navcomputer.cpp: I got rid of using namespace std in it, and it still compiled fine. That means that it's
getting a using namespace std from some header file. Thing is, grep didn't find any I haven't taken out
already from header files. :roll:

Code: Select all

#include "vegastrike.h"
#if defined (_WIN32) && !defined (__CYGWIN__) && !defined (__MINGW32__)
//For WIN32 debugging.
#include <crtdbg.h>
#endif

#include "navscreen.h"
#include "navpath.h"
#include "in_kb.h"
#include "in_kb_data.h"
#include "in_mouse.h"
#include "gfx/cockpit.h"
#include "main_loop.h"
#include "lin_time.h"
#include "gui/modaldialog.h"
#include "gui/eventmanager.h"
#include "gui/newbutton.h"
#include "gui/staticdisplay.h"
#include "gui/textinputdisplay.h"
#include "gui/simplepicker.h"
#include "gui/groupcontrol.h"
#include "gui/scroller.h"

vector< unsigned int >nav_keyboard_queue;
.............................
If you look around there are also a lot of sections that go using std:string or std:vector Did you check on those?
Because of YOU Arbiter, MY kids? can't get enough gas. OR NIPPLE! How does that mkae you feeeel? ~ Halo
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: Code reformatting project [DONE]

Post by safemode »

you have "using" directives in many headers that specify the individual functions ... like easydom.h this is why you have std functions that compile fine even though you have no local using directives.
Ed Sweetman endorses this message.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: Code reformatting project [DONE]

Post by safemode »

chuck_starchaser wrote:
safemode wrote:chuck, you need to rebuild your makefile. i fixed the boost m4 file to include the correct cflag or compiling with system boost (not sure why it was removed).

double check you haven't made local changes to it so it will get updated when you sync to head.

-DBOOST_PYTHON_NO_PY_SIGNATURES should be on your command line as a g++ arg. If it's not, your build files aren't being generated correctly.

I tested autoconf on my system using 1.40 and python 2.5 and it worked fine. (python 2.5 is detected by default even though it says 2.4 will be default... it uses whatever boost was compiled against).
What's the command to rebuild the makefile? You mean bootstrap-sh and config?
bootstrap should do the trick. You can doublecheck your m4 file to make sure the following code block exists (it should if you are running HEAD.

Code: Select all

if (test "x${with_boost}" = "xsystem"); then 
BOOST_CPPFLAGS='-I/usr/include -DBOOST_PYTHON_NO_PY_SIGNATURES '
with_boost_ver=$with_boost
If it doesn't exist, then delete the file and re-run svn update --ignore-externals

also make sure you have libboost-python1.40-dev installed.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Code reformatting project [DONE]

Post by chuck_starchaser »

@storm: I haven't, but I will.

@safemode: I moved everything in the m4scripts folder to a temp folder, did an svn up; followed with
a make clean and ./bootstrap-sh. Then ran,

Code: Select all

./configure --enable-release --disable-debug --enable-cubemap --with-python-version=2.5 --with-boost=system
and configure tells me,

Code: Select all

configure: WARNING: unrecognized options: --with-python-version
then make... I read in the output for each module:

Code: Select all

-I/usr/include/python2.5 
So, I guess it took my directive even though it said it didn't recognize it... :shock:
Building no problem so far...
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: Code reformatting project [DONE]

Post by safemode »

--with-python-version isn't required to link against the correct python. At least on my system. It picked 2.5 automatically. As it did on yours too.

I would seriously suggest cmake. autoconf's likely not going to be the primary build platform once cmake is squared away in win32 land. Since that will let us use a single build config for all our archs. negating the need to maintain vc files and autoconf files separately.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Code reformatting project [DONE]

Post by chuck_starchaser »

Do we have a wiki on how to build with cmake?

Got a link error:

Code: Select all

/usr/bin/ld: cannot find -lboost_python-st
collect2: ld returned 1 exit status
make[1]: *** [vegastrike] Error 1
make[1]: Leaving directory `/home/d/vs/repo/trunk/vegastrike'
make: *** [all] Error 2
pheonixstorm
Elite
Elite
Posts: 1567
Joined: Tue Jan 26, 2010 2:03 am

Re: Code reformatting project [DONE]

Post by pheonixstorm »

safemode wrote:I would seriously suggest cmake. autoconf's likely not going to be the primary build platform once cmake is squared away in win32 land. Since that will let us use a single build config for all our archs. negating the need to maintain vc files and autoconf files separately.
I'm still working on getting cmake running under windows. Its irritating though since in windows you don't have all the source for everything that would normally be used like you do under linux.
chuck_starchaser wrote:Do we have a wiki on how to build with cmake?
I don't recall seeing one. Who can edit the wiki? Anyone registered on the forums or just a select group?
Because of YOU Arbiter, MY kids? can't get enough gas. OR NIPPLE! How does that mkae you feeeel? ~ Halo
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Code reformatting project [DONE]

Post by chuck_starchaser »

Yes; you login with your same forum name and pax sword.
Me I can't, because my name has an underscore :(

You know how one builds with cmake?
I don't need a treatise; just the commands I need to build this thing.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: Code reformatting project [DONE]

Post by klauss »

WOW... I dissappear a day or two and everything gets turned upside down ;)

svn up-ping, make clean, make -j2, enjoying a nice mate at the right temperature...

I'm really curious about what the problem with shaders was.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Code reformatting project [DONE]

Post by chuck_starchaser »

Hey; having mate here too ;-)

The problem with the shaders was what I suspected.
Let me say first; you were right about those mistakes in default and highend fp's, but fixing those
mistakes didn't make any difference; probably because there aren't more than two lights, and the
mistakes involved lights 2 through 7; -- 0 and 1 don't use attenuation of any kind.

The problem with rocky planets and oxes was that they only call for one texture; and don't specify
a shader. So the engine code was/is selecting highend_simple.technique; which in turn calls for
fixed8.vp and ambientmapped_simple.fp.
What fixed8.vp was doing was computing the reflect vector, and then using a sphermap formula
to pass a final, 2D texture coordinate to the fp. It also passed a computed fetch from the normal
for like ambient light. The funny thing, and what I don't understand at all is, the fp didn't seem
to be using these texture coords. I don't know; there's a lot I still don't understand. But anyhow,
I removed the spheremap formula, removed the passing of xy reflect coordinates (had a reflect
vector3 and a specular fetch, but then I changed my mind; not good for planets), and simplified
the fp a bit, and it worked. Handling of alpha was wrong. There was also repeated assignments
to glFragWhatever, I mean the output, which I don't think is kosher; may be wrong; but I think
the output auto-clamps, so it should be written to once at the end of the computation.
pheonixstorm
Elite
Elite
Posts: 1567
Joined: Tue Jan 26, 2010 2:03 am

Re: Code reformatting project [DONE]

Post by pheonixstorm »

chuck_starchaser wrote:Yes; you login with your same forum name and pax sword.
Me I can't, because my name has an underscore :(
Will try it out.
chuck_starchaser wrote: You know how one builds with cmake?
I don't need a treatise; just the commands I need to build this thing.
Not in linux land... in windows its all gui. Open cmake and put in the directories it asks for as you hit configure. Not sure if its the same on linux... probably not.
Because of YOU Arbiter, MY kids? can't get enough gas. OR NIPPLE! How does that mkae you feeeel? ~ Halo
Post Reply