Jump to content

  • Log In with Google      Sign In   
  • Create Account


VladR

Member Since 04 Dec 2001
Offline Last Active Jan 16 2014 07:47 PM
-----

#5056375 Terrain generation in 3D Tile Based Game

Posted by VladR on 24 April 2013 - 09:14 AM

This is where you can find code samples, tutorials and forums on everything XNA-related: http://xbox.create.msdn.com/en-US/education/catalog/

 

There are lots and lots of samples. Browse through them, open them in VisualStudio and have fun.

 

As for the Triangle Lists - there are two ways how you can render them

1. Non-Indexed : You need just VertexBuffer (for Vertices)

2. Indexed - you need both VertexBuffer (for vertices) and IndexBuffer (for indices)

 

Start with the Non-Indexed - basically you just fill the vertexBuffer with all vertices of all triangles. It does not get any simpler than that.

 

Indexed are faster, because it is only when using the indices that the HW's post-transform cache gets used, but at the very beginning you do not have to mess with that. Get something on screen first, and only then figure out how to make it faster.




#5056100 Tacking performance degradation

Posted by VladR on 23 April 2013 - 10:26 AM

First of all, let me express my congratulations that you managed to stay away from optimizations up till this point, since now you have something up&running and just need to clean it up a bit.

 

 

Is this C# ? What platform are you getting the slowdowns on ? I am asking since under .NET, the GC runs in a separate thread on PC and you can experience the GC-caused slowdowns only on XBOX.

 

Also, note that you don't want to write to a log file 10 times during a single frame. You want to collect the data in RAM and only dump the data to physical file after you are done with profiling.

 

If it is C#, there are countless threads on XNA forums (of MS) about what does and what does not leak memory under C#. That list is pretty long and some of the stuff you find there is really suprising.

 

I will, however, mention No1 suspect and that is the String class. Whichever way you use it, leaks incredible amount of memory (so just use StringBuilder).

 

On XBOX, even if all you do is this single line every frame : String s1 = s2+s3; it will cause your game to halt for half a second every ~5 seconds.

 

There are .NET profilers, that will run alongside your game and will tell you exactly, each frame, how much memory has been leaked and you can see the moment when the GC runs. The name of that .NET profiler , unfortunately, escapes me at the moment.




#5056058 Terrain Weird Movement

Posted by VladR on 23 April 2013 - 08:28 AM

Did you read the link you were provided ?

 

If you did, you would understand that the ratio between front/far Z-plane is too big - thus causing the Z-Buffer Shimmering.

 

Reduce the Far plane by at least a factor of 10.0f or increase the Near plane by at least a factor of 10.0f .

 

Yes, that means you will have to rescale the terrain and all objects to preserve the precision of Z-Buffer.

 

If you don't want to do that, your other option is to implement a Linear Z-Buffer - see http://www.mvps.org/directx/articles/linear_z/linearz.htm

 

If you don't want to do that either your last (and by far the easiest) option is to ignore the artifacts :-)




#5055116 A good site for kids to work on games together and share them?

Posted by VladR on 19 April 2013 - 08:18 PM

I can definitely recommend Scratch. My son was barely 7 when he took the class at his school, but the results are really amazing and it's much lower level than a GameMaker (that I did not really want him to dive into).

 

I am not sure, however, if it is a good idea to introduce him to forums at this age, though. It's a battleground for adults, let alone kids who don't understand some people devote their full life just to being mean on forums and I think it's a tad too early for them to get totally shatterred on the forum when they submit their first game ...

 

Which, among other things, is not particularly beneficial for their motivation ...




#5054233 Projective Texturing

Posted by VladR on 17 April 2013 - 11:28 AM

I agree that a Shadow-Mapping approach for Projective texturing is easier to get up&running faster. Plus, you will then be able to reuse parts of the pipeline for other stuff.

 

Before we had SM HW, we had to do projective texturing manually and it is truly a PITA to implement correctly and generally enough.




