Developing Ronimo s multiplatform graphics engine Joost van Dongen

Developing Ronimo's multiplatform graphics engine Joost van Dongen Co-founder Lead programmer

Ronimo Games Currently 21 people (7 coders) Utrecht city centre Exists over 7 years now Indie game developer De Blob, Swords & Soldiers, Awesomenauts, Swords & Soldiers 2

Joost van Dongen Lead programmer and co-founder Studied Game & Media Technology And Game Design & Development at HKU Also hobby games: Proun, Cello Fortress

Video? Video!

Awesomenauts 2 D MOBA League of Legends + Super Smash Brothers Over 1. 7 million copies sold 3 VS 3 online Fast action game Launched mid-2012 Very active user base

2 D games tech Often underestimated compared to 3 D Many things similar: certification, file handling, online multiplayer, etc Just as interesting!

Console development

Normal programming Standard C++ Normal Visual Studio Special compiler

Deviations from C++ standard Visual Studio adds to C++ standard Other compilers do not Cannot use those extras Differences: std: : vector> #include inline for templates

Pragma Cannot use #pragma once Must use this instead: #ifndef MYCLASS_H #define MYCLASS_H //code goes here #endif

Other APIs Biggest difference Special APIs for all kinds of things File access, graphics, sound, controllers, networking, etc

Multiplatform Must write specifics for every platform! Or use existing engine (Unreal, Unity, etc) Or partially use specialised middleware (e. g. FMOD)

Compiling multiplatform Must hide platform-specific code behind defines

