Jump to content

  • Log In with Google      Sign In   
  • Create Account


scniton

Member Since 10 Jun 2012
Offline Last Active Mar 15 2014 12:50 AM

Posts I've Made

In Topic: C++ IDEs for Linux

25 February 2014 - 12:14 AM


Still, KDE won't be on my arcade machine. It won't even have a desktop environment since I'll be cramped for processing power. Not sure if that'll be a problem as I'll be running a GLUT window from a command line program.
KDevelop, like every other IDE, only requires its dependencies on your development machine. It does not force you to add any dependencies for deployment.


I haven't figured out the licensing, or what kind of royalties I'd have to pay Nokia if it came down to me producing a commercial produce.
The LGPL licensed Qt option sounds like what you'd want.

In Topic: C++ IDEs for Linux

24 February 2014 - 10:24 AM

KDevelop looks beautiful! This is the first time I've heard of it. Tell me, is it as "bloated" as Eclipse?

It runs much better than eclipse here. "Bloated" can be subjective, the only way you'll know for sure is to try it.

I would also vote for QtCreator. KDevelop is nice but not really suited to cross-platform development (not everyone wants to install the whole KDE on Windows)

The OP specifically asked for Linux and didn't mention cross-platform.
Furthermore, I don't think most people consider having to use different IDEs on different platforms a deal breaker.


In Topic: C++ IDEs for Linux

24 February 2014 - 04:28 AM

My hands down favourite is KDevelop.
Before finding KDevelop I had tried:
* Code::blocks
* codelite
* QtCreator

I haven't looked back since switching to it.


In Topic: [SOLVED] C++ compiling on Linux. (IDE for Linux)

21 September 2013 - 11:49 AM

As others have stated, things are more diverse on linux.
I personally love KDevelop for C++ on Linux (I used to use codelite.)


In Topic: max coord values and fp precision

28 March 2013 - 02:08 PM

another issue: true range checks (pythagorean) require squaring dx and dz (and dy for 3d range). that could lead to overflow with signed int and values on the order of 50 million. 50 meg ^2 = 250 trillion (?).  time for long long, eh?

Yes, and depending on the range of height values (dy) a 64bit unsigned may not be enough for the intermediate results depending on the chosen representation.
Using doubles is the easier path if it satisfies your requirements.

 

now, what abut loss of precision when converting to camera relative? just have to make sure you have enough decimal places in your fixed point eh? and your integer parts don't get too big?

Converting to relative doesn't usually cause significant loss of precision.
If the integer parts are big, then your objects are at extreme distances from the camera and so any differences introduced from converting from fixed point to floating point should be insignificant.


PARTNERS