Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 03 Nov 2006
Offline Last Active Today, 12:24 AM

#5243124 Cheap Rendering Tricks Used in Game Industry?

Posted by BarrySkellern on 28 July 2015 - 01:46 AM

I've played a lot of racing games over the years and seen a lot of effects overdone. Don't implement god-rays and fireworks, this isn't Grid2. No offence meant, NightCreature83 ;-)


Here's a few things I think you'll need: motion blur; environmental reflections on cars; shadowing on the track and cars from nearby objects; shadowing on the track from cars; probably some kind of tessellation for curved road and scenery sections; smoke; dynamic lighting from headlights/brake lights; very nice shading models for the track and cars.


I can't stress the last point enough. If you're making a racing game you're expecting me to spend a lot of time looking at your simulation of some tarmac. I also probably drive a car myself in real life, and I instinctively know what a real road and real cars looks like. Your textures, shading models and illumination tricks need to hold up to that standard. Take into account new/old surfaces with different material properties, patches of grease or oil, tyre rubber impregnating the asphalt in the braking and traction zones on the racing line, wet surfaces and standing water etc. And some of these need to be dynamic, i.e. cars laying down rubber as the race progresses.


I know this is a lot, and I know that even the latest racing games don't get it right, but this stuff is the target. But start small, concentrate on maybe two or three of these effects that you think are most important. I'd say get the curved surface tessellation stuff going as best you can (polygon kerbs are awful) and then a nice material model for the track that just gets the fundamental light response right for night racing. Go for a drive, take some photos.


Don't worry about foliage simulation for now. If I'm close enough to see how your trees are rendered then I've already crashed. ;-)

#5240216 Some Maya normal issues

Posted by BarrySkellern on 14 July 2015 - 04:58 AM

Not sure I understand, are you multiplying the normals by the world matrix twice, once when you export the model and then again in the shader?


I'd expect the workflow to be something like: model the object at the origin in Maya (i.e. in its untransformed position) and export it. Then, in your vertex shader, multiply the vertex positions by the world matrix, and the normals by the inverse transpose of the world matrix.

#5240214 Some Maya normal issues

Posted by BarrySkellern on 14 July 2015 - 04:35 AM

I disagree - if your normals are in the same space as the model vertices then they *do* need to be multiplied by the inverse transpose of the world matrix to correctly transform them to world space. If you just use the world matrix itself then the resulting normals will not be correct if the world matrix contains non-uniform scale.


The positions of the vertices should be multiplied by the world matrix.


(Note that for a pure rotation the inverse and the transpose are the same, so the world inverse transpose matrix will be the same as the world matrix anyway.)

#5236136 Research mechanics in 4X games

Posted by BarrySkellern on 22 June 2015 - 05:12 AM

The thing that I've always questioned about the 'tech tree' approach is that you normally know in advance what the results of your research will be and when they're due. That's totally the opposite to how research works!


I pondered a system where you put funding into various fields of research, maybe funding PhDs and staff in your university's physics department. They will suggest research topics, the number of proposals depending on your staff count. You can then approve or deny funding for their projects, and some time later they complete their projects. Some projects don't give you anything - the project was a failure. Some give you some random perk - maybe they improved the efficiency of your power generators by 5%. And occasionally the research results in a breakthrough - some new weapon type is unlocked or something. The actual unlocks will be different each game (but with care in the probability weighting so that nothing on the critical path of the tree is omitted for too long.) The chance of getting the better results is dependent on your funding level both now and historically, but the one thing you can't do is dictate "ok guys, I want you to invent me this thing I already know about within ten turns."


No idea if that would be fun, or an improvement, but might be worth a go.

#5235465 How to connect UAV with Back buffer.

Posted by BarrySkellern on 18 June 2015 - 07:23 AM

I don't think UATs for sRGB targets are supported (maybe someone can correct me?) Have you tried creating the backbuffer in the equivalent non-SRGB format? You can always apply the gamma correction yourself in your shader at an appropriate point in your pipeline.

#5234401 C# becoming obsolete ?

Posted by BarrySkellern on 12 June 2015 - 12:28 AM

Languages and frameworks will always come and go. You could spend two years worrying about that, or you could spend two years becoming very proficient with any language of your choice.


As long as you don't go out of your way to learn something completely weird then your knowledge will set you in good stead for the future, so grab some good books and get down to it. And if in two years everyone stops using C# overnight and Perl somehow becomes the flavour of the month, then learn that too. Most programmers can use several languages, and a lot of very good programmers go out of their way to learn more all the time. Each one tends to get easier to learn, and each one will expand how you look at code in any language.

#5233765 Where to publish games?

Posted by BarrySkellern on 09 June 2015 - 05:45 AM

You could set up a page on itch.io which covers a lot of platforms and has pretty flexible payment systems. It may not be the most discoverable of places but it's quick and simple, and free.

#5232342 An Open World Idea

Posted by BarrySkellern on 02 June 2015 - 04:00 AM

It would probably be quicker, easier and cheaper to just go to Nevada and take over a small town using a crowbar.

#5229996 Unreal Engine 4 beginner advice

Posted by BarrySkellern on 20 May 2015 - 02:24 AM

