• Create Account

Need scary sound effects or creepy audio loops for your next horror-themed game? Check out Highscore Vol.3 - The Horror Edition in our marketplace. 50 sounds and 10 loops for only \$9.99!

# Yet another OpenGL Shading/Lighting Question

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

20 replies to this topic

### #1Terin  Members   -  Reputation: 192

Like
0Likes
Like

Posted 02 March 2012 - 12:56 PM

Hello all.

I'm having huge difficulties working shadows and lighting into my engine. I've been working on it for a few weeks and having some difficulties understanding why it's not working as expected. I'm just trying to get lighting working first -- then I'll worry about shadows. I'm just trying to get the preliminary question for lighting out there before I start building out questions on shadows (though, it seems there are a myriad of options with shadow maps, stencil, GLSL, and I know a few others I probably haven't mentioned).

Mainly, my problem is that with directional lighting, the infinite light source always seems to focus at 0,0,0 in space... I'd like to translate the light, such that I can emulate something like sunlight coming from the different directions, based on the hour of the day.

Here's the general "rendering" that I'm doing (C# / OpenGL wrappers. I'd prefer to avoid the entire "C# sucks as a language" dialog -- I've been getting very good benchmarks out of it, even on a netbook without a graphics card (60fps).

Graphics.BeginRenderingLayer();
{
Video.MapRenderingMode();
Graphics.BeginLightingLayer( Graphics.AmbientR, Graphics.AmbientG, Graphics.AmbientB, Graphics.DiffuseR, Graphics.DiffuseG, Graphics.DiffuseB, pCenter.X, pCenter.Y, pCenter.Z );
{
Graphics.BeginRenderingLayer();
{
Graphics.CenterCamera( pCenter.X, pCenter.Y, pCenter.Z );
RenderMap( pWorld, pCenter, pCoordinate );
}
Graphics.EndRenderingLayer();
Graphics.BeginRenderingLayer();
{
Graphics.DrawMan( pCenter );
//TODO: Character Rendering (by layer)
}
Graphics.EndRenderingLayer();
Graphics.BeginRenderingLayer();
{
Video.FlatRenderingMode();
//TODO: Render animation effects
}
Graphics.EndRenderingLayer();
}
Graphics.EndLightingLayer();
}
Graphics.EndRenderingLayer();

Begin/EndRenderlingLayer is Push/Pop Matrix. CenterCamera is a Translate on -x, -y, -z (to push the center into the viewing area). DrawMan just draws a billboarded dude to traverse my terrain. RenderMap draws the terrain with

Here's the relevant code for lighting (Begin Lighting layer is the call used to create it.)

public static void BeginLightingLayer( float pAmbientRed, float pAmbientGreen, float pAmbientBlue, float pDiffuseRed, float pDiffuseGreen, float pDiffuseBlue, float pX, float pY, float pZ )
{
Gl.glEnable( Gl.GL_LIGHTING );
Gl.glEnable( Gl.GL_NORMALIZE );
Gl.glEnable( Gl.GL_RESCALE_NORMAL );
Gl.glEnable( Gl.GL_LIGHT0 );

float[] AmbientLight = new float[4] { pAmbientRed, pAmbientGreen, pAmbientBlue, 1.0f };
float[] DiffuseLight = new float[4] { pDiffuseRed, pDiffuseGreen, pDiffuseBlue, 1.0f };
float[] PositionLight = new float[4] { pX + 5.0f, pY, -5.0f, 0.0f };

BeginRenderingLayer();

Gl.glLightfv( Gl.GL_LIGHT0, Gl.GL_AMBIENT, AmbientLight );
Gl.glLightfv( Gl.GL_LIGHT0, Gl.GL_DIFFUSE, DiffuseLight );
Gl.glLightfv( Gl.GL_LIGHT0, Gl.GL_POSITION, PositionLight );

//This doesn't help.
//CenterCamera( pX, pY, pZ );

EndRenderingLayer();

Gl.glEnable( Gl.GL_COLOR_MATERIAL );
Gl.glColorMaterial( Gl.GL_FRONT_AND_BACK, Gl.GL_AMBIENT_AND_DIFFUSE );
}

The light always pivots around the 0,0,0 point -- so if the hero is to the right, it'll be on the right of it. If to the left, it'll be to the left. If I head infinitely left, the light is bright all the way there -- still focusing on lighting around 0,0,0 as the "center" of the scene, rather than the new center that was translated to.

Thoughts?

### #2Tsus  Members   -  Reputation: 898

Like
1Likes
Like

Posted 02 March 2012 - 04:45 PM

Hi!

The variable pCenter is the position of your player, right?
You used a directional light, since your w-component is 0. This means what was set in
Gl.glLightfv( Gl.GL_LIGHT0, Gl.GL_POSITION, PositionLight )
is the direction of the light. If you want the light direction independent from your player’s world position, you shouldn’t let the direction depend on the position of the player. Here is your problem:
float[] PositionLight = new float[4] { pX + 5.0f, pY, -5.0f, 0.0f };
pX and pY are coming from pCenter.

You want to emulate sun light, right? So, perhaps something close to this will be what you want:
float[] PositionLight = new float[4] { cos(alpha)*sin(beta), cos(beta), sin(alpha)*sin(beta), 0 };
This little code converts the spherical coordinates of the sun (alpha = azimuth angle, beta = elevation angle) to Cartesian coordinates, which we use as direction. (Maybe you have to negate all 3 components, not sure which way around it is defined.)

Cheers!

Acagamics e.V. – IGDA Student Game Development Club (University of Magdeburg, Germany)

### #3Terin  Members   -  Reputation: 192

Like
0Likes
Like

Posted 02 March 2012 - 05:03 PM

Hi Tsus,

Thank you for the help.

I'll test it out and let you know. The only thing that I'm worried about is that, again, the directional light seems to focus on 0,0,0 as the center of the screen. Does that make sense?

Let me show you a few pictures to explain.

If you notice in the first image, the light seems fine -- it's relative to the player and it's on one side. The second part -- the light stays in the same place, even though it's directional. The player just moved northwest a little bit. I've added the yellow line to help show where the light's gradient starts.

I will definitely be putting in the calculations for the azimuth, etc -- but in the very least, it shouldn't be so "set" in stone. Because if the character keeps walking west, the light will always make that side bright, regardless of time of day.

I'm almost wondering -- does light always center around 0,0,0 -- so rather than translating to the negative of the character to draw (saving having to do subtraction on each tile/etc relative to the player), should I be always adjusting it so that my scene is at 0,0,0 in the center, rather than the player's position = center of the screen?

Thanks! Hopefully that helps explain my dilemma!

### #4Tsus  Members   -  Reputation: 898

Like
1Likes
Like

Posted 02 March 2012 - 05:41 PM

Hi again!

I'll test it out and let you know. The only thing that I'm worried about is that, again, the directional light seems to focus on 0,0,0 as the center of the screen. Does that make sense?

Directional light is independent from the position of the fragment/vertex being shaded, because the light itself doesn’t have a position. It only has a direction. OpenGL simply computes the dot product of the normal and the light direction, which is the cosine of the enclosed angle between the two, in order to compute the brightness. If the normal faces in the same direction as the light (enclosed angle=0) it is fully lit (1) and if it is perpendicular to the light direction (enclosed angle=Pi) it is dark (0). (If it faces away, it is clamped to zero.)

Let me show you a few pictures to explain.
If you notice in the first image, the light seems fine -- it's relative to the player and it's on one side. The second part -- the light stays in the same place, even though it's directional. The player just moved northwest a little bit. I've added the yellow line to help show where the light's gradient starts.

Your pictures look fine to me. They meet my expectation. I can’t see anything that’s wrong with them. The gradient only comes from the orientation of the normals. Your player position doesn’t change them, so walking around shouldn’t change the lighting.

I will definitely be putting in the calculations for the azimuth, etc -- but in the very least, it shouldn't be so "set" in stone. Because if the character keeps walking west, the light will always make that side bright, regardless of time of day.

Why is that? The lighting shouldn’t depend on the position of the tiles (being more west for instance). It also doesn't have a falloff, since it has no position and thus no distance to the shaded surface.

I'm almost wondering -- does light always center around 0,0,0 -- so rather than translating to the negative of the character to draw (saving having to do subtraction on each tile/etc relative to the player), should I be always adjusting it so that my scene is at 0,0,0 in the center, rather than the player's position = center of the screen?

Both ways should yield the same. (Directional lighting is independent from the position.)

Hopefully that helps explain my dilemma!

I rather think that I’m missing to see your problem. Since, obviously something isn’t working as you expect. Could you somehow rephrase the problem or show me more pictures? Thanks!

Cheers!

Acagamics e.V. – IGDA Student Game Development Club (University of Magdeburg, Germany)

### #5Terin  Members   -  Reputation: 192

Like
0Likes
Like

Posted 03 March 2012 - 01:33 AM

Again, thank you for the response, Tsus.

So, my problem is that I want that lighting to stay the same each time -- like an overlay, I guess. So in the second picture, I'm expecting the light to lighten up the same relative area of tiles, compared to the character (i.e. to the right of him). Think like an overlay -- in a way, I was considering having the sunlight be an actual light that was always around relative to the player and adjusted based on the time of day and their location (morning = to the west, evening to the east, x += 20 in the morning; x -= 20 in the evening, or something similar).

Since you're a bit more familiar with how lighting works (and OpenGL -- thank goodness, I'm constantly learning), is there a good formula for calculating point-based normals -- I know that OpenGL has a few "surface" normal formulas that are public knowledge. I read a few forum posts where they suggested setting each vertex's normal to be the entire triangle (or geometry's)'s surface normal. I did this and had really funky results. My understanding is that normals always face the camera, correct? (they will be in my case, but they're supposed to be perpendicular to the plane they're on) Right now, my normals are just equivalent to the "height", i.e. normal = point; so x,y,z (tile x, tile y, height) = normal x, y, z. Maybe not correct, but it *seems* to work. I've considered that this may actually be the problem that I have. Perhaps normals need to be relative to the center of the screen 0,0,0 center, instead of conveying the x/y/z that I've been doing such, so far?

