Archived

This topic is now archived and is closed to further replies.

JwayneT

Hey, do you guys keep DX stuff global?

Recommended Posts

In all of MS''s DX examples, like for DDraw. Primary Surfaces and stuff are all global. I was wondering if everyone did that, or if MS did it just for time constraints or something.

Why is it called a hot water heater? Isn't it cold when it goes in the tank?

-=CF=-

Share this post


Link to post
Share on other sites
I got the answer to this from lamothe''s book. It''s because globals are faster then sending in and out variables. Yes everyone does do this. Every single source I''ve seen they are all global, so far.

Share this post


Link to post
Share on other sites
With games programming, global variables are a must. They''re actually quicker than declaring a new variable everytime a function runs.

In normal application programming, global variables are a bad habit, but game programming is completely different.

Share this post


Link to post
Share on other sites
Microsoft puts everything global because it keeps things simple for the samples. You''d never do this in real life. If your using C, then maybe but its still better practice to just pass a ptr around. Though i would never recommend C, its such an ugly language. There''s virtually no way to protect your data in C.

I keep everything in classes.

BTW, making everything global is not going to give you any noticable speed. Maybe a few unnoticable nano seconds. But i doubt even 1 FPS more.

Global variables do not belong in games or applications. They are dangerous, unsafe, and not good programming practice. If you are in a position where you must use global variables it is often do to poor design. Of course in C(there''s ugly C again) you are sometimes forced to use them no matter what, but if its a well designed C program there should be minimal globals.

Ifyour working with a team, globals are a big no, no. Nobody wants to maintain code with global variables all over the place.

Global variables don''t make for reuseable code, whereas classes and a robust C-library do.

ECKILLER

Share this post


Link to post
Share on other sites
Well, I mostly agree with the "globals==bad" thing. I, however, consistently code one global variable:

ifstream log("out.err");

I then put this in my shared header file:

extern ifstream log;

And finally, right before WinMain() (or main() or whatever) finishes:

log.close();

This way you can log anything you want from anywhere you want. You could also do a conditional compile depending on whether or not DEBUG is defined. If someone has a better way to log stuff to a file from EVERYWHERE, I would love to hear it. Please don''t say that ALL of my functions should have an ifstream& as a parameter.

Maybe I can countenance only passing it to the contructor of every class and then keeping a referrence to it, but that seems kinda silly

Why is this one instance of a global bad?

Share this post


Link to post
Share on other sites
You can hide data in C. Put stuff in different modules and it becomes hidden if you do not declare it as an extern in the H file. If you have a lot of things and you are constantly passing them around I''m sure there would be a speed hit in terms of things being passed onto the stack.



Please state the nature of the debugging emergency.


sharewaregames.20m.com

Share this post


Link to post
Share on other sites
--------------------------------------------
Microsoft puts everything global because it keeps things simple for the samples. You''d never do this in real life. If your using C, then maybe but its still better practice to just pass a ptr around. Though i would never recommend C, its such an ugly language. There''s virtually no way to protect your data in C.

I keep everything in classes.

BTW, making everything global is not going to give you any noticable speed. Maybe a few unnoticable nano seconds. But i doubt even 1 FPS more.

Global variables do not belong in games or applications. They are dangerous, unsafe, and not good programming practice. If you are in a position where you must use global variables it is often do to poor design. Of course in C(there''s ugly C again) you are sometimes forced to use them no matter what, but if its a well designed C program there should be minimal globals.

Ifyour working with a team, globals are a big no, no. Nobody wants to maintain code with global variables all over the place.

Global variables don''t make for reuseable code, whereas classes and a robust C-library do.

ECKILLER
--------------------------------------------

Erm, if C is an ugly language, than C++ is a childish hack put around it. But no, neither are. Of course you can do OOP in C, and you can do very ugly things in C++, or the opposite. Please keep your offensive, insult starting opinions to yourself.

Now that I got that out of my system:

