#169003 - the-anonymous-coward - Tue Jun 09, 2009 7:58 am
These questions are some that I have just been curious about and may not be of any help to others. If they seem helpful for beginners in my shoes, then perhaps they can be included in the Q&A section.
Questions:
I. When learning C++ in college, we were never introduced to a specific compiler (basically just whatever we wanted to use) or things that seem important to me but IDEs take care of for most tasks nowadays. So, when learning about things like writing makefiles, using a compiler with arguments from the command line, or adding proper files to certain parts of your IDE so that you don't have to write a makefile, did you learn that from class, on your own, did you just read things like gcc's documentation, or did the book you learned from explain them? It seems like, to me, learning the language is easier than learning all the things you need to get your programs working (setting up your environment to be able to use allegro or SDL or openGL etc), unless you let the IDE take care of some stuff for you. Not knowing this stuff before jumping into game programming has really held me back and sapped a lot of my motivation.
II. When learning a library like SLD or Allegro or SFML, do you look first for tutorials or examples or just read the docs?
III. Were you taught to read docs properly so that when you look at them you don't feel overwhelmed to the point where you think you will never discover the proper way to say display a sprite with transparency, or does that just come naturally to everyone but me? I feel like without someone telling me the order to do things, it would take ages to learn home to properly make a game from looking at something like http://alleg.sourceforge.net/stabledocs/en/allegro.html without already knowing what a game is going to need. (Oh, and if anyone has any well documented code they did for demos and the like with allegro or SDL I would love to get my hands on it; I know there is a lot out there, but the more the better)
IV. What is the order of learning that led you to GBA/DS development (example: I learned C/C++ the decided to learn allegro, then had to learn about makefiles and compiler arguments before I could continue bah blah blah)?
V. EDITED OUT-I know where to find this. I was tired and on sleeping pills when I originally wrote this. Problems sleeping sometime.
Last edited by the-anonymous-coward on Wed Jun 10, 2009 4:47 pm; edited 1 time in total
#169010 - gauauu - Tue Jun 09, 2009 3:12 pm
As my usual disclaimer, there are people way smarter than me here, so take my answers with a grain of salt:
| the-anonymous-coward wrote: |
Questions:
I. .... did you learn that from class, on your own, did you just read things like gcc's documentation, or did the book you learned from explain them? |
Generally, it's a gradual thing. You pick up some basics from a class or from a book or a tutorial. Once you realize the basics, picking up more is easier by reading man pages or online manuals, other references, etc. My advice: don't be intimidated. Learn just as much as you need to accomplish what you want to do. And learn how to lookup commands or parameters that you don't understand.
| Quote: |
II. When learning a library like SLD or Allegro or SFML, do you look first for tutorials or examples or just read the docs?
|
If there's a good tutorial or book available (like SDL and Allegro have), then the books and tutorials can be really useful to help you know where to start. My route is usually to read a tutorial if available so I understand the very basics, then use the docs to fill in the gaps.
| Quote: |
III. Were you taught to read docs properly so that when you look at them you don't feel overwhelmed to the point where you think you will never discover the proper way to say display a sprite with transparency, or does that just come naturally to everyone but me? |
No, not taught. But skill comes with time and experience. Like I said before, the tutorials will help you get an idea of where to start. Once you have some basics down, then you need to rely on the docs.
(That being said, some things don't have tutorials, only docs. In that case, there's often a lot of pain involved).
| Quote: |
| (Oh, and if anyone has any well documented code they did for demos and the like with allegro or SDL I would love to get my hands on it; |
I found the book "Focus on SDL" to be helpful. You can get it fairly cheaply at a used price on amazon.
| Quote: |
| IV. What is the order of learning that led you to GBA/DS development (example: I learned C/C++ the decided to learn allegro, then had to learn about makefiles and compiler arguments before I could continue bah blah blah)? |
I had done a lot of programming in various languages. I knew a little about GCC and makefiles, but not much. I started looking into homebrew development for various consoles -- When I discovered how well documented GBA programming was (and how easy it was), I was so excited (Using TONC and other tutorials had enough information to get me started, and I picked up additional knowledge along the way.
| Quote: |
| V. Using multiple source files excites me and scares me. Anyone know a good, very clear tutorial on doing that? |
Be excited -- it's the only practical way to get anything done. Sorry, I don't know of a good tutorial.
Overall -- don't be scared off. Work through a tutorial like TONC, and don't worry about all the compiler options or makefile bits that you don't understand. Learn them gradually as the need arises, and you won't get as frustrated and stuck.
#169013 - the-anonymous-coward - Tue Jun 09, 2009 6:02 pm
Thanks for the detailed response. Gives me some motivation, as it seems like I am heading in the right direction. The best thing is to see that the route I am taking is not unusual. So, I really appreciate your reply. Of course, I still would not mind to see other's answers, as it is just interesting to me (feel free not to answer ever question if you don't feel the need).
I feel like the difference between me and most other members of the forum is my inconstancy. I am very busy (in a band that is recording an EP right now (in different sessions, due to the fact that we are funding it), I'm a college student, behind on math so have to study that on my own, I also write, etc.) so game programming is forced to be a sporadic hobby with me. I may only get to work on it once a month, which leads to a lot of refreshing each time I start.
Anyway, I have been interested in GB programming since I was 12 and I am now 23. Lol, I don't know if I should have admitted that, seeing as how there are people who have been doing this a few weeks and are more advanced than me.
I will always have a love for the derivative consoles of the original GB. I know it's trite but I have always loved RPGs. It has always been about story to me (primary of course, the other aspects are very important). So, my biggest goal is just to program an RPG demo (perhaps a short story) with the somewhat original battle system I have in mind. I know that this is a ton of work, and that's why it is my final goal. Hopefully one day it will see light.
So, that is a little about me.
#169018 - the-anonymous-coward - Tue Jun 09, 2009 6:52 pm
Oh, and how relevant would you consider Focus on SDL? Are the libraries and functions used still pretty much the same?
#169019 - sajiimori - Tue Jun 09, 2009 6:54 pm
I. I learned the basics of makefiles via internet tutorials. I also found it somewhat discouraging when I'd have to spend a long time learning something that seemed auxiliary to programming, like makefiles or the subtleties of a linker command line. After some years in the industry, that hasn't changed -- I still have to learn that stuff every time I work with a new toolchain, and it's still boring. At least I can learn it faster now.
That said, it's definitely better to bite the bullet and learn those things well; trying to avoid them always led to more frustration for me.
II. I always start with the official docs and examples. If those aren't sufficient, I start reading the source (if it's available) and looking for real world examples.
III. Nobody taught me how to read documentation. If reading it doesn't help me create working demonstrations of basic API functionality, then I look for examples (again, starting with official ones), but I still refer back to the docs to understand what I'm reading.
But! API documentation will never tell you how to properly make a game. In my experience, nothing will tell you that, at least not directly. You just have to try, and fail, and try again. It also helps to experiment with some existing engines, to get ideas, and to get a sense of how widely varied they are -- there's no silver bullet.
IV. I went in this order (leaving out lots of stuff): BASIC, C, x86 assembly, Lisp, C++, GBA, DS.
What you don't see there is how long it took me to really get the hang of programming -- it was very, very slow. I was essentially stalled at BASIC for 10 years. I'd get stuck and come back to the problem a month later. But all that thinking about programming somehow led to me being rather good at it, eventually.
Edit: I mentioned Lisp because I feel like it was a major prerequisite for my current level of understanding. I'm glad I learned it before C++.
#169020 - the-anonymous-coward - Tue Jun 09, 2009 7:12 pm
Thanks! I am actually interested in Lisp. I have learned a little, but don't know much. I basically want to learn it as a mental exercise. I am very excited about clojure, the only lisp that is written specifically for the JVM instead of ported. I am not a fan of Java and clojure seems a great alternative. It is also said to run in most cases as fast as Java. The JVM, in my opinion, is brilliant; Java, not so much.
#169021 - gauauu - Tue Jun 09, 2009 7:31 pm
| the-anonymous-coward wrote: |
| Oh, and how relevant would you consider Focus on SDL? Are the libraries and functions used still pretty much the same? |
Relevant for SDL programming? It was relevant a few years back, and I'd guess things haven't changed much since then (I haven't touched SDL in awhile).
Relevant for GBA programming? Not at all.
#169026 - the-anonymous-coward - Tue Jun 09, 2009 8:33 pm
Sorry, should have been clearer. Yep, I meant SDL programming. I didn't know how much the api had changed since 2002.
Okay, my current plan is to make my demo first using SDL, setting the screen to the resolution of the NDS (doubled in size through SDL if that's possible) and the color depth to 16-bit (I think that's right; may have to change that if I read otherwise). I want to make sure I use a palette and tiles size that will be easily ported to the NDS. Do you guys recommend th single 256 color palette or the 16X8 palette for an RPG demo? Also, I think my tiles sizes will be either 16x16 or 32x32. I am decent at pixel art. This is likely to be the main character.
[Images not permitted - Click here to view it]
#169031 - Drovor - Wed Jun 10, 2009 6:31 am
I. My college and I think a lot of others treat things like Makefiles, compilers, IDE's, libraries / API's, OS specifics and other abstractions as something separate than the curriculum. They are certainly important to creating a program, but using them doesn't count as "computer science". I am like you, learning the a programming language is easy compared to setup tasks like getting the compiler and linker to pull in the proper libraries and setup the Makefile (fortunately we have google and these types of problems are often documented very well)
II. I don't know what those libraries are, but in general example code is how I learn fastest. Once I know the basics I can then move into the doc's and understand the details. This has been especially true for me with NDS programming, the gbatek documents are, for the most part, far too detailed for me to jump into without first tinkering with example programs. The doxygen docs for libnds are good for me as a reference type documentation.
III. No teaching of how to use documents for me. I often feel lost trying to read a manfile that doesn't have an "example usage" section.
IV. I learned all the basics of C/C++/Java in school, during that time I picked up enough to be dangerous with Makefiles, compilers and linkers. I picked up the basics of 3D programming from NeHe tutorials and eventually found devkitPro + libnds and decided to make a PONG game. That turned out to be easy for me and I kept going with something more interesting. I also briefly used functional languages like lisp and prolog, they may have built some character but its hard to say how much..
V. I use C++ for most of my work, so multiple files come naturally (i.e. the 1 header file and 1 implementation file per class convention)
#169760 - Karatorian - Sun Aug 02, 2009 9:59 am
Learning Makefiles Etc.
Well, don't quite remember the details of when I learned to write makefiles, so I can't be sure exactly how I went about picking them up. I do remember a few things about it though. Firstly, I had already picked up the basics of gcc's command line options and was able to knock my way around shell scripting (if not exactly fluent), so the basics of make I grasped pretty quickly.
I do recall quite vividly the day I first ran into the fact that make requires tabs, not spaces. I though I was going crazy as because, from a visual inspection, my code looked identical to any example I could dig up.
I also recall that I didn't quite get make at first. Sure, I knew how to get make to build my code and even rebuild it if it changed, but getting beyond that took some getting used to. At first I my dependancy checking was often buggy and I'd just "make clean" and rebuild if I suspected something was flawed. I also didn't quite get the idea of only rebuilding the required bits. Once I groked the philosophy behind make, we became friends.
During my younger years, there was a period where I would attempt to learn just about any programming language I came across. (Perl, Java, Javascript, C, x86, Scheme, Forth, and Python are just the ones I sank a lot of time into.) I picked up make as just another language during those years.
Learning Libraries
Usually the first thing I do with a new library is look for a well writting tutorial that helps to explain the "feel" of the api and provides solid code examples. Generally the I test the sample code to make sure I've got everything set up properly. Then I try to write my own stuff using the bits of the API covered in the tutorials.
Usually, I rely on API docs (if they're any good, some are aweful) more than tutorials once I get the basics. Lately, I've found myself more inclinded to just jump straight in with the docs if they're decent and skip tutorials unless there's an offical one or I get stuck. (Maybe after twenty years I've finally got the hang of things.)
I've also had to dig into the source code on more than one occasion to figure things out. (Sometimes it's the easiest way.) If the docs are vauge or non-existant, or some docs conflict one another, going to the source will straighten it out. (Provided you can get sources, of course, and the level of black magic involved is within your skillset.)
Reading Docs
Well, I'm self taught, so I wasn't taught to read docs, but I did get a grasp of how to go about it over time. Generally, when I'm reading the docs, I'm looking for specific information on how to do something or jog my memory if I forgot.
If you're looking for something specific and the docs are well organized, you can ignore large chunks of stuff you don't care about at the moment. Of course, this can bite you if you're ignoring something important, but once you've got the basics down, you can usually disregard a lot of stuff that's not relevant to what you're doing.
However, if I use something alot, I sometimes geek out and read some massive tech doc front to back. Generally I only do this for stuff I use frequently, or need use a bunch for my current project, but don't know by heart.
Learning GBA
Funny as it may sound, my method of learning the GBA was to basically ask "What can it do above and beyond the NES?" The NES was the first embedded system I ever learned, 6502 is the only assembler I'm any good at, and at the time, was one of the only two systems I'd ever programmed on the bare metal (the other being the PC).
So, a lot of my early GBA learning was comparing it to the NES. Despite the vast improvement in power, the systems are actually quite similar (tile and sprite based, etc). So it basically consisted of learning the details of the differences and what new things one could accomplish. That I picked up from the Tonc and Pern tutorials and reading GBAtek over and over again. Various other tutorials and tech docs helped as well.
Then I had to give myself a C refresher. My my C isn't bad, but it's not great either, and rusty as all get out. Basically, once I discoverd Python (my current language of choice), I only used C if I needed to. I did briefly look into ARM assmbly language and I must say I really like the ISA, but I never bothered to really learn it. Even today, the hard parts of getting things to work on the GBA (for me) are likely to be my rusty old C skills, rather than the platform itself, which is a dream to code for.
As for how l learned the NES in the first place, well that's an interesting story. While I've always been interested in games since I started to learn to program, I never really got into console coding until a couple of years ago. Which is funny, because I do almost all my gaming on consoles or emulators.
But then I got invloved with romhacking NES games. I'm old enough to remember when the NES was state of the art, so it was mostly a nostagia kick at first. In the end, I eventually learned 6502 assembler, NES gpu hardware, the joys of bank switching, and a million other things I was never really interested in before.
I actually specifically bought my GBA to dev for it. Which is silly because I've yet to buy a link cable or flash card. I had heard it was fairly homebrew friendly (i.e. not packed to the gills with crypto) and was interested. As I tend to jump from one terminally incomplete project to another, shortly after I got it, I moved on. (I have since aquired a handful of old school games for it. Good stuff.)
Lately I'm back at it and I'll probably stick it out for now. As much as the flexibility and power of the PC is wonderful, I'm kinda sick of it at the moment. The limited resources, dedicated hardware, and other features of the system make it a nice change of pace.
![[Images not permitted - Click here to view it]](http://farm4.static.flickr.com/3362/3526833463_d2c6788ce5_o.gif){kind=link}