Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 02 Nov 2012
Offline Last Active Today, 01:47 AM

#5196833 How is a game engine made?

Posted by C0lumbo on 07 December 2014 - 02:12 PM

If you want a good introduction on the topic, you could do worse than read Game Engine Architecture by Jason Gregory

#5195449 Some link to list of game sales?

Posted by C0lumbo on 30 November 2014 - 12:29 AM

There's this from the TIG forums (sticky post in their business forum): http://forums.tigsource.com/index.php?topic=35689.0

#5195259 Particle Systems & Handling Transparency

Posted by C0lumbo on 28 November 2014 - 04:20 PM



(it is possible to draw additive and alpha blended particles in a single draw call).


How do you do that? (I'm an OpenGL beginner)



I suppose with the blend function: Dest * (1 - SrcAlpha) + Src


Aka premultiplied-alpha.


If SrcAlpha is 0, it simply reduces to additive blending.

If SrcAlpha is between 0 and 1 you can achieve alpha blending but you have to premultiply your textures by the alpha value first.


This also allows you to seamlessly blend from explosion to smoke and other cool effects.



Yep, that's it.

#5195115 Particle Systems & Handling Transparency

Posted by C0lumbo on 28 November 2014 - 01:30 AM

Once you start looking for it, you'll see incorrectly sorted particles in a lot of very high quality AAA games, it's surprising how much incorrectness you can get away with.


One solid solution which I favour is to have all your particle textures on a single texture sheet. It's a bit limiting in terms of texture space (less so if your target platforms support texture arrays), but it means you can have a single correct sort for all your particles and render the lot with a single draw call (it is possible to draw additive and alpha blended particles in a single draw call). Particles can be perfectly sorted with one another, but aren't sorted with other transparent objects in the scene.


The more common solution is to just make do with a coarse sort. Rather than managing your particles purely by their type, you separate them according to the instance, sort the instances and render the instances according to their depth. So the particles from explosion #1 are managed separately form the particles from explosion #2. Arranging things this way might make more sense when you want to manipulate the particles, e.g. immediately destroy particles from explosion #1, or attach explosion #2 to a moving object. Plus by managing by instance this way, it becomes feasible to frustum cull particle effects.


PS: Your summary of the rest of the pipeline seems pretty good. I tend to make a distinction between 3 types of transparency, Decals (i.e. transparent stuff that's rendered just over opaque stuff, like blob shadows, bullet holes), 1-bit (e.g. foliage that uses alpha discard but no translucency), 8-bit (e.g. particles). Then you render in the order, opaque->decals->1-bit->8-bit. Only the 8 bit stuff needs to be sorted by depth.

#5194727 Projectile logic

Posted by C0lumbo on 26 November 2014 - 12:39 AM

I think googling "projectile motion equations" is going to direct you more toward equations that will help you answer 'where will it land' or 'what launch angle should I use' kind of questions, they'll be useful for AI aiming no doubt.


If you want the sort of projectile movement you see in DDTank (which from a cursory googling looks like a worms clone to me), then you're probably more interested in frame by frame movement. Which is even simpler.


You're going to have 3 vectors:


Acceleration (gravity)




Each update you need to know the duration of the frame/tick (dt = delta time).


void UpdateProjectile(float dt)


   Position += Velocity*dt;

   Velocity += Acceleration*dt;

   if (CollisionTest())






Updating the position/velocities of physics objects is known as integration, and that function is the simplest most intuitive approach and should work fine for your needs. There are better approaches which reduce calculation error slightly (verlet integration for example), but that's probably not necessary at this point.

#5194686 how to get the same repeating numbers for any of my imput number?

Posted by C0lumbo on 25 November 2014 - 04:37 PM

You want the modulo operator, which essentially gives you the remainder of a division (although there are some subtle differences for negative numbers)


It might look like 'mod' or '%' depending on the language.


For your specific case, try: ((n - 1) % 4) + 1

#5194554 Blurring a specific object in the scene

Posted by C0lumbo on 25 November 2014 - 12:43 AM

There's no reason your plan couldn't work, but there's any number of mistakes that could have occurred along the way to make it not work. Maybe check your blend modes when you're rendering the light?


Would it not be simpler to make the glow texture offline in photoshop/gimp, and slap that on a sprite instead though?

#5194367 Reverse normal in ray-plane intersection

Posted by C0lumbo on 24 November 2014 - 02:21 AM

If the dot product between the ray direction and the plane normal is greater than zero then it indicates that if you're going to collide with the plane at all, you'll be hitting the back of it.


Exactly what behaviour you want to take when a ray hits a back face is up to you. By reversing it, you're essentially making your plane double sided, which might be desirable, it probably depends on your usage case. You might want to be able to see through the back faces, or to ignore them because you have another plane at the same location but pointing the other way with different material properties.


Taking steps like precaclulating dot product results because your ray's direction is always 0,0,1 sounds like it might be a premature optimization at this stage. I would get stuff working before you put in special optimizations that take advantage of your ortho projection.

#5194085 Properly handling mixed languages at run-time

Posted by C0lumbo on 21 November 2014 - 11:53 PM

To be honest, I'd just replace any unsupported characters with something like an underscore _ or the white rectangle glyph ▯ and be done with it. I don't think it would adversely affect a significant number of users, and if you get any support requests raised, you can just tell them that they ought to set their in-game language to match their locale setting.

#5193830 Soft Particles and Alpha Blending

Posted by C0lumbo on 20 November 2014 - 11:34 AM

Not much info to go on here.


Soft particles do a compare against the depth value which controls a fade-to-transparent as they get close to intersecting.


If your transparent meshes were to write to the depth buffer that the soft particles are comparing against, then it'd probably work. Note that the depth buffer the transparent meshes need to write to may or may not be your main scene z-buffer. It may be part of a G-buffer or something.

#5193656 Compression questions

Posted by C0lumbo on 19 November 2014 - 01:29 PM

This is a nice article about compressing normals (in a g-buffer): http://aras-p.info/texts/CompactNormalStorage.html


In general, the trend on modern hardware seems to be that math gets cheaper and cheaper while bandwidth gets (relatively) more expensive. So compression at the cost of a few ops is often worthwhile. It does depend on the specific hardware and use case though (and I'm no expert).


I think half floats would struggle a bit to cover 1000m at 0.1m intervals. A half float is only 16 bits so only has 65536 possible values, plus most of them will be focused close to zero, so perhaps not appropriate for position data. Half floats are probably fine for direction and colour though.

#5189217 Spherified cube

Posted by C0lumbo on 26 October 2014 - 07:04 AM



Just a quick question regarding the process of converting a cube to a sphere, like this:#




...am I right in guessing that this could be done in a vertex shader by taking each vertex, finding a vector from the vertex to the centre of the cube and moving the vertex along that vector until its length matches the desired sphere radius? Or is it more complicated than that?


Thanks a lot smile.png


That'll work pretty well.


If you want to reduce the distortion slightly (i.e. reduce the difference in size between the largest quads and the smallest quads), then there is another more complicated method you might want to look at (I use it in Rapture): http://mathproofs.blogspot.co.uk/2005/07/mapping-cube-to-sphere.html


I would only do the more complex approach if the distortion is a problem though.

#5188169 C++ header inclusion question

Posted by C0lumbo on 20 October 2014 - 11:46 AM

My guess is that you've accidentally used the same name for the include guards in both header1.h and header2.h


(as an aside, you should always use forward declarations when you can get away with it, not just as a last resort).

#5186492 motion blur with trancparency

Posted by C0lumbo on 12 October 2014 - 09:53 AM


i need a simple technique using trancparency decreasing 


if you taken a look at my motion blur in the image, i have used that that technique but i did'nt love it


if you have a simple shader (verry verry simple) that describes the basics of a motion blur without errors when i convert it, please give it to me.



Thanks,  I understand now.


Well, the method works more or less, but it never looks great in my opinion.  Somebody else may have a counter-example of it done well, but I'm not familiar with anything real time.


I think you should probably go for a post-process motion blur.


That means rendering a buffer for velocity to use to apply a kind of blurring effect to the image.


What kind of physics system are you using?


You should be able to get the velocity for each of your vertices, and interpolate those to get each pixel, and create a velocity buffer from that.  Think X Y Z = R G B, kind of like a normal map.  127 is stationary (relative to that axis).

Then just blur according to your buffer.

It's still not perfect, but the effects are pretty good.


GPU Gems has another method here, which seems to be better/more clever:  http://http.developer.nvidia.com/GPUGems3/gpugems3_ch27.html

It's a little heavy for me, though.


http://john-chapman-graphics.blogspot.co.uk/2013/01/per-object-motion-blur.html  This might help.


If anybody can help explain exactly how those velocity buffers are created, that would help a lot.

As it stands, I need to do more research on that topic.



That GPU gems link is a good one. This article on the blur in split-second gives some idea of how fiddly it can be to get a technique like that looking right and running efficiently: http://www2.disney.co.uk/cms_res/blackrockstudio/pdf/SSMBNotes.pdf


I think that what the original poster really wants is a mechanism for just drawing the sphere a few times to blur it. I'm a bit confused by what's going on in that image tbh. How many copies of the sphere are being rendered, and at what opacity. Maybe you could post a picture of the sphere unblurred so I can understand what's going on in the blurred pic better.


Couple of things you might want to try:


1. Draw the transparent copies of the sphere in order of most transparent first, with your opaque one appearing last (if there is an opaque one).

2. Turn off z-write for all but the last copy of the sphere.


Ideally you'd want to render the sphere out into a separate render target with the destination alpha using a 'max' blend mode. That way you can avoid the problem of the sphere becoming too opaque where there's lots of overlapping. Sounds like messing around with render targets is something you're trying to avoid though.

#5186193 Are mobile games revenues real?

Posted by C0lumbo on 10 October 2014 - 10:22 AM

This is a great post that pulls together lots of app store sales figures: http://thegamebakers.com/money-and-the-app-store-a-few-figures-that-might-help-an-indie-developer.html


I've heard that google play revenues are usually around 15%-30% of App Store revenues (although it varies a lot according to your revenue model).


Don't just look at the charts when you're trying to find out how much you'll earn. By definition you're ignoring all unsuccessful titles.