Tutorials | 3dkingdoms.com
Here is where I'm putting some thoughts on programming. This isn't a tutorial
of any kind. There is chance you might learn something useful, albeit a small
one. If you're not a programmer, or interested in computers, I suggest watching
ice melt as an exciting alternative to reading this page.
I may be wrong sometimes, but I think there are no unbreakable general rules for programming, so I can't really be wrong =). Just do whatever works for you or works for your current project. Different people will always have different opinions on what's easier to understand, or easier to maintain.
Why I like programming: It's the act of creation and problem solving. You're in complete control of your program, you set the rules and it plays by them every time it's run. Of course there's odd behavior, but 99% I find it's from a correctable bug in my programming, so even solving these frustrating 'mysteries' can be interesting. You need a computer and a compiler, but once you have that you can do anything any other programmer can, so it's reasonable as an individual pursuit/hobby, or as team or career work.
A Rule? If there's one thing I find to be always good, it's to have code that performs a certain function in only one place. Dependencies between different functions can be very annoying. It makes changes much easier if you only have to edit one function to make a change. I still do find myself giving in to the urge of just using copy and paste then changing a few things because it seems slightly quicker now. (It indeed might be quicker if I decide later I don't need the new change.) This rule goes for constants as well as functions. If you decide to use the same constant in different places, make a define like MAX_ARTICLES, this way you only have to change the value in one place.
Reusability is good, but only if you use it. Making code reusable will be a waste of time if you're not going to reuse it for anything. Although you're not always sure what code you might want to reuse. I usually consider reusability issues only if I already can think of how/where to reuse the code. An example of reusable classes that have saved me a lot of time is the Asset Manager/Chooser classes in 3D Kingdoms Creator. Individual assets fulfill an abstract base class (functions like Load, Display, etc..) then everything for managing directories of these assets, and choosing any of these assets to add to scenes etc. is taken care of by the framework. An example of reusability of code between programs is that my Othello Program and Chess Program both support TCP/IP for multiplayer games among humans. Luckily I had made the network code reusable, and I was able to convert it to work with a new game and program in less than a day. If I decide to add network support to my checkers program, I could probably use the same code to do it in less than a day.
C versus C++: I now like C++ better than C for large projects. I used mainly C for a long time, but gradually switched to C++. (When I started programming I used Basica.) One thing I like about C++ is having the option to use the standard template library containers (STL). I don't use STL for everything, but it's nice for not having to worry about set size restrictions, and makes many things a little easier in general, although I always get the feeling that it could be even better, and thus feel a bit dissapointed with it. Object-Oriented programming is another aspect of C++ that I use and prefer to C (there really is a difference between huge projects and smaller projects, and OO does seem to benefit larger projects.) Again though OO doesn't guarantee good code and C is perfectly workable. So in short I fully recommend using STL and OO programming, even though I don't find either to be essential improvements some might.
Bugs: Anytime I encounter a bug using one of my programs I immediately try to reproduce it, and if I can, then correct it in the code. A reported bug that can't be reproduced is almost impossible to fix, although I can usually quickly correct bugs that I can reproduce every time. I also try to make sure I understand the exact reason for the bug instead of flailing around until it disappears, so that I can be sure it's completely corrected and be more likely to avoid creating similar bugs in the future. Learning to use your compiler's debugger is useful, they do help a lot, although so does adding your own logging code and knowing other debugging techniques. It's also a good idea to test on multiple computers, you'll never come close to every possible configuration, but you can at least use more than one.
With user interface, you can't win, especially if there's more than one user for your program, as there usually is. For instance, it seems like adding more options (features/customizability) would be a good thing to do, so users can set up the program how they want. However, it's possible options could accidentally or purposely be altered by a user, leading to frustration trying to unset them, or figuring out why things are suddenly working differently than before. Another problem is that with too many options it can be hard to find the ones you really want... but different people want different options. A separate more specific question is whether or not to allow a user to click on menu item or button that can't produce meaningful results with the current state of the program/open file. You might not want to set the user up for a fall by leaving options clickable, only to popup an error message when its clicked. However it could lead to frustration and confusion trying to figure out why they're grayed out, when an error message could tell him exactly why. (Perhaps the best solution here is a grayed out button with a popup on mouse over that explains why it's disabled.)
Lines of code written per day is almost entirely unrelated with productivity. I mention this because on a few occasions I've seen/heard people correlate the two. Some days that I consider very productive I actually have fewer lines of code than when I started, but the code is more elegant, easier to maintain, and does the same thing or sometimes more or sometimes faster. There is some dependency on the type of program being coded though. For instance if you're trying to write the strongest possible chess engine, then lines of code written in a day has absolutely no correlation with that day's progress. I actually can't think of any examples with a strong correlation, but there is often some minor relation for other types of programs.
Prefix notation on variables is unimportant, but nowadays
I usually prefer it to nothing. There are advantages and disadvantages to using
notation. The main thing is that it is good to name variables as clearly as
possible whether or not you use any special notation. In my own code some prefixes
I (sometimes) use are p=pointer, m_=member of a class, g_=global, n=number,
M=matrix, v=vector3d, f=float, etc.. so a code line of mine might look like:
m_pvRenderVerts[ nVert ] = MObjToWorld * m_pvMeshVerts[ nVert ];
Programming assembly language, for me, is no longer important. The main reason for this is that current compilers are pretty good at optimizing code. Another reason is that it seems more productive to me to spend time adding functionality than trying to squeeze a few percentage points increase in overall program speed. I do feel however, that having some knowledge of assembly language (and how compilers translate C code to assembly) sometimes lets me write more efficient C code, so I don't feel like my assembly programming was a complete waste. I used to use assembly, but I'm no longer any good at it. I remember writing a software texture mapper in assembly and getting a 300% increase in speed over my C code to do the same thing (This was on the then brand new Pentium 60mhz.) Now, this would be done on a GPU anyway, and if not (only a guess) my C and assembly would run at about the same speed.
Include version numbers & chunks in save files for backwards compatibility. This way you can change the file format of a single chunk at any time. For instance if you want to add a few variables to the "light" chunk, you can increment the version number in the save light function, and check in the load light function if the version read is >= this version, and if so, read in the extra vars, so now you can load both the old and new versions. To convert scenes from old to new you can just load and save.
When programming, everything takes twice as long as you think it will. Occasionally something is completed early, but this just means that the next thing will take three times as long. Also, nothing ever compiles without errors and runs correctly the first time. And once it is running correctly it usually needs to be changed at a later date. Frustrating bugs from silly mistakes will take many minutes or hours to locate and fix. So therefore nobody considers themselves a great programmer. Whatever you've accomplished, it could always be done better.
Writing a full-fledged programming tutorial is surprisingly hard work. (This page however wasn't too hard.) There's not just the writing, there's also checking it over to make sure it says what you want to clearly, isn't accidentally misleading (because of typos, or wrong thinking.) Also the double checking tomake sure you understand the subject. Then there's creating the images you want to illustrate your tutorial with, to do a decent job on this takes a while too. Even after all this, years later you'll probably find some grammatical errors, and that you've misspelled gouraud =), and not everything you've written is clear or describes the best way to do something. I think as long as you've put in reasonable effort, and you have experience with the subject, it will be useful despite not being perfect. I now understand why some people leave pages unfinished for years, or forever.
When I started this website, I had 1 email address for both website and private
email. I didn't use this address to sign up for any mailing lists, or fill in
forms on random websites, just on my website and to email friends. For 1.5 years
I received very little spam (unsolicted email advertising.) I had my email address
on every page, and I started hearing other webmasters complain about email spam,
but to me it seemed like an exaggerated problem. Then I started getting 1 or
2 a day. Once it starts to build up it can cascade into an unmanageably amount
over the course of a couple years. When I finally decided to get rid of my jkreuzer
email address it was receiving about 100 spam emails a day. Spam Assassin running
on the server filtered out maybe 65% of these hundred.
Here's a rundown of the types of SPAM email I received, if you've received a lot of spam yourself, you'll recognize these categories:
~30% stock market "news|etters" recommending a certain stock.
~21% cheap drugs / online pharmacy / Vi grA
~18% mortgage / loans
~14% cheap software
~8% h0rny teens / housewives
~2% p3nis enlargement
~1% breast enlargement
I now have 1 email address for this site. 1 for everything else. The one for this site is still on 3 or 4 pages (unscrambled), so if spam builds up again, I may change it again.
Update: It's started to build up again although predictably only for my public email address. Looks like the the old #1 on the list above was mostly a fluke.
Browsers: I mildly prefer Firefox to Internet Explorer. The main plus for me is Firefox's tab-based browsing capabilities, but there are other reasons I like it too (useful plugins, should be somewhat safer than IE, its popup blocker has worked better for me, etc...) I have to remember to test my pages in IE though before putting them up, since they don't always display pages in the same way, and IE is the most used browser even if it's less standards compliant.
return to 3dkingdoms.com