Hope that helps communicate it a little more clearly. I owe you a beer, sir.

### #6Tsus  Members   -  Reputation: 898

Like
2Likes
Like

Posted 03 March 2012 - 04:04 AM

Again, thank you for the response, Tsus.

No problem.

So, my problem is that I want that lighting to stay the same each time -- like an overlay, I guess. So in the second picture, I'm expecting the light to lighten up the same relative area of tiles, compared to the character (i.e. to the right of him). Think like an overlay -- in a way, I was considering having the sunlight be an actual light that was always around relative to the player and adjusted based on the time of day and their location (morning = to the west, evening to the east, x += 20 in the morning; x -= 20 in the evening, or something similar).

Mhm, so the light should be relative to the player. You mean, so that it fades out to the borders of the screen? That would be doable with a spot light. You could places the light relative to the player like this:

float[] PositionLight = new float[4] { r*cos(alpha)*sin(beta) + pX, r*cos(beta) + pY, r*sin(alpha)*sin(beta) + pZ, 1 };
Gl.glLightfv( Gl.GL_LIGHT0, Gl.GL_POSITION, PositionLight );
r is the distance to the player and the addition of the players position takes care for the light being relative to the player position. (Note we use w=1). So we the light is placed on a sphere with radius r around the player.

float[] SpotDirectionLight = new float[4] { -cos(alpha)*sin(beta), -cos(beta), -sin(alpha)*sin(beta), 1 };
Gl.glLightfv( Gl.GL_LIGHT0, Gl.GL_SPOT_DIRECTION, SpotDirectionLight);
This sets the direction of the spot. It points from the point on the sphere towards (0,0,0). So, the player is in the center of the spot light.

