Elysian Shadows

Benjamin100 wrote:I think I'd like Visual, I'm just not sure I want to make the investment right now.

-Benjamin

Express 2010 is free, and has all the functionality you'll need.

Krolgar wrote:But I feel like it's hiding too much from me (not in terms of GUI--I actually think the GUI could be minimized a bit more--but when it comes to the project itself), and I absolutely loathe qmake.

Ah, that's explain it. If you want to do any sort of powerful nonQT-based customization, you really have to go through QMake... I don't hate it too much, because the variable names are at least somewhat relevant to their make counterparts (that they get translated into).

I will say that I use QTCreator on Windows 7, OSX Lion, Ubuntu, and Kubuntu on a daily basis, while working on the same project, and it works amazingly. It does the whole multiplatform thing very well... unlike Code::Blocks, which worked fine until you got it on a Mac... then I wanted to kill somebody.

I started out using devc++ and moved on to codeblocks after I couldn't get SDL to work. After using codeblocks for a while I decided to try VS express 2010. My biggest problem at the time with it was the fact that it ran slow as shit and I couldn't run nearly anything else at the same time because it would crash. This was more the fault of my computer though, it was made back in 2003 and had trouble just running windows xp. I also found the solution project relationship to be kind of annoying. So I stayed with codeblocks for a little while longer (mainly due to how much simpler it was), until I couldn't take its broken symbol list anymore. So I gave VSe 2010 another try and after using it for a while it started to grow on me. Now that I finally have a decent computer VSe runs just fine, I just wish I could afford the full version of VS.

Interesting... I LOVE the Solution/Project approach in VS2010. As a matter of fact, I just spent HOURS last night trying to emulate something like a solution with multiple projects dependent on one another last night in XCode4...

GyroVorbis wrote:Interesting... I LOVE the Solution/Project approach in VS2010. As a matter of fact, I just spent HOURS last night trying to emulate something like a solution with multiple projects dependent on one another last night in XCode4...

which failed?

BugInTheSYS wrote:

GyroVorbis wrote:Interesting... I LOVE the Solution/Project approach in VS2010. As a matter of fact, I just spent HOURS last night trying to emulate something like a solution with multiple projects dependent on one another last night in XCode4...

which failed?

It worked, but it's fuck-ugly. I have a "workspace" with a libGyro project and an Engine project that has a libGyro project reference embedded within it as a dependency... So there's essentially two libGyro projects (one actual, one reference) in the same workspace...

I used to love the VC++ 2005 interface but I haven't used it in forever. XCode really pisses me off until I figure out what I need to figure out - then its clear why they did it that way.

Still, damn thing needs a better (existing?) manual.

GyroVorbis wrote:

BugInTheSYS wrote:

GyroVorbis wrote:Interesting... I LOVE the Solution/Project approach in VS2010. As a matter of fact, I just spent HOURS last night trying to emulate something like a solution with multiple projects dependent on one another last night in XCode4...

which failed?

It worked, but it's fuck-ugly. I have a "workspace" with a libGyro project and an Engine project that has a libGyro project reference embedded within it as a dependency... So there's essentially two libGyro projects (one actual, one reference) in the same workspace...

No reason you have to do it that way.

If both projects are in one work space. all of the projects and their "products" are visible to each other. Thus, if you went to the build phase tab, and clicked link binary with. your first option would be any libraries or object files that are in the workspace.

The only thing that will show in the project linking libGyro is the actual libGyro.a/dylib.

In this configuration when you build the project, it will automatically rebuild libGyro if it is out of date.

This is all in the documentation online, as well is built into Xcode.

GyroVorbis wrote:I use VS2010, QTCreator, and XCode on a daily basis.

VS2010 has my vote as the most streamlined, professional, and powerful. You think VS2010 is buggy? XCode 4 crashes at least twice a day for me.

QTCreator is my IDE of choice for multiplatform development. It's what Code::Blocks and DevCpp WANTED to be, but didn't get right. If it weren't for VS2010's raw power, QTCreator would be my top pick.

