FreeBasic uncommon knowledge
By Kiyote Wolf
things you think you know, but you really don’t
1.Using your own patterns of behavior for your benefit.
You use the forum, posting here and there. If you use a unique signature with everything you post in the FreeBasic forum, you can search the forum by your unique signature, and find everything that you’ve ever posted under, as long as you are consistant.
FREEBASIC FORUM SEARCH [_____~Kiyote!__]
Answer:
Search found 536 matches
2.Finding programmers and pixel artists willing to help you is great.
But, like many things on the internet, the cake is a lie.
Asking for help on a game project? Asking for a pixel artist? Well, you might as well have never even asked. Getting people on board, for the long haul, is one near impossible, and two, as reliable as asking a bee to act like a fly.
Your “help” is still surely going to sting you.
People always have good intentions, and people always have a burning desire to make that video game.
The thing is, people are procrastinators. You are going to have to deal with this, plan for this, expect this, and to avoid it altogether, do all your own art and all your own programming. About the only reliable way, to get art, is to pay someone to do it. People always do stuff on time and for sure, if they get money for it.
Programming help? Forget it. Just figure it out on your own. You are probably not going to find someone with the same mindset as you, programming styles are not going to mesh, you are going to find yourself with a partially finished abandoned project. Say no to help with programming.
Do ALL the programming yourself. You can divy out art jobs to people you can hire, freelance, I do $25.00 down, $5.00 an hour, first hour guaranteed. That way, someone works on a project in the art department, takes 60 min or less, they automatically get $30.00. It’s worked like a charm so far.
Another great solution, is to encourage your help “TO BE THAT PROCRASTINATOR THEY WANNA BE.” Like a bizzare mantra, you can actually encourage them to be more productive, if you relax the standards even more for them. Don’t ask me how it works, but from experience, so far it has worked.
3.Find the cheapest way of doing business.
Alot of game development, means pouring over alot of things, and all sorts of things.
This means, usually, lots of printing. My personal preference, a lazer printer. Now, a B/W printer, don’t get the cheapest B/W lazer printer. They are missing a fundamental self-cleaning feature, and when I went to print out a 300 page magazine, it stopped me 3 times, and asked me to clean a printing wire in the cartridge. You are going to have to start out with a higher end lazer printer, because the el cheap printers, even the lazer ones, are junk.
Why choose lazer.. they have excellent resolution. You can draw up tiny graph paper you can use for pixel art drawing, and it won’t bleed or run when you use markers.
Another really good money saver, is getting an old dot matrix printer, you can order a new ribbon for it from any office supply house usually, and print on tractor feed paper.
Another bonus of that is, you can get tractor feed carbonless duplicate paper to print on too. You can have an exact copy to mark up & doodle all over, making pretty pictures, while you keep a pristine original to store away for later.
Another cheap way to print, is to use the lazer B/W printer to do lineart, then shove the same piece of paper in an inkjet printer to print the color on it. You can draw out large black areas, then re-print the color over it. Don’t ask me how to remove the black from the image before printing, I forget as of this moment.
4.Make your program for the non-programming sector of your audience.
If you’re making a utility program, make it in the form of a ‘WIZARD’ program.
Make your program do something, but do it intelligently. Assume the user is going to give you bogus data. If you are on a platform with lots of sharing rules and privacy settings, use the %TEMP% folder on your target platform system, as your sandbox. Any flavor of Windows will give your program almost all the permissions it wants, even creating files, if you set your program to work there.
You can even run into permissions issues when trying to install your product to the C:\PROGRAM FILES folder. My recommendation is to install to the %TEMP% directory and be done with it. It’s a good hiding place. Tons of malware can’t be wrong. * cue laughter. *
Make your program uninstallable. Nothing irks a user more than the illusion that it can’t get rid of your program. Even if the user is pleasantly surprised and very happy with your program, make sure to include some form of unloading itself from the user’s sight. Even if it’s just a dummy program which gives the illusion of uninstalling, say your user won’t mind a few KB lying around doing nothing, just give the user a sense that the program is gone and will stay gone.
You can use a windows registry key to mark to your program, saying, hey, I got uninstalled, I guess I shouldn’t run even though I’m being called again. This is an extreme case, but still, something to consider.
5.Don’t be afraid to lock in your expected peripherals.
If you develop a game based around a very specific controller, say a fancy flight stick with a twistable handle for extra Z axis control, then lock the code into expecting it to be there, as programmed.
If you distribute your game as an open source project, where any user can compile it, then let your audience do the work for you. Just get the xxxx thing done, and write it already. Don’t waste time making it able to adapt to all sorts of game controllers.
Programs for dummies is just an excuse to delay and slow down your programming. Unless you are writing a wizard program, designed to have stupid users bash it around, then just write it for the purpose intended, and the hardware you have lying around.
You are not going to be able to account for every eventuality, like the fact you might be writing for an analog pad, and your user only has a directional pad. If they really wanna make it work, they’ll buy the correct hardware, and you won’t have to do anything to fix that, they will for you.
You can lock in your hardware by showing a visual map of the hardware the program expects, and ask the user to enter a correct sequence of button presses and motions. If the user fails entering the proper sequence of buttons, you can almost bet, they don’t have the exact same hardware you dev’ed the program with. Once they fail the test, then move on to the hardware for dummies adapting code.
6.FreeBasic will teach you C, but subtly and very sneakilly. [warning : may be a tiny bit inconsistent]
#include is from C, the expression “ -> “ is from C, which is called “de-referencing”, there are more but hard to explain.
I was looking in the ANSI C manual, which just came out, on the 2nd edition, since 1978.
I noticed something. FUNCTION’s and SUB’s in C, or at least ANSI C, are written the same way in the body of the code, but referenced in a weird way, rather you write them, and they look confusing.
VOID Butterflies { code here }
If I’m not mistaken, please forgive if I’m wrong, that is a SUB.
INT Butterflies { code here }
That, was a FUNCTION.
That void means, it doesn’t return a value. Well, what does that? FUNCTION’s always return a value. A SUB does not.
The INT means, the block of code will return an integer value.
[This is a guesstimation, based on what I read. I may or may not be totally correct or not.]
This has merit in FB, because people are always porting C and C++ over to FB. Files in C are *.C, and files in C++ are *.CPP.
7.Calculating bytes, kilobytes, megabytes even gigabytes.
Anyone working with a significant amount of data will appreciate it when you count exactly how much data you have, relating it to the user in a fashion they can grasp.
Like measuring in feet yards and inches, we programmers have our units of measurement too. KB, MB and GB. They are mathmatically as thus.
- 2^10 = kilobytes
- 2^20 = megabytes
- 2^30 = gigabytes
You divide the number of bytes you have by those numbers, and you can have the count in larger units.
It seems too simple, and don’t seem exactly right, but it is indeed correct and accurate, the exact number for bytes to larger units. I always have to re-look this up, whenever I go a few days. I forget that it’s actually right.
8.When posting in the forum, don’t apologize, and post with confidence.
Unless you do something really stupid, or insulting to someone, don’t try to be overly cushy. Post like you mean it, and also, be serious about what you’re talking or asking about.
Get to the point, and don’t try to assume you’re talking to a deaf audience. Assume there is someone out there who already knows the answer to your problem. There are a bunch of brilliant programmers in the FreeBasic forum. Treat them simply, and you always get a good response. Nobody likes drama or messy posts, in any forum. Also, anything that seems to be coming from a n00b, assume there is a language barrier. Alot of confusion comes from people who can’t put into words exactly what they want to say, but that doesn’t mean they’re not intelligent. You might be talking to someone who simply has a barrier understanding.
9.You can see if your code is working in a *.BI or *.BAS which is to be #INCLUDE’ed in your program, simply by compiling them to run.
If you compile your #include file, unless there is some odd reason it won’t compile, there are reasons, you’ll be able to check for errors in your supplimentary programs.
Another thing to know about, is when you have IF/END IF, DO/LOOP, WHILE/WEND loops which don’t complete themselves, you will get very odd errors. If your loops do not complete themselves, you can find errors pop up in the weirdest places. If you have problems keeping track of the beginnings and endings of the code functionality loops, mark them with unique identifiers in REM statements. If you have many overlapping loops, you might end up with over 12 layers of loops, some inside others, some around huge groups of them. When you fail to end a loop, the errors will pop up from the compiler, and you might get the errors in the right place, but more often than not, until you close the end of it, you’ll get errors all over the place.
10.Writing for an audience can really clarify your programming technique.
If you sit and isolate a functional piece of machinery you built, or simply an adaptation of something existing, which is robust and useful, you will not only one back up a piece of code you find valuable, two you will clarify what it is exactly what you did that was so useful.
When you do a release package for a programming technique, a modification or adaptation of something, you have to isolate what your code does, as well as just enough to make it work. You have to cut and trim the fat of the program, if you’re going to tailor it for show and tell, but you still have to provide it a functioning sandbox, for it to do something useful. When you give a program, a complete program in it’s entirety, and it’s the bare minimum, just what you need to get the job done, then you will clearly get the message across.
Then, when you leave, off to new projects, if you leave these little pearls of wisdom, these gems you can pick up again and again and inspect, even if you lose all your source code, due to a massive storage failure, and a healthy lack of proper backing up techniques, you can still recover what you lost, if you’ve documented enough of your toolset. If you diversify your code, put it in a forum, put regular backups in NAS storage, burn CDR’s of your stuff once a month, you will never face the horrible realization that all your work is gone.
One time out of pure stupidity, I deleted my entire hard drive, from my first DOS based Win 3.11 computer, with all my programming. Thanks to the power of UNDELETE, and some error correction, I recovered an entire directory, of all my work.
You can set yourself up for failure, if you don’t factor in the human factor in programming. Everyone can get emotional, and destroy their own good work. If you share, and do it clearly and neatly, you can preserve your knowledge, in the face of accident, or otherwise. Writing articles for an e-zine, like B2B, is another place where such clarity is both required, and expected, but not something you have to do. For the sake of readers and yourself, clean up your code before you share it. Don’t publish dirty code.
~Kiyote!