• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

205 Neutral

About Haptic

  • Rank
  1. Understanding the sine function

    tan of an angle simply equals y/x in Emergent's diagram. ie. sin(theta) = y cos(theta) = x tan(theta) = sin(theta)/cos(theta) = y/x The 'arc' or 'a' functions are the inverses. If you have the values of x or y, they allow you to find the angle, theta. arcsin(y) = theta arccos(x) = theta arctan(y/x) = theta Hope it helps!
  2. Problem solved. It was indeed a precision error. I now create my textures using the GL_RGBA32F_ARB format instead of GL_RGBA. Unfortunately it has halved the framerate, but I guess I'll have to live with that. Edit: GL_RGBA16F_ARB also works. I assumed they were already 16 bit but they must have been 8. Anyway, it's running a fair bit faster now. [Edited by - Haptic on August 31, 2010 9:05:28 PM]
  3. I still have one last problem! When I rotate the plane that is being lit, it gets all blocky around the center of the light. Could this be some kind of accuracy issue with my depth values or something? Any ideas? Thanks again
  4. Thanks for the reply jcabeleira. I fixed a couple of errors including adding the camera position and it now works perfectly! Thanks for the tip.
  5. I've found the main mistake, for those interested. The reason half of the picture is black while the other is lit is because I was normalising the normal map in the geometry-pass shader. No idea why I did that, but anyway, the output is now looking almost exactly like the desired output in the first post. Oddly, there's a few parameters that have to be tweaked to get it exactly the same, but I'm far less concerned about that.
  6. Ok, so my frustum corners are not in view-space. Because it's view space, am I right in saying it will never change? It will always be a plane with z = -farDist? So ignoring the 45.0f z-translation, my frustum calculations become float Hfar = 2 * tan(Rad(45.0f)/2.0f) * farDist; float Wfar = Hfar * ((float)width / (float)height); vec3 p = vec3(0.0f, 0.0f, 0.0f); vec3 dir = vec3(0.0f, 0.0f, -1.0f); vec3 up = vec3(0.0f, 1.0f, 0.0f); vec3 right = vec3(1.0f, 0.0f, 0.0f); vec3 fc = p + dir * farDist ; vec3 ftl = fc + (up * Hfar/2.0f) - (right * Wfar/2.0f); vec3 ftr = fc + (up * Hfar/2.0f) + (right * Wfar/2.0f); vec3 fbl = fc - (up * Hfar/2.0f) - (right * Wfar/2.0f); vec3 fbr = fc - (up * Hfar/2.0f) + (right * Wfar/2.0f); Also, my depth was not in view-space. I think it is now..? varying vec3 N; varying vec4 V; void main() { N = gl_Normal; V = gl_ModelViewMatrix * gl_Vertex; // multiply by modelview = View space? gl_TexCoord[0] = gl_MultiTexCoord0; gl_Position = ftransform(); } This doesn't change anything much. Fiddling with the lights z-pos, the best picture I can get is
  7. Hey everyone, So I am trying to reconstruct a pixel's position in 3D space from its depth in GLSL, OpenGL and C++. I was hoping I could run my code by you guys and see if you can spot the mistake. I have been following the tutorials by MJP and the frustum one from Lighthouse3D, as well as the original posts MJP was responding to. To give you an idea of what I'm after, here is the output using forward rendering. And my result using the deferred method. I think my problem might be the spaces I am working in, ie. View or World etc. I'm pretty average with these and have most likely made some errors I can't track down. Frustum Corner Calculations: float fov = 45.0f; float nearDist = 0.1f; float farDist = 100.0f; // ..... // Assuming projection is set as follows gluPerspective(fov,(float)width/(float)height, nearDist, farDist); // ..... // Camera is positioned using // glTranslatef(0.0f, 0.0f, -45.0f); float Hfar = 2 * tan(Rad(45.0f)/2.0f) * farDist; float Wfar = Hfar * ((float)width / (float)height); vec3 p = vec3(0.0f, 0.0f, 45.0f); vec3 dir = vec3(0.0f, 0.0f, -1.0f); vec3 up = vec3(0.0f, 1.0f, 0.0f); vec3 right = vec3(1.0f, 0.0f, 0.0f); vec3 fc = p + dir * farDist ; vec3 ftl = fc + (up * Hfar/2.0f) - (right * Wfar/2.0f); vec3 ftr = fc + (up * Hfar/2.0f) + (right * Wfar/2.0f); vec3 fbl = fc - (up * Hfar/2.0f) - (right * Wfar/2.0f); vec3 fbr = fc - (up * Hfar/2.0f) + (right * Wfar/2.0f); Geometry Pass VERTEX SHADER: varying vec3 N; varying vec4 V; void main() { N = gl_Normal; V = gl_Vertex; // View independent. Is this world space? gl_TexCoord[0] = gl_MultiTexCoord0; gl_Position = ftransform(); } FRAGMENT SHADER: uniform sampler2D diff; uniform sampler2D norm; uniform sampler2D spec; uniform float farDist; varying vec3 N; varying vec4 V; void main() { vec4 d = texture2D(diff, gl_TexCoord[0].st); vec4 n = texture2D(norm, gl_TexCoord[0].st); vec4 s = texture2D(spec, gl_TexCoord[0].st); n = normalize(n); gl_FragData[0] = d; // Diffuse gl_FragData[1] = n; // Normal gl_FragData[2] = s; // Specular //Linear normalised depth gl_FragData[3] = vec4(-V.z / farDist, 0.0, 0.0, 1.0); } Reconstruction Pass VERTEX SHADER: varying vec4 v; varying vec3 viewDir; attribute vec3 corner; void main() { viewDir.xyz = corner.xyz; v = gl_Vertex; gl_TexCoord[0] = gl_MultiTexCoord0; gl_Position = ftransform(); } FRAGMENT SHADER: uniform sampler2D diff; uniform sampler2D norm; uniform sampler2D spec; uniform sampler2D depth; varying vec4 v; varying vec3 viewDir; void main() { float z = texture2D(depth, gl_TexCoord[0].st).r; // normalisedDepth // pos = frustumRay * normalisedDepth // need this to be identical to gl_Vertex in geometry pass vec4 pos = vec4(viewDir.xyz * z, 1.0); ... // Lighting Calculations } If you need any more info let me know. Thanks alot [Edited by - Haptic on August 26, 2010 10:30:54 PM]
  8. Yeah I can see what you're saying, I'll look into it. I might make the thrust and torque adjustable for testing purposes so people can quantify the settings they'd like. Thanks alot.
  9. Thanks alot karwosts, glad to hear it worked (never given out a build before). Do you mean how fast it can actually turn, or how long it takes to get to its maximum turning speed? See, it feels fine to me but I'm used to it now, so that sort of feedback is great. When the game is a bit further along, you will be able to customise your ship, so you could just make it lighter and put better boosters on the sides.
  10. I've finally had some spare time to knock up a prototype for the flying and ship-destruction aspects of the game. Summary: You're in charge of a small fighter, flying between numerous colourful rectangles of varying size. This is basically just a flight test. The ship is composed of its main body (can not be destroyed), and a wing on either side. If you hit an object hard enough (needs to be a bigger object), then there's a chance the wings will break off. This makes your ship always want to turn (due to lack of symmetry), but I've tried to make it more of a nuisance than a death blow. The movement I've aimed for lets you slide around a bit. You can really become quite good at it and drifting around an object with only several pixels between you and death is a great feeling. Feedback Wanted: Any comments you have on the physics/wing-strength etc would be greatly appreciated. Controls Up Arrow - Forward Thrust Down Arrow - Backwards Thrust Left/Right Arrows - Rotate Ship Esc - Quit Game W/S - Inc/Dec Thrust Value D/A - Inc/Dec Torque Value Requirements - 1920x1080 - Windows - VSync Enabled (no dt-movement yet) - Microsoft VC++ 2008 Redistributables It runs at over 1500FPS without VSync on my rig, so performance shouldn't be an issue. Thanks alot to anyone who tries it out. Edit: Customisable thrust and torque values added. Base torque value increased. Angular damping increased accordingly. Download from RapidShare (<200kB) [Edited by - Haptic on May 22, 2010 9:05:56 PM]
  11. Thanks for all the replies! You've given me alot to think about. I must admit I havent played a whole lot of space shooters, I just had a compulsion to build one. I will definitely check out Star Control when I get a chance. Quote:To me it makes sense to just get the controls solid with a minimal amount of add-on components, if any. Yes, I've made sure so far that the 'flying around' by itself is fun enough to captivate me for a while. I'll put up a flight prototype for testing once the damage system is in place. I was thinking each attainable ship class would consist of a 'core' body which would serve as a foundation for adding physical components. The core would contain the bare essentials, such as tiny boosters, so you always have something to fall back on. Of course, if the core dies, you die. So essentially, with no components, you can still have fun flying around, but it will get better and better handling and speed as you improve the ship. Quote: perhaps have a "required men" amount for the parts (like the gun turret) to operate them and so instead of perma death in the context to ships maybe the hired people would die instead and thus you would need to once again hire men to work the part which would further incur financial loss. This is more or less what I was going for. Whether it is crew you have to replace or parts, the essence is that you lose money if you die. The main problem is balancing the economy correctly so that it's a decent blow to the player, but not crippling. Quote:1. Make hanger menu where you can look and re-equip your ships. Of course =). Quote:2. Make level of upgrade modules non-linear. Yeah, balancing the game will be pretty important so I'd definitely invest a lot of time there. I like the idea of show a strength, expose a weakness. One ship will never be the best for all situations.
  12. Edit: Flight prototype. Description can be found in a lower post. Download from RapidShare (<200kB) Hey guys, Out of nowhere, I've started building a 2D space shooter mixing action/strategy with some RPG components to be added later. This is a fledgling idea and I'm happy for people to tear it apart, as long as it's constructive. It will let you design your own ships basically from scratch based on components you have bought or discovered/looted (with a range of defaults/templates for those not so interested in that aspect). Combined with the physics system, this means you can have a tiny agile fighter that can only take a few hits, or a lumbering battlecruiser that can take a beating but handles horribly. There will be large amounts of upgrades (most with optional automation $$), with an intuitive key-mapping system to use them all. So say you add a turret. The basic version will be manually controlled, and so you will have to press keys to aim it and shoot. If you are willing to pay more money though, you can get varying levels of automation or crew which will make the tasks automatic. The automation levels for a tracking missile for example, will most likely involve how many targets can be tracked at once and that sort of thing. Or maybe you just prefer to be in control of particular weapons. All ships would be piece-by-piece destructible. So basically, if somebody runs in to your giant cannon, theres a chance it will break off, and you will lose any benefit it gave. If you were able to, say, break off an enemy fighter's wing without totally destroying it, and then captured it, you could get 'research points' (or just technology) based on its condition and the components attached to it. This would be similar to the usual RPG looting system, but I'm not sure if it would become incredibley tedious or not. How strong the components are depends on your upgrades and ship design and this adds strategy to the design and combat. You could fortify your ship massivley, but this would make it heavy and slow, so your battle-plan would have to change accordingly. I'm not a fan of permadeath in this context, so maybe once you discover a technology, you can always refit it to your ship. This would make dying incur a financial loss but little permanant damage. I like these ideas but they still don't sit completely right with me. I'm especially worried about things becoming overly tedious. The combat is fast-paced and exciting though so maybe it will balance. It's obviously all in early planning but Id love to hear any criticisms or suggestions you guys have. [Edited by - Haptic on May 22, 2010 9:53:30 PM]
  13. tearing (gaps between tiles) ?

    I'm not sure which API you are using, but this should work for OpenGL. In your texture creation code, you need to put these lines: glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP); glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP); You probably already have these lines, but with GL_REPEAT instead of GL_CLAMP. GL_REPEAT wraps the texture around, which can sometimes cause banding because the rightmost column of pixels drawn is actually from the leftmost part of the texture. GL_CLAMP stops this. If this doesn't work, changing your texture coordinates to something slightly different than (0,1) usually works. Say, (0.01f, 0.99f). Good luck,
  14. Here's a daytime shot, which I think looks alot nicer. The diffuse issue is also fixed. I made it nighttime because I was trying to add atmosphere, but adding a slight red tinge to the daytime light does a better job I think. Adds a touch of warmth to it. I'm new to the whole visual design side of things so I'm sure I will make many mistakes along the way! Any comments or suggestions are more than welcome.
  15. Thanks for the feedback Lightness, You are right about the ambient light, I noticed this the other day. I think I accidentally negated the diffuse factor when I made my light color changeable (to allow nighttime effects). This will be a simple shader bug. The game obviously needs some better art, but that's just my lack of ability. As long as the functionality is there to do it, I'm happy enough. I will probably end up seeking help in the forums here for the art and some of the design. Point lights are still yet to be implemented but they will have a great effect on the atmosphere and life of the scenes. I've said the engine's nearly finished, but I keep thinking of things I forgot to add in!
  • Advertisement