I have a very love/hate relationship with XCode. XCode4 did a LOT of things correctly that XCode3 did wrong. Looking back, XCode3 was borderline a piece of shit. XCode4 still remains unstable, and hard to use compared to the others, but it's admittedly quite powerful and LIGHTYEARS more user-friendly than XCode3.

Honestly, you were better off with Makefiles than using XCode3...

If you chose not to read the manual maybe...

avansc wrote:

GyroVorbis wrote:

BugInTheSYS wrote:

GyroVorbis wrote:Interesting... I LOVE the Solution/Project approach in VS2010. As a matter of fact, I just spent HOURS last night trying to emulate something like a solution with multiple projects dependent on one another last night in XCode4...

which failed?

It worked, but it's fuck-ugly. I have a "workspace" with a libGyro project and an Engine project that has a libGyro project reference embedded within it as a dependency... So there's essentially two libGyro projects (one actual, one reference) in the same workspace...

No reason you have to do it that way.

If both projects are in one work space. all of the projects and their "products" are visible to each other. Thus, if you went to the build phase tab, and clicked link binary with. your first option would be any libraries or object files that are in the workspace.

The only thing that will show in the project linking libGyro is the actual libGyro.a/dylib.

In this configuration when you build the project, it will automatically rebuild libGyro if it is out of date.

This is all in the documentation online, as well is built into Xcode.

Oh shit, son... I even found a post on ask.com or whatever confirming that my way was the only way to do it... The problem with that you can't add the dependency to "Target Dependency" in the "Build Info" tab unless it has been added to the other project...

So how does that work? Either XCode implicitly considers it a dependency without even telling you (it doesn't show up in the dependency window), or this method doesn't work.

avansc wrote:If you chose not to read the manual maybe...

Right... I forgot that that's how good software design works. You're completely excused for having a cluttered, unintuitive UI, because the users should have stopped and read a 100 page manual. I'm sure glad other IDEs don't share this philosophy.

Well damn. Okay, avansc's method DOES work. Even though the other project doesn't show up as a dependency and cannot be set explicitly as a dependency, "it just is" when you link against its product.

Well, regardless of our differing opinions in the IDE wars, avansc has ultimately bettered my XCode4 project. So thanks, much appreciated. :D

GyroVorbis wrote:Well damn. Okay, avansc's method DOES work. Even though the other project doesn't show up as a dependency and cannot be set explicitly as a dependency, "it just is" when you link against its product.

Well, regardless of our differing opinions in the IDE wars, avansc has ultimately bettered my XCode4 project. So thanks, much appreciated. :D

np. Also, if you want to do it the "proper" way, here when you explicitly use the word dependency, you want to add a target to your game project that is an aggregate. With in the aggregate you can add dependancies as project or targets within projects.

Also, my read the documentation comment was meant in all sincerity. If you just stick someone who has never used VS they will have the same issues. They might do things a bit differently, but the level of abstractions are very similar. I think a lot of your strife came in with you being proficient with VS and expecting XCode to just be the same, or that you SHOULD be able to do it BECAUSE you can in VS. Thats just human and not just you, we all do it.

On a bit of a side note. man the blame git blame view in xcode is super nice.

GyroVorbis wrote:Interesting... I LOVE the Solution/Project approach in VS2010. As a matter of fact, I just spent HOURS last night trying to emulate something like a solution with multiple projects dependent on one another last night in XCode4...

The only time I ever found it useful was when I was building the lua library and the compiler.

Rapid Cube wrote:

GyroVorbis wrote:Interesting... I LOVE the Solution/Project approach in VS2010. As a matter of fact, I just spent HOURS last night trying to emulate something like a solution with multiple projects dependent on one another last night in XCode4...

The only time I ever found it useful was when I was building the lua library and the compiler.

And let me guess, that's the only time you've ever had to use two projects together?

I mean, I feel like I know how to use Code Blocks now.
Is there really anything that makes Visual SO much better that it is worth learning to use another IDE?