• 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.

Simon_Roth

Members
  • Content count

    67
  • Joined

  • Last visited

Community Reputation

149 Neutral

About Simon_Roth

  • Rank
    Member
  1. Hi I'm trying to get a lot of light data into a shader to perform deferred lighting. The lighting system populates the screen with 32*32 tiles, which are drawn instanced onto the screen. Each tile needs to be fed the data for 8 point lights. I'm struggling to get my head around how to get the data to the shader in GLSL. Currently I have a large UBO with all the tile light arrays in, and can rebind the UBO at the correct data struct for each tile. However, when doing this, I can't use a single instanced call. So thats not fast enough. Is there any way I can just bind the whole UBO? Trying to define a large array in GLSL (understandably) causes the shader not to link. I know I can do this relatively easily by packing the data into a texture, but I'd like to know if there is a more intuative way that fits the uniform paradigm.
  2. [quote name='thedodgeruk' timestamp='1322181866' post='4887462'] i not sure what your asking here , im part way through doing my engine for my final year degree , and what you are asking is the whole system by sound of it you say you have done several renderers before , go back a nd find out were they fell short of the idea you had , you need to make it so its loose coupling and easy to change. [/quote] Yeah I'm a bit all over the place at the moment so I'm kinda using the forum to get my thoughts down, whilst letting people pick them apart. In everything I've had, we always put features ahead of implementation... everything I've made looks great and runs fast, but the code was pure sin. Agreed on the loose coupling, I think I may try to use lots of interfaces to create "firewalls" between systems. Theres a price to pay in performance, but hopefully it will be offset by the gains from having a well engineered renderer,
  3. [quote name='Hodgman' timestamp='1322189671' post='4887484'] [quote name='Simon_Roth' timestamp='1322155362' post='4887323']We also want shaders and textures to be able to be swapped in at realtime. No company I've ever worked at has managed to make that happen as fluidly as the artists would like, what design considerations would you make to make it easier? My first thought is a material manager which would centralise the change over.[/quote]IMO, this is a must-have feature for any modern game engine. As long as there is a level of indirection between your game and your actual resources, this should be really simple to implement. e.g. if the game has pointers to "resources", which themselves point to the underlying swappable resources: [font="Courier New"]struct Texture { InternalTexture* asset; };[/font] [quote]The core render would sit on a separate thread and run continuously. Render calls would be sent via an interface on the game thread and communicated via a buffer. Perhaps a lock-less ring buffer of some sort, or a set of buffers set to ping-pong.[/quote]This is a huge red-flag for me -- no low level module should not dictate your threading policy. If I want to run it in the same thread as my game logic, or in it's own thread, or spread over 8 different threads, I should be able to. Fair enough if some parts of it have to be run by one thread only ([i]e.g. the part that actually submits commands to the GPU[/i]), but if those parts are documented as such, then I can choose to build a [i]renderer-in-it's-own-thread-with-a-message-queue[/i] model on top of it if I wanted to ([i]which I don't, because one-thread-per-system designs don't scale and waste resources[/i]). [quote]Calls would be made by providing a function (pointers or handles to) a mesh object, a material (shader + textures), a culling volume, a transform and an ID of the targeted rendering stage. How would you organise your shader uniforms? In terms of organisation it makes sense to have them inside the material bundle, however that means different objects will need different materials increasing the amount of binds I will need to do. If I keep them separate then models using the same material can skip its shader and texture bind stage, but that leaves the question of how to neatly deal with uniform variables.[/quote]There's nothing special about transforms that should elevate them to a core concept -- they're a shader uniform just like material parameters. Same goes for materials, they're just a collection of required state-changes and shader uniforms. Moreover, transforms and material settings are not the only uniform parameters -- also included are skeleton poses, lights, environmental settings, per-game-object states, etc... So this all seems way too high-level and specialized for a core rendering library. I would have the lower level submission API take in bundles of state + draw-calls. State can include the binding of cbuffers ([i]which are groups of uniform parameters[/i]) and textures. You can then build higher level concepts, like common transform groups, or materials, on top of these basic primitives. [quote]The renderer will be deferred, with a latter forward stage for transparent objects.[/quote]This again is a red flag for me. The rendering library shouldn't dictate what kind of pipeline I'm allowed to implement with it -- the pipeline needs to be able to change from game to game, and be easily changed over the life of a single game's development. The core rendering library should be agnostic as to what kind of pipeline you build on top of it.[quote]I'm thinking I will make the render passes system reasonably generic, with no "fullscreen effect manager" or other classes to differentiate between pass types. The passes will probably be broken down into 3d and 2d/compositing. I will probably create a node based system that is scripted via XML with a series of inputs and outputs.[/quote]If you build this kind of system, then you should also use it to implement your deferred/forward rendering logic, to address the above point. [quote]Since I'm not sure if I'm going to get pre-culled data from the game engine yet I'm not sure if I'd implement it. Most likely it will just be a Frustum-sphere/AABB test.[/quote]Yeah I would expect the engine to have a scene management module (separate from the renderer), which can determine the visible set of objects that need to be rendered. [/quote] Cool thanks. Good points. I'm surprised anyone could untangle my post. I was very tired when I wrote it. hehe. On the deferred shading point I meant the implementation I'll be creating in the the game would be deferred since I'll be using the engine for that. I absolutely agree that I don't want to dictate a pipeline. As for the threading policy I agree, although is dictation that bad for an engine targeted at specific platforms? Since I will need a low level generic interface for the graphics hardware API, I guess that would allow the renderer to use that interface from any thread anyway, so as long as I design it right I guess I'm OK there. Is the message queue +thread idea that bad in terms of an implementation? I've found it reduces the complexity whilst giving reasonable performance. I've seen a lot worse in modern games... Halo Reach copies the entire game state over to the rendering thread every frame! Excellent point on the transforms, I guess I've always written stuff for people learning to code (or been learning myself) so have presented them with a obvious interface. Building it from the ground up from the lower level API sounds like a better idea than the top down fluffy approach I was planning on taking. Thanks for your thoughts
  4. So if you read my last thread I'm looking into renderer design for an upcoming project. Having decided to roll my own I'm now looking for good resources for designing a such system. This thread is going to be something of a ramble! Since I am doing this for a AAA quality game it has to work, but I am also doing it for my doctorate so I have to defend and reference any of my choices, even ones made in my gut. Any book suggestions would be great. I already use the GPU Gems series and Games programming Gems series with Game Engine Architecture, and Game engine Gems 2 in the post. So far, while there are tons of great titbits of knowledge to be found, a nice rounded next gen architecture hasn't been documented anywhere to my knowledge. I'm no stranger to building renderers, but often I find my designs fall short at implementation. Heres areas I need to consider: [b]Interface:[/b] The core render would sit on a separate thread and run continuously. Render calls would be sent via an interface on the game thread and communicated via a buffer. Perhaps a lock-less ring buffer of some sort, or a set of buffers set to ping-pong. Calls would be made by providing a function (pointers or handles to) a mesh object, a material (shader + textures), a culling volume, a transform and an ID of the targeted rendering stage. How would you organise your shader uniforms? In terms of organisation it makes sense to have them inside the material bundle, however that means different objects will need different materials increasing the amount of binds I will need to do. If I keep them separate then models using the same material can skip its shader and texture bind stage, but that leaves the question of how to neatly deal with uniform variables. We also want shaders and textures to be able to be swapped in at realtime. No company I've ever worked at has managed to make that happen as fluidly as the artists would like, what design considerations would you make to make it easier? My first thought is a material manager which would centralise the change over by tracking relationships between assets etc at for a small overhead in artist's builds. [b]Render passes:[/b] The implementation of the renderer in the game will be deferred, with a latter forward stage for transparent objects. We will have perhaps more than 20 passes in some frames so I need to build a compositor that artists can access and fully control. I'm thinking I will make the render passes system reasonably generic, with no "fullscreen effect manager" or other classes to differentiate between pass types. The passes will probably be broken down into 3d and 2d/compositing. I will probably create a node based system that is scripted via XML with a series of inputs and outputs. [b]Culling:[/b] Since I'm not sure if I'm going to get pre-culled data from the game engine yet I'm not sure if I'd implement it. Most likely it will just be a Frustum-sphere/AABB test. I'll add to this as I think of more issues for the design. -Si Edit: Clarified my tired ramblings a bit.
  5. OpenGL

    You will certainly want a good noise algorithm even for a tile based world. A RNG will only give you a mess where noise combined to give turbulence will give good effects.
  6. [quote name='DTR666' timestamp='1320776267' post='4881836'] Thank you for your tips ! I will make more tries with CSM / static shadow maps. Cheers ! [/quote] How many splits are you using in your CSM? What res maps and where is the bottleneck occurring that's slowing it down? -Si
  7. [quote name='PolyVox' timestamp='1320794678' post='4881918'] I would also be interested in knowing about any lightweight open-source graphics engines. I'm not so interested in full game engines as there are lots of those, and I'd rather handle integration myself. Some ones that I've found include: [url="http://www.horde3d.org/"]Horde3D[/url] [url="http://www.visualizationlibrary.org/"]Visualization Library[/url] (Ignore 'visualisation' in the name - it actually appears quite [url="http://www.visualizationlibrary.org/documentation/pag_key_features.html"]low level[/url]) [url="http://www.linderdaum.com"]Linderdaum[/url] (more restrictive license) [/quote] Cool those are useful thanks. I've found out today that Torchlight is using Ogre and Hand circus used it on their indie titles. Whilst they are hardly huge developers, its useful to see it in production and working well. Heres what I've jotted down this evening on the pros and cons of Ogre I've seen at a quick glance. [quote] [color=#000000][font=Arial][size=2]Ogre:[/size][/font][/color] [color=#000000][font=Arial][size=2][/size][/font][/color] [color=#000000][font=Arial][size=2][/size][/font][/color] [color=#000000][font=Arial][size=2]Positives features[/size][/font][/color] [color=#000000][font=Arial][size=2][/size][/font][/color] [color=#000000][font=Arial][size=2]Multiplatform abstraction. The code base would be platform agnostic, and allow DirectX and OpenGl builds. This will be of specific help for more difficult platforms such as the Ipad.[/size][/font][/color] [color=#000000][font=Arial][size=2][/size][/font][/color] [color=#000000][font=Arial][size=2]The code base is mature.[/size][/font][/color] [color=#000000][font=Arial][size=2][/size][/font][/color] [color=#000000][font=Arial][size=2]The source is free and documented.[/size][/font][/color] [color=#000000][font=Arial][size=2][/size][/font][/color] [color=#000000][font=Arial][size=2]The licensing is an MIT license, which is flexible and does not require source code redistribution.[/size][/font][/color] [color=#000000][font=Arial][size=2][/size][/font][/color] [color=#000000][font=Arial][size=2]There are some third party tools that integrate with the engine, to allow asset loading etc. These could replace the need for using <redacted engine> formats and remove the need for conversion in engine. These tools are unofficial however so may not be entirely useful.[/size][/font][/color] [color=#000000][font=Arial][size=2][/size][/font][/color] [color=#000000][font=Arial][size=2]Negative features[/size][/font][/color] [color=#000000][font=Arial][size=2][/size][/font][/color] [color=#000000][font=Arial][size=2]By specification, features must be implemented on both DirectX and OpenGl, this leads to a situation where specific technologies fail to overlap and gaps are left in the API.[/size][/font][/color] [color=#000000][font=Arial][size=2][/size][/font][/color] [color=#000000][font=Arial][size=2]The multiplatform abstraction is large and consists of two major classes. These are almost impenetrable so would leave us in a difficult position were we to need lower level functionality or hacks for the Ipad. It also create a lot of redundant function calls, eating CPU cycles unnecessarily changing state.[/size][/font][/color] [color=#000000][font=Arial][size=2][/size][/font][/color] [color=#000000][font=Arial][size=2]The animation system is robust, however does not include physics based animation. This would lead to issues of integration when a 3rd party solution is found, potentially requiring much work.[/size][/font][/color] [color=#000000][font=Arial][size=2][/size][/font][/color] [color=#000000][font=Arial][size=2]The scene management would be largely obsolete as the game and <redacted engine> will provide that and is matured in the in-house development pipeline.[/size][/font][/color] [color=#000000][font=Arial][size=2][/size][/font][/color] [color=#000000][font=Arial][size=2]As a personal observation and its maintainers. Few of the developers involved work in rendering technology in the games industry. This means that the engine may make assumptions on its use that are incorrect in real time development. Eg proper object abstraction vs performance.[/size][/font][/color] [color=#000000][font=Arial][size=2][/size][/font][/color] [color=#000000][font=Arial][size=2]If we modify the engine we may have to spend time committing our code back to the main project or risk creating a fork that is incompatible with the trunk patches and updates.[/size][/font][/color] [color=#000000][font=Arial][size=2][/size][/font][/color] [color=#000000][font=Arial][size=2]Although many small independent projects have been released using the engine, few AAA quality projects have employed it. Torchlight is one such game. The graphical style does not use dynamic lighting and is heavily dependant on high quality art assets. Indeed early developer posts indicated that a fix function pipeline was used. [/size][/font][/color] [/quote]
  8. Hi I'm currently studying the state of graphics engines and middleware to decide on the direction for a major indie title I will be working on. The current engine of the studio is a well known, stable, commercial engine, but has been left behind in the DirectX 8-9 era and would need to be significantly rewritten to hit the requirements of our new project. We are looking at things like many dynamic moving light sources (so probably differed lighting), soft shadowed point lights, large amounts of reflections and a heavy emphasis on costly post effects such as motion vector driven blur. Currently I am thinking of just writing my own renderer from scratch. This doesn't phase me, and due to the very specific brief of the project, I can literally build what I need. That said, it would be foolish not to consider every other option. What rendering engines do people recommend? I've looked at Ogre and it seems promising, however I havnt seen it proven commercially. I'd worry that integration would also be a pain in the ass, since we'd need to mash it in with the current engine. Any pointers would be great. I'm considering anything from small open source solutions (preferably MIT license or similar since releasing source can raise problems) to larger commercial systems, such as Englighten(standalone). Platforms are PC, Ipad and perhaps consoles depending on platform holder whims. Cheers -Simon
  9. I have a large game that I'm porting from a different language to C++ and SDL. I got it built and running great in VS. Ported to Linux and got strange behaviour. I don't really want to step through it all as the system is very complex and its not my code. I put the code into MinGW in Windows and got the same bug. I've cleaned up all the important warnings in the project and the remaining cast related ones are unlikely to be causing this. Is there anyway to get MinGW to behave more like the VC compiler? Or indeed visa-versa, so I can debug in Visual studio? Thanks in advance -Si
  10. I'm a fan of emailing my encrypted backups to my gmail and using a free SVN host for larger projects. I really want to get a NAS set up soon with Automatic backup, but have nowhere to put it.
  11. That rig is overkill and a waste of money. A 650W power-supply will do. 12gig of Ram is more than anyone needs, 16 gb? What are you planning on doing with this?! A 950 can be overclocked to 3.8ghz on air, the higher end chips are just throwing money on a fire. The Geforce 570 is a good card for graphics, at no point will any modern game push it to anything near to its extremes and has much better in terms of heat and noise than the other 500 range cards. SLI does not offer improvements in many 3d applications. I wrote an article here about choosing components for a Rig: [url="http://www.machinestudios.co.uk/viewentry.php?id=41"]http://www.machinest...entry.php?id=41[/url]
  12. You could have a bunch of particles with a Navier Stokes solver. Forces can be applied for certain effects and particles could have different attributes like temperature that could diffuse to nearby particles and objects.
  13. Display lists may be acellerated on some implementations, but the specification does not dictate that. To my knowledge, they are not used to increase speed, but to save typing for the programmer. In modern opengl all geometry should be in an VBO.
  14. Since the edges will be hidden underneath the ground geometry. Start with the regular grid and just test the center of each grid cell against your splines (whether they are inside or outside the water area). It will be faster and less hassle to code.
  15. Yep youve got the right idea. Find the pixel width/height. Add them (or minus depending on how the pixel is sampled) onto the pixel position in small increments of the width/height. You can do this in a uniform pattern or by using a star or even a random stippled pattern. If you need it to be fast, a random pattern with fewer samples can give the good results, specially for natural looking shaders.