Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 29 Nov 2009
Offline Last Active May 09 2013 03:26 PM

#5039174 Best Multiplatform IDE?

Posted by on 04 March 2013 - 03:14 PM

Question though: what amount of work does it take to make vim from just a text editor with some fancy key commands, and being able to turn it around and make it a serious development tool? Seems like the biggest reason people prefer vim or emacs over just... text editors is because you can extend them to include very basic development needs (like compiling, for instance).


I guess that depends largely on what works for you.


I use vim professionally and so do my fellow team members. We're all working on Linux, though (embedded systems and networking application software). I haven't seen people using things like auto-completion or pop-ups, but some people like to use 'cscope', which integrates with Vim pretty much out of the box. But that's kinda C-specific.


I make heavy use of tabs, copy/paste/cut with markers, search and replace, and regular expressions in Vim, along with formatting features, navigation strokes, etc... I also have my vimrc set to do things like color column 81, color text past column 80, underline the line the cursor is currently on, color trailing whitespace, number lines, etc... That's pretty much it and that, for me, goes a long way. Except for the vimrc stuff, it all comes with Vim. To get the coloring, you can just google and copy someones vimrc, or I can post mine, etc...


Side note:

I consider a bash shell to be my IDE (at work) and all the command-line programs like vim, grep, sed, awk, less, cat, gcc, make, git, etc... are like plug-ins for my IDE. So, this is why I don't really super-size my vim. Instead, I focus more on how to improve my shell usage via learning/writing new programs, shell scripting, etc... The other nice thing about those tools I listed is that they have a similar "dialect". Basically, they play nice with each other.


I remapped my hotkeys for gnome-terminal so that I can easily spawn new windows (in tabs or separate), move the tabs around, and move between the tabs. When I want to build, I just spawn, move over, and run make. I just like having the output separate like this. (e.g. ctrl-n: new tab ; ctrl-N: new window ; ctrl-[,]: move to prev,next tab ; ctrl-{,}: move tab left,right) My coworker really likes terminator, which is pretty nice with split-panes, broadcasting to all panes at once, etc...