#5054226 Texturing large surface

Posted by VladR on 17 April 2013 - 11:16 AM

Look into Procedural Texturing.

 

If you can't afford the cost of run-time generation of the textures on your target HW, go with blending of different materials - e.g. sand, rock, snow, gravel,.... in a shader.

 

This way, if your terrain mesh is reasonably detailed and with different features (rolling hills + valleys + sharp peaks), the texturing will look pretty good.

 

Even a primitive combination of a  slope (precalculated&stored per vertex) +elevation gives really nice results and might even be enough.

 

This is a screenshot of a very old [per-vertex-blending] implementation (just slope and elevation) of mine without blending in pixel shaders (e.g. this works on a REALLY old HW - GeForce 2):

ScreenShot005.jpg




#5054223 Cascaded shadow maps

Posted by VladR on 17 April 2013 - 11:02 AM

Perhaps you might not have to deal with CSM at all, and just play/tweak the SM`s projection matrix.

 

I am too having a large terrain where you can have a visibility of few kms, but most of the time, the camera is about 20 meters above the player (but player can zoom in/out at any time).

 

I came up with a very simple workaround where I can get a reasonable detail in a shadow map for both near and far objects. My SM is either 2048x2048 or 4096x4096.

 

At run-time, you set the near/far plane of SM based on the camera - if it is a mostly top-down camera, move the far plane as close as possible - this gives you maximum detail in view space, since with that camera you don't see very far anyway.

 

When the camera view changes into the distance, adjust the far plane accordingly. Now, you will loose some detail in foreground, but will gain the shadows in the distance, so it's a reasonable trade-off.

 

To avoid the ugly "pop" in a shadow, I just fluently lerp between Max_Far_SM_Plane and Min_Far_SM_Plane every frame. This way, you will get the fluent transition even during the camera flythroughs over waypoints, without having to set anything, fully automatically. 

 

Considering it took me about 15 minutes to come up with this, I consider it a pretty neat and cheap trick without having to bother myself with implementation of yet another  different Shadow technique smile.png




#5053835 Poly Count for a Standalone game?

Posted by VladR on 16 April 2013 - 08:01 AM

Hey, im developing a 1st person game for the PC and i can't seem to find anything online that would really help me in figuring out where my poly counts should be.

 

  •  Engine: Unity.
  •  Platform: PC stand alone.
  •  Genre: Puzzle Adventure.

 

One of the core goals is to immerse the player into the atmosphere of the game, so graphics is a priority we're trying to keep.

While we were modeling props we thought are 300 polys really fine for a single door that would be multiplied over the environment?

or a 200 poly window? or if the House the player is going to play in is 5,200?

 

You did not make a typo ? Did you perhaps mean 300 thousands tris ? Wow, talk about a trip back to the past long gone...

 

A scene of 5,200 tris, is something that an nVidia TNT2 32 MB card can do. How can I know that number exactly ? Because over 10 yrs ago I had to create a series of 3D screensavers (C++/DirectX) that had to run - emphasis being on the word- fluently on an nVidia TNT 2. Do you have any idea how old that card is ? It was released in 1999. That's ~15 yrs ago !

 

Hell, even GF2 GTS, that was released mere 13 yrs ago, was giving me fluent framerate for scenes consisting of over 120,000 tris - though I gotta admit,that terrain renderer had some pretty neat optimizations - but still - scene of over 100k tris on GF2.

 

I can't talk about Unity's renderer performance, so you will have to test that one out, assuming you can even lay your hands on a properly ancient (& still working!) HW of sorts(not implying Unity'd run on TNT, but you get my point).

 

 

 

Now, I know very well it is very easy to write renderers that waste performance.

 

But to write a renderer that has a problem with a primitive scene of 5000 tris and a couple textures , even on a gfx card 5 yrs old, now that would be a truly icredible feat.

 

 

I don't remember the exact model of my gfx card that I have in my computer, it is GF 4XX-series, so it's best yrs are at least 3-4 yrs behind us.

But few days ago, when I was testing some hi-poly meshes, I got myself a scene consisting of over 4 million tris, yet I still got over 50 fps.

 

And that's with zero optimization - 200 Mil tris per second. I did not play with proper caching of indices, or proper vertex size or proper configuration of multiple vertex streams or anything. It was just a simple brute-force for a short test.

 

 

 

Who, in this day and age, spreads the rumors that a 300-poly mesh could possibly be a problem ? If someone has a phone that can't handle 5000 tris, he sure as hell ain't gonna play your game on it for a very simple reason - 'cause he ain't playing games on his phone at all...

 

Now, I'm just waiting for the first person to bring the integrated gfx "argument" to this discussion...




#5052297 Augmented Reality

Posted by VladR on 11 April 2013 - 06:53 PM

You don't need those expensive products.

 

In my previous job, we have used OpenCV which is free.

 

 

Getting it to compile under Linux environment that you can't really break or properly configure is no fun, though - prepare to switch between different versions of gcc during the build, handling different versions of ImageMagick (and no, certainly not the latest, that tend to explicit various bugs in OpenCV).

 

Should you desire to compile OpenCV with the GPU support, there is even more fun in front of you :-)

 

Once you get through the incredibly problematic linux compilation, it is easy to use.

 

You can start looking into SURF algorithm, of which there are lots and lots of papers on the internet.




#5052182 Basic shadow mapping shader?

Posted by VladR on 11 April 2013 - 11:54 AM

Frankly, the Stencil stuff is probably even more complex and you get all kinds of terrible artifacts when your mesh is not "closed" and has holes. And you can't do self-shadowing of trees with Shadow Volumes.

 

Look here for the self-shadowed tree I got using SM : http://cloud-2.steampowered.com/ugc/596979776527790985/066CF9742ECC3539A073337F27E2F3285B3BB2E4/

 

The best thing - I did not have to do anything ! The damn algorithm just works on everything you throw at it, since it works in Image Space. It does not care if it is a rock, animated character or a tree canopy.

 

The performance hit I got from using SM is about 7% on an XBOX360 and is practically ~free on PC (assuming a full engine/gameplay load)

 

 

It makes me want to cry every single time I think about how much time I spent trying to fix and work around (especially closing the meshes and reexporting them is a nightmare) the principally fundamentally flawed algo like the Shadow Volumes via the Stencil, when we have something as drop-dead simple, beautiful and practically almost free (in terms of a performance hit).

 

The time when Stencil Shadows were an option is a decade behind us. Just let it die like fixed-function pipeline...

 

 

 

 

Feel free to ask here, but I found all replies to questions I had during implementation of the SM in my engine directly on the XNA forums. If I remember correctly there were about 20 threads about SM at that time, so it was easy to read through them and find lots of other SM-related info there.




#5052155 Basic shadow mapping shader?

Posted by VladR on 11 April 2013 - 10:19 AM

I can relate to the frustration of using flattenned shadows, since that's what I've been using few yrs back and then switched to Shadow Mapping and couldn't be happier !

 

I would definitely recommend the Shadow Mapping example from the XNA Samples, since it's drop-dead simple to use and tweak.

 

It took me a mere single evening to load up that sample, debug through it and reimplement the technique into my engine and tweak it to a much higher quality.

 

Due to the similarities between XNA / DX9 I don't suppose you could run into any issues converting that sample.

 

 

Note, that understanding just the shaders is one thing. You also need an understanding of the Render Targets and that you practically have 2 sets of shaders - one for just rendering them into the ShadowMap and the other set that actually applies the ShadowMap to your geometry.

So, I'd make sure you understand, conceptually, how Shadow Mapping works first - since there's quite a lot of stuff that can (and will) go wrong.

 

 

The XNA Sample for SM : http://xbox.create.msdn.com/en-US/education/catalog/sample/shadow_mapping_1

The SM Tutorial : http://www.riemers.net/eng/Tutorials/XNA/Csharp/Series3/Shadow_map.php




#5052124 2D Deferred lighting in XNA

Posted by VladR on 11 April 2013 - 08:46 AM

Start experimenting with transformation of the distance in either / both of (x,y) directions - you will get different shapes this way. If you double the x-coord, the light cone will be twice as wide (and so on).

 

Play with it and see what shape you like.

 

 

Alternatively, you should look into GI - namely Radiosity and check the Area Lighting, where if you take into account the ypos of the light (e.g. how high above ground it is), the shape of the cone will, obviously, change due to physical properties of a light distribution.

A Radiosity gives you shapes like this:

ScreenShot004.png




#5052117 XNA/Monogame - Drawing around position

Posted by VladR on 11 April 2013 - 08:32 AM

Your description of what happens can be interpreted in several ways. Are you 100% sure it is not culled by the viewport ? Your first image looks like it displays only the bottom-right corner of the red bitmap, hinting it got culled by the topleft corner of the screen...

 

Check that the same bitmap is not drawn afterwards with some other coords - sometimes you will get surprised when you put a breakpoint and the thing gets executed actually one additional time in the same frame smile.png




#5052114 DrawText and character spacing

Posted by VladR on 11 April 2013 - 08:19 AM

Welcome to the club smile.png

 

There's a reason why most of even AAA games have their HUD in one [lower] resolution and as you raise the resolution, the HUD becomes smaller and smaller untill you can't even read it.

 

The amount of work needed to make UI look equally good across all resolutions is just not worth it.

 

 

That's not to say you could not do it yourself - but wouldn't it be much wiser to spend the same effort on improving the gameplay/engine/features/levels than this ?

 

I can't really speak for D3DXCreateFont, since I found it way too limited and slow and just rolled out my own font rendering routines that handle spacing correctly.

 

 

 

But if you plan on spending some time on creation of your own font routine, I suggest you look into kerning. That should keep you busy for a while smile.png




#5051876 Man Hours Necessary to Make a Game

Posted by VladR on 10 April 2013 - 11:56 AM

You should however drop the C++ and go for C# unless you want a (almost) direct portability to linux and mac ? Because it saves the time of having to setup and understand boost and stl, memory overrun issues and dangers of temporary references and other joys. C++ needs to code while concentrated and focused at 100%, with rigor, (apply RAII, careful design thinking with SOLID, avoid smells...) Whereas in C# you can code correctly even after a beer, and the compiler is much much nicer in its messages. Sometimes it even gives you the solution directly. Also there are virtually no build times which accelerates code-to-test cycle. I could go on and on...

I can absolutely sign my name under that (which is something I NEVER do). I did spend few yrs writing 3D engines and games in C++ / OpenGL / DirectX, so I have a meaningful base for comparison.

 

Switching to C# / XNA meant my productivity quadrupled, sometimes it attacks the 10:1 ratio.  It's THAT different.

 

Now, I know, you could object, that I now have more experience than I had 8 yrs ago.  And you could also object that the C++11 is waaaaay different/safer/feature-rich from C++ under Visual C++ 6 :-)

 

But it still freaks the crap out of me, when I just copy/paste 7-10 C# classes (for a new gameplay feature or a massive refactor) that I wrote in Notepad++ (without an access to a compiler) and the beast just works right out the box. That's just insane and it happened to me very rarely in C++ / DirectX (not even mentioning the time it took me to LEARN to write the stuff without any memory leaks whatsoever without smart pointers)...

 

Of course, if you want to do C++ profesionally later on, then you just gotta get burnt, there is no real substitute for that kind of an experience. Reading about a bug fix on a forum and spending a day (or evern a week for that matter) under the debugger are two drastically different things...






PARTNERS