Avoiding using globals..
BlitzMax Forums/BlitzMax Beginners Area/Avoiding using globals..
| ||
| I keep hearing globals are bad because they are not as fast as locals, but I've been trying to rewrite Paratrooper Plunge in Max, but I just can't figure out how to not use tons of globals. The way I structure is like this: So because I structure my code all functions like that, doesn't that mean I need lots on globals? Anyone have suggestions as to how I should structure my code and such to use more locals? |
| ||
| If there aren't too many, you could pass the images and variables used to MainMenu(). Or you might consider creating a "Type TMainMenu", setting up only the images and variables that it needs as fields within it, then creating functions within it to use those fields (or an instance of it with methods that use them). That's how I write my larger programs: each "set of functionality" (Input, Output, Networking, AI, etc.) has a type with fields that contain the variables/data that it uses, and I create an instance of each. I don't have a single global in my set of types (except within functions/methods that need to retain values between calls, but those are really "static locals"). However, the main reason that I do this isn't for speed, but to separate each set of functionality. Since each set is a type instance and only deals with the fields contained within, there's no chance of "contamination" - of one set of functionality accidentally influencing another (which can happen when globals are shared). The only way that the different sets communicate is by passing parameters to each other, so it's easy to see how they share information. This does lead to some data duplication (such as the AI, Input, and Output type instances all having specialized versions of the map data), but I consider this a worthwhile trade-off. This slows things down a little since the map data needs to be passed among the various type instances, but because this must be done explicitly, I can see exactly what each instance is dealing with and there's no way for one type to change another type's set of data. But maybe that's just me... hope this isn't more confusing than helpful, otherwise just ignore it. :) |
| ||
| good vs bad is usually a poor way of thinking about these things locals and global both have there uses but in different senarios as for global being "slow" well I really wouldnt let that influence you too much, thay aint *that* slow! just a bit slower than locals I'd rather have 1 global than 6 versions of the same value floating about - nightmare |
| ||
| A lot of info there Wendell, a lot of it over my head =) Chris, I guess you're right. My games aren't exactly large scale so it really doesn't matter what I use.. |
| ||
| Locals can and should be quite a bit faster than Globals because they are cpu registers, not memory addresses. Use locals where you can. |
| ||
| Locals make sense in loops. Every variable in a list of types is gonna have the impact of a type anyway, so don't worry about it. If you're paranoid, benchmark your game, then when you reach a loop, put the global inside a local in that loop if you can. You won't see much difference... For in-loop calculations you want locals, and all temp vars should be locals. |
| ||
| po: if you need a lot of gfx, then why not put all your gamegfx in one big type, called TMediapool orso. Then you don't have hundreds of globals, just one orso (the mediapool instance), and even the mediapool could be part of a TGame orso.. reducing the amount of globals.. in fact, just describe it as a local in your main! The problem with globals comes not so much with unique names but more when you're using a typical variable name. You don't want to have x,y,t,i,a,b,mx,my,dx,dy,sx,sy,w,h etc. global, typical forloop-variables they are.. Also, you don't want stuff like enemyx, enemyy, enemylife etc. global, if you ever need another set o' these then you can't, as globals are meant for one 'user'. An extreme example would be a pinballgame in a window of 320x800. If you make everything global, then a single window it stays. But! If you make everything local, the whole game, then you can simply create another instance of the Pinball type, et voila: 2-player-mode. And all you need to do is create another instance (with different coordinates), and that's all! Usage of locals is essential if you don't know what you'll be doing in the future. Globals are for a dark future only.. |
| ||
| Thing is, types aren't strictly "local" anyway are they? They still have to fetch fresh stuff from memory per object. these are the lines you ought be thinking on... |
| ||
| Hmmmm.. The choices... I like how organized the type idea is, but then there's the speed thing too... |
| ||
| If the speed thing is your worry, you will never ship. Simply code for the correct purpose. Don't mess up your program design for the sake of 5fps. |
| ||
| ok |
   |