• 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.
  • entries
  • comments
  • views

zoloEngine - Cloud and a walking disease

Sign in to follow this  
Followers 0


Gotta love how easily kids pass along the sickness. I'm a walking disease today, no work, don't want to hang out in fear I'm may be too far from a bathroom ;) So here I am, clean or code... let's code. While were at it lets toot my horn aswell. Yes there is more than one in this head.

Wasn't expecting to start this till tomorrow, but with my situation, I started today anyways. Torn my old render interface a new one and put together the skeleton for the new interface. Be proud of me, I kept the old interface and everything in the engine is still completely intact. There's actually two interface to choose from at the moment. The only thing lacking from the new one, is font and particleSystem support. The old system had a hackish way of using fonts and the particle system was very reliant on the old interface to work properly.

Funny I'm looking at the two headers... old header 145 lines ~15 of it comments... the new header 95 lines ~ half of it comments. That's also including that I incorporated the window, input, and frame timer into the new interface aswell.

new interface

#ifndef _ZECloud_H
#define _ZECloud_H
#include "ZEMath.h"
#include "ZESystemWindow.h"
#include "ZESystemTimer.h"
#include "ZEInputInterface.h"

#include "ZEGraphicsDevice.h"
#include "ZEGraphicsTextureCache.h"
#include "ZEGraphicsEffectCache.h"
#include "ZEGraphicsCamera.h"
#include "ZEGraphicsRenderList.h"
#include "ZEGraphicsInterfaceParameters.h"

ZoloEngine - Cloud
2/2012 - Corey Marquette

namespace zecloud
class Cloud

Default Constructor - This constructor should not be used and will popup a
warning message if it is.

Contructor(...) - This constructor must be used to initialize the engine.
It initializes everything based on the data from a config file.
Cloud(HINSTANCE instance, std::string configFilepath);

Destructor - all cleanup is done here. releasees everything from textures to

Update - calls update on all sub components, and returns false if the engine
has shutdown from any errors. If it has shutdown, the engine should not be used.
bool Update();

Render - processess all renderLists and present to the screen, use this
function after all drawcalls have been made for the frame.
bool Render();

These accessors are meant to be used to create resources for the engine to use
instead of doubling implementations in the interface.
ZEGraphics::TextureCache& TextureCache();
ZEGraphics::EffectCache& EffectCache();

CreateRenderList - adds a new renderList to the queue and gives a pointer back
to be used for rendering. ownership of the RL's still remains with the
engine interface. RenderList are never released until the engine is.
bool CreateRenderList(ZEGraphics::Sprite* renderTarget, bool clearTarget, ZEGraphics::RenderList*& renderList);


ZESystem::Window window;
ZEInput::Interface input;

ZESystem::Timer frameTimer;

// Renderer specific data
ZEGraphics::Device device;
ZEGraphics::Camera camera;
ZEGraphics::TextureCache textureCache;
ZEGraphics::EffectCache effectCache;
std::vector renderLists;



simple, just the way I like it. Starting a new project is as easy as adding a couple directies and creating a winmain file like so.

#include "ZECloud.h"

int WINAPI WinMain(HINSTANCE _instance, HINSTANCE _prevInstance, LPSTR _cmdLine, int _cmdShow)
Engine initialization

zecloud::Cloud cloud(_instance, "data/config.xml");


while (cloud.Update())


return 0;

super simple... me really like. I have the tendency to be creating new projects constantly just to test out new ideas all the time. So having a fast setup proccess is very crucial to me.

The old interface took on a master type role... every sub component had a double set of functions in the interface that would call the actual functions in the sub components. Don't know if that would be considered "PIMPL" or not, eitherway it was cumbersome. Anytime I wanted to add new functionaliy, I basically had to do it twice. Then ownership started to get blurry, which brings up the truth behind font rendering and the particle system. because they are seperate from the render interface, and they should be. They required the interface to render anything. This meant any changes to how the DrawQuad function worked, would effect how those system worked aswell. Especially when I added diffuse coloring to allow quickly changing the fonts colors. I had to dig deep into the rendeerlist, then change things in the interface, then had to change thins in how textures were loaded... it was just a mess.

This time I've centralize, the act of drawcalls to renderList only. Similar to how XNA uses spriteBatch. The interface is no longer required to draw sprites to the screen. It is instead the point were resources are created, and manages the work flow of the system. It's still a major joint in the system, but should facilitate changes better.

The one hurdle I'm still contemplating, is the difference between translated and untranslated coordinates. My camera is run in software, so its simple enough to just skip it when process translated coordinates. ie for things like the UI or other screen aligned sprites. I'm not sure if I want to store a tranlated flag in the drawcall struct or make it global and keep it in the renderList class. The former would allow alot of flexibility, but require an if branch for every drawcall (upwards of ~150K per frame). Keeping it in the renderList would mean only one if branch per renderList, but also means more work for the user (me). Creating seperate renderList for translated and untranslated rendering. I'm leaning towards the later, since I kinda already do this... but not always. and could easily lead to renderlist with only 10-20 calls stored, but requirring that many state changes. Defeating the purpose of batching.

This will also problably mean more clutter in the draw function. I've been trying to minimize the require arguments over time, so I really didn't want to add more. Should I just create seperate function for translated and untranslated? Probably not.

