Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 09 Feb 2012
Offline Last Active Aug 14 2014 08:46 AM

Posts I've Made

In Topic: 2D Platformer Technique?

14 July 2014 - 06:59 AM

Thank you for the reply Ashaman! I hadn't thought about dynamic vs kinematic controllers. And I guess it just felt like the path finder had to control everything but yeah, it can just execute a direct action if the object it's chasing is within its vicinity, and otherwise it uses the path finder.


The first method you had really didn't look that bad.  Sure some cases it didn't handle well, but do other people notice?  As long as the AI can handle most of the cases, you might just shrug and say, "good enough".  You could also cheat, and ensure that all levels work with the AI, ie, just get rid of the cases the AI can't do.  


(I realize neither of those might be acceptable to you, but I think it's worthwhile to at least consider them, even if only briefly)



It looks like, for the first method, it might work if you just expanded the possible move set for the character to check, and perhaps widen the search a little.  It gets a little specific, but it reminds me of games like Dawn of War \ Company of heroes, which basically have a set of moves that vehicles can make, like three point turns, and tries to overlay those over the tiles, and see which ones are valid to use or blocked, and then use the end position of the valid ones to continue the next search from.


EDIT:  To expand further, for example, knowing all the methods of getting to a tile that is 2 tiles to the right, and 2 tiles up, just cycle through all the possible methods.  So you end up with basically an array of moves for traveling from one tile to another, for each of the X tiles surrounding the jumper.  Something like the surrounding 24 tiles.  sort of vaguely similar to marco pinters 24 or 48 square directional search.


This confirms what I've had doubts about, that I was doing it too "manual" or hardcoded by giving it all these cases, but I guess it's a pretty legit method.



You might want to take a look at this answer:




The answer basically says "Look at how Mario AI did it" and my question is, "I want to do it like Mario AI..how?"


I'm currently implementing the first method and it's actually playing well against a human player or against each other with a little tweaking. But I'm still thinking about doing something that searches steps in the future so it can allow for "unlimited interactivity in mid-air"


Maybe if instead of considering every possible step (left, right, up, up right, up left and no key) at each and every node. It just draws out a path from the current grid cell to the next. So it keeps left pressed until it passes 256 pixels, and same for other keys, and that would be the second node. This would VASTLY lower the search space, and of course lower its flexibility but I think by tweaking the grid size we may have something that would work great and be fast enough. Will have to experiment more with it.

In Topic: Efficiently Detecting if objects are out of screen?

10 January 2013 - 10:14 AM

The moving object problem isn't that bad. If you think for a while, you'll realize that you'll need to update only objects which move outside of the octree node. So, as long as the object stays inside a node, you don't need to change your spatial structure.


I wanted to ask about this. Even if the moving object is moving inside one cell, how do I know that? How do I know when it needs to be reassigned to a new node/cell if I'm not constantly checking if it's still within its node?

In Topic: Efficiently Detecting if objects are out of screen?

09 January 2013 - 08:07 AM

Thanks for all the replies so far!


To confirm, the game I'm working on is a 2D game.


So from what I understand there's really no one perfect solution that is going to fix everything, but combining all these different things to get the performance I need.


So I could implement quad trees, plus this "frustum culling" (which I'm guessing works just as well to 2D games as it does for 3D?)


I could also split my objects into "static" and "dynamic".


I could do as wintertime suggested, and have this sort of "probability" buckets, and not update some objects as much as others depending on how probable it is that they would be in the screen on the next update.


I'm using Lua with Love2D by the way.

In Topic: Sending lots of data to the GPU?

02 November 2012 - 01:50 PM

Hmm deferred rendering looks interesting. It seems like it'd make the process of applying the lighting on objects much faster, but I still don't understand how it allows me to use more lights.

I'm reading the article here: http://www.gamedev.net/page/resources/_/technical/graphics-programming-and-theory/deferred-rendering-demystified-r2746

Afterwards, the lights in the scene are rendered as geometry (sphere for point light, cone for spotlight and full screen quad for directional light), and they use the G-buffer to calculate the colour contribution of that light to that pixel.

I would still be sending light data somehow right? And that would be limited by how big I can make my array, or am I not understanding it right?

In Topic: Simple diffuse light. Weird Behavior.

14 October 2012 - 09:40 AM

Here's your modified code, including shifting the texture into [-1..1] and an ambient term without specular (only diffuse yet).

Thanks for taking the time to write that Ashaman!

I still have a few questions though.

I'm not sure I understand what's going on in this line:

vec3 normal = normalize(normalColor.xyz*vec3(2.0)-vec3(1.0));

Actually..reading it again, this is the part where you convert it from [0,1] to [-1,-1] right? I'm assuming this affects the angle of the light? Because that seems to be what fixes everything.

Also this line:

img_color *= mix(vec3(1.0) , dotProduct, ambientFactor);

What's being mixed and why? And what's the purpose of that (1.0) ?

Finally, the reason I was adding to the color instead of multiplying is that, when I multiply, the color of the material or the object seems to turn greyish as it darkens. Like it loses its color. Which makes sense. But if I add the color then, with some tweaks, it looks a lot better because the object's color just gets brighter, more towards white, and darker, towards black, without really seeming to lose its color.

Do any lighting models add/subtract to the color instead of multiplying or is that just a bad idea?

Here's little code snippet for SH lighting:

Thanks for this as well! I'll try to implement that and post again if I have any problems.