Global variables for DX is probably the best thing to do, unless you have a really good design specification, you may find yourself needing the DX vars in weird places. Simply put, totally eliminating globals from any program would be ridiculous, considering classes are basically global variables anyway. So, if you are gonna wrap the DX functionality into a library, you shouldn''t use globals, but if you are making a Quake-like engine(insanely fast), globals are the way to go.

-----------------------------

A wise man once said "A person with half a clue is more dangerous than a person with or without one."

The Micro$haft BSOD T-Shirt

Share this post


Link to post
Share on other sites
mavimn, i'd consider your log file thing acceptable. Furby, your idea makes maintaince harder. ImmaGNUman, c++ suffers from the same things C does because it includes everything C does, but at least with c++ you have an option. This wasn't meant to be a C vs. C++. We all know C++ is superior anyway. We also know that all computer science courses and books do not advocate global variables. They are as evil as the goto statemeant. Now a lot of ppl on this board we'll say, "We're game programmers, to meet our special demands we must code special", as in use globals. That is ridiculous, why would game programming be any differant then application programming. See "Game Architecture and design"
Too many ppl on this board are brainwashed by la'mothe--use globals, their fast-- and that kinda BS. Use C its faster than C++--more BS.
ECKILLER

Edited by - eckiller on November 3, 2000 6:50:41 PM

Share this post


Link to post
Share on other sites
ImmaGNUman, how are classes like globals variables?

Globals break code reuse, plain and simple. No globals are NOT evil, and neither are goto''s but they are NOT considered good program technique for many reasons.

And for those who seriously think passing a pointer to a variable slows down your program so much then why use functions? They cause your program to run more slowly to. You should just code everything into the main function for speed. Or better yet, code everything in ASM. Passing pointers or variables are not going to cause your program noticably slower.


- Houdini

Share this post


Link to post
Share on other sites
actually, cout and cin are objects, not classes. cout and cin are really not global actually, but a kind of quasi global.
They belong to the standard namespace.

std::cout
std::cin

ECKILLER

Share this post


Link to post
Share on other sites
Well,

Since I''m using C++ I think It would be best if I just created a screen class, and passed that around. I started this post because I was running into trouble with the global setup. I just wanted to see what everyone else did. Thanx for replying.

<style>a.h{text-decoration:none;color:blue;};a.h:hover{text-decoration:underline;background:red;};

Why is it called a hot water heater? Isn''t it cold when it goes in the tank?

-=CF=-</html>

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Frankly, I like to compromise.

Keeping a pointer to the screen class inside of EVERY object in your scene adds alot of unneccessary memory cost, copy-overhead, and so on.

The way I decided to split things, is to make a class that encapsulates all I/O functionality (key/mouse, video data, etc), and then declare a global object of that type.

class Iowrap { ... }
Iowrap base;

then you have global access to IO functionality. ie:

void foo::bar() {
// get a key
int key = base.getkey()
// if key == KEY_CLEAR
base.Clearscreen();


Doing this grants you several benefits and only a few downsides.

Benefits :

1) There is no pointer-passing overhead for all of your graphic calls. There is also no memory and performance cost for containing a IOClass pointer in every actor in your game. Now in both cases, the performance cost of doing those things is very low, but:

2) My main concern is that, frankly, carrying a IOClass pointer around to every function call that might need it is ugly, and muddies up otherwise simple and functional objects. It''s far simpler to take a page from the istream/ostream objects cin and cout, which are defined in a standard library, and are global objects in the same way.

3) In my project, having more than one IOClass makes no sense. I can see some projects that might want to have multiple seperate rendering objects exist at the same time, but this is not needed in my case. Having a central global variable to encapsulate all input/rendering then makes alot of sense.

Downside:

1) This method probably causes some OOP zealots to foam at the mouth.

2) Like all globals, sometimes it leads to confusion about the best way to encapsulate the code. For example, should all drawing code belong in Iowrap? Or in a more appopriate place (for example, in the Bitmap class, which, for drawing, needs access to both its own information, and screen information.)



Decide for yourself, the tradeoffs are correctness/usability/readability/performance, and your decision will emphasize several of these as the most important.

Share this post


Link to post
Share on other sites