Is it just me or are there no solid tutorials?
BlitzMax Forums/BlitzMax Beginners Area/Is it just me or are there no solid tutorials?
| ||
| I'm a BlitzMax beginner (mostly a beginner to programming in general) but every tutorial I've seen for the Bmax beginner doesn't help much. The BMax manual is a mess, and the tutorials on this forum are often filled with hungarian notation, magic numbers, and brief examples. They're frustrating to read and understand, or just lacking in information. Maybe it's just me. I don't know. Programming examples on the web tend to be horrible as it stands, and now I'm into BlitzMax I'm finding things to be the same. My next step is to just ask lots and lots of questions, but I thought I'd ask if anyone knew of any solid tutorials (not the ones on this forum- I've seen those) which exist for Max and provide a good foundation. |
| ||
| Hungarian notation? Blitzmax probably isn't for the absolute beginner, I'm not saying you can't learn it, its just another language might be better for learning the main aspects of programming. I asked questions when I first started blitzmax, there weren't so many tutorials back then. BEFORE you ask anything use google or the search functions here on the forums. P.S. You can do 'site:www.blitzbasic.com <search query>' in google to get only the results that are on this site. |
| ||
| http://en.wikipedia.org/wiki/Hungarian_notation I don't have an issue understanding the language itself (it seems fairly straight forward, although I realise there are advanced things to worry about down the track) but what I'd really like to know are simple things, like what : means in a type. Or is it with variables? I can't tell, and no one explains it. Everyone uses it all over the place as if the beginner is supposed to somehow magically understand what's it's doing. The BlitzMax manual covers what the period does in user defined types, but I can't find a thing on : so working out the syntax of the language has been driving me bonkers. Every now and then I run into bits and pieces that no one seems to cover, other than saying things like, "This is how we create a type." or, "Here we use this function." and I'm left to figure out what it is that's going on. Talk about the whiner I am ;) It's cool that people write tutorials at all, but solid, well-explained examples are as rare as hen's teeth, even if you google all day long. |
| ||
| I agree that there's a lack of concise tutorials explaining the more high-level fundamental concepts, like timing, tile-based movement, basic AI etc - the same old problems people keep bumping up against if you go through the forum's history. However, I feel that the guides available are sufficient to help you get up to speed, but it really depends on what level of past experience you have. Blitz does assume you've had some other programming experience before, hence the colon not being elaborated on since it's such a fundamental part of the language syntax. My first few weeks in Blitz was spent playing with the sample programs provided with it, tweaking a variable here, adding a little there, tackling the notation bits I didn't understand, etc. Between that and using the help functionality built right into the IDE I was able to get things moving nicely. At first I didn't bother too much with why the finer concepts did or didn't work, until I could wrap my head around the basics. I think what you'd like is something more of an absolute beginner's guide to programming in general - have you done some before? (Sorry if that sounds in any way condescending, it's REALLY not supposed to) FYI: When declaring a variable, the colon means "is an". For example: Local x:int - This means variable x "is an" integer. There are shortcut notations too like Local x# or even just Local x (Blitz assumes it's an integer if no type is specified) but don't let it confuse you. I like the :Int notation most of all as personal pref. |
| ||
| Isn't :int required in Superstrict mode anyway? |
| ||
| Sure, but many examples, guides and tutorials don't use SuperStrict. |
| ||
| Rite, and that'd actually bad if you ask me. I think every tutorial and example should be superstrict compliant. If you'd use a strict compliant example while your program is superstrict then you're off for some fixing. *I* could fix those, but let's hope beginners at least understand the whole problem too.. |
| ||
| Thanks! That makes sense :) I'm sure I'll get there eventually... a lot of the language I have managed to come to grips with, and certain things I've picked up quickly having used B3D for a while and because of my 3D art background, but... yes, small things like that have eluded me. And, absolute beginner guides, as good as they can be in places, tend to spend most of their time on things like x, y and z (which I get already) and then breeze over things like types, trying to explain their use by the good ol, "Imagine you have a spaceship, and it has a colour, an x value and a y value... (etc) and now imagine a room full of chairs..." By the end of many beginners guides I'm usually ropeable because many things get missed, or assumed. Maybe in a utopian world somewhere I'll find that perfect guide, but for now I think I'll just ask on the forum, because that answer was exactly what I was after. Thanks again! |
| ||
| Agreed! When I just started out on Bmax, it just frustrated me to see all the different ways people did even the simplest of things - like declaring variables for example. Nowadays I don't touch code without SuperStrict in place, it really does prevent hard-to-track problems further down the line. A beginner's guide is on the cards. |
| ||
| Reactor: problem with all those spaceship examples is that the example itself is high-level while I think a low-level approach is a bit more clear. Esp. as anything high-level has the risk of being subjective when it comes to solutions. When a beginner is confronted with 10 totally different solutions for 1 problem, I can imagine him being completely confused. It's a form of information obfuscation. |
| ||
| I agree about the approach- I didn't enjoy the spaceship/chair examples for the reason you mentioned (correct me if I've misread you here, and you're saying they're a good thing). Okay, I have another question for BlitzMax masters :) What is TImage? Apparently it's a data type (according to a tutorial), but when I look in the manual it's not listed as one. In fact, it's not in the manual index anywhere, so... is it one, and if so, is it in the manual somewhere? |
| ||
| Timage is simply an image. like this: Local MyImage:TImage=LoadImage("c:\booh.png") or Local MyImage:TImage=CreateImage(64,64) ; creates an image of 64x64 pixels |
| ||
| Thanks CS_TBL. I worked that out by looking at examples, but... what does Timage stand for? How did you guys find out what it meant? Did you guess based on what Mark had written? This is why beginners are so unsure a lot of the time :) A beginner's guide is on the cards. Just while I think of it- the kind of thing that'd be helpful to me is a list of Max's functions, methods (etc) and what they do in plain english. Along with that, a brief bit talking about how they could be used in a 'more than hello world' program. There's nothing better (imo) than knowing what you have available, and having a few ideas in mind about how to use them. An idea, anyway... or one for the wiki... when it's actually around ;) |
| ||
| TImage is the image class. How to find out: Right is this funny tree, in there you find the documentation for the stuff. Thats where you will find informations on what they do in developer english (you have to learn the basic vocabulary yourself) Alternative enter local test:timage, go with the cursor over timage and press F1 twice. As for learning BM: Visit assaris great tutorials. |
| ||
| partly just logical thinking. image > timage, bank > tbank, gadget (gui) > tgadget, sound > tsound, event > tevent, timer > ttimer, etc. Many of those sorta commands were already present in the older Blitzes, so this is just legacy knowledge.. :P But afaik this is mentioned in the manual at the relevant sections.. (can't check atm) |
| ||
| Ah, good ol' legacy knowedge! But what does the 't' stand for? :P j/k Thanks Dreamora, but I've been looking in the funny tree already ;) I like assaris' tutorials, but he also skips over many things. Plus his notation, like many others, is filled with one letter variable names and the like. So far the best tutorials I've seen have been those written for Truevision. But, that's mainly to get to grips with the TV api and not BMax. |
| ||
| Nothing wrong with 1-char vars for small loops, like nested x,y(,z) loops. Of course, for permanent storage some more descriptive vars come in handy. Keep in mind however that in many cases you rarely need to remember variable names when working with your own types. Usually you let methods handle the variable stuff and you only need to remember the name of methods. Over time you develop some kinda naming convention for that. |
| ||
| That's true, yes... but it doesn't always help the learning process when you have to remember what someone elses strange naming conventions are... especially when they're one or two letters in length. |
| ||
| B3D or B+ are as close to basic as you'll get, very flat learning curve. However, BlitzMax has alot of OOP, which in itself, is very hard to grasp. But it's worth it, because most good languages today are OOP based. Also, BlitzMax is very flexible, while it's basic counterparts aren't as much. It's so flexible that the own language's source code comes with it. And people (off the top of my head, simon and leadworks) have created full 3d out of it, you can include CPP or C files, resource files, and many more. Additionaly, many third party engines can be/have been wraped by Blitzmax. |
| ||
| i think short vars are good for your own code, but for tuts and examples i think vars should be more discriptive. ex. i put up an example for someone in another post. i used vars like characterX and characterY, instead of what i'd noramally do like cx,cy. although short vars would be ok if they had descriptive remarks after wards. ie. Global cx# 'holds the charactes X position. but again for tuts and examples, i do feel discriptive vars all the way through the could is much better. it makes for easier reading and comprehending(IMHO). i can see where Reactor is comming from. after taking over a year away from programing, its taking a bit to get my head around things i used to under stand fairly well. |
| ||
| I usually find long variables to be obfuscating the general view of my source code. It all comes down to splitting-up code into separate methods/functions, then you can use x,y etc. again in each method/function. |
| ||
| especially: if you every need long descriptive names you perhaps have some problems with usefull modularisation, otherwise you would know that you are within type XY and this can only mean X and not x,y,z,a,b,c The better you class design, the less problems. And the T stands for Type. you better use it because in BM names are unique! this means you can not have variables with names of types with names of methods with names of functions |
| ||
| i do agree with you CS_TBL with personal projects. but as far as looking at tuts and examples ( more importantly the ones targeted for beginners), i find it easier to understand if the vars are descriptive especialy if theres more then a page of code to look through. again were talking about beginners not someone who has a great deal of programing experience. once they've got the basics down, then they can work on a more structured and organized approach. edit: you don't need Global ThisVarIsForTheXPositionOfThePlayer# but instead use Global PlayerX# then later when the person has more understanding, and understands types, the PlayerX# var will migrate to x# within in the type. its about teaching and understanding. code targeted for more advanced things can and should be simplfied to the later. because in most cases the ones to look at those examples will or should have a better grasp at the basics. beginners shouldn't even look at the more advanced topics until they understand the basics, except to maybe peek their curiousty. but in the long run it would just leave them confused and frustrated. |
| ||
| Ok, just an example then: There's a 2d table you need to fill with random values (e.g, a heightfield you want to smooth later on, or just whatever) local table:int[64,64] You're gonna need a nested y,x loop and fill the table with a random value using those x and y variables. What are you gonna use for the for loops? x and y? Or something else? |
| ||
| Well, I can only speak for myself here- I'm personally familiar with Cartesian coordinates so and x and y are locked firmly into my brain. Cz and Cy are not. At this point, what's easier on my brain is reading anything that's as close to english as possible- not reading letters, and then having to translate those into english. I have a lot to remember as a beginner! ;) Do you know how long its taken for me to accept that 'i' is okay in loops? It's a silly letter that is always chosen because of programming tradition, more or less... so when I originally saw 'i', the first thing I thought of wasn't a temporary variable. I'm sure people not used to the Cartesian coords must feel the same way about x, y and z. So, the easier you make things for the beginner, the less our poor little brains have to worry about while trying to learn all the other stuff :) McConnell in Code Complete lays out some good foundations for variable names. If you name them well, your code can often be easy enough to read that other people won't be screaming for comments. I'm sure it also comes down to a personal thing for your own code, but if you're going to share it with others, or try and teach someone with it, the more explanatory you can make it the better. |
| ||
| @ CB_TBL it depends on the targeted level in your example its pretty basic and the use of x and y makes perfect sense to me and probably should to even most people. but when writing an example targeted at beginners you should never assume the reader will know what x and y is, and you should leave a comment above the forloop explaining what x and y is for. yes for more advanced people having comments for the most basics of operations is clutter, but when trying to teach a beginner that clutter imho is a nessicary evil. like i said in the long run i do agree with what you are saying. just not for teaching beginners, as they progress through more advanced tutorials they will understand and copy or form their own better structure and order of things. edit: Reactors post above mine confirms the point i'm trying to get across. |
| ||
| To add to the above- a lot of advanced programmers also forget that variable naming shortcuts aren't common knowledge outside of programmer land. In fact, in different industries (web, print, cg) they often stand for vastly different things. Only today have I learned what 'n' means, which is pretty scary since I've read it in tutorial code before, unexplained. I could take a guess at what it means, but I've seen 'n' stand for many things before. So, it's not always about making things simpler to understand... sometimes it's also about making sure people don't assume something is something that it's not. |
| ||
| Haven't read it all but I think there are some superb tutorials : Beginner's Guide Learning 2D Game Programming With BlitzMax Maxgui Learning Object-Oriented Programming in Blitzmax Moderator Edit: Please use relative URLs when linking to other pages on the Blitz site, so that the correct links are inserted into posts no matter what domain users are accessing the forums from. |
| ||
| I think the tutorials are good and they brought me up to speed on BMax. I am struggling with one thing in BM that I don't understand and it has brought me to a halt. I still haven't found the info I need even though I have searched the forum. |
| ||
| By all means ask, I'd love to know what it is so I can have the answer too :D |
| ||
| I think the tutorials are good and they brought me up to speed on BMax. I am struggling with one thing in BM that I don't understand and it has brought me to a halt. I still haven't found the info I need even though I have searched the forum. Ditto Duffer. Same thing happens to me all the time. Searching these forums is pretty much the primary tool for dealing with that. Learning by example seems to be the mode of operation. I think that more/better/deeper tutorials, a comprehensive manual, wiki, and a big code archive (blitzcoder.com?) would make all the difference. BM seems very community supported and depends very much on the time and expertise of "volunteers". I only hope that I too can contribute somehow someday. I too found "Learning 2D Game Programming with Blitzmax" to be invaluable for learning the basics of BM and OOP (which is really powerful) in the beginning. FWIW, I do this for fun and my experience level is "tinkerer". The price was right, the language is awesome, the community is engaging, and I'm having fun indeed. But a comprehensive user manual would really make this waaaaay easier. -pmc |
| ||
| Thats why some more "professional" users bought HotDocs while it was available to generate the documentation with it. it generates the documenation in a totally different style with per type listings, per function, per module etc. makes it far simpler. This + Blide make BM very easy to learn. But you still have to keep in mind: BM is much larger and complex than Blitz3D for example. You won't be able to learn the functionality in a week or even a month. You will have to dive in and learn it over the time. (learning the possibilities for the functionality is a thing thats pure experience, you will not find any documentation on that in any language) I should mention thought that I was one of those who bought it when it was a Mac only thing with nearly no documentation. most of the stuff you knew about BM was by reading the module sources |
| ||
| The real problem is, BlitzMax is simply not a game development llanguage....out of the box. But for some strange reason alot of peeps new to the langauge assume it is so they get frustrated with it. When I first (I'm still learning) learned BlitzMax it seemed very similar to Visual Basic so the learning curve was non existant, except for graphics calls. What I simply adore about BMax is, programming with it can be as simple or complex as you want. I still get amazed by some of the code around here (so techy) and then I look at my code and it's like I'm working with a different language. But that's what I like about it, there are no rules. ;) |
| ||
| To create a good tutorial and to teach the subject well can be quite an art, and most people are not willing to put in the time and effort. Most people aren't that giving. There are a few good tutorials out there but most people either don't know how to write one or they just throw together some vague sourcecode and call it a tutorial. It would be nice if BRL came up with some official tutorials, but they. |
| ||
| It would be nice if BRL came up with some official tutorials, but they. Wheres the rest!?!? |
| ||
| maybe we we need is a tutorial written by someone going through learning or who has just gone through learning the language, someone who still understand intimately what the beginner is going through. |
| ||
| ImaginaryHuman surely meant something like "but they will most likely not do that". So far they have never hired or payed anyone for doing documentation and tutorials. Most of the stuff present is freely donated by users. |
| ||
| ImaginaryHuman surely meant "but they will most likely not do that". Or "It would be nice if BRL came up with some official tutorials, but hey." |
| ||
| Problem with tutorials....there is no one way to do it, who says the tutorial would be "the" way to do it? What might be better is a few community projects. ;) |
| ||
| I found the asteroids in about an hour example to be incredibly helpful |
| ||
| Project examples aren't usually that helpful (not for me, anyway) simply because the project that's often put forward isn't what I'd like to make. Often, it's not even close. And, that's why I say I'd like to see more details on what each of BlitzMax's commands are, and then some solid examples of how they might be used... instead of just using a few random ones in a project, and leaving everything else unknown. I hope that makes sense. An example might be maps. What are they, and why could they be good to use? It means by the end of the lesson I know what options are available to me, and not, (as an example) "the way bob decided to make his menu using maps". There seems to be a thought (in all programming circles) the best way to teach someone commands is to wrap the lesson in a project. Sometimes I think that's done because it makes the thing more interesting, but when you're just trying to find out how to use an option that's available to you, it can be frustrating working through space invader games and other projects to find your answer. Now I've mentioned this, I have half a mind to make a wiki to hold the info I'm looking for... hmm... |
| ||
| There used to be a wiki for Max, don't know what became of it .. A TMap is a binary tree (or hashtable? I've heard both, but never personally used them or know exactly what they're good for), this should help: http://en.wikipedia.org/wiki/Binary_tree |
| ||
| Thanks Plash... I actually know what a map is (amazingly) after my brother, who's a very tallented programmer, explained it to me :) I might go ahead and put together that wiki... or page... so people can learn how that kind of thing can be used. I'll need strong community help to get it all sorted, but I have feeling it'll be helpful (and not work to replace existing tutorials, but work with them). |
| ||
| I'm sure the community will be quick to answer any questions you might have. A good idea (if your bored) is to just trawl through the code archives to learn new stuff. |
| ||
| There are some super threads on maps and how best to use them. Assari came up with another great post/idea (again!!!) here where people submitted examples for commands and the chm file makes searching for the right command easier. In fact this page does a good job of bringing it all together. |
| ||
| how about instead of a tutorial on how to program, a tutorial on understanding the blitzmax in-app documents? Explaining what their different symbols and stuff are. Then get the reader started with something small, and from there they can simply look up what they need in the document, and actually understand it. |
| ||
| What do you mean by 'in-app documents' and 'different symbols'? |
| ||
| That's pretty much what I'm going to do with the new wiki. It's going to be aimed at people who don't know a thing about programming, and have basic explanations about the syntax and the like. It'll mostly be for me, but I welcome others to check it out and add to it as well :) |
| ||
| @Duffer, I am struggling with one thing in BM that I don't understand and it has brought me to a halt. I still haven't found the info I need even though I have searched the forum. Have you posted about it? |
| ||
| tony I mean the help documents that are IN blitzmax. I frequently bump into roadblocks when trying to figure something out cuz all they do is give you the line of code with the given command, and all the x,y,w,h,int,ID,(),[],global, you name it, then one short sentence that is supposed to make you magically understand it... and with that kind of background the example is usually pretty much worthless. Unless someone wants to rewrite the blitzmax help document there's not much you can do about their ability to explain, but you can at least tell the beginner what x,y,w,h,int,ID,(),[],global and all that means. |
| ||
| If you don't understand what a function is doing open up the module source and see for yourself. Works for me. |
| ||
| and is someone who is new to programming expected to know how to do that? |
| ||
| If you goto the top of a module documentation you should see a link that says 'Source', that will open the modules main source file. |
| ||
| ok thx I didn't know that lol. |
| ||
| That still doesn't really help. There are conventions in many of the source comments that aren't anything I understand. Plus, not everything has the source available to read. |
| ||
| There are conventions in many of the source comments that aren't anything I understand. I was referring to reading the code itself, not the comments. Though it will probably take awhile for you to decipher some of the cryptic stuff people write. Plus, not everything has the source available to read. What exactly do you mean by this? like when the main source imports other code? If thats the issue you can just goto the mod folder and delve through the imported files (ie. 'brl.linkedlist' would be located in 'BlitzMax\mod\brl.mod\linkedlist.mod'). |
| ||
| Though it will probably take awhile for you to decipher some of the cryptic stuff people write. I realise you were talking more about the code than anything else, but yes... it's not easy to decipher. What exactly do you mean by this? Sorry, I thought that a few of the audio functions didn't have a 'Source' link available in the manual, but I can they're under the main audio lisiting. The main issue is- for the beginner, rummaging through code trying to figure things out isn't a good way to learn. It's a way to come to a deeper understanding, sure... but there's that issue of familiarity with many programming conventions that get in the way. |
| ||
| I must agree that everyone has his own writing style to do the same thing. The best option would be that if the creators of BlitzMax created some kind of tutorial with examples with at least using strict mode so that we would know what the intended writing style should be so everyone could use that as a good base. It's better that everyone learns the code the same way. Reminds me also of coding PHP where there is no solid documentation on how to write it. At least on the Amiga with Blitz Basic 2 I only had 1 book, no internet at all and I learned Blitz Basic 2 faster than BlitzMax with too many not strict written examples. I remember putting strict on top at start all the time and most examples didn't work anymore, it was really anoying and wasted lot's of hours because of that. |
| ||
| Funny you should mention php... I just spent the day watching some video tutorials for beginners. I really like this guy's teaching style. www.killerphp.com |
| ||
| Not complaining, but I do think that in the end, these forums function as "the manual" for me. Example: I just wrote a quick program over the weekend and for the first time I needed all the routines that slice and dice strings. I knew it could be done and easily, but didn't know how. What I needed was mid$, left$, right$, instr$, String.find, and a couple of others. I haven't bumped into them in tutorials so far. I looked up "strings" in the docs but didn't find references to those functions and how they are used. I think that section of the help docs only talks about string objects, type casting and what-not. Then I searched here but I couldn't use the names of the functions in the search because I didn't know what they were. I eventually found a bunch of discussions that were very relevant (a beginner asking the question and getting a series of responses). Then I did some seaching for the specific function names in the docs (the CHM, the HTML docs, the web, and the forums again) and I learned enough to figure it all out. My program works great, but I lost an hour trying to discover what I needed to learn first. That's where, in the past, manuals have always help me out. I don't think that more/better tutorials would help with that cycle, but a solid wiki might. Anyway, if there's a way I can help contribute, I hope that I can. -pmc |
| ||
| Yulp. They really need to bring back the wiki. |
| ||
| I think there definitely are some difficult hurdles for beginners to BlitzMax even when they DO have some previous programming ability. Some of the syntax took a while for me to grasp and especially the whole object-oriented thing. Also you can't just throw a small example program at someone and expect them to understand what's going on. Things need to be explained line by line sometimes. The BRL docs really are just a reference manual for syntax and even that isn't explained clearly in many cases. It's really not pitched at a beginner to programming. It sort of says `this is how blitzmax works and these are the commands you have to use, go write some programs`. I still fondly remember the manuals for AMOS and AMOS Pro on the Amiga, recalling that there were numerous good tutorials explaining how to program. That's what the beginners need. |
   |