Advanced C++/Graphics Tutorial 19: Namespaces, Window

preview_player
Показать описание

Today we learn about namespaces and how to use them to encapsulate our entire game engine in a named scope! We also make our own window class that wraps the SDL window :)

Рекомендации по теме
Комментарии
Автор

Hey Ben... I'm loving your tutorials so far! Just wanted to say thanks for doing this :)

lukecxu
Автор

Hi all! Just to point out, if you named the FatalErrors file we have written in the past couple of lectures ago either "Errors.h" or "errors.h", after adding the 2nd project(Bengine) your graphicsTutorial project will stop to compile, throwing at you a compilation error saying WINAPI undeclared. The reason of this happening is that in VS2013, there is a built in .h file called "errors.h" file that will take priority in terms of inclusion. To solve this problem, change the errors.h module into something else. I don't know why it works here in the video, but it doesn't work on my Windows8. Also, if you started from a clean installation of VS and OpenGL, you might have to also copy the "Additional Include Directories" into Bengine's property menu as well.

yandayixia
Автор

Great tutorial! It really feels like a game engine properly wrapped under a common name. :D

I'd like to point out for those using Code::Blocks: This IDE is really annoying, if you get stupid "file not found" errors whenever structurally changing the engine (like wrapping everything inside a namespace), try closing the IDE and saving changes when prompted, then delete the *.layout file, and re-open the project. You should be able to build everything fine.

paulocbbf
Автор

Just a note for everyone: Using the flag SDL_WINDOW_FULLSCREEN_DESKTOP with a resolution set that is different from the native resolution will screw up the mouse coordinates that SDL spits out. So if you want to be able to use resolution that has different aspect ratio than your native resolution you should also implement the flag SDL_WINDOW_FULLSCREEN which will set the proper resolution instead of using the desktops resolution.
This really gave me headaches when testing my GUI with different resoltutions.

Mal_
Автор

Thanks so much for making these videos!
You've motivated me to clean up my own engine code, and you've given me some great advice too ^_^

LeviG
Автор

i made the flags work much more straightforward and simple:
enum windowFlags
{
NONE = 0,
FULLSCREEN = SDL_WINDOW_FULLSCREEN,
INVISIBLE = SDL_WINDOW_HIDDEN,
BORDERLESS = SDL_WINDOW_BORDERLESS,
RESIZEABLE = SDL_WINDOW_RESIZABLE,
MINIMIZED = SDL_WINDOW_MINIMIZED,
MAXIMIZED = SDL_WINDOW_MAXIMIZED,
INPUT_GRABBED = SDL_WINDOW_INPUT_GRABBED,
INPUT_FOCUS = SDL_WINDOW_INPUT_FOCUS,
MOUSE_FOCUS = SDL_WINDOW_MOUSE_FOCUS,
MOUSE_CAPTURE = SDL_WINDOW_MOUSE_CAPTURE
};

and then passed flags| SDL_WINDOW_OPENGL to SDL

it simply maps one enum to the other, so when switching to DX(for example) you would just replace the SDL_WINDOW constants with the ones DX uses

i also added an auto-build script for the engine so you don't have to worry about it being outdated:

EDIT: i've found a better way to auto-build the game engine along with the game itself:

- right click the top-most solution file and go to properties
- select project dependencies
- from the "projects" drop-down select your game's project
- ensure the checkbox next to your game engine is selected

this version works well enough that even if you've only changed something in the game engine and your game is still up-to-date, a simply f5 will cause VS to rebuild both the engine AND the game to ensure they're both up-to-date

OLD VERSION, DISREGARD BUT IT MIGHT BE HELPFUL TO KNOW REGARDLESS:


under the game's properties (so your startup program, not the game engine) go to:
Configuration propertoes -> build events -> pre-build event

then under "command line" enter:
msbuild /p:Platform="x86/x64"

is the .sln file in your solution's root folder
is the project name for your game engine

for debug/release and x86/x64 pick the build configuration you want your game engine to use (i'm using release/x64, but if you're following the tutorial strictly it would be debug/x86)

now this will only work when it's building the game, but it's something


as a final note, you think 20 episodes to create a game engine is a long time? heck i've only been following this tutorial and messing around plenty and i've gotten here in about 1 week, that's CRAZY fast considering i had almost 0 experience with C++ (and that i was under the impression making even a basic engine like this took months XD)

siriusblack
Автор

Might be just me, but I never use 'using namespace xxxyyy'
Using std:: or Bengine:: or ... seams, a lot better, since you learn a lot more about libraries and to wich you are actualy linking to and why. You really get to know what you are using and why. And in 2 - 3 programs you don't even notice you are putting aditional std:: or glm::, ... . Just my humble opinion. AND ALL PRAISES to Ben for making C++ insanely simple and easy to understnd.

sParadox
Автор

All compiled fine under CodeBlocks, thanks, it's been educational.

I am wondering if we couldn't have simply put: "using namespace Bengine;" at the top of the Bengine .cpp files?

NeilRoy
Автор

Hey Ben! Do you think it's better to name the engine lowercase or does it not matter? Sorry if you mentioned this in later tuts

smodman
Автор

using namespace is considered bad practice in header files, but I think it's ok to use it in cpp files since the cpp code is never actually seen by the project that uses the library. I only use it for my engine namespace though, never for std. If this is wrong, please let me know.

andreweastplateau
Автор

Yay! We build an engine!
Also: I didn't like superlongnamespace::Sprite
using namespace is bad practice(then we shouldn't have done this obviously)
So I looked up on google and I found a way:
namespace system = superlongnamespace;
You can call it now like this: system::Sprite
Is this also a correct way?

DJoppiesaus
Автор

Inside the init() function, i want to keep the code the code that prints the opengl version and glsl version. Why does glGetString(GL_VERSION) there crash the program?

jhlcompositions
Автор


EDIT: Scratch that, if anyone else has this error, remove example decoding function at the bottom of picoPNG.cpp.

redspah
Автор

Instead of wrapping my .cpp files with   namespace Benging {}I used   using namespace Bengine;Is this still a valid method of achieving this in terms of code convention.

zacharyshepherd
Автор

Anytime I try changing the directory to just (SolutionDir), I get a whole bunch of really weird errors from a file called error.h in the program files (x86) folder

davidpyle
Автор

I am unable to pass in any flags for the window even if I pass in Visual studio recognizes the enum, but passing any of them in doesn't seem to do anything.

BillyBob-xofc
Автор

Hi Ben, My main game is loading my engine, [namespace=lwavery], which builds fine, but the Compiler states:
function
reference to `SDL_CreateWindow'|... an 14 more undefined reference errors. Is it a linker error in the engine, or in the game?

lwavery
Автор

You could just type "using namespace Bengine;" (no quotes) at the top of the .h files in the GraphicsTutorials project.

Zoku
Автор

the link to the source code is not working

Автор

when changing $(SolutionDir)Bengine/ to $(SolutionDir) i get build messages saying there are errors in errors.h example:

error C2065: 'WINAPI' : undeclared identifier    c:\program files (x86)\windows kits\8.1\include\um\errors.h

But changing it back to $(SolutionDir)Bengine/ stops those errors from coming up. Just have to #include <GLSLProgram.h> and not #include <Bengine/GLSLProgram.h>

Not sure what is causing these errors. just a heads up.

Using Visual Studio 2013 ULT

TheNeutralNoise