Additionally we have to set the opening angle of the spot light (cutoff) and a parameter controlling how smoothly the light fades out towards the boundary of the spot cone (exponent).
Gl.glLightfv( Gl.GL_LIGHT0, Gl.GL_SPOT_CUTOFF, 10.0);
Gl.glLightfv( Gl.GL_LIGHT0, Gl.GL_SPOT_EXPONENT, 50.0);

Is this what you're looking for?

is there a good formula for calculating point-based normals -- I know that OpenGL has a few "surface" normal formulas that are public knowledge. I read a few forum posts where they suggested setting each vertex's normal to be the entire triangle (or geometry's)'s surface normal. I did this and had really funky results.

Yes, that’s called a face normal. What do you mean with funky results? When you use faces normals you should get a constant lighting over an entire triangle. If you want to have smoother results (i.e. the lighting being interpolated across the triangle) you should use vertex normals. You can compute those by averaging the normals of the four or eight adjacent vertices.

My understanding is that normals always face the camera, correct?

They don’t automatically do that. Normals always stay the same. If you move behind a triangle the normal faces away from the viewer.

Right now, my normals are just equivalent to the "height", i.e. normal = point; so x,y,z (tile x, tile y, height) = normal x, y, z. Maybe not correct, but it *seems* to work. I've considered that this may actually be the problem that I have. Perhaps normals need to be relative to the center of the screen 0,0,0 center, instead of conveying the x/y/z that I've been doing such, so far?

