• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Muzzy A

A question about where to store the Camera!

11 posts in this topic

Hi, I'm building my own little renderer and there's a couple things that I get undecided about.

 

Where exactly do most of you store things like the Camera and Projection matrix?

I've seen and tried several different ways of doing so, but I'm not satisfied by any of them.

  • Save it in the renderer, pass them as parameters to the render functions - Probably the best way, but I don't want Parameters!
  • Make a singleton for the camera ( HORRIBLE! ) to access it anytime.
  • Make a static variable in the render objects that holds a reference to the camera and projection matrix.

 

I'm just a little curious at how others would do this minor little thing.

0

Share this post


Link to post
Share on other sites

I don't really have a problem with it.  I've just been turning into a clean freak lately when it comes to code and when I see methods with more than 1 or 2 parameters I'm like ARRRGGHH! But like I mentioned, I know it's probably the best way to go about it overall lol.

0

Share this post


Link to post
Share on other sites

I am storing the parameters in "camera"-classes which are modifying the view directly when they get called at the beginning of every drawing.

 

This allows easily to change the "active camera" when needed as well as supporting multiple-monitors, split screen, mirros and camera screens.

 

This is what object orientated programming is for that is why those languages were developed.

Those static parameters or the use of singleton is so often misused for OO-languages and this case is not an exception. Singleton is really the badest idea of all of them; static just destroys your OO-environment.

 

When you start thinking about how many ticks you can spare by using fewer methods calls and objects, you have already lost.

If this should be really a matter then you are using the wrong language for your task.

Edited by IceCave
2

Share this post


Link to post
Share on other sites

Depends on the game.

 

For some games, the camera is just another scripted game object. It has a component of Camera type, which specifies all the parameters. You can have many of them. Typically one is active at a time, but with split-screen or PIP you can have more than one active at a time.

 

See now this is something that I would be satisfied with!  I think this will be how I manage the camera/camera's.

 

I am storing the parameters in "camera"-classes which are modifying the view directly when they get called at the beginning of every drawing.

 

This allows easily to change the "active camera" when needed as well as supporting multiple-monitors, split screen, mirros and camera screens.

 

This is what object orientated programming is for that is why those languages were developed.

Those static parameters or the use of singleton is so often misused for OO-languages and this case is not an exception. Singleton is really the badest idea of all of them; static just destroys your OO-environment.

 

When you start thinking about how many ticks you can spare by using fewer methods calls and objects, you have already lost.

If this should be really a matter then you are using the wrong language for your task.

I agree with you, but this isn't about performance or OOP, well I guess it is about OOP... but It's all about writing clean flexible code. frobs described the EXACT thing that I've been looking for.

0

Share this post


Link to post
Share on other sites

I usually have Camera objects that are Nodes in my scene tree. Other nodes are Geometry, Lights, etc. By having the camera in the scene tree, they are in the scene hierarchy and their position can be relative to any object in the scene. Or I can animate the Camera, or whatever.

 

Then, in my renderer, I have an attribute that is the active camera, the one actually being shown in the screen right now. Whenever I want I can just pass the camera using a "setActiveCamera()" function to the renderer, and that's the one used.

 

Concerning the projection matrix, I store it in the Camera. Concerning the view matrix, it is just the transformation of the Node class...

Edited by Javier Meseguer de Paz
0

Share this post


Link to post
Share on other sites

From rendering perspective, there need be no camera, just a view matrix. Pass view and projection matrices into methods that do rendering (packed together if you like) then camera need only exist at the point where the view matrix is calculated (matrices are just local variables now).

 

For example, I tend to divide games into Modes (GameMode, MenuMode etc) and have an Application class that calls abstract methods on a BaseMode interface. Camera can now exist as member of the GameMode object and is used inside GameMode::render(GraphcisDevice&) to create the view matrix. Scene objects are then passed it via SceneObject::render(GraphicsDevice &graphics, const Matrix &view, const Matrix &proj) etc.

 

Camera can then be separately passed to Entity interfaces to update the camera to centre on the player or move it with the player's motion etc but this is entirely removed from rendering subsystem then.

Edited by Aardvajk
1

Share this post


Link to post
Share on other sites

The camera is a scene object like any other object in your game.  It exists as part of the scene graph and can attach to other objects as a child or have objects become a child of it.

You will typically have a “scene manager” which manages all the objects in your scene, and as such the camera would be registered with the scene manager.  Any number of cameras can be registered with the scene manager so you can do split screens, cuts, etc.

 

Cameras have projection and view matrices as members of their class.  These need to be passed to the rendering system once per scene render.

 

 

L. Spiro

2

Share this post


Link to post
Share on other sites

I am not a fan of cameras being a component or an entity.  I do make them using a class and have helper functions for culling etc but they live in thier own hierarchy outside of my object system.  I have found it's better for things to have a reference to a camera instead if they really must.  Now where the camera is created and stored will be specific to your game.  Create in your script perhaps and make it the currently active camera in the world is the simplest and may be enough for your game.  It's hard to say without seeing everthing and know the scope f the game.

 

The most important part of this question IMHO is the rendering part and I would say without a doubt it should be passed to the rendering functions.  I have a RenderJob I pass around and it's main purpose is for multi-threading but it does also hold a reference to the camera, lights, rendertarget etc.  This is more flexible for rendering objects.  I use the same render call with a different job to render an entity to a texture and use it in my ui as I do for rendering in the actual world.

0

Share this post


Link to post
Share on other sites

I like the idea of using the camera like a scene object, I never would have thought to use it like that. It makes everything go together smoothly and there isn't code in random places for the camera. To me a hierarchy beats having references all over the place any day. I guess it's all about preferences.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0