I am now a proud owner of BlitzMax.
BlitzMax Forums/BlitzMax Beginners Area/I am now a proud owner of BlitzMax.
| ||
| My first job was to reconfigure those hideous IDE colors to be more like those of Blitzplus. At which point I realised Mark had not included the option of coloring numbers like in all previous versions of Blitz! :-( My second task will be porting my AniBOB system over. But before I do that, I tried compiling the tempest demo, only to notice the compiling is rather slow. But then I looked under build options, and noticed "debug build" is turned on. And there is another option "quick build". And there is yet another "Builkd GUI app". It seems that disabling the debug build causes it to build much faster, but the Quick Build thing intrigues me. Why is that not enabled by default, if it will automatically detect changed files and rebuild only those? Also, I assume the compiler will complain if I try to build and app that needs GUI stuff if I don't have that checked, so why doesn't the IDE simply detect if I have used any of the GUI commands and automatically enable that or disable it as needed? |
| ||
| Good on ya! 1 debug build adds a lot of crud to the output, the fact it is noticably slower to build may be cause for concern, of course progs will always run a lot faster in release mode 2 quick build is for imported files (similar to includes but don't have to be recompiled every time you build your main app if quick build is enabled) 3 gui app means non console, as in you click on it with an icon rather than run it from command line, leave it as gui |
| ||
| Hm... The help file could still use work: Function compress2( dest:Byte Ptr,dest_len Var,source:Byte Ptr,source_len,level ) Description Compress a block of data at specified compression level. That tells me nothing about what I am expected to input into the level parameter. Also, while I understand that "dest:Byte Ptr" is declaring a parameter of type byte ptr, (pointers! yay!) What in the world is "dest_len Var" doing? Did someone forget to put a colon in between in the help file? Is adding a colon optional? Variables default to int I assume. What's the Var for? |
| ||
| "2 quick build is for imported files (similar to includes but don't have to be recompiled every time you build your main app if quick build is enabled)" Yes, but can I safely enable it? When should I not have it enabled? |
| ||
| After detecting an updated BlitzMax compiler the IDE automatically disables QuickBuild so that objects from different versions of the compiler are never linked. |
| ||
| At which point I realised Mark had not included the option of coloring numbers like in all previous versions of Blitz! :-( The community IDE adds this, amongst other things. |
| ||
| "After detecting an updated BlitzMax compiler the IDE automatically disables QuickBuild so that objects from different versions of the compiler are never linked." Wouldn't installing a new compiler change the those files if they are indeed different? And shouldn't quickbuild, by it's very nature, detect they have changed, and rebuild them? |
| ||
| Persevere with BlitzMAX for the first week, download wave's "Beginners Guide to BlitzMAX" (I printed it as an A5 booklet) and you will soon have a big fat smile on our face when you realise that Methods are the best implementation of OOP in a BASIC language that we are ever likely to be blessed with. Writing workable, efficient, reusable, intuitive and (best of all) bug-free code is so much easier. You will spend less time thinking "how do I code xyz?" and more time thinking "what else can I add?". You might want to investigate BLIde, a freeware IDE for BlitzMAX. Two things you will find useful, which might be missed if you're not looking carefully: Press F2 for quickhelp on function parameters, click on the little 'drawing pin' icons on the windows at the bottom of the IDE to have them auto-hide. I use BLIde for project work and the community IDE for testing little bits of code. This method came in very handy last weekend when I spent 6+ hours struggling to perfect a particularly gnarly routine. |
| ||
| Vinyl: I dunno about that. Looking at Mark's Tempest exmaple, I have to scroll pages and pages just to get through the type declatarions because he's got all these methods in there that are full of code. That makes it hard to find the main loop, and it means that my "functions" will start out already indented like two times, and I indent a lot as it is. So it might get a bit crazy. Even if I stick those types in an include file, which I probably would do, it would be much cleaner if I could stick the methods outside the type below in the program where they would not be indented. I could just NOT indent them of course inside the type, but then that wrecks the whole "stuff which is indented more is contained by the stuff that is indented less" thing. |
| ||
| So what's this Var thing? |
| ||
| Pass by reference. |
| ||
| Why is it called Var, and not Ref? |
| ||
For Example: Local Width:Int Local Height:Int Local Depth:Int Local Hertz:Int GetGraphicsMode(1,width,Height,Depth,hertz) 'this function has the Var thingy for the last for parameters 'Now the related data is stored in the previous declared variables Print Width Print Height Print Depth Print Hertz In simply words: Var let you return multiple Variables from a Function or Method |
| ||
| sswift: I hear you re the comment on having large Type declarations. I know what you mean, include files (especially type declaration includes) containing actual code (and not just contructors) seems counterintuitive if you're used to C++. The thing is, once you get your head around it and start to manage a project, it doesn't seem so bad. Mark's enemy code isn't an example of perfection, by any means. I can almost see the train of thought there though, the man was rushing :) That code can be shrunk down a fair bit by using an Abstract 'nme' class which all the different enemies extend. Mind you, if Mark has got some bookmarks set up in his IDE then he probably won't have much trouble navigating the code. If it were me, and the code got much larger I would probably split each individual enemy into its own file. Game code is never going to be the tidiest, especially when you're adding multiple enemy types and suchlike. Mark has done a fairly good job with it though. Heck, I could understand what was going on, and I'm stoopid :) |
| ||
| vinyl: Include files having code is just fine in C. Header files are what you're thinking of, and those don't have functons in them. Then again you did say C++ and I am not familiar with C++, so I could be mistaken. "In simply words: Var let you return multiple Variables from a Function or Method" Yeah, but the word Var still seems wrong for it. |
| ||
| depends on the point of view. I think its original root comes from the VarPtr command which you use to retrive a reference pointer. |
| ||
| Once again, the help file sucks, and I've been trying to figure out what the difference is between methods and functions when used in a type. I found a post asking asbout methods, and let me see if I have this right... If I put a method in a type, then I can access any field of that type in the method, just by using the name of the field as a variable. I don't have to stick the type name on the front. So:
Method Draw()
DrawImage image , xPosition , yPosition ' Draws the Whatever object it was invoked on.
EndMethod
Is accessing the type fields "image" "xPosition" and "yPosition" of whichever type the method "Draw" is a member of. A function in a type on the other hand, will not have ready access to these type fields. You would have to pass the pointer to the instance of that type to the function when calling it in order to get access to those fields. And both functions and methods can return values. Now, with that said, I don't understand why you can stick functions in types at all. What benefit is there? Anything I can do with a function in a type, I could apparently do with a Method. The only possible benefit I could see would be if the compiler were not smart enough to optimize out passing the type pointer to the function if said pointer is never used in the function. But this seems about as dumb as having both Functions and Procedures in Pascal, where the only difference is that Procedures can't return values. As we well know, that is completely silly, because we can just use functions and not use Return to return a value, and not assign it to anything and the compiler can deal with that just fine. There's no need at all to have both for any reason. So why does BMax allow both methods and functions in a type, when Methods alone would appear to suffice? Am I missing some crucial bit of functionality here? |
| ||
| methods are attached to the instance functions are global type bla function monkey() end function method ape() end method end type ' right here I can call bla.monkey ' but not: bla.ape local poo:bla=new bla ' now i can still access poo.monkey ' if I want, AND poo.ape |
| ||
| You need to create an object before you can use a method. You don't need to create an object before you use a function. So you can use a function as a constructor with which to create an object, amongst other things. You can use it to keep track of objects too. Functions in types are just like static functions in C++. And 'globals' in types are like static variables in C++. |
| ||
| You could do a constructor using a function, ppl tend to have a .Create "function" in their type to initialize the type. Personally I always make a global wrapper to make it look more uniform with the older blitz and blitzmax' own thingies. so, for a wrapper, I'd do: function Createbla:bla(args) local a:bla a.member=1 a.momber=2 a.mumber=3 a.mimber=5 a.update return a end function Then I simple can do: local mypoo:bla=Createbla(args) |
| ||
| function Createbla:bla(args) local a:bla a.member=1 a.momber=2 a.mumber=3 a.mimber=5 a.update return a end function Huh? You haven't created a type instance there with New. So how does that create anything? You're just acessing fields of a type which does not exist, and should crash the compiler, unless BlitzMax is doing something funny. |
| ||
| yeahyeah, those were just example-fields, I figured you'd understand :D It was just to show how you could initialize stuff with a wrapper function or .create function :P ops. typo, that's what you get for coding on the forum-replybox rather than c/p code from the IDE :D local a:bla=NEW bla yes.. ^_^ |
| ||
| You haven't created a type instance there with New. So how does that create anything? You're just acessing fields of a type which does not exist, and should crash the compiler, unless BlitzMax is doing something funny. Pretend it's pseudo code. |
| ||
| but.. to be complete type bla field member:int field momber:int field mumber:int field mimber:int method ape() end method function monkey() end function method update() end method end type yes? :P |
| ||
| No. To be complete? I don't think you understood what I was asking. Coming from Blitz3D and BlitzPlus, I would assume this is how that should be coded:
Type Bla
field x, y
function Createbla:bla()
local a:bla
a = new bla
a.x=1
a.y=1
return a
end function
end type
ThisBla:Bla = Bla.Create()
You however, don't have New in the create function. For some reason it seems you assumed that I was complaining about the fact that you didn't show me how the type fields were set up which was not at all what I wanted to know. So is it correct to use New in the create function? Or not? And if not, where does the new instance of the type come from? And don't give me that pseudocode crap Throb. :-) I'm trying to learn the nuances of the language here. I need to see code snippets that could actually conceivably work, not ones which leave out crucial bits and expect me to understand those bits are assumed. Of course, it seems like you may have assumed the same thing about what I was asking for, which was the type that goes with the function. But that isn't what I wanted. I was asking about a seemingly missing New command. |
| ||
| Yes it is correct to use new in the creation function. It is actually the only way to create a type. (new and delete are core methods of BM that can be overloaded. Same as default constructor / destructor in C++ and other languages) |
| ||
| Thank goodness for that. I didn't want to have to remember another nutty thing Blitzmax does to make my life "easier". :-) It took me long enough to figure out Types in Blitz in the first place! |
| ||
| Quit whining, pull the finger and get busy like the rest of us. Be a man.... :) |
| ||
| I just found the AddHook function. Question about that... If I hook a function to flip, is said function executed before, or after flip executes? One Eyed Jack: I am getting busy, that's why I'm asking all these questions. Be a man? I plan to port one of my sprite animation systems to Blitzmax just a day or two after I first got it. Is that MAN enough for you? I bet you won't even be able to tell I haven't been coding in it for years. :-) |
| ||
| yes, it was a typo (see the edit) Never used types either, in the older blitzes, it looked weird with that \ thing. Now however I'm completely into the whole bmax type stuff. ^_^ |
| ||
| I would assume after, as the flip must happen first to send a flip event (which says that the flip happens / happend). At least from the pure logical point of view. |
| ||
| for hooks you'll find this thread handy: http://www.blitzbasic.co.nz/Community/posts.php?topic=55887 flip, I'd figure it's after flip executes, purely based on how the eventhook works: event happens > evenhook catches it > you do something with it. |
| ||
| "Never used types either, in the older blitzes, it looked weird with that \ thing. Now however I'm completely into the whole bmax type stuff. ^_^" Oh I use types, all the time. But it took me several days to "get" them, because the examples provided weren't very good. I think I understood they were like structures in C fairly quick, but I didn't get the whole "linked list" nature of them. Speaking of which... Blitzmax does still do that linked list thing with types doesn't it? Please? Oh... I have a bad feeling about this. I hope Mark didn't decide to get rid of those. That would mean every program which uses linked lists to maintain lists of things would have to use different variable names to iterate through the list, and that's not very nice when I want someone to be able to access my list of particles and iterate through it. I guess it would be less wasteful or memory maybe, but... :-( Also, another gripe: In the Language section of the docs it says "types". When I click that I get the different data types, not information about how "types" work. Maybe Mark should have called them classes instead. I see the Type entry now though under Blitz Runtime... And I see EachIn... But that doesn't seem to relate to types. But rather, some kind of array. And the code there is comfusing and doesn't explain itself: Local a[]=[0,5,12,13,20] for b=eachin a print b next That a[] is clearly an array. And those numbers are clearly being placed into that array. A convenient feature that C and Pascal both had. But there's no number in the array to indicate its size. Does Blitz make the array whatever size is needed to fit the data being assinged to it? And are the arrays accessed starting at 0? And if I have an array with 10 elements, does it go from 0..9 instead of 0..10 like in all other versions of Blitz because beginners don't realise they're supposed to start at 0 and Mark is holding their hand? :-) |
| ||
| "yes, it was a typo (see the edit)" I'm looking, but that post of yours with the Create funciton still doesn't have a New in it. :-) |
| ||
| Blitzmax does still do that linked list thing with types doesn't it? Types are no longer automatically added to a linked list. You have to assign them to a list youself. The benefit of this is that you can have multple lists per type. Does Blitz make the array whatever size is needed to fit the data being assinged to it? Yes. And are the arrays accessed starting at 0? And if I have an array with 10 elements, does it go from 0..9 instead of 0..10 Yes. |
| ||
| Thanks for all the help so far. :-) A BlitzMax type that contains Abstract methods becomes abstract itself. Abstract types are used to define interfaces that extending types must implement before they can be used to create new instances. In the following code TShape is an abstract type in that you can not create a TShape but anything extending a TShape must implement a Draw() method. End Rem Type TShape Field xpos,ypos Method Draw() Abstract End Type Type TCircle extends TShape Field radius Function Create:TCircle(x,y,r) local c:TCircle=new TCircle c.xpos=x;c.ypos=y;c.radius=r return c End Function Method Draw() DrawOval xpos,ypos,radius,radius End Method End Type Type TRect extends TShape Field width,height Function Create:TRect(x,y,w,h) local r:TRect=new TRect r.xpos=x;r.ypos=y;r.width=w;r.height=h return r End Function Method Draw() DrawRect xpos,ypos,width,height End Method End Type I just noticed this Abstract command. What is the point of it? It seems like something you might want to use if you were using that strict thing that forces you to declare all your variables. But that doesn't make sense, because trying to call the draw method of a type which doesn't have a draw method, would result in an error anyway. So why would I need something that forces me to put that method into each of those functions? Either I put a call to that in my code, and it errors during compile and won't let me run the program, or I don't, and it doesn't matter that I haven't added that method to one of the types. The only thing I can figure on is if you were wiritng a lib and didn't actually call your types, you might want to have that to make sure you didn't forget one. But how huge would your collection of types for a lib you haven't tested have to be before that is an issue? |
| ||
| Abstract just marks a method as being 'empty', then you can write the code for it in an extended type. For example if you was to write an entity system like Blitz3D's, you might have an 'Entity' base class, with abstract methods like Update. Then you might extend the Entity class with Camera, Mesh, Sprite types and so on, with different Update methods for each one. However, because you defined those abstract methods earlier, you will be able to use any entity object with Update and the correct method will be called. So this is handy if you have a list of entities, then you can just cycle through them all and do ent.Update Hope that makes sense! |
| ||
| Abstract is to define base classes with method in it that you don't want to implement in the base class but that extended classes must implement. This way you can force an interface coreset for all subclasses which you could use then for example in your type handling list. There is as well the final command which marks a type in a way you can't extend it anymore. Very usefull as well. |
| ||
Try repeat a:+1 print a if a>20 throw "chunks" forever Catch a$ print "caught exception "+a$ EndTry What's the point of this? I could just as easily write:
repeat
a:+1
print a
if a>20
print "caught exception "+a$
exit
endif
forever
Which is much easier to read, and doesn't require memorizing yet another command. Examples in the help file should really do more than just show how a command is used. They should show examples of where it makes sense to use the command. Here is appears to make no sense to use it. It would be like having this be the example for select:
select a
case true print "success!"
end select
When you'd take one look at that, and wonder why the hell they even included the command, when If a Then Print "success!" Would do the job better. Of course, I understand that Mark is busy making 3D engines and stuff for the language, but still, it's frustrating. The docs for Blitz 3D and Blitz Plus were much better written. Even the Max Wiki doesn't show any good excuse to use this command. |
| ||
| "There is as well the final command which marks a type in a way you can't extend it anymore. Very usefull as well." For WHAT? You object oriented programmers are crazy. I understand well why one would want strict variables, function pointers. Even methods. But half the stuff I read about oop and the suggestions I have read for stuff oop people want added to max just sounds crazy. There's nothing wrong with procedural programming with a little oop stuff here and there for managing objects in your game... And having types extend other types is okay I guess if you want to save some typing. No pun intended. But something to make sure you don't extend a type further? Like I'm going to do that by accident?! Crazy talk. :-) |
| ||
Okay I thought of a better example for Try and Catch. This is what should be in the help file:
Try
repeat
For x = 0 to 799
For y = 0 to 599
' Oops.
'a = 0
Repeat
a:+1
print a
' Help! Jane! Get me off this crazy thing!
if a>20 throw "chunks"
Until a = 10
next
next
forever
Catch a$
print "caught exception "+a$
EndTry
See? Now it is obvious why you would want to use it. It would be a pain in the ass getting out of that loop otherwise. |
| ||
You have to look in "Language" > "Program Flow" to find it, but there it is, the elegant label exit way:Strict
Local k,j
#Label1 'loop label
For k=1 To 4
#Label2 'another loop label (unused in this example)
For j=1 To 4
Print k+","+j
If k=3 And j=3 Exit Label1
Next
Next
|
| ||
| Peter: Yeah, I just found that out about Exit about two seconds ago on the Blitz Wiki. But thanks for pointing out where it is in the help file. I'm having a hard time finding stuff in there. Exit doesn't apply to the example above though, which I was just using as an example as to how the Try Catch help doesn't show WHY you'd want to use it. I guess even my example though is imperfect, because you could just stick that error code in the if a>20, and then use Exit Labell like you have. So a better example would show multiple points of error inside those loops all of which need to exit and run the same exact code on the error. But considering that, now I'm once again convinced Try Catch is rather useless, because I can't think of any sane example where I would have a loop with multiple points of failure that all need to give you the same error message. |
| ||
Rem My Rem Example First created 9th August, 2004 (C)2050 Blitz Intergalactic Software Corporation End Rem Print "This program has no useful function" Rem Remarks are useful for making your program easily readable. You can leave details explaining the function of your program in a remarks section so that you and any other programmers that work with your code can more easily understand the workings of your program End Rem Print "Sorry." End And that, my friends, is irony. Rem is perhaps the best documented command in the help file, is designed for documenting things, and is the least in need of extensive documentation. But I accept your apology Mark. |
| ||
| One way I use Try Catch is if I have functions, calling functions, calling functions. Throwing an error in the innnermost function, will unroll all the way to the top function. I throw because of an error or a certain condition, but I allso use it for letting the user end a lenghty task with [escape] |
| ||
| Yay, I got to the end of the Blitz Runtime help section. Now to go on to the more interesting stuff. :-) [edit] Ooh, you can save PNG's, that's nice. [/edit] |
| ||
| [edit] Ooh, you can save PNG's, that's nice. [/edit] lol, keep at it sswift you'll soon be there... :D |
   |