I went to the Unity Vancouver Meetup last night which was pretty fun, about 25-30 people attended (although I didn't stay too late). It was interesting meeting some people that worked with Unity, and there were a couple students and indie teams that came out to the event: http://www.meetup.com/UnityGames/events/41411882/
I didn't expect to see many/any of the big companies at something like this, but am curious to see what comes out of some of the bigger partnerships. EA signed a multi-year enterprise deal with Unity back in 2010 (google it), but I do not know of any big EA titles that actually used it (although I did work with a developer who's Unity project was scrapped). Only one EA title "Tiger Woods PGA Golf Online", is listed on Unity's game list link I posted previously. Perhaps it is still too early to call, but it will be intersting to see what comes out of from the larger companies (and if you have to install a custom web plugin, you know that it is not 100% Unity).
I look forward to more meetups, and the best thing about something like this, is that it can be inspiring to hear about people pationately talking about game development. I will have to startup one of my projects again soon.
Until next time,
Michael Hubbard
http://michaelhubbard.ca
Showing posts with label Unity. Show all posts
Showing posts with label Unity. Show all posts
Thursday, January 12, 2012
Sunday, January 8, 2012
Unity current thoughts
An old colleague of mine recently asked what I thought of Unity, I gave him my answer, but thought I would share part of it in the blog too. For starters I would like to say I really like Unity, and think that it is moving in a great direction, but thought I would try and give an objective view of what I see as the current status of the engine.
Unity3D is basically a good generalist indie game engine. It fills the niche of being cheap easy entry to game development for multiple platforms. However, because it is a generalist engine and does not offer the source code (without a special license) a developer has very little control over the low-level parts of the game engine, or optimizing or expanding any low-level behaviour. This can result in creating really nasty hacks in trying to get the desired functionality out of Unity, but often ends up being feasibly impossible to achieve certain things. Most games focus on what Unity does offer, and the result of this is that many games created using Unity end up looking and playing similar to other games created with Unity. Unity is constantly improving, so you may eventually see some AAA titles out there, but for now the games are mostly indie with a few slightly larger games, (although I suspect a few of the larger games have also bought the source code license) see: http://unity3d.com/gallery/made-with-unity/game-list. As for development experience, I have worked at companies that use Unity since 2007, and think that the best approach for success with Unity is to work in a very small tightly nit team of programmers and artists/designers. In this approach, the programmers create some standalone script components and the artists/designers apply these scripts to gameObjects to have them bounce around and interact with each other. The best paradigm to I can think of for Unity development is to treat Unity as a big scripting engine: you don't really run Unity, instead you write scripts that Unity runs.
Overall, I see a bright future for Unity, and think it is moving in an interesting direction. Hear is hoping of another 5 years (and more) of Unity fun.
Bye for now,
Michael Hubbard
http://michaelhubbard.ca
Unity3D is basically a good generalist indie game engine. It fills the niche of being cheap easy entry to game development for multiple platforms. However, because it is a generalist engine and does not offer the source code (without a special license) a developer has very little control over the low-level parts of the game engine, or optimizing or expanding any low-level behaviour. This can result in creating really nasty hacks in trying to get the desired functionality out of Unity, but often ends up being feasibly impossible to achieve certain things. Most games focus on what Unity does offer, and the result of this is that many games created using Unity end up looking and playing similar to other games created with Unity. Unity is constantly improving, so you may eventually see some AAA titles out there, but for now the games are mostly indie with a few slightly larger games, (although I suspect a few of the larger games have also bought the source code license) see: http://unity3d.com/gallery/made-with-unity/game-list. As for development experience, I have worked at companies that use Unity since 2007, and think that the best approach for success with Unity is to work in a very small tightly nit team of programmers and artists/designers. In this approach, the programmers create some standalone script components and the artists/designers apply these scripts to gameObjects to have them bounce around and interact with each other. The best paradigm to I can think of for Unity development is to treat Unity as a big scripting engine: you don't really run Unity, instead you write scripts that Unity runs.
Overall, I see a bright future for Unity, and think it is moving in an interesting direction. Hear is hoping of another 5 years (and more) of Unity fun.
Bye for now,
Michael Hubbard
http://michaelhubbard.ca
Sunday, March 20, 2011
The Programming Languages to Know
The programming languages to know (for Game Programmers and Technical Artists), but can really be applied to almost any programming task:
1. C++: The language to learn, and while I like C, object oriented programming is nearly always a better approach for large game projects. This is the language that job market talks in, is the language you want to be taught in university and the language you should be the most comfortable with. While a number of other languages are gaining interest (see C#) the low level control and history of code written in C++ will keep this language in the running for a long time (or at least until C++0X).
2. Javascript: While this may surprise some, this is the language for Adobe product pipeline scripting. Need something automated for Photoshop, Illustator or After Effects? Of course you do... always automate any tasks can be automated, and with javascript this will be one of the only options that these products have API support for. It was also great for some XSI scripting back in the day. Oh and it doesn't hurt that it is the language of client side websites either.
3. Python: This is quickly becoming the language for scripting and glue logic. Once, I would have put Perl here which is great for tasks you need a "swiss army chainsaw", but if your script needs to be maintained or is very long, it is often better to go with Python's object oriented approach. Maya including Python (along with MEL) also bumps this signficantly up the list.
4. C#: Really? Sure, more indie engines like Unity or XNA are worth picking up and playtesting with. While you can use Javascript with Unity, for a very large project it is worth going with C# and the tools (Visual Studio or MonoDevelop) that go along with it.
5. Cg (shader language): If you learn this NVIDIA shader language you will find both HLSL and GLSL a snap. If you are looking at Unity's ShaderLab or the very cool cgFX you should definitely pick up this language in your toolkit of skills.
Other languages that are great to know about are web based languages like Ruby or PHP, some other more unusual languages like Prolog or Scheme (so that you can think about solving problems in different ways) and of course knowing and using a little assembly never hurts (if you really need to optimize).
You will likely look at other languages in your career: such as Java, Obj-C, Lua and more. In fact, the more languages you know and practice with the easier that it will be to transition to other languages. Most languages (especially the popular ones) have lots of good books on them, and lots of examples, but don't worry so much about the syntax anyway, learning the syntax and key words is only the first step. Learning how to program effectively can be done in any language, focus on the language you work in, and learn it inside out. Learn how to architect software, break down problems into solutions, how to optimize and debug what you have written, and what it really comes down to is being able to think in a programming language. When you learn other languages, picking up the syntax differences and a few specialties in the libraries shouldn't be too hard to pick up after that.
If you really want a challenge, you could always try http://www.muppetlabs.com/~breadbox/bf/ or try some of the more obscure ones at http://c2.com/cgi/wiki?HelloWorldInManyProgrammingLanguages and http://www.99-bottles-of-beer.net/
But only if you are up for a challenge...
Michael Hubbard
http://michaelhubbard.ca
1. C++: The language to learn, and while I like C, object oriented programming is nearly always a better approach for large game projects. This is the language that job market talks in, is the language you want to be taught in university and the language you should be the most comfortable with. While a number of other languages are gaining interest (see C#) the low level control and history of code written in C++ will keep this language in the running for a long time (or at least until C++0X).
2. Javascript: While this may surprise some, this is the language for Adobe product pipeline scripting. Need something automated for Photoshop, Illustator or After Effects? Of course you do... always automate any tasks can be automated, and with javascript this will be one of the only options that these products have API support for. It was also great for some XSI scripting back in the day. Oh and it doesn't hurt that it is the language of client side websites either.
3. Python: This is quickly becoming the language for scripting and glue logic. Once, I would have put Perl here which is great for tasks you need a "swiss army chainsaw", but if your script needs to be maintained or is very long, it is often better to go with Python's object oriented approach. Maya including Python (along with MEL) also bumps this signficantly up the list.
4. C#: Really? Sure, more indie engines like Unity or XNA are worth picking up and playtesting with. While you can use Javascript with Unity, for a very large project it is worth going with C# and the tools (Visual Studio or MonoDevelop) that go along with it.
5. Cg (shader language): If you learn this NVIDIA shader language you will find both HLSL and GLSL a snap. If you are looking at Unity's ShaderLab or the very cool cgFX you should definitely pick up this language in your toolkit of skills.
Other languages that are great to know about are web based languages like Ruby or PHP, some other more unusual languages like Prolog or Scheme (so that you can think about solving problems in different ways) and of course knowing and using a little assembly never hurts (if you really need to optimize).
You will likely look at other languages in your career: such as Java, Obj-C, Lua and more. In fact, the more languages you know and practice with the easier that it will be to transition to other languages. Most languages (especially the popular ones) have lots of good books on them, and lots of examples, but don't worry so much about the syntax anyway, learning the syntax and key words is only the first step. Learning how to program effectively can be done in any language, focus on the language you work in, and learn it inside out. Learn how to architect software, break down problems into solutions, how to optimize and debug what you have written, and what it really comes down to is being able to think in a programming language. When you learn other languages, picking up the syntax differences and a few specialties in the libraries shouldn't be too hard to pick up after that.
If you really want a challenge, you could always try http://www.muppetlabs.com/~breadbox/bf/ or try some of the more obscure ones at http://c2.com/cgi/wiki?HelloWorldInManyProgrammingLanguages and http://www.99-bottles-of-beer.net/
But only if you are up for a challenge...
Michael Hubbard
http://michaelhubbard.ca
Saturday, November 20, 2010
Unity 3.0 ShaderLab
Everybody loves shaders, and Unity's 3.X ShaderLab http://unity3d.com/support/documentation/Components/SL-Reference.html is interesting in what they have done (ShaderLab is similar to CgFX scripts, but unique to Unity).
Unity 3.X has updated their rendering model, and specifically changed how to write shaders for Unity 3.X. The newly structured surface shaders, which through a combination of ShaderLab syntax (often pragma settings) and Cg progamming language allowed shaders to be created that would work with both Unity's forward and deferred rendering lighting model. The pragma basics include the Lambert and BlinnPhong lighting models as well as more complex bump, cubemap and emission shader properties and logic. The Unite talk I went to also mentioned a specific “gotcha” related to Unity's use of the specular color, requiring the specular color parameter to be specifically named _SpecColor to allow Unity access to the separate specular highlight (this appears to be a hardcoded issue, but is different from the Unity 2.X standard).As a whole Unity is still rendering average scenes with minimal lights much faster in forward rendering (at least in the test scenes that I have been working with). The deferred rendering will likely be useful for very specialized scenes with lots of lights, but it is nice to have options.
Unfortunately the biggest issue for large scale projects is the incompatibility between Unity 2.X shaders and Unity 3.X. If you have written custom shaders, and have exported assetBundles using those shaders, you will have to rewrite the shader using Unity 3.X techniques and re-export all the assetBundles (hopefully you have an automated build process, for your assets to help with this, but not everyone will). If you notice assetBundles brought in with bright pink colors, it means that your shaders are incompatible and will need to be updated (which makes QA much easier on these assets).
Overall, there is not turning back, and you should strive ahead using Unity 3.X and all the other great features it has, the ShaderLab language is much simpler and will allow more artists to contribute their ideas for shaders and will greatly improve writing time and debugging of shaders in general. Still, would have been nice if the shaders were backwards compatible and not pink :P
Hopefully you have minimal pink,
Michael Hubbard
http://michaelhubbard.ca
Unity 3.X has updated their rendering model, and specifically changed how to write shaders for Unity 3.X. The newly structured surface shaders, which through a combination of ShaderLab syntax (often pragma settings) and Cg progamming language allowed shaders to be created that would work with both Unity's forward and deferred rendering lighting model. The pragma basics include the Lambert and BlinnPhong lighting models as well as more complex bump, cubemap and emission shader properties and logic. The Unite talk I went to also mentioned a specific “gotcha” related to Unity's use of the specular color, requiring the specular color parameter to be specifically named _SpecColor to allow Unity access to the separate specular highlight (this appears to be a hardcoded issue, but is different from the Unity 2.X standard).As a whole Unity is still rendering average scenes with minimal lights much faster in forward rendering (at least in the test scenes that I have been working with). The deferred rendering will likely be useful for very specialized scenes with lots of lights, but it is nice to have options.
Unfortunately the biggest issue for large scale projects is the incompatibility between Unity 2.X shaders and Unity 3.X. If you have written custom shaders, and have exported assetBundles using those shaders, you will have to rewrite the shader using Unity 3.X techniques and re-export all the assetBundles (hopefully you have an automated build process, for your assets to help with this, but not everyone will). If you notice assetBundles brought in with bright pink colors, it means that your shaders are incompatible and will need to be updated (which makes QA much easier on these assets).
Overall, there is not turning back, and you should strive ahead using Unity 3.X and all the other great features it has, the ShaderLab language is much simpler and will allow more artists to contribute their ideas for shaders and will greatly improve writing time and debugging of shaders in general. Still, would have been nice if the shaders were backwards compatible and not pink :P
Hopefully you have minimal pink,
Michael Hubbard
http://michaelhubbard.ca
Sunday, November 14, 2010
Unite 10
I was at Unity's UNITE conference in Montreal, and it was both informative and fun http://unity3d.com/unite/ UNITE is an annual conference to showcase and educate users and developers using Unity technologies. This conference is the largest annual Unity developer conference and is the tenth such conference. UNITE is often the platform Unity uses to announce new releases and features, as well as gain feedback and interact with the Unity developers.
Unity appears to be gaining popularity with more mainstream game and interactive media companies. They have begun to announce more pronounced companies such as EA, Disney, Marvel and Nokia developing software using Unity. Unity has currently carved out a niche market with its attempt to support as large a range of platforms as possible (mobile devices to high end consoles) and have attracted more attention because of this business model. With fiercer competition in the game and web/browser market it is important to get additional training and knowledge directly from the source.
The conference allowed developers to have one-on-one talks with the Unity developers as well as see demos of competing vendors and hear about alternative implementations and solutions for development problems. The networking opportunities also provide us additional information about how Unity is being used.
The main keynote presentation was broken into two main parts. The first part was a talk by David Helgason (CEO of Unity Technologies) and Brett Seyler, who presented information about some current Unity stats and upcoming Unity enhancements (of course mentioning the release of Unity 3.1). The information provided included the current number of Unity plugins installed at 40 million, and over one thousand iPhone games produced using Unity's iPhone license (including some top selling games). Helgason also showed Unity's commitment to the indie market with what would become the common phrase of the conference “democratization” which when used by the Unity team, described a philosophy of providing more large scale production tools and options to indie developers. The major democratization addition was the Unity Asset Store, which allows developers to buy, sell and share content through the Unity editor (similar to the Apple App Store, but embedded in the editor) The focus on the indie developer can also be seen in the announcement of the Unity Union, which allows companies to get into a contractual agreement with Unity to provide custom licenses and options for developing Unity game on a platform currently not supported by Unity (such as the Nokia phones).
The second part of the talk was by Jesse Schell a game designer (previously a creative director at Disney's virtual imagineering studio) but the focus of Schell's talk was not specific to Unity, but mroe on game character's and virtual characters. Schell provided a of his predictions on the direction of game and character interaction, including a focus on: facial expression tracking; persistent databases; speech recognition; natural language understanding; emotion sensing; integrated multi-platform games; interface to everything; cognitive tutors; intelligent actors; and augmented reality. Schell also mentioned that he is doing work on ‘The Mummy Online’ in collaboration with Universal and Bigpoint for launch in Winter 2010.
I learned some new things about Unity and how it was used, although much of the conference was focused on the high level introduction, and since I have been using Unity since 2007 in many forms (Mac, PC, Unity source code, web and iPhone) I would have liked to have had a bit more indepth approach about the low-level details.
A number of talks were focused on developing tools for Unity that more commercial engines (such as Unreal or the Hero engine) already have and maintain. It did not appear that many companies were using Unity for large scale MMOs (outside of the mention of the upcoming Mummy MMORPG) and Unity's immediate focus still appears to be indie (over large scale commercial) support.
I really enjoy Unity and feel like the company has a bright future, with Unity 3.X and their support for consoles, more and more companies will look to Unity as their potential engine. As always, it is so important to use the right tool for the job, and I can't stress that enough. Unity covers a wide range of options, and feel like it is a great engine to use for an indie to intermediate sized project. Unity has a great and helpful community and you can make some fun games. It is always worthwhile in doing your homework on any engine, and look at what kinds of games are produced, and make sure that these are the approximate types of results you would expect. One caveat though, Unity also deals with some additional licenses for undocumented features which may give other companies a competitive advantage, some other companies also purchase the Unity source code and develop their own plugin that gives them additional features that do not exist "out of the box". There are some fun games and applications made with Unity, and I wish you best of luck with yours.
Unite Montreal,
Michael Hubbard
http://michaelhubbard.ca
Unity appears to be gaining popularity with more mainstream game and interactive media companies. They have begun to announce more pronounced companies such as EA, Disney, Marvel and Nokia developing software using Unity. Unity has currently carved out a niche market with its attempt to support as large a range of platforms as possible (mobile devices to high end consoles) and have attracted more attention because of this business model. With fiercer competition in the game and web/browser market it is important to get additional training and knowledge directly from the source.
The conference allowed developers to have one-on-one talks with the Unity developers as well as see demos of competing vendors and hear about alternative implementations and solutions for development problems. The networking opportunities also provide us additional information about how Unity is being used.
The main keynote presentation was broken into two main parts. The first part was a talk by David Helgason (CEO of Unity Technologies) and Brett Seyler, who presented information about some current Unity stats and upcoming Unity enhancements (of course mentioning the release of Unity 3.1). The information provided included the current number of Unity plugins installed at 40 million, and over one thousand iPhone games produced using Unity's iPhone license (including some top selling games). Helgason also showed Unity's commitment to the indie market with what would become the common phrase of the conference “democratization” which when used by the Unity team, described a philosophy of providing more large scale production tools and options to indie developers. The major democratization addition was the Unity Asset Store, which allows developers to buy, sell and share content through the Unity editor (similar to the Apple App Store, but embedded in the editor) The focus on the indie developer can also be seen in the announcement of the Unity Union, which allows companies to get into a contractual agreement with Unity to provide custom licenses and options for developing Unity game on a platform currently not supported by Unity (such as the Nokia phones).
The second part of the talk was by Jesse Schell a game designer (previously a creative director at Disney's virtual imagineering studio) but the focus of Schell's talk was not specific to Unity, but mroe on game character's and virtual characters. Schell provided a of his predictions on the direction of game and character interaction, including a focus on: facial expression tracking; persistent databases; speech recognition; natural language understanding; emotion sensing; integrated multi-platform games; interface to everything; cognitive tutors; intelligent actors; and augmented reality. Schell also mentioned that he is doing work on ‘The Mummy Online’ in collaboration with Universal and Bigpoint for launch in Winter 2010.
I learned some new things about Unity and how it was used, although much of the conference was focused on the high level introduction, and since I have been using Unity since 2007 in many forms (Mac, PC, Unity source code, web and iPhone) I would have liked to have had a bit more indepth approach about the low-level details.
A number of talks were focused on developing tools for Unity that more commercial engines (such as Unreal or the Hero engine) already have and maintain. It did not appear that many companies were using Unity for large scale MMOs (outside of the mention of the upcoming Mummy MMORPG) and Unity's immediate focus still appears to be indie (over large scale commercial) support.
I really enjoy Unity and feel like the company has a bright future, with Unity 3.X and their support for consoles, more and more companies will look to Unity as their potential engine. As always, it is so important to use the right tool for the job, and I can't stress that enough. Unity covers a wide range of options, and feel like it is a great engine to use for an indie to intermediate sized project. Unity has a great and helpful community and you can make some fun games. It is always worthwhile in doing your homework on any engine, and look at what kinds of games are produced, and make sure that these are the approximate types of results you would expect. One caveat though, Unity also deals with some additional licenses for undocumented features which may give other companies a competitive advantage, some other companies also purchase the Unity source code and develop their own plugin that gives them additional features that do not exist "out of the box". There are some fun games and applications made with Unity, and I wish you best of luck with yours.
Unite Montreal,
Michael Hubbard
http://michaelhubbard.ca
Tuesday, September 28, 2010
Game performance and optimization
The question of performance and what can benefit from additional work optimizing code (or art) is a very complex problem. To grossly oversimplify the questions of performance, it is worth looking at a few of the terms used to describe what involved in the actual measure of performance. Usually when talking with people about a game's performance in simplistic terms they will focus on fps (frames-per-second) but there are many other considerations memory usage, texture memory usage, cpu usage, gpu usage, network usage (if applicable) or things like load time, amount of loads, and more. To measure any of these it is worth focusing on testing different types of components, and the platform and/or engine and getting minimum specs for what you need (size of art assets, number of triangles, animations, size of textures, number of lights, number of postprocess fx, complexity of shaders, etc.), the list goes on and on.
One thing that is often talked about CPU bound vs GPU bound, meaning that one of these systems is a bottleneck for the other.
CPU bound could be for a lot of processing, physics calculations (on the CPU) or a lot of other complex calculations (searching or sorting large amounts of data or complex AI calculations like pathfinding).
GPU bound if a lot of polygons, high resolution textures, or dealing with a lot complex shaders (often with multiple lights and shadows).
The best approach is to find the first largest bottleneck and try to minimize it, then the next largest and so on. While it is sometimes worthwhile to look at the code and try and optimize it (things like replacing divides, multiplications ect. with bitshifts and attempting to precalculate as much as possible before actually hitting runtime), this won't solve the problem if the game falls over from huge art assets that the hardware does not easily support. It is often considered that premature optimization is a huge mistake, since it is often difficult to know if you are optimizing the right part of the code (and often the code becomes significantly more complex and more difficult to maintain if it is optimized). It is still worthwhile to make as efficient code as possible while writing it (considering order of magnitude algorthims (big O notation)), but if you don't actually test with real data, you may be wasting huge amounts of time optomizing the wrong thing.
In terms of performance and optimizations, I almost always come back to an example that a colleague of mine gave me that he saw on a previous project. The project was on a 3D handheld and the team wanted to add a depth of field postprocess render fx to the game, but were worried that the performance hit would be too expensive. They decided that the look was so cool, they had to try it and see what it would cost. What they found was that by adding this fx they actually got better performance! On this particular 3D handheld both the CPU and GPU shared the same bus, so by adding this postprocess fx the bus was freed up to handle a lot of CPU processing, while the GPU was dealing with this more complex rendering. Not an easy thing to estimate or plan for :P
There are a few useful tools in helping debug performance, PerfStudio for AMD http://developer.amd.com/gpu/PerfStudio/Pages/default.aspx and PerfHUD for NVIDIA http://developer.nvidia.com/object/nvperfhud_home.html are great tools for seeing the low level API calls to the graphics card as well as debugging tools for texture visualization and overrides which are great for shader debugging, checking mipmap level etc.
One of the things that really impressed me in the UDK was the use of performance and memory built right into the editor, as well as things like mipmap levels, shader complexity, that are great ways of helping artists debug scenes and texture sizes. Unity3D offers a few tools (like the stats window and profiler) to help see where some of the memory is being used, but I haven't seen it at the level of UDK anywhere (and will still need to look at XNA, but without an editor, it may be difficult to provide any of these kinds of tools).
In the end, it all comes down to trade offs, and what you can live with for performance for your game, usually at the expense of something else, and hopefully not too much of the visual look. It is worthwhile to develop some tests that check for significant changes in memory usage, video memory usage, frame rate, etc. on every commit (or at least everyday) to help catch these memory issues as soon as possible (especially on a large project).
Best of luck optimizing,
Michael Hubbard
http://michaelhubbard.ca
One thing that is often talked about CPU bound vs GPU bound, meaning that one of these systems is a bottleneck for the other.
CPU bound could be for a lot of processing, physics calculations (on the CPU) or a lot of other complex calculations (searching or sorting large amounts of data or complex AI calculations like pathfinding).
GPU bound if a lot of polygons, high resolution textures, or dealing with a lot complex shaders (often with multiple lights and shadows).
The best approach is to find the first largest bottleneck and try to minimize it, then the next largest and so on. While it is sometimes worthwhile to look at the code and try and optimize it (things like replacing divides, multiplications ect. with bitshifts and attempting to precalculate as much as possible before actually hitting runtime), this won't solve the problem if the game falls over from huge art assets that the hardware does not easily support. It is often considered that premature optimization is a huge mistake, since it is often difficult to know if you are optimizing the right part of the code (and often the code becomes significantly more complex and more difficult to maintain if it is optimized). It is still worthwhile to make as efficient code as possible while writing it (considering order of magnitude algorthims (big O notation)), but if you don't actually test with real data, you may be wasting huge amounts of time optomizing the wrong thing.
In terms of performance and optimizations, I almost always come back to an example that a colleague of mine gave me that he saw on a previous project. The project was on a 3D handheld and the team wanted to add a depth of field postprocess render fx to the game, but were worried that the performance hit would be too expensive. They decided that the look was so cool, they had to try it and see what it would cost. What they found was that by adding this fx they actually got better performance! On this particular 3D handheld both the CPU and GPU shared the same bus, so by adding this postprocess fx the bus was freed up to handle a lot of CPU processing, while the GPU was dealing with this more complex rendering. Not an easy thing to estimate or plan for :P
There are a few useful tools in helping debug performance, PerfStudio for AMD http://developer.amd.com/gpu/PerfStudio/Pages/default.aspx and PerfHUD for NVIDIA http://developer.nvidia.com/object/nvperfhud_home.html are great tools for seeing the low level API calls to the graphics card as well as debugging tools for texture visualization and overrides which are great for shader debugging, checking mipmap level etc.
One of the things that really impressed me in the UDK was the use of performance and memory built right into the editor, as well as things like mipmap levels, shader complexity, that are great ways of helping artists debug scenes and texture sizes. Unity3D offers a few tools (like the stats window and profiler) to help see where some of the memory is being used, but I haven't seen it at the level of UDK anywhere (and will still need to look at XNA, but without an editor, it may be difficult to provide any of these kinds of tools).
In the end, it all comes down to trade offs, and what you can live with for performance for your game, usually at the expense of something else, and hopefully not too much of the visual look. It is worthwhile to develop some tests that check for significant changes in memory usage, video memory usage, frame rate, etc. on every commit (or at least everyday) to help catch these memory issues as soon as possible (especially on a large project).
Best of luck optimizing,
Michael Hubbard
http://michaelhubbard.ca
Subscribe to:
Posts (Atom)