You don't really need any C++ ability at all to get started, you can make an entire game using Blueprints. I'm a pretty experienced C++ programmer for my day job, but one of the things I enjoy most about using Unreal Engine for my hobby projects is that I hardly if ever have to write any code. You might be pleasantly surprised at just how far you can get with blueprints alone.


As far as learning goes, I found the curve to be a bit steep at first, but the most useful thing for me was checking out some of the example projects. Download the Flappy Bird blueprint project for example, and walk through the most important bits of its blueprints, stuff like input handling and so on. Try to distil that down to the things that you need in your game. I find the documentation is complete but is a bit hard to apply at first without seeing a working example. You could also get some blueprints from the marketplace and see how they work, for more inspiration.

#5226748 Fisheye by using pixel shader. Help.

Posted by BarrySkellern on 01 May 2015 - 01:44 PM

I think I get what you're planning because I've done a similar thing for work (virtual colonoscopy flythrough with fisheye projection - as much fun as it sounds).


One approach I tried was to render the scene into a cube map from the camera's point of view (i.e. draw in six directions along the camera's local basis), then render a fullscreen pass, and in that pixel shader compute the fisheye ray direction through each pixel and sample the cube map at that point. This allows up to a full 360 degree field of view and actually any nonlinear projection you desire (there are different angular functions for different types of fisheye).


It worked, though as a naive approach it has its problems too. You tend to have issues of either under- or over-sampling, i.e. you need a high resolution cube map to support narrow fields of view, but then those samples are wasted when you increase the field of view. Conversely, if you optimise your cube map resolution for a wide field of view then you can't narrow the field of view very much before the result becomes blocky. An approach to solving this could be to dynamically switch between different resolutions of cube map depending on field of view, and only render the faces that actually appear in the field of view. So if you narrow the field of view to 40 degrees then you'd flip to only rendering the front face and using a high resolution target. For a 330 degree field of view you'd need to render all faces, but only at lower resolution. If you're careful about how you select these cases the performance is pretty reasonable and the results look fine.


Well, that was my take on it. We actually ended up going for a pure raycaster in the end anyway!

#5213298 Which tool is better for start? Engine or framework?

Posted by BarrySkellern on 27 February 2015 - 06:20 AM

You can get a long way with the free version of Unity - don't assume you need to spend a lot of money on the full version to be able to make games. Your knowledge of the system and your ability to innovate and produce great content will be far bigger factors in the quality of your games than the fact you didn't pay for the full licence. You can always upgrade later, just spend the profits from your first successful release.


Edit: also agreed, Unreal is a good deal financially. Personally I found it harder to get started with than Unity, but it's worth considering.

#5211423 What do you use for handling sounds?

Posted by BarrySkellern on 18 February 2015 - 07:25 AM

To some extent though you get what you pay for. FMOD comes with the toolchain to package your sounds, easily manage the loading pipeline, set positional and environmental effects, etc etc, which is more than a mere API and will be worth the money for you if it saves three months of your £50,000 salary that could be better spent making a game rather than reengineering an audio engine from the raw API up.


Not that I'm a huge FMOD advocate, I'm just saying "free" is an illusion if it ends up costing you money ;-)

#5207448 How to pass content through the project's structure efficiently?

Posted by BarrySkellern on 29 January 2015 - 10:05 AM

Oh, and since this is for XNA you might look into using the SpriteFont generator for sprites generally. I don't know what it's like nowadays in XNA but I think the one in the native DirectXTK is basically the same. You can coopt the same functionality to pack any sprites you like into a 'spritefont' file, they don't have to be letters. Then you draw single frames by using the appropriate single-character 'string' for the sprite in question. It's a clunky API for the task because it annoyingly assumes you'll be drawing text, but it'll do the job effectively and saves you having to write your own sprite-sheet packing tools.

#5207383 How to pass content through the project's structure efficiently?

Posted by BarrySkellern on 29 January 2015 - 03:58 AM

I'd also question the wisdom of having so many small textures. Why not combine all frames of animation for one unit into a single texture? Or even all frames for multiple units in one texture? Reducing the number of textures will improve your ability to batch draw calls, with improved performance. In the limit, if every sprite in your game can fit in a single texture then you'll never need to switch textures at all. That's unlikely of course, and deciding what to combine into textures for maximum benefit is very much dependent on your content and how it's used. But you can potentially gain in both performance and simplicity by merging assets.

#5207152 Could you advice me which book or books should I go for?‏‏

Posted by BarrySkellern on 28 January 2015 - 06:40 AM

Physically Based Rendering is an excellent book with a huge amount of detail in it. But, it's not geared towards the real-time end of the scale, being more concerned with high-quality offline rendering methods. You can learn a lot (a LOT) about rendering from it, but whether you can apply it is another matter.


Real Time Rendering doesn't contain the same level of nitty-gritty detail, but as long as you're willing to do some further reading and research yourself then it's a great kickoff point for a wide range of topics that are a lot more applicable to game development.


I'd say experience is more important than reading though, so my main advice would be to spend as much of your time working as you can, rather than studying. They're both good books though, well worth their place on your desk.