void write. File(const std: : string& text) { #ifdef _PC std: : ofstream. write(text); #elif _X 360 x. Write. Data(text); #elif _PS 3 nin. Write(text. c_str()); #else implement_me; #endif }

Practical multiplatform Big challenge: how to structure this? Huge structural differences per platform Lots of platform-specific code Must keep as much multi-platform as possible

Our structure Example class structure for file handling: As much as possible in File. Tools itself Similar systems for other topics

class File. Tools { virtual void write(string) = 0; }; class PS 3 File. Tools: public File. Tools { virtual void write(string) { //blabla real code yo } };

File. Tools* create() { #ifdef _PC return new PCFile. Tools(); #elif _PS 3 return new PS 3 File. Tools(); #else implement_me; #endif }

Console certification Console manufacturers test game extensively Must adhere to certification requirements Long lists Hundreds of detailed requirements Months of work per platform!

Example requirements "Pause game if controller disconnected" "Do not crash" "Load in less than 30 seconds"

Consistency requirements Not all requirements make sense from developer's standpoint Make experience similar across platform "Home menu always accessible" "Use standard terminology"

Console development flow Gain development license for console Order devkits Ask for concept permission Get age ratings Send in for certification Get failed for stupid oversight or lame detail Make fixes Send in again Wait for release slot

Limited RAM Traditional challenge on console Much less RAM than on PC Won't overflow onto hard disc when out of RAM Less of an issue on PS 4/XBox. One Big challenge on Wii/360/PS 3 (88 / 512 / 2 x 256 mb)

Graphics API differences

Graphics API Library for communicating with videocard Call functions to render triangles, use textures, etc

Per platform PC: Direct. X, Open. GL, Mantle Mac / Linux: Open. GL i. OS / Android: Open. GL ES PS 3: Open. GL, GCM X 360: Direct. X 9 Wii: GX Wii U: GX 2 Special versions of GL and DX per platform!

Similarities Basic primitive is always triangle Textures Hardware is similar, so APIs wrap around similar concepts

Differences APIs do same thing differently Each console has special hardware features Some consoles lack major features

API difference: texture sampling

API difference: texture sampling GL: per texture DX: per stage For performance must only set when needed Must decide differently per platform gl. Tex. Parameteri(GL_TEXTURE_2 D, GL_TEXTURE_MIN_FILTER, GL_LINEAR); device->Set. Sampler. State(texture. Index, D 3 DSAMP_MINFILTER, D 3 DTEXF_LINEAR);

Speed Consoles are slower than PCs. . . but targeting specific hardware gives huge boost Also much more efficient drivers Plus economics: no one targets high end PCs

Texture handling Console: just memory PC/Mac/Linux: abstracted, no direct access Console: notify that piece of memory is texture PC/Mac/Linux: copy texture to video memory Much more control, much faster streaming on console

EDRam Xbox 360 only 10 mb of super fast GPU memory Benefit: super fast Downside: super small Full HD with anti-aliasing requires two render passes Much more complex with deferred shading

Shaders Direct. X on 360: HLSL Open. GL on PS 3: Cg Need to write all shaders twice? Nope: languages are 90% same Can make everything without touching differences

GLSL shaders GLSL is different Still very similar Required on Wii U and i. OS We modified Cg shaders by hand

No shaders on Wii was technically a Gamecube Technology from time of Napoleon No shaders Instead the ultimate puzzle fun: TEV stages!

TEV stages Repeat this 16 times: out = a*(1 - c) + b*c + d Set what a/b/c/d/out are per stage Can switch states to: if(a. r > b. r) out = c; else out = d; Can do surprisingly much Difficult puzzle for advanced stuff!

PS 4 and Xbox One Boring hardware Just really fast PCs Awesomenauts port outsourced to Abstraction I don't know API details

Ronitech rendering structure

Inspired by Ogre Basic structure inspired by Ogre engine Object oriented C++ graphics engine Extremely neat class design Great engine, good low level access Few tools for modern standards Used for De Blob, Snowball Earth, Proun, Cello Fortress

Renderable Core object for rendering Functions like these: set. Position set. Scale set. Parallax set. Texture. Wrap set. Blend. Mode set. Colour

Flexible for GPU types Basic structure not based on shaders Properties can be implemented in various ways Shaders of course used on most platforms Looks exact same on Wii without shaders! set. Texture set. Colour. Combine. Mode //add, multiply, blend, etc set. Secondary. Texture. Operation

Inherited to provide geometry virtual void get. Vertices(Vector 2*& vertices, Vector 2*& texture. Coordinates 0, Vector 2*& texture. Coordinates 1, unsigned int& count, bool& is. Tri. Strip) = 0; Implemented by various shape/geometry types: Rectangle Circle Render. Text Particle. System Terrain

Automatic registration Scene. Manager keeps track of all Renderables Renderable registers itself automatically Renderable: : Renderable() { Scene. Manager: : get()->add. Renderable(this); } Renderable: : ~Renderable() { Scene. Manager: : get()->remove. Renderable(this); }

Rendering order Everything has alpha in a 2 D game Must render back to front Order by parallax and depth

Viewports Viewport defines part of screen to render to Viewport has a camera Viewport has a Render. Group Automatically renders all Renderables in that Render. Group

Flexible Viewports Not just for splitscreen. . .

Flexible Viewports. . . also for overlays and such

Performance

Performance Videocards insanely fast Can draw 1000 objects per frame at 60 fps Our main performance bottlenecks: CPU in general Fillrate

Fillrate Number of pixels drawn per frame or second 1920 x 1080 screen: 2073600 pixels Need to draw them all every frame No problem for modern videocard

Overdraw Drawing the same pixel several times Transparent objects like glass or smoke Rare in 3 D games, super common in 2 D games Quickly 10 x overdraw or more Video! Video?

Modifying art assets

Rendering background at low res Background in Awesomenauts is blurred Improves visual focus and clarity Looks really good Can render background very low-res! Massive overdraw reduction

Multi-threading

Modern consoles Modern consoles have many CPU cores Newest generation is simple: just a bunch of cores Previous generation more complex: SPUs on PS 3 How to use these efficiently? Limited time to spend because small indie studio

Basic multi-threading approach Don't use multi-threading Ignore the other cores Ignore the SPUs Ignore compute shaders Fine for most games (not for AAA of course)

GPU timing GPU is like an extra thread Runs any commands you feed it Commands go into queue, fire-and-forget How is the timing of that?

What I thought (wrong!)

What it is

Must analyse No use optimising GPU if CPU bound And other way around Must accurately measure before optimising!

PS 3 performance trouble PS 3 heavily reliant on SPUs Main cores are slow Couldn't get good framerate on just one core

What to multithread? Multithreading gameplay too difficult No heavy fluids/physics/lighting More doable: split renderer to separate thread

Multithreading renderer Cross-thread GL/DX calls not allowed Must split gameplay and renderer Gameplay updates for next frame while rendering previous frame Must keep copies of all objects

Awesomenauts threading model This all happens on CPU! GPU not shown here

Tools

Video! Video?

Character animation Art in Photoshop Animate in After Effects Mostle deformation/skeletal, some frame-toframe

In-engine animation Mostly special effects Particles Squash/rotate/skew Recolours Everything animated In-game Animation and Particle editors

The power of recolours Video! VIDEO!

GPU compatibility

PC videocards vary a lot Several types (Nvidia, AMD, Intel) New types every year Many driver versions New versions of Open. GL / Direct. X Random feature differences Random rare bugs Must support them all!

2 D relatively simply here No need for advanced stuff like compute shaders Can just skip most difficult compatibility topics

Testing Test on varied PCs Ask friends to test Closed beta close to launch

In-house testing Ultimate test-case: very old Intel cards Suck at everything If these run, almost everything will Intel GMA 950, 2005

Our approach Fix issues Work around weird bugs Add LOW graphics quality for super bad cards Result: Awesomenauts runs on REALLY crappy Netbooks

NPOT Non-power-of-two textures Supported for ages Except by old Intel cards Only do 1024 x 512, 64 x 64, 128 x 256, etc Rescaled ALL textures for SD Half resolution, power-of-two, very little video memory 1 gb to 400 mb

Render textures Not supported on old Intel cards Game significantly uglier Still wanted to support such cards

Ati x 900 Old videocards Lie about their features Had to recognise by name and make special shaders for Proun

Asus laptops Certain series only Cannot initialise Open. GL at all Needed to add Direct. X option to PC Also fixes for people with broken drivers

Wrapping it up

Ronimo looking for interns September: C++ programmer on Awesomenauts February: New positions in February C++ coder, 2 D art, game/level design Minimum 4 months, no research thesis projects

Conclusion Console development is just normal C++ With special secret libraries Very high technical requirements through certification Big challenge: keep as much code multiplatform as possible

? Questions? Development blog: www. joostvandongen. com