
e36e6a35c65c19593fc5406749c2ef45.ppt
- Количество слайдов: 85
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
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