RenderList.DrawQuad(position, size, sprite, shader, rotation, diffuse, translatedFlag)

not too bad I guess.

Another big change for me, is moving from only translated coordinates, to using world coordinates then letting the camera translate these. I've been comtemplating letting the engine do all the culling instead of doing it in game logic. Should this be done early at the point when drawQuad is used or later when the renderer starts processing the renderLists? I'm thinking early, but this can have problems. Take for example, we make some drawcalls that get rejected for being outside the camera, but before processing the renderLists, we move the camera and the old calls would be in view now. This would cause were popping, were objects aren't visable for a split second, then suddenly are. But would also keep the RenderLists at resonable sizes. They have always been a bottle neck in the pipeline, so anthing to make them a little quicker is beneficial... it's just the drawbacks are icky.

for the weirdos out there, heres the old interface for comparison and a look into my madness.

#include "ZEGraphicsInterfaceParameters.h"
#include "ZEGraphicsTextureCache.h"
#include "ZEGraphicsEffectCache.h"
#include "ZEGraphicsDevice.h"
#include "ZEGraphicsCamera.h"
#include "ZEGraphicsRenderList.h"
#include "ZEGraphicsSprite.h"
#include "ZEGraphicsColor.h"
#include "ZEVector3.h"
#include "ZEVector2.h"

namespace ZEGraphics
/** DEBUG information struct. */
struct DI_Interface
: drawPrimitiveCalls(0),
largestBatch(0) {


void Clear() {
drawPrimitiveCalls = 0;
trianglesDrawn = 0;
smallestBatch = 0;
largestBatch = 0;

DWORD drawPrimitiveCalls;
DWORD trianglesDrawn;
DWORD smallestBatch;
DWORD largestBatch;

/** Graphics API main Interface. */
class Interface

ZEGraphics::Device device;

ZEGraphics::Camera* camera;
ZEGraphics::TextureCache* textureCache;
ZEGraphics::EffectCache* effectCache;

std::vector renderLists;
IDirect3DVertexBuffer9* vertexBuffer;


ZEGraphics::DI_Interface dInfo;

/** Data used by the deferred lighting pipeline. */
ZEGraphics::Sprite gbNormals;
ZEGraphics::Sprite gbPositions;
ZEGraphics::Sprite gbColors;

DWORD gbShader;
DWORD dirLightShader;


ZEGraphics::InterfaceParameters parameters;

Interface() { };
~Interface() { this->Release(); };

int Create(HWND _windowHandle, ZEGraphics::InterfaceParameters& _paramters);

/** Display will process all the renderlists. Internally it will run these lists through the desired pipeline, specified by the renderList. */
void Display();

/** Specific pipeline for rendering the drawcalls. */
void DefaultPipeline(DWORD rl, IDirect3DTexture9* _texture, DWORD _shader, UINT _primitiveCount, bool _isTransparent);

/** Release... releases all the allocated resources. */
void Release();

/** Drawing functions for drawing textured primitives. */
void DrawQuad(DWORD _renderList, ZE::VECTOR3 _pos, ZE::VECTOR2 _size, ZEGraphics::Sprite* _sprite, DWORD _shader, ZE::VECTOR3 _rot, ZEGraphics::COLOR _diffuse);
void DrawQuad(DWORD _renderList, ZE::VECTOR3 _pos, ZE::VECTOR2 _size, ZEGraphics::Sprite* _sprite, DWORD _shader, float _alpha);

/** Texture loaders. */
ZEGraphics::Texture* CreateTexture(std::string _filename, D3DFORMAT _format, bool _transparent);
ZEGraphics::Texture* CreateRenderTarget(int _width, int _height, D3DFORMAT _format, bool _transparent);

/** Effect Loaders */
bool CreateEffect(std::string _file, DWORD& _index) {
if (effectCache == NULL)
return false;

return effectCache->CreateEffect(device.direct3DDevice, _file, _index);

/** Deferred Lighting interface. */
bool SetupDeferredLighting();
void BuildGBuffer(LPDIRECT3DTEXTURE9 _texture, UINT& _primitiveCount);
void ProcessLights();

/** The renderer stores pointers to a light source, so that it can be moved easly outside the renderer.
The renderer won't cull the lights so it's up to the user to remove lights that are no longer visible. */
void AddLight();
void RemoveLight();
void ClearLights();

/** Misc resource loaders. */
DWORD CreateRenderList(ZEGraphics::Sprite* _renderTarget, bool _clearTarget);

/** Resource access. */
ZEGraphics::EffectCache* EffectCachePTR() { return effectCache; };

/** Debug info. */
ZEGraphics::DI_Interface& DebugInfo() {
return dInfo;

void ClearDebugInfo() {

/** anchors return the screen position at the specified position. */
ZE::VECTOR3 anchorTopLeft();
ZE::VECTOR3 anchorTopCenter();
ZE::VECTOR3 anchorTopRight();
ZE::VECTOR3 anchorCenterLeft();
ZE::VECTOR3 anchorCenter();
ZE::VECTOR3 anchorCenterRight();
ZE::VECTOR3 anchorBottomLeft();
ZE::VECTOR3 anchorBottomCenter();
ZE::VECTOR3 anchorBottomRight();




Tomorrow I bother you again about the renderLists, the backbone to my renderer... its a yordle, run!

Sign in to follow this  
Followers 0


There are no comments to display.

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