The Scale of Justice
BlitzMax Forums/BlitzMax Programming/The Scale of Justice
| ||
| I have Blitz3D but have yet to make a 3D game in it - I'm still a 2D kind of guy. Can anyone tell me what makes BlitzMax so great - better than a simple update of BlitzPlus - without using fancy jargon and lingo like "WIP" and "GUI"? What do "WIP" and "GUI" mean anyway? |
| ||
| work in progress graphical user interface BMax is object-oriented (if you choose to use it, that is). From personal experience: you can't explain OO-benefits to ppl who only did small-scale apps of only a few thousand lines. I got a lil' bit o' c++ at my study, years ago, explained using small examples (bull@#!* like "putting a coin in a piggybank object" etc.). Back then I was still happily QBasic'ing all the way.. naturally I completely failed to see the point of OO. The funny part is that no-one needs to be taught OO, it's discovered! Usually when you're doing multiple thousand lines of large-scale apps in a procedural language, you think of solutions how to make things more structured, automagically you 'invent' a solution... OO ! What's nice about OO? - Datahiding - Modularity (when designed well) - Large degree of reusability - Can speed up construction of you apps largely, tho the initial start might be a bit slower as you don't go rushing things but take your time to setup things nice 'n tidy. 'OO' isn't 'modular' perse. It's just that OO makes it way more easy to do modular stuff. In the end it's the coder who makes things modular, not OO. And for the rest, there's new non-OO stuff in BMax as well. Personally I see OOP as the 'upgrade' for Procedural programming. Some code-gurus think ppl shouldn't ever touch Procedural languages and start immediately with OOP languages. I don't think so, I think you need to know the night to appreciate the day. Why would you appreciate objects if you don't know what programming without them means? So, my ultimate programming-history would be: linenumber basic in the 80's on homecomputers, followed by QBasic to learn about procedural thingies, followed by Blitzplus, to learn about events and windows-GUI, followed by Blitzmax, to learn about OOP. In this case you've done it all, you learnt every new thing coming from a situation where you didn't have that thing yet. So, ask yourself: 'Am I a procedural guru yet, making huge large-scale programs already, and getting lost in the chaos when things are exceeding 5000 lines?' If yes: you're prolly ready for OOP. |
| ||
| It's a LOT faster than BlitzPlus in terms of raw code execution ( ie: ignoring graphics which can't really be compared since BP did pure 2d via GDI and DDraw. ) In fact, in my tests, it's a lot faster than PureBasic which is pretty damn fast and not far off C speed. The GUI stuff ( windows, gadgets, etc ) is vastly improved over BlitzPlus ( thank god, because BlitzPlus's GUI stuff was really poor. ) Lots of new cool language features like slices ( just think easy and powerful string manipulation ) and pointers ( no point me explaining the benefits, you don't get the benefits of pointers till you use them ) and extensions to previous language features like Lists ( like For Each but you can control them and put objects of different types in the same list ) and banks ( the ability to create a bank from any given chunk of memory is nice ;) ) |
| ||
| Another nice thing of BlitzMax is that it's 2D-in-3D, so even if you're a 2D-only kind of person (like me), you can use features such as alpha blending/transparancy, real-time rotation and scaling of your sprites, etc. |
| ||
| Let's not forget that it's cross-platform Win/OSX/Linux, which is quite nice. Regardless of personal preference, there are large numbers of people out there who just don't have a Windows machine at their disposal. It can also be argued that the game market for OSX/Linux is substantially less saturated than the Win market, so you'll have a more receptive audience with the "other" OSes. (On the procedural/object-oriented discussion, I find that I'm a big fan of the hybrid approach--use objects to help streamline code and reduce clutter, but use good ol' fashioned procedural programming to futz about with some of the more complex stuff...) |
| ||
| Thanks for all the feedback, but I shamefully have to admit that the only answer I really understood was xlsior's. What a pathetic nerd I am. What is "modular"? What's a gadget? What makes OO better than "procedural" programming? (Give me an example like in a space invaders game) |
| ||
| Modular: Built up from small independent modules. for example, Blitz3D has a single run-time engine that contains all the commands -- so every blitz3D program you create, it links this runtim in, regardless of what commands you use.. This means that you get a fairly large executable file. Since Blitzmax is made up from from smaller modules, you can compile a program and only include the portions it actually needs -- so if you don't use network access you don't have to add the networking library, if you don't use sound you don't have to add the sound library, if you only use JPG and not BMP or PNG images you can drop those two image libraries, etc -- resulting in smaller executable files. The other advantage is that people can create their own modules, so a 3rd party can create an extension to blitzmax and add completely new commands... Or even replace some built-in commands with better versions. A lot of the actual sourcecode for the blitzmax commands themselves are included, so people (who know what they're doing) can make their own modifications to the core of the language itself. with the older versions like Blitz3D or blitzPlus, you are a lot less flexible. |
| ||
| xlsior, I think you have a knack for making sense. Thanks a lot. |
| ||
| Buggy: modular means: -the way I see it- Constructing an application from individual parts that don't rely on other parts other than the data they manipulate. Compare it with a classic clock, full of wheels 'n stuff: each wheel is a complete autonome object, and together they make the clock, each wheel is so autonome that you can replace it with another wheel and it still works! (As long as the inputs and outputs are identical!) Meaning of the word 'gadget': buttons, windows, scrollbars, editfields, canvases, labels, menus etc. Why OO>prodedural? As I wrote already, it's prolly no use to explain it, you have to discover it. You can easily teach yourself why OO (or better: datahiding and modularity) is handy by making a large editor right now, and don't come back unless you've 8000 lines of unique code. :D Ok, a small hint then? Imagine you're making a tile-editor, that's not a map-editor but more like a classic drawtool like deluxepaint, but without freehand drawing, just a zoomer for tiles. Easy! Let's setup what we need: - Mainwindow - Zoom editor, big canvas somewhere on our mainwindow - Palette, with a number of colors to choose from - Some manipulation-buttons like rotate, mirror, colorfill etc. - The 'image' where we store all our finished tiles. So the idea is to fill our big image with pieces o' grass, water, brick, rock, rooftops, windows, doors etc. etc. Everything we need for our Zelda RPG! Seriously, you can do this in about 2000 lines o' blitzplus code.. I'm talking out of experience here, that's why it's sooo easy for me to come up with this particular example. :P We don't know datahiding, modular, so we just code like a madman, all with global vars so we can access everything everywhere. Like: (assume non-bmax here) Dim paletteR(AmountOfColors) Dim paletteG(AmountOfColors) Dim paletteB(AmountOfColors) Dim Zoom(31x31) ' for a 32x32 zoomer Dim StorageImage(511,511) ' for a 512x512 image ..and a lot of gadgets. Result: seriously: in 3 days you can have things working like a charm, without ever touching something as 'complex' as OO! Sofar there appear to be no problems, and indeed, there simple aren't any! The problems start now. :D You're obviously the user of your own app, so you'll start adding features, that's just common practice.. creative ppl invent features faster than one can code them. Suddenly you realised you hadn't thought of any UNDO mechanism. Yipes, wadayado..? Let's first focus at the palette: This could be a solution: Dim paletteR(AmountOfColors,1) Dim paletteG(AmountOfColors,1) Dim paletteB(AmountOfColors,1) When we start modifying we could store everything from (,0) in (,1). When we perform an undo operation we could copy the data from (,1) to (,0). And you know what, it works! Another possible solution: add these! Dim paletteRtmp(AmountOfColors) Dim paletteGtmp(AmountOfColors) Dim paletteBtmp(AmountOfColors) Same store/restore mechanism. And again: it works! But as you might have spotted, the amount of 'weird overhead' grows. And this is just for an UNDO for a palette editor. Next, the creative mind decides your tile-editor should in fact include a full-featured map-editor! Yipes! Ok, add another fullscreen panel and some key to switch between tile-editor and map-editor and it'll be allright. Again, more oddness. Oh, meanwhile: the palette-editor, used to be for 256 colors, you really need more colors.. your palette-editor layout changes drastically ofcourse. Ah, and what's next? Your 32x32 zoomer was all nice 'n stuff, but you need more formats! like 16x16, 48x48, 32x64 (!) etc. More! Your map-editor shows you that creating convincing maps requires way more tiles than the 512x512pixel images provides you. Hence, you think it should be handy to have a dynamic image-size! Hey! Why are your default maps always square? Must be able to expand or shrink them at all the 4 edges! Say! One map-layer?? We need at least 3, including real parallax-scroll! Gosh. What's a game without enemies and items? We need a special layer for that. But, naturally this won't be a map-layer, but a list, so items/npc's aren't fixed to the grid (amongst other reasons) As you see, all newly invented stuff, probably stuff you forgot about when you first rushed together your perfectly working app in 3 days. This is a so-called one-shot application. + done quickly if you don't care for the future - completely NOT future-proof What you *want* is a solid modular system - takes quite a while before you're even going to see something that will remotely look like your end-goal, rather you'll be spending ages on small components. Not because each component is hard to code, but because each component has to be autonome and independent! And it's soooooooooo easy to ruin that, to make dependent objects that somehow are related (codewise or datawise) to your end-goal. + you may have guessed by now: in the long run you can keep expanding it without much trouble. How can objects become autonome and independent? - key-rule: NO GLOBALS, EVER, ANYWHERE. Print it and stick it at the wall above your bed. - everything must be self-contained, that's where object-methods/functions come in. - seperate data from GUI, make 2 objects instead. There's an object with data (palettedata for example), and an object which is the GUI (a palette-editor for example). Why? You can link your 'image' to that same data, so whenever you change the data with your palette-editor, it's automagically changed for the 'image'. If you don't seperate all this you have to manually send all changed stuff to other parts that use the data. For one or two objects it's peanuts. In a year you have 30 parts that use that same data. :P So, when you have hundreds of little independent objects you still have no tile-editor! Now comes the trick: your tile-editor app won't be 'coded', it will be connected! You just connect all those little independent objects together and they will work together. More fun? Create that same tile-editor with XML! "Oh, but then my app is dynamic and can be modified by artists, so they won't have to bug me anymore with their annoying feature-requests!" "yezzzzzz!" You should try to find/download/experiment with a modular system for audio (there're plenty o' synths) and try to superimpose that way of 'connecting icons with wires to form a synth that never excisted before' to code/apps! Ok, enough with the brainwasing :P |
| ||
| Just to make things clear: I made quite some gfx/game-editors with B+, I did everything wrong multiple times. :P Someone could've explained me "you're doing it wrong" 2 yrs ago .. wouldn't have made any difference. Coders 'discover' OO by themself, teaching it to them is a waste o' time. ^_^ |
| ||
| Even if teaching it is a waste of time, I think you managed to do just that! But why is it called "Object-Oreinted" and not "Self-Contained" or something like that? |
| ||
| Because you create 'things' with a number of properties and functions. These things are 'objects' ofcourse. Imagine the properties of a dishwasher: variables: washprogram soap_amount dishes methods: Opendoor() Closedoor() AddDishes(Dishes:TDishes) Wash() Mind you, this is a pitfall! C++ books for beginners (those ppl who're used to procedural languages) start talking about dishwashers and stuff. By doing so they are talking too abstract from my pov. Working with objects leads to somewhat more abstract jargon, still I think it's good to know that OO is just an 'upgrade' of prodecural programming. It's just a mechanism to put private variables and functions together for the object they belong to. |
| ||
| - key-rule: NO GLOBALS, EVER, ANYWHERE. Print it and stick it at the wall above your bed. I disagree, globals don't always have complete program scope, you can have globals in your types (all objects of that type share the globals) and inside functions as well! (for use with functions in functions 8) ) |
| ||
| Was mainly referring to complete program scope tho :P Just had to add some weight to it. ^_^ I've yet to think a while on object-globals.. are you sure things stay 100% modular then? And in-function-globals are temporarily, right? (also less of an issue then) |
| ||
Here is a good example of using Globals in a type, there is only ever one list created and its shared by all instances of that type, each new instance adds itself to the list.Type TExample Global List:TList = CreateList() Method New() List.AddLast(Self) EndMethod EndType Local n For n=1 To 100 New TExample Next Print "created "+TExample.List.Count()+" objects" And in-function-globals are temporarily, right? (also less of an issue then) No, a function will retain its globals between calls, which is brilliant IMO :) Basically the function itself is an object :) Function TestFunc() Global Count Add Print Count Function Add() Count:+1 EndFunction EndFunction TestFunc() TestFunc() TestFunc() |
| ||
| hmm.. hmm.. is all this actually portable to c++? What if I create something with all this, and hand it over to someone who would have to port it to c++? Would that person cut his wrists on my source then? I dunno, looks all a bit too abstract/new to me orso .. maybe later. Well I really have to find a suitable purpose for it.. I guess I'm too oldskool atm. ^_^ |
| ||
| Would that person cut his wrists on my source then? Depends how good that person is at c++, it might even convert them to the ways of Max :PThe great thing about BlitzMax is theres so many different ways to do things, you can't really go far wrong, whatevers suites your style :) |
| ||
| Someone could've explained me "you're doing it wrong" 2 yrs ago .. wouldn't have made any difference. Coders 'discover' OO by themself, teaching it to them is a waste o' time. ^_^ I beg to differ. You can be taught it in 2 weeks, but it might take you years to discover on your own. But why is it called "Object-Oreinted" and not "Self-Contained" or something like that? Because encapsulation is only a subset of the Object Oriented Paradigm. Other things to keep in mind are the "Seperation of Concerns", a multi-layed software architecture, a high coherency, low coupling and ultimately the application of software design patterns to solve often occuring common design problems, all resulting in a high degree of reusable code.The main points of the Object Oriented Paradigm, is that EVERYTHING is an object, and an object is defined by a unique Identity (its name or reference), a State (often a collection of Fields or Attributes) and Behavior (usually Methods or Functions). |
| ||
| Thanks so much everyone. I still think I'll do things my noobie way, but now at least I *kind of* understand OO. One last question (hopefully), though: If everyone "discovers" OO on their own, how do people realize they're all doing OO. If I discovered a way to do things better, I would simply think I've gotten marginally smarter and thank whoever's up there for it. I wouldn't run off and anounce that I've "discovered" something, and that from a vision, I've decided to call it OO! |
| ||
| I dunno, perhaps I was just talking crap. :P I 'discovered' it because I got some lessons on it somewhere in '99 already, yet only the past year orso I got the hang of it. For the simple reason I never made really big apps before. And OO for something small'ish is ridiculous. If you want to get the hang of OO, just go coding some editor with 8000 lines, noobie-style. What you really discover is not the word 'OO', but you discover that you desperately need to hide data and organise functions that belong to a single thing. A class/type is just a container to hide specific variables and functions for an object so that they don't wander around everywhere. Books that start talking abstract about dishwashers should be burnt. :P |
| ||
| Speak of the devil, part of my dishwasher melted the other day... |
| ||
| But what exactly is a gadget? |
| ||
| Gadgets are those little GUI components you see in apps, like buttons, toolbars, scrollbars, windows, panels, etc..., I believe another name for them is widget. |
| ||
| Ahh... one more for you helpful guys: Is there any way - in Blitz3D - to create custom popup boxes? Actually, I know there is, so can someone tell me how? I know this isn't in the B3D forum, but I don't like to post there because I don't program 3D games and that's all they talk about. |
| ||
| Thanks ever so much for helping, you guys... can someone please just answer the above question? |
| ||
| You can't, at least not those that you are used to from windows because that minimizes your game and can crash it. You must create it using a GUI system. BlitzUI is one for example, there are others. You might check the toolbox section. |
| ||
| Thanks. At least now I know that I have no hope of understanding it! |
   |