Hm, this doesn’t sound right. As you already said, normals should be perpendicular to the surface that the triangle mesh is approximating. So, computing vertex normals as I explained above would be a good way to go. You are working with a height map, right? Then you could also use the cross product of its partial derivatives to estimate a normal.
First the partial derivatives:
height_x = (height[i+1, j] – height[i-1, j])/2;	// Central difference of the height in x direction.
height_y = (height[i, j+1] – height[i, j-1])/2;	// Central difference of the height in y direction.
If your height map is a little noisy, you can use the Sobel operator to compute the derivatives. The Sobel operator does also compute central differences, but it blurs the result afterwards. On the boundaries you have to use forward/backward differences (see Finite Difference if you're not familiar with them).

Then create the tangent and bitangent vectors (heightScale scales your height map):
vec3 tangent = vec3 (1, heightScale * height_x, 0);
vec3 bitangent = vec3 (0, heightScale * height_y, 1);
The normal is perpendicular to them (so we take the cross product) and afterwards we normalize it.
Normal[i,j] = normalize( cross( tangent, bitangent) );
If you expand the cross product it becomes even simpler:
Normal[i,j] = normalize( vec3( heightScale * height_x, 1, heightScale * height_y) );

Hope that helps you a little.

Cheers!

Acagamics e.V. – IGDA Student Game Development Club (University of Magdeburg, Germany)

### #7Terin  Members   -  Reputation: 192

Like
0Likes
Like

Posted 03 March 2012 - 09:09 AM

You have been immensely helpful, thank you. Let me play with this and see if I can get the results I want. I'm assuming the smartest thing to do with normals, is to cache them in the engine to save calculation time, right?

Let me see if I can get a result I want from the spotlight and/or the normals, and then I'll definitely be hitting you up with questions about an efficient shadow-rendering method, hehe.

Thank you *so* much again!

### #8Terin  Members   -  Reputation: 192

Like
0Likes
Like

Posted 04 March 2012 - 07:22 PM

Tsus, again, THANK YOU. I've been playing with the code that you posted earlier and managed to alter/get it working for my uses (nothing wrong with your code, obviously, but have to tailor it to my engine).

My question at this point revolves around actually writing some shadow code. I've seen a *lot* of stuff circulating -- most of it fairly old (circa 2000 or 2002 at best). I'm looking to do very simple shadows -- nothing too crazy with multiple light sources -- just the sun. Is the most efficient way to go about this by rendering the scene again from the light's viewpoint into the stencil buffer and then rendering it on top of the scene? I'm trying to go for as efficient and lightweight as possible, even if the shadows aren't *completely* perfect. Just so long as they're not glaringly wrong.

### #9Tsus  Members   -  Reputation: 898

Like
1Likes
Like

Posted 04 March 2012 - 08:16 PM

You’re welcome.

With stencil shadows the scene is rendered three times from the viewer’s point of view. First you write the depth and only do ambient lighting. Second you fill with two-sided stencil mode your stencil buffer by rendering a shadow volume that was extruded from the objects silhouettes. (If your viewer can be placed inside a shadow volume, you have to use Carmack’s “z-fail shadow volumes”.) And finally you render the lit areas, based on the values in your stencil buffer. Stencil shadows are a little expensive since you have to build up the geometry for the shadow volumes each time an object or the light moves.

With shadow maps you render a depth map from the sun and later compare this depth to the actual distance of an object to the light. If the objects distance is bigger than something is blocking the light. In your case this might be easier and more suited, since your view is limited to a small depth range. For the rendering from the sun’s view you need to create a view and projection matrix. Usually you try to place its frustum as tight around the visible scene as possible (aka pan-caking). You could have a look at the slides and the audio-track of David Tuft’s talk at Gamesfest in 2010. He explains shadow mapping (and many of its extensions) nicely. I would recommend implementing it with GLSL, but it is also possible with the fixed function pipeline. The GLSL implementation here directly extends from the fixed function implementation. Though it does not apply a depth-bias. The necessity for the depth-bias is explained in the slides above and I posted a bit on that a few weeks back here.

Cheers!

Acagamics e.V. – IGDA Student Game Development Club (University of Magdeburg, Germany)

### #10Terin  Members   -  Reputation: 192

Like
0Likes
Like

Posted 09 March 2012 - 05:13 PM

Hey Tsus,

I'm having a hard time finding some good examples on the web. A lot of the stuff I'm finding is based on using GLUT and GLSL. I think I can pull off using GLSL, but trying to avoid GLUT since it has become deprecated. The stuff you have posted is poorly organized (at least the actual implementations). The slides and theory behind it all makes sense -- essentially we render the depth buffer (looking from the light's point of view) to an image, and then project the image back onto the resulting image. A lot of stuff I've found has Peter Panning, fragments, and other crap, unfortunately.

I'm not doing any Frustrum projections -- just Ortho.

Are there any good examples with decent amounts of documentation? Most stuff is so old, I can't even run it and the libraries are difficult to find!

At the moment, the best example I've seen is:

But the code requires Glut32.dll and I'm still trying to understand which of the extensions he's including are common now... Since the code was written in 2002 and he's referencing geForce 6x cards at best, I believe. Was hoping to just have a shadow projection in it's own texture/layer and only render as much as necessary (i.e. like a rasterization). Not sure if this is the optimal way of doing it either... any thoughts or pointers?

Thank you, so much!

### #11Tsus  Members   -  Reputation: 898

Like
1Likes
Like

Posted 10 March 2012 - 08:30 AM

Hi Terin,

I wrote you a small sample that does basic shadow mapping with OpenGL 3.3. (Everything I used is still core profile up to 4.2), so you should perhaps read on VAOs and UBOs if you haven’t heard of them.
I used freeglut to replace glut. (Glut is indeed a little old.)
I haven’t had the time to comment everything, but if you have questions you can just ask.

Cheers!

#### Attached Files

Acagamics e.V. – IGDA Student Game Development Club (University of Magdeburg, Germany)

### #12Terin  Members   -  Reputation: 192

Like
0Likes
Like

Posted 10 March 2012 - 12:16 PM

Wow, thanks Tsus! I finally found some decent code from Pauls' Projects too (I had a hard time navigating the site and figuring it out). I'll definitely be looking at both and seeing what I can do.

I see that a lot of people are doing 512x512 shadow maps... Is that a standard size? I realize textures have to be powers of 2, but curious if I render in a window at 1024x768, would I be better going to 1024x1024 shadow map to make it look cleaner?

### #13Murdocki  Members   -  Reputation: 251

Like
0Likes
Like

Posted 10 March 2012 - 03:49 PM

512x512 is okayish but you'll need more of those to make the shadows look good, For example if you implement cascaded shadows you could put four cascades in a 1024x1024 texture.

### #14Terin  Members   -  Reputation: 192

Like
0Likes
Like

Posted 11 March 2012 - 02:20 PM

Is there any benefit to doing cascaded shadows, aside from just jumping the resolution on the shadowmap to just 1024^2?

### #15Tsus  Members   -  Reputation: 898

Like
1Likes
Like

Posted 11 March 2012 - 02:46 PM

Hey,

Is there any benefit to doing cascaded shadows, aside from just jumping the resolution on the shadowmap to just 1024^2?

Choosing the right shadow map resolution is a difficult thing. If the resolution is very high you’ll probably have perfect shadows near the camera, but get in the far distance awful aliasing. If you choose a lower resolution the aliasing in the distance will vanish but close to the camera you get blocky shadows. Either way, it is not optimal for the whole scene.
Whether you really need cascaded shadows depends on your scene. If you are looking more from the top at the scene (meaning the depth range isn’t that big) then a single shadow map should do it.

Cheers!

Acagamics e.V. – IGDA Student Game Development Club (University of Magdeburg, Germany)

### #16Terin  Members   -  Reputation: 192

Like
0Likes
Like

Posted 11 March 2012 - 10:53 PM

Cool, Tsus. I've been looking at your code and it's a little (read: lot) more simple than PaulsProjects' code. The only problem is that I don't have Visual C++ installed. I was hoping to try to benchmark it and see if it works on my (poor performing) netbook and older computer to see if they'll support this kind of code.

Or rather, do you know for sure if GLSL and your method will work on older computers... say within the past 5 years at least? The benefit of PaulsProject was that the code worked and ran lightning fast. His code, however, is very ugly. Yours is way more straight-forward in the way that it's rendering each segment a little more clean.

I do have a question, though. If I'm re-rendering the scene, would it be considered optimal to not render the textures on the objects during the lighting pass? I imagine not pushing the extra data into the GL pipeline would save some cycles, right?

Slowly getting the hang of this after looking at all of these different sources. I feel kind of stupid though -- I thought that the ShadowMap was actually the Shadows... but it turns out that it's actually drawing the *Light* rather than the Shadows and then layering that on top... unless I'm not reading it right!

As always, look forward to your responses and help. :-)

### #17Tsus  Members   -  Reputation: 898

Like
1Likes
Like

Posted 12 March 2012 - 03:33 AM

Hi Terin!

The only problem is that I don't have Visual C++ installed.

As you probably know, Visual Studio is free available here.

Or rather, do you know for sure if GLSL and your method will work on older computers... say within the past 5 years at least?

In the current state, the implementation needs OpenGL 3.3, which means DirectX 10 class hardware. This would be at least Nvidia GeForce 8-series or ATI Radeon HD 2000 series.
We could rewrite the code a little so that we get as backward compatible as you like (in case you need it). However, we would have to give up the latest language features.

I do have a question, though. If I'm re-rendering the scene, would it be considered optimal to not render the textures on the objects during the lighting pass? I imagine not pushing the extra data into the GL pipeline would save some cycles, right?

Yes, it would help during capturing of the shadow map, since we only render depth to a FBO.

Slowly getting the hang of this after looking at all of these different sources. I feel kind of stupid though -- I thought that the ShadowMap was actually the Shadows... but it turns out that it's actually drawing the *Light* rather than the Shadows and then layering that on top... unless I'm not reading it right!

Yeah, it’s kind of rendering the depth of the area that is lit into a texture. The actual mapping of this texture to figure out the shadows is done in the second pass. It's a little misleading to call the depth map "shadow map", but we actually do a mapping of shadows.

Cheers!

Acagamics e.V. – IGDA Student Game Development Club (University of Magdeburg, Germany)

### #18Terin  Members   -  Reputation: 192

Like
0Likes
Like

Posted 12 March 2012 - 07:47 AM

Tsus,

I have Visual Studio 2010 with C#, but not sure if you guys are using managed C++ or what to compile these things.

I was thinking that the code was a little too "advanced" for what I was shooting for. Is there any way we can drop it back to... Well, pretty primitive stuff? I had noticed the shaders were in v. 3.3, and then did a Wiki cross-reference and saw that this was circa 2010 hardware.

Not trying to build out a monster shader, if possible. My goal is to have this run on very weak machines, i.e. my netbook. I've done a few other optimization's, like limiting the number of things being rendered, shrinking the actual viewing volume, and so forth -- after all, a netbook isn't going to have a huge screen either, so it's fine.

Sorry to be so picky with this stuff -- your code is really awesome and clean -- I can see all the relevant details mapped out. Almost possible to take the code and cookie-cutter it into something else.

### #19Tsus  Members   -  Reputation: 898

Like
1Likes
Like

Posted 13 March 2012 - 07:40 PM

Hi Terin,
Sorry I didn’t have time earlier… Currently I’m programming through day and night… deadlines...
During waiting for some computation to finish, I ported the shadow mapping demo back to GL 2.0.

I have Visual Studio 2010 with C#, but not sure if you guys are using managed C++ or what to compile these things.

No, I’m just using native C++ (e.g. Visual C++ Express Edition), so the Visual C# Express Edition won’t do.

Not trying to build out a monster shader, if possible.

It’s not that GL3.3 shaders are any more complicated or so, they are just a little differently.
I just didn't know that we are targeting a netbook.

Cheers!

#### Attached Files

Acagamics e.V. – IGDA Student Game Development Club (University of Magdeburg, Germany)

### #20Terin  Members   -  Reputation: 192

Like
0Likes
Like

Posted 14 March 2012 - 07:49 AM

Tsus,

As always, THANK YOU! I totally understand coding night/day. I'm the same.

It's not targeting specifically a netbook -- but I want the power to be able to put this on a lot of different machines, which means going with older tech that is most likely more common at the moment.

I'll let you know if I have any questions on this code -- don't be a stranger on the WPF stuff you're working on, if you have any questions! Send me a message here. :-)

Thanks again!

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

PARTNERS