🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Author
Ok, say I''ve got a lot of surfaces that I wan''t to be able to access from all the files in my vc++ project.
Do I have to write
extern LPDIRECTDRAWSURFACE7 thesurface;
and create them in the main file,
or is there any easier way, that doesn''t look that ugly?
Put everything in a class or struct , and then just extern that struct. That way you only need one extern line for a whole bunch of global things.
FYI - global variables, bad. Classes, good.
Mason McCuskey
Spin Studios - home of Quaternion, 2000 GDC Indie Games Fest Finalist!
www.spin-studios.com
FYI - global variables, bad. Classes, good.
Mason McCuskey
Spin Studios - home of Quaternion, 2000 GDC Indie Games Fest Finalist!
www.spin-studios.com
mason, you're not solving anything by putting all your globals in one big, juicy struct. it's the same thing, wrapped in scotch tape. it'll fall apart sooner or later, sooner rather than later.
ZomeonE, I suggest you restrict access to surfaces somehow, or else they will run rampant, and you don't want that. I mean that you should create the surfaces in separate, more relevant file. other parts of the program that dont need to know about those surfaces dont need to bother including the header(s). one thing you dont want to do is include "main.h" in every single source file, because that's the "i give up" approach to program design. with more thoughtful design, you can figure out which surfaces are meant for which parts of the program. for example, the AI code doesnt need to know about sprites or the surfaces used to draw fonts. sound drivers don't need to know which network protocol is being used, etc..
one thing i adhere to, which works well for me, is that a main file doesnt define ANYTHING. it only acts as the "glue" between all systems, gets the ball rolling, and directs traffic on the highest level. it doesnt need to know how each little part is done, just that it IS done.
Edited by - foofightr on 1/27/00 8:12:49 PM
ZomeonE, I suggest you restrict access to surfaces somehow, or else they will run rampant, and you don't want that. I mean that you should create the surfaces in separate, more relevant file. other parts of the program that dont need to know about those surfaces dont need to bother including the header(s). one thing you dont want to do is include "main.h" in every single source file, because that's the "i give up" approach to program design. with more thoughtful design, you can figure out which surfaces are meant for which parts of the program. for example, the AI code doesnt need to know about sprites or the surfaces used to draw fonts. sound drivers don't need to know which network protocol is being used, etc..
one thing i adhere to, which works well for me, is that a main file doesnt define ANYTHING. it only acts as the "glue" between all systems, gets the ball rolling, and directs traffic on the highest level. it doesnt need to know how each little part is done, just that it IS done.
Edited by - foofightr on 1/27/00 8:12:49 PM
You really need to be careful about declaring global variables. The number of surfaces and buffers that even a small game can use can quickly become unruly.
Typically, I declare my main DirectX interfaces as globals, since they really can be used anywhere. Anything else, I can usually find a better design for them.
Typically, I declare my main DirectX interfaces as globals, since they really can be used anywhere. Anything else, I can usually find a better design for them.
Why not just create one class with all the globals in it, and make functions referencing the globals, member functions of that class? Don''t make the class a global, but create only one instance. That way you get rid of your globals, and are able to group your initializers/finalizers in logical areas of your object. And it doesn''t clutter your header files with any extern statements. If you''re careful even DirectX interfaces can be isolated like this.
Yeah, I wrapped up my main interfaces like that once in a project I was working on. I didn''t really like it though. There aren''t that many main interfaces and I just like the ability to get them as needed. In my opinion, it helps with code readability as well.
> mason, you''re not solving anything by putting all your
> globals in one big, juicy struct.
foo, I totally agree with you... as I said before, global variables bad, classes good.
But... Zomeone didn''t ask for a design critique; he asked for a simple way to access surfaces from all files in his project.
A struct will solve that - instead of making one extern line for each surface, you put all your surfaces in a struct, make an instance of that struct, and make THAT extern. This was a common trick that was used by many C programmers back in the days before OOP.
Off topic rant: When someone asks a question in our forums, the responses tend to criticize their design rather than simply answer their question. This must be irritating to those who asked - maybe they know that''s not the best way to do it, but that''s the way they feel comfortable with, or maybe it''s too hard or too late to change.
So... I''ve taken up a new habit lately... when I answer a post, I now try to stick to exactly what they asked, maybe briefly mentioning other solutions... hoping that after I post, the thread will go on and talk about other solutions.
That, and the fact that I''m just a lazy bastard and don''t want to write out complete responses.
Mason McCuskey
Spin Studios - home of Quaternion, 2000 GDC Indie Games Fest Finalist!
www.spin-studios.com
> globals in one big, juicy struct.
foo, I totally agree with you... as I said before, global variables bad, classes good.
But... Zomeone didn''t ask for a design critique; he asked for a simple way to access surfaces from all files in his project.
A struct will solve that - instead of making one extern line for each surface, you put all your surfaces in a struct, make an instance of that struct, and make THAT extern. This was a common trick that was used by many C programmers back in the days before OOP.
Off topic rant: When someone asks a question in our forums, the responses tend to criticize their design rather than simply answer their question. This must be irritating to those who asked - maybe they know that''s not the best way to do it, but that''s the way they feel comfortable with, or maybe it''s too hard or too late to change.
So... I''ve taken up a new habit lately... when I answer a post, I now try to stick to exactly what they asked, maybe briefly mentioning other solutions... hoping that after I post, the thread will go on and talk about other solutions.
That, and the fact that I''m just a lazy bastard and don''t want to write out complete responses.
Mason McCuskey
Spin Studios - home of Quaternion, 2000 GDC Indie Games Fest Finalist!
www.spin-studios.com
Author
Well, I think it''s good to get some critisism. I wan''t to write better code and I can''t do that by myself, so It''s good with a few tips!
I''ll redesign my post a little:
What is the best way of writing a good code design, including sharing the surfaces with the files that need them?
I''ll redesign my post a little:
What is the best way of writing a good code design, including sharing the surfaces with the files that need them?
Get "Code Complete" by Steve McConnell. Everyone who programs anything after Hello World should read this book. I can''t say enough good things about it.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
