Chris Burrows

Members
  • Content count

    14
  • Joined

  • Last visited

Community Reputation

121 Neutral

About Chris Burrows

  • Rank
    Member
  1. Where is my Geometry Shader broken?

    I have shader error checking, some things slip through you know.   Ah sure. What I did was delete all my shader code, and then re-write it from my mind. It's hard to say where the error was and since then the code has changed too much to compare it to my original post. There's really nothing more I can say about it.   That geometry shader above doesn't even do anything, it simply passes the same values from the vertex shader to the fragment. But since getting that working, I enhanced it to render all my shadow maps in a single pass which marks a huge breakthrough for me, 32 shadow casting point lights running at 60fps.  
  2. Where is my Geometry Shader broken?

    I changed the code in the post to make it more readable, so it could have been either. I ended up re-writing the shaders from scratch and that fixed it. Thanks heaps for taking a look.
  3. Hi, I've successfully implemented shadow mapping and would like to incorporate a geometry shader for optimisation. It works fine without the geometry shader, but with it, it breaks, and nothing meaningful is drawn to the cubemap. At this point, the geometry shader doesn't even do anything, it simply passes the values from the vertex shader to the fragment. I suspect the geom_v_position or frag_v_position values aren't being passed across the stages correctly. I've been going over this for some while and can't find the problem. Any help would be amazing. Thanks in advance! ^_^ Vertex Shader #version 330 precision lowp float; layout(location = 0) in vec3 in_position; uniform mat4 projectionMatrix; uniform mat4 viewMatrix; uniform mat4 modelMatrix; out vec4 geom_position; void main() { gl_Position = projectionMatrix * viewMatrix * modelMatrix * vec4(in_position, 1.0); geom_v_position = viewMatrix * modelMatrix * vec4(in_position, 1.0); } Geometry Shader #version 330 layout(triangles) in; layout(triangle_strip, max_vertices=3) out; in vec4 geom_v_position[]; out vec4 frag_v_position; void main() { for(int i=0; i<3; i++) { frag_v_position = geom_v_position[i]; gl_Position = gl_in[i].gl_Position; EmitVertex(); } EndPrimitive(); } Fragment Shader #version 330 precision lowp float; in vec4 frag_v_position; layout (location = 0) out vec4 outColor; void main() { float depth = length( vec3(frag_v_position) ) / 20; float moment1 = depth; float moment2 = depth * depth; float dx = dFdx(depth); float dy = dFdy(depth); moment2 += 0.25*(dx*dx+dy*dy); outColor = vec4( moment1, moment2, 0.0, 0.0); }
  4. OpenGL OpenGL Paid Work

    I'm after somebody to re-write two C++ OpenGL examples in C# OpenTK. They're pretty basic and I'm sure it'd take under an hour for somebody who knew how. $50 (AUD) up for grabs. They are deferred rendering and deferred rendering shadow mapping from Marco Alamia's website. The problem is my knowledge of C++ is limited, I've been programming for years, but almost exclusively in C#. Basically, I look at his code and can't discern the program flow. To speed up the process, I've thrown together a basic OpenTK project to work atop of, unless you'd rather go from scratch that is. The code is pretty clean, and should be easy to navigate. I'll email it upon request.  
  5. Representing an iso map in a 2d array?

    [quote name='FLeBlanc' timestamp='1348064577' post='4981685'] no need for negative array indices; not sure where you got that idea [/quote] As I said originally, I require the entire visible map to be covered with tiles. Using a traditional square grid on a tilted on a 30 degree angle means that there are going to be tiles with negative array indices, shown in black. [img]http://imageshack.us/a/img138/4294/negative2i.jpg[/img] Unless however, the (0,0) index is far off to the left somewhere, seemingly the preferred method. In the image below, the green rectangle depicts the desired visible map, it also shows the array co-ordinates within the map using the staggered approach. The giant blue rhombus, demonstrates the size of a tilted array required to cover the same size map with tiles. [img]http://imageshack.us/a/img100/4223/arrayh.jpg[/img] As you can see, using the staggered approach cuts the size of the array in half, but as FLeBlanc mentioned, this is unlikely to have any impact on performance. Personally, I prefer the staggered approach for it's elegance. Positioning the tiles on screen is simple: X co-ordinate: (X index * Tile width) + ((Y index mod 2) * ( Tile width / 2)) Y co-ordinate: Y index * (Tile height / 2) I've already coded the pathfinding and movement with a staggered grid ([url="http://www.diybandits.com.au/Random/Update.zip"]here[/url] is a demo if anybody is interested), but I haven't come much further than that. I think I'll head the advice and re-write with the (0,0) offset method. Thanks for the help. [quote name='Krohm' timestamp='1348037153' post='4981568'] But your world representation does not have to be an array. [/quote] What other choices do I have? Hash table? My pathfinding code is pretty dependant on arrays, but I'm always open to suggestions...
  6. Representing an iso map in a 2d array?

    Hmmm, interesting. Is that the general consensus? I know in Starcraft 1, although it appears iso, it actually uses a square grid with square tiles. The Blizzard artists simply faked the iso. But in games that are "true" iso, with rhombus tiles, are you saying they use an extra large tilted array with thousands of unused cells?
  7. Hello, I'm working on an iso RTS and I'm using the staggered approach to store my map data in an array. This means that each X co-ordinate represents 2 different X tiles, depending whether or not the Y co-ordinate is odd or even, in which case the tile is offset, shown below. [img]http://imageshack.us/a/img221/7870/mapiso.gif[/img] This works fine, however it does add an extra layer of complexity to every calculation, pathfinding, movement, etc. I am curious, what are the alternatives? I require the whole map to be filled with tiles, so simply tilting a traditional square grid will not work, because many tills will have negative co-ordinates, and arrays do not have negative cells, shown below. Unless (0,0) is far, far off in the top left somewhere, but that leaves a huge amount of empty array cells and a seemingly unnecessary giant array. My maps are 256x512. [img]http://imageshack.us/a/img27/7569/negativem.jpg[/img] I'm open to all suggestions. Thank you for your time. - Chris
  8. A* jaggard lines?

    Not in Multimedia Fusion 2. The closest would be a string array, in which you would convert the float to a string before you store it, and then back to a float when you retrieve it. Obviously, this is not very efficient. But, now I've solved the problem, I will re-write the code in c++, although that would have worked from the beginning. Silly integer arrays!
  9. A* jaggard lines?

    [size=8][b]VICTORY![/b][/size] I re-implemented A* from scratch and found the problem! I am using a 3d array to store the G, H, F, ParentX and ParentY values for each tile during the search. But the thing is, in Multimedia Fusion 2, arrays are unable to store floating point values. All non-whole numbers are rounded down to the closest integer. The Heuristic is rarely a whole number and that was the direct cause of my A* blues. My solution was to use a cost of 1000 orthogonal and 1400 diagonal as opposed to 10 and 14 allowing for the equivalent of 2 decimal places of percision. However, if you examine the G, H and F values for each square, you will notice they don't quite match 1000 and 1400. This is because I am multiplying every G value by 0.9925 and every H value by 0.0075 to break the tie between F values which would otherwise be the same for multiple tiles. This causes A* to favour tiles which are closer to the target. [img]http://imageshack.us/a/img707/5151/victoryz.jpg[/img] Thank you everybody for your help. [img]http://www.sega-16.com/forum/images/icons/Pirate%20Smiley.gif[/img] Yarrr! Until next tyme me hearty!
  10. A* jaggard lines?

    Thanks Jefferytitan, The formular for xadjusted is correct, but the yadjusted is a little off. [img]http://imageshack.us/a/img69/1778/mapiso2.gif[/img] Both red tiles are 2 below the yellow tile. But, according to your formular, the leftmost tile is 3 below (2 - 5 = -3). However, I noticed a correlation between your two formulars, and this works: x adjusted = x - floor(y/2) x distance = (A.x - floor(A.y/2)) - (B.x - floor(B.y/2)) y distance = (A.x - floor(A.y/2)) - (B.x - floor(B.y/2)) - (A.y - B.y) So, using pythagoras, I calculated the correct Euclidiean distance, but the strange thing is, it hasn't changed my paths. They still favour the same long straight lines shown in my original screenshot (in dark red). I've decided the staggered iso grid only adds an extra layer of compexity to my problem, so I will re-write the code for a square grid and see if I can achieve my desired zig zags there. On a side note, Jefferytitan, you mentioned my staggered grid is unusual. The alternative of a titled square grid means that if I want the entire screen to be filled with tiles, then some squares with have negative co-ordinates, shown below (the top left and bottom left white regions). [img]http://imageshack.us/a/img27/7569/negativem.jpg[/img] And seeing as there are no negative array cells, this was not an option. Thanks again! I'm open to all suggestions.
  11. A* jaggard lines?

    Thanks everybody for your help, it seems it is the Manhattan heuristic after all. I found a program called [url="http://www.programmersheaven.com/download/1001/download.aspx"]PathDemo[/url] which allows you to test and modify a variety of path finding algorithms. The image below shows A* using both the Euclidien and Manhattan distances for a heuristic. [img]http://imageshack.us/a/img826/7922/distanced.jpg[/img] The path found using the Euclidiean distance is definitely more natural. So that's solves one problem, but presents another: How do I caculate the Euclidean distance? Traditionally it is simply sqr((ax-bx)^2+(ay-by)^2), but that won't work for me because I am using a staggered iso grid in which each X grid co-ordinate actually represents 2 different tiles depending on if the Y co-ordinate is odd of even. [img]http://imageshack.us/a/img221/7870/mapiso.gif[/img] I just can't seem to crack it. Any help would be greatly appreciated!
  12. A* jaggard lines?

    Haha, I don't want excess zig zags, I'd just like the same treatment everybody else gets. I'm a huge fan of Warcraft 2 and I'm aiming for a similiar standard. The zig zags don't bother me, but what I have currenlty is something much worse. Either lonng straight lines or lonng straight diagonals. I guess what I am asking is has anybody seen this before? and if so, do you fix it? and if not, any ideas what is causing it?
  13. A* jaggard lines?

    I think you're mistaken FLeBlanc, the zigs and zags is what I want! For the heuristic, I am using the manhatten distance. The formula itself is somewhat complicated because I am using a staggered iso grid and every other cell is offset.. (Max(Abs(2*TargetX+(TargetY mod 2)-2*CurentX-(CurrentY mod 2)), Abs(TargetY-CurrentY)))*10 The formula is spot on, plus, I was experiencing the same problem with a square grid, so it's not that. Is there a better choice than manhatten? Regarding the G cost, I have given orthogonal traversing a cost of 10, and diagonal a cost of 14. As described in the article I linked, yet his code favours the jaggard lines. The Gamasutra article, Toward More Realistic Pathfinding, explains how to make zigs and zags into straight diagonal A to B distances, shown below... [img]http://imageshack.us/a/img829/4708/90201812.jpg[/img] .. but what I am experiencing is something different all together, see my original screenshot.
  14. A* jaggard lines?

    Hello world, Recently, I began working on an RTS. I'm using A* and it is working well, only I don't like how my paths contains long straight lines (both orthogonal and diagonal), shown in dark red below. I would prefer if the paths favoured more "jaggard" lines, as shown below in light brown. [img]http://imageshack.us/a/img145/6460/astarblues.jpg[/img] It seems every other implementation of A* which I have seen actually favours jaggard lines by default, but for some reason mine doens't work that way, and as far as I can tell I am not doing anything differently. I can't paste my source because I am writing the game in Multimedia Fusion which doesn't use traditional code. But, I did base my "code" on [url="http://www.policyalmanac.org/games/aStarTutorial.htm"]this article[/url], seemingly a pretty standard of version A*. If anybody has any ideas why this is occuring, I'd love to hear about it! Thanks in advance, Chris. PS. [url="http://www.diybandits.com.au/Random/Update.zip"]Here[/url] is the executable if anybody is interested.