Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 25 Apr 2004
Offline Last Active Dec 19 2013 12:03 AM

Topics I've Started

Car flush against wall, can't turn away!

24 March 2011 - 02:27 AM

As the topic title hints, I have a 2D rigid body system consisting of oriented bounding boxes (OBB), enclosing vehicles. The vehicles roam about in a 2D world, fenced-in with a bunch of vectors representing road barriers. The collision detection works well, almost too well. For the most part, I'm quite happy with the impulse and the collision response of the system.

However, sometimes the racing car gets into a tricky scenario, where it slides along the road barrier, particularly in a bend. Put simply, the car side is flush against the wall. Forward and backward motion is possible, but the car can not turn away, due to its OBB corners making contact with barrier and thus restricting the angular motion required to make the turn. If you ever tried rolling a brick on the table, you'll know what I mean. This is correct behaviour, as far as the physics is concerned. However the situation is not always desirable from a gaming perspective, as you can imagine.

I'm looking for a possible solutions to this problem.

At the moment I have devised a hack to disable the angular contribution of impulses when the car is turning away. Unfortunately, this method causes the car model to slightly penetrate the barrier, which occasionally "kicks" the car away form the barrier. This happens when the vehicle stopped turning away from the barrier but it still penetrating.

Another possible solution is to use a curved bounding model for computing the collision. Although, I'd like the avoid using complex polyhedra, or curved shapes, if possible. My code is optimised to deal with OBBs extensively, hence taking advantage that resource would be beneficial.

I'd be interested know if anyone else encountered such problems how they managed to solve them!

Newton Game Dynamics now open source

18 February 2011 - 08:40 PM


Can anyone comment, or compare this library with other implementations? Pros and cons, etc? I'd be interested to hear from those who had some experience using this lib.

Glsl Vertex Displacement Mapping

10 January 2011 - 01:41 AM

I'm having some problems using a texture for applying displacement mapping on my vertices. Basically I have a VBO consisting of a grid. The aim is to displace the vertex by whatever the texel luminance value is for that vertex.

Admittedly, I'm still new to GLSL, perhaps I've missed something fundamental. Sample vertex shader is provided below:

uniform sampler2D Texture;

vec3 LumConst = vec3(0.2990, 0.5870, 0.1140);

varying float Z;

void main(void)
   gl_TexCoord[0] = gl_TextureMatrix[0] * gl_MultiTexCoord0;

   vec4 Texel = texture2DLod(Texture, gl_TexCoord[0].st, 0.0);
   Z = dot(Texel.rgb, LumConst);

   gl_Position = gl_ModelViewProjectionMatrix * vec4(gl_Vertex.xy, gl_Vertex.z + Z, gl_Vertex.w);

What's happening there is that I'm grabbing the RGB value for each texel at the vertices, apply RGB-to-luminance transform and use the result to displace the Z component of the vertex position.

The only problem is, the program does not seem to fetch the texel. The computed Z value is always 0. The texel coordianes are correct at each vertex, I checked (I've fed either the .s or .t component to Z value for testing). The texture also seems to be bound correctly, because i can render it in the fragment shader using the same uniform name. The actual texture itself is uploaded as a 16-bit height map, I'm not sure if that would be a problem though.

My hardware is an 8600 GT with GL 2.1 capable drivers.

Using LGPL with other licenses

10 December 2010 - 11:10 PM

I have been reading though the Lesser GPL, but there some grey areas for me, particularly the reverse engineering aspects.

Say I'm writing a closed source application that dynamically links with an external library "A", which is covered under the LGPL. LGPL stipulates that the end-user license agreement for my application must make allowances for reverse engineering. I'm cool with that.

Let's say, I'm using another dynamically linked library "B" that falls under under a different license, which does not allow reverse engineering. Library "B" is completely independent of library "A", but of course, both have different licensing demands.

However, if my application dynamically linked with both, am I violating LGPL? If so, what are my options to get around that? This lawyer crap is doing my head in.


Oops, sorry I accidentally posted this in the wrong forum. Could a mod please move this into "The Business and Law of Game Development" forum? Cheers...

Suggestions for resolving access violation bugs?

04 November 2010 - 03:09 AM

I have this bizarre problem with Visual C++ 2010 Express. I get an unhandled access violation exception only when I run my executable in debugging mode.

When I compile and run the release build without debugging - all good. When I run the debug build (that retains debug symbols), again without debugging - all good. But when the debug build is started in debugging mode, something trips the exception.

The entire project is written in C, and I'm using the OpenGL ES 1.1 emulator provided by Imgtec. According to the debugger, the exception seems to originate somewhere in eglMakeCurrent (libEGL.dll library), which is part of emulator.

eglMakeCurrent is an essential part of the setup code. It allows me to attach an OpenGL ES context to my window application. So naturally, this problem occurs way before any rendering code is called.

To make the situation even more frustrating, the problem is sporadic. Sometimes when I clean and rebuild the project, everything works fine in debugging mode. Then, if I edit a source file, build, and start in debugging mode... bam... access violation at eglMakeCurrent blah blah.

First I figured maybe something in my project is causing the trouble. So I started to divide and conquer the project. I commented out big blocks of code. Unfortunately, this did not get me closer to the cause. Sometimes culling code made the problem go away, other times the problem persisted.

And the crazy thing is, on occasions the problem went away when I commented out rendering code that is never called prior eglMakeCurrent. I seriously can't see a pattern to this madness.

Are there third party tools I could use to track down issues like these? Has any of you experienced compatibility issues with OpenGL ES and Visual C++ 2010 binaries? I never experienced this with Visual C++ 2008 Express. I posted on Imgtec forums, but fell on deaf ears.