I have tried this in Windows too, with powershell, vim, cl.exe, nmake, git, etc..., and it works fine, so I do that sometimes. I just find bash easier to use than powershell (maybe I don't grok ps, yet). I think it's important to be flexible, though. I really like the look and feel of visual studio, for example, especially with a Vim plug-in. I also really like Eclipse with a vim plug-in, but I don't work with Java a lot (and I ran into some technical bumps with CDT, not sure how smooth it is now, though).


To say something about the last remark, I prefer Vim over other text editors, not because it does things that other text editors don't, but because it does things better. I know this doesn't sound right if you are new to Vim or you don't get Vim because I was both those things at one time and another. At least, this is how things went for me.

#5038854 Best Multiplatform IDE?

Posted by on 03 March 2013 - 03:58 PM

To my mind, having never been taught or learned as a kid/teen how to use vim or emacs, it seems a lot simpler to just do everything in a Notepad like editor and have the terminal up near by... even if it is an extra click or two.


These editors have a certain level of knowledge that you need to gain before you can use them. It's really not that much info at all, but it feels like a lot because, in addition to learning, it takes practice using something that might seem bizarre at first.


Once you understand something like vim, those "simpler editors" become too simple, way too simple. e.g. I used to not care about moving around text with the arrow keys, but now I feel crippled without an edit mode.


I recommend reading this post on understanding vim: http://stackoverflow.com/questions/1218390/what-is-your-most-productive-shortcut-with-vim/1220118#1220118

#5036628 What GUI Toolkit Would Be Best For My Game Editor?

Posted by on 26 February 2013 - 01:41 AM

I've used clutter before for school and playing around with creating widgets:



Fun to work with, based on C (+ gobject), cross-platform, lot's of language bindings (vala, c++, javascript, etc...)...

#5036614 portfolio

Posted by on 26 February 2013 - 12:06 AM

I'm new here, too, but for what it's worth welcome.


+1 for keep posting.

#5033602 Starting 3D Modeling - or sculpting? Advise please

Posted by on 17 February 2013 - 08:49 PM

I've used modo. The problem with it is that it doesn't have any kind of skeletal animation system (at least not when I used it). Other than that, it was pretty cool.


I recommend Blender. I like the UI. It takes learning, they all do, but it's a good UI. Once you get a hang of the basics, you will want to focus on modifiers and constraints.


Scultping is typically used to create high-res meshes. You "bake" the detail information into a texture that gets used in a lighting equation used to shade a counter-part lower-polygon version of the model. This applies to anything you want to look detailed, but cost cheap, including characters, architecture and other props.



As for your project, I would recommended skipping making the base mesh. Animating and game programming are more than enough for the time period you are looking at. The animation and programming tasks are related, the modeling is, essentially, orthogonal. It will eat into your time and be a little counter-productive.


I suggest doing some personal modeling and sculpting exercises separate. For example, every day, give yourself an hour to work on something that you'll trash. Sculpt a new head or polygonal model a humanoid base mesh or sub-div surface model a vehicle component thing.


You can use this base mesh: http://cgcookie.com/blender/2009/11/14/model-male-base-mesh/

And then follow these tutorials to rig and animate it: http://cgcookie.com/blender?s=rigging

Then drop it into unity, create a little state machine system, and start adding more states, animations, and logic to it.

#5033396 Where to go to learn 3D modeling...complete beginner

Posted by on 17 February 2013 - 10:33 AM

I was playing around with Unity 3D just before their Unity 4 release. I just saw Mecanim and it looks like an optional way to animate and manage animations for a biped character. If you want to animate something like a spider, I don't think it would be much help:



Unity's documentation says that it supports .blend files natively, so it sounds like you could do one or the other:



I'm not sure how interoperable animating between the two is, though.


Within the scope of the kinds of things they both can animate, I do not see any kind of fundamental difference. They are both a means to produce data that tells your rig how to transform itself as time passes. However, things like ease of use, personal taste, turn-around time, or available community content are all factors that could sway someone one way or the other.

#5033291 Where to go to learn 3D modeling...complete beginner

Posted by on 17 February 2013 - 01:48 AM

You'll be fine with Blender. IMO, it's amazing to have software like that available at no cost.


I'm the type of person that loathes tutorials. In general, I just want to read it, concise and lucid, in text, and then apply it. HOWEVER, when it comes to learning about how to use Blender, the BlenderCookie tutorials are far superior to any textbook. IMO, don't even touch a book, just check out their tutorials.


But I'm only saying this for learning Blender's UI and how to get it to do interesting things (how to make rope/shoe laces, polygonal/subdivision surface modeling, sculpting, rigging/skinning/animation, etc...). Though you could probably learn a lot about how to create art from those tutorials, that's not really what I used them for.


The first thing I ever did in Blender was subdivide the default cube a bunch and started sculpting. I ended up making a troll head, but there was no plan for that. I was just sculpting. I recommend just diving in and making some practice stuff. Don't be too precise and take lots of time (unless things are starting to really turn into something), but instead try to play it quick and loose. Try to move stuff and cram things together so that it looks right. Later on, you'll learn how to do things clean and with more intent. Also, you want to focus on the real "problem" here, getting things to look right. That's what you want to learn.


However, one thing I wish I knew before I started playing with modeling apps was the whole workflow thing. Basically: what is the "big-picture" that you're working towards, where does appX fit in, and will I need an appY, appZ, etc... to finish? I'll explain my workflow with Blender. (Note, people have different workflows, where they do things in their own order and use their own preferred collection of tools)


Say I want to create a high-poly looking character that I can animate and put in a game.

With Blender, I can:

  1. create a base mesh for the character, apparel, extra parts, etc..
  2. sculpt it (high-res)
  3. retopologize it
  4. transfer my high-res detail to the retopo and touch it up
  5. bake maps (normal, ao)
  6. texture it (diffuse)
  7. create a rig for the model (a collection of bones that have various relationships and constraints with one another)
  8. skin the model to the rig
  9. create multiple animations
  10. export the result (I can also create my own export script in python, to target my game engine directly)

So, Blender is pretty much all you need. In reality, I'll sometimes use sculptris or zbrush for 1-2, but I'll usually use xNormal for 5. In steps 1-2, I'm trying to figure out what the character looks like. In steps 3-5, I'm trying to make it look good, but with far fewer polygons. I'm also arranging my polygons in certain ways, in anticipation for animation. In 6, I'm coloring it. In 7-9, I'm animating it. In 10, I'm done and sending it to the engine. Anyways, that's one example of a workflow.


Just for note, Unity 3D can read .blend files. Basically, do steps 1-9. At 9, remove all the intermediate/beginning stuff from the scene that you don't need. Just keep the final work and the animations. Then, drag and drop the file into Unity. This will create a separate copy of the file that unity will keep in the assets folder (if I remember the names correctly). Want to add an animation? double click the file in Unity, Blender launches, then create your new animations. (when I was playing around with it, there were a couple of small bumps here and there, but it was still pretty smooth and quite usable).

#5020977 Game engine or no game engine

Posted by on 13 January 2013 - 12:05 AM

You can take a look at the Doom3 BFG source code to see what an engine looks like. It's very clean code. The book Game Engine Architecture (Gregory) is also a good introduction to the subject. I would also recommend taking a look at some early engines, like Sierra's Adventure Game Interpreter. (Don't forget to check out the spec!)


"Engine" can be a blurry term, but take a look at what Sierra did. They defined a sort of "machine abstraction" that took as input resources (logic, pictures, sounds) and produced as output an "interactive graphic adventure". The engine is then kinda like the stuff between the input and output.


I don't think you need to make an engine to have a good understanding of how it works, especially if it has a well defined architecture (because then it looks kinda straight-forward, a machine or service provider with various components that do particular tasks). What you would probably end up with is a deeper understanding of how various platforms work, how compilers work, how your language manages memory, how data is accessed and transported, how to better architect libraries, how to deal with floating point calculations robustly, etc... kinda nuts and bolts stuff. 

#5018346 No knowledge of any programming language

Posted by on 06 January 2013 - 05:07 PM

Note, I'm joking a little in this post and kinda having fun with it, so take what ever you think is valuable and leave the rest. biggrin.png



I'll assume you're running a Windows machine, just because I'm running Win7 and it will let me talk freely.


Now do what I say:

  • Decide to learn C and C++. Why? Because.
  • Install VirtualBox and Ubuntu on a VirtualBox virtual machine. Why? Multi-platform shenanigans  Terminal love-affair. Easy access to tons of great tools. Ubuntu is a great Linux starting point. The virtual machine is self-contained, so feel free to break stuff.
  • Login to the Ubuntu machine. At your Ubuntu desktop, press CTRL+ALT+t to open a new terminal. (Note, the terminal opens up in your home directory.)
  • Install vim on Ubuntu. Why? Because this will be your text editor from now on.
  • $ sudo apt-get install vim   (the $ symbolizes the terminal prompt. don't type $)
  • Install git on Ubuntu and Windows. Why? Because this will be your version control system from now on.
  • $ sudo apt-get install git
  • Install gcc, g++, and make on Ubuntu. Why? These are the guys that will take the code you write in c/c++ files and turn it into a file containing machine instructions (an executable).
  • $ sudo apt-get install gcc g++ make

Now, write a hello program:

  • $ mkdir -p code/hello
  • $ cd code/hello
  • $ vim hello.c (In vim, push 'i' to enter "insert mode" and start typing regularly. Push <esc> a bunch of times to return to "edit mode", the mode vim starts up in. In edit mode press ':wq' to write the file and quit.)

Make your hello.c text file look like the following, then save and exit.


#include <stdio.h>
#include <stdlib.h>

int main(void) {
    return EXIT_SUCCESS;

Now, compile+link and run your new program:

  • $ gcc -o ola hello.c
  • $ ./ola

Just for kicks, do it again:

  • $ gcc -o salut hello.c
  • $ ./salut
  • $ ls
  • (ls should list three files, your code and the two executables you just made. Lets delete the executables.)
  • $ rm ola salut
  • $ ls

Wonder what else you can do with commands like gcc or ls?

  • $ man ls
  • $ man vim
  • $ man git
  • $ man gcc
  • $ man make
  • Now start googling stuff.

Note, you can code like this in Windows, too. (After installing Visual Studio C++ and setting the appropriate environment variables.)

  • bash -> powershell
  • gcc/g++ -> cl.exe
  • make -> nmake
  • vim -> vim
  • git -> git
  • and see gnuwin32