jacmoe

Members
  • Content count

    398
  • Joined

  • Last visited

Community Reputation

2179 Excellent

About jacmoe

  • Rank
    Crossbones+
  1. Programming is a practical skill. Yes, some of it is knowledge of encyclopedic nature and can (must) be acquired. You are leaving out the 80 % Nyaanyaa. I hope you are not a scientist because right now you seem to be reworking reality to suit your theory.
  2. @Nyaanyaa : You have practiced critical and analytical thinking for years - mathematics and theories on the university level - so it should not surprise anyone that you find it easy enough to learn how to program. You forget that important element when you jump to a conclusion. Your anecdote actually proves the opposite point, the point brought forward by Oberon_command: programming is so much more than theory, syntax and typing. It amounts to 20 % roughly speaking. The last 80 % is practical experience where critical thinking, problem solving, creativity and an analytical mindset is applied to each and every programming problem being undertaken. Programming is much like modern mathematics where the real learning is achieved by doing (20 % formal knowledge, 80 % practice).
  3. It all starts with a strong desire to make a game. Then everything else has got to follow: learning a programming language, some content creation tools (Blender, Krita/Gimp/Photoshop), storyboarding, whatever. A strong desire means that you don't mind putting a lot of hard work into it. If not, then the desire is not strong enough and you will not succeed.
  4. Starting out - making sure I am doing it right

    Do all the tutorials! Everything you can get your eyes/hands on. Some of them are good and some of them are bad. And there are probably a lot of them which costs money. Like any other technology that people might be interested in learning. Just use your critical sense. However, be careful to choose the latest revision/edition of the language C# and stay clear of the most outdated resources. Otherwise, knock yourself out.   <edit> And get a couple of books as well. </edit>
  5. C# becoming obsolete ?

    I programmed in Delphi for a couple of years and loved it. Programming graphics, and later games, led me into the murky mires of C/C++. I was thrilled to hear that Hejlsberg was brought in to create a new language called C#, he did an awesome job with Delphi. And he did not disappoint. However, the surrounding .NET framework has never appealed to me, especially since I don't like to be married to Microsoft/Windows. It is a pity that Mono was so badly handled but let's see how it goes now that MS has opened the source code.   Bottom line: Some of the technology around C# will definitely become obsolete and replaced by something else, but C# is a very good language so it will stick around.
  6. IDEs vs editors

    I just wanted to point out that there are a couple of very good reasons for not firing up the IDE and that it is more common to call the MS build tools from the command-line than you might think (and for non-ideological reasons too); I didn't mean it to be a hard-core rule. I like an IDE and the productivity that it provides.
  7. IDEs vs editors

    Yes, that was my point: you don't need to open the IDE to build. I am building my framework/application/game frequently without coding to test that it builds in different configurations, but I also open the IDE to code (obviously) and then I choose either QtCreator or Visual Studio depending on what kind of work I do.   Swiftcoder: I know that you hate CMake, and I love it. And that we can never meet It's just ironic, I think, because amongst SCons, Premake and CMake and a lot of other build script tools, it is only CMake that has a dependency management system built on top of it. It's called Bicode, and I know of several other projects that predates that. But let's just let it rest for now.
  8. IDEs vs editors

    You are entirely out to lunch Graelig. It's a pity that you can't figure out how to invoke nmake from the shell and that CMake is giving you a hard time and that you find it difficult to function without an IDE, but I guess you will survive.   You are asking why I would like to not use an IDE, and the reason is that it is much, much faster to just fire off a batch of commands instead of opening the IDE (takes a while to load), load the solution and all projects (takes even longer to load), wait for intellisense to do it's parsing, and then finally activate the project that you want to build, select the right configuration and hit build. Whew, that's a lot of waiting and clicking, isn't it? Of course, when you are coding, then an IDE is great, because then you actually need the intelli-sense and the nice UI. Not when you just want to configure and build the damn thing. :)   I am not off-topic: if you are using an editor for programming then you need to call the build tools (nmake/make) from the shell. Could be Emacs, Sublime Text, Notepad++,.. Code::Blocks (which is an IDE) does call out to MinGW or Microsoft's build tools too, it's not as obvious as when you do it manually.
  9. IDEs vs editors

    Beats me why you feel you have to write your own Find_ODE.cmake module for N different platforms.. The Find_SDL module ships with CMake and works across all supported platforms (OS X included). And I think it would be a trivial thing to get hold of a battle-tested Find_ODE CMake script as a result of a quick Google. If it was me, in my projects, I would probably have queried for ODE and it's dependencies and if any of them aren't found, I would let CMake download/checkout, unpack and build and install (locally, into the build directory) by means of CMake's ExternalProject.   This discussion is getting us nowhere - it's a bit like complaining about how the alarm clock sucks because it doesn't brew coffee.   <edit> I could ask why on Earth you would want to be using ODE when you could be using a hard-ware accelerated physics library like Bullet? But that would definitely derail the topic even further. </edit>
  10. IDEs vs editors

    Npm, Gem and (I guess) Gradle are package managers, not cross-platform tools to manage build systems. CMake is not, and does not try to be, a package manager with dependency management.   Biicode, however, is indeed comparable to Gem/Npm/Gradle but I find it to be too intrusive. It is built on top of CMake, which illustrates that you can build almost whatever you want on top of it. Perhaps that would make CMake more palatable to the 10% people? :)   I do not think it is fair to criticize CMake for not being what it is not intended to be. I like that it is not an operating system. :p
  11. IDEs vs editors

    That was my starting point as well, but it is not well written. Not exactly an example of clean and modular CMake scripts. I didn't know about XCode and CMake having fallen into neglect, but almost anything that has to do with Apple is arcane by design it seems. I don't find the find_package system (pun intended?) to be too much of a hassle - seems to work great on at least Windows and Linux flavors. I tend to rely on environment variables a lot, though. Definitely makes it simpler on Windows which doesn't have a canonical file system. (/usr/lib, /usr/local, etc)   I am totally aware that CMake is not even close to being the magic bullet, but more often than not it is quite simply faster for me to just write a CMake script for a project than messing around and trying to fix broken VS projects. And, yes: I do create a lot of CMake projects because not everything has been CMake'd. And I have a tendency (hobby?) to constantly try out things, hence the need to create new projects on a regular basis.   So, in an attempt to connect our derailed post to the topic: I find that it is easier and less error-prone to create/maintain/handle projects outside of an IDE than from within. That is my personal experience and thus not universally applicable (even though I'd love that to be the case )
  12. IDEs vs editors

    Come on yourself. I have quite some experience setting up projects from within Visual Studio and "New Project" generates a new project. After that, however, you need to configure the newly created project. I maintained the OgreAppwizards project for years where people could download and install an application wizard for various editions of Visual Studio to easily create new projects using Ogre3D. That eliminated most edits to the project as the project wizard set everything up for you. The project also had a Code::Blocks project generator, a project template for KDevelop, ..   But since I began using CMake I gradually stopped using the appwizards and have stopped actively supporting the project. Now, whenever I want to create a new project - for any IDE - I just copy a simple CMake based directory with a simple CMake script, some common scripts and a skeleton application (C++ files). I adjust the CMake script to reflect the needs of my new project and launch the CMake GUI, hit configure twice and generate once. And that's a new project for Visual Studio or other depending on what generator I used in CMake GUI. The generated build script does not need to be edited - I treat the Visual Studio solution and it's projects as read-only output. There is no command-line involved either.   That is definitely much faster in my experience. Even compared to using property sheets, etc with VS - and then you still only get build scripts for one version of that environment. I would love to hear about even faster methods.   I guess I could write a Python application wizard that spits out a CMake script - it's on my RSN list.. that would be faster still.   The syntax is only arcane and the semantics only inconsistent when you haven't used CMake or SCons yourself. I find it fairly straight forward. As always, you can write your build scripts as simple or as contrived as you like. I favor simplicity and just enough to get the job done. If you don't like the feel of either then there is also Premake. However, more and more projects have begun using CMake so it can't be that bad. :p
  13. CMake for ogitor

    Hold on .. Ogitor 0.4 does use Ogre 1.10 - sorry that I got confused (was thinking about Ogitor unstable - stay away from that ). Ogre 1.10 it is.   <edit> Will try and make room/time for compiling Ogitor 0.4 against Ogre 1.10 today-ish to make sure that it isn't broken. </edit>
  14. CMake for ogitor

    Try and see if deleting the CMake cache and reconfiguring does the trick. Ogitor does use Ogre default branch (1.10) but the error you are getting suggests that CMake is having some internal hickup. <edit> It does not use Ogre default - it uses Ogre 1.10
  15. CMake for ogitor

    Don't worry about the pkg stuff in the output.