• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

subi

Members
  • Content count

    115
  • Joined

  • Last visited

Community Reputation

157 Neutral

About subi

  • Rank
    Member
  1. i did alot of testing about 12 months ago on rendering terrain's using brute force. My results showed the fastest way was using triangle strips and display lists. Using triangle strips and a static VBO was very close but on averages the dsiplay list always beat it. That was on ATI hardware and i never bothered on nvidia hardware. Arranging the data into triangles strips always beat arranging the data into a triangle list. I was suprised because i thought the static VBO way would win hands down but it didn't. Also note i did not use any culling methods at all in my testing. GeoMetrical Mip Mapping is still my favourite terrain algo, simple to implement and still works pretty good on modern hardware and is alot more CPU friendly than ROAM is. ROAM is very outdated and i would not recommend using it at all. Have alook at vterrain, they have a very good list of alot of different terrain algo's.
  2. thanks zoret u r dead right, u must multiply the texture with the color.
  3. still doesn't work, it almost removes the texture completly
  4. i am having a little trouble with my per-pixel lighting under GLSL. below is a pic of the problem. OpenGL fixed Function Lighting GLSL Lighting vert shader: varying vec4 diffuse,ambient; varying vec3 normal,lightDir,halfVector; varying vec2 Texcoord; void main() { normal = normalize(gl_NormalMatrix * gl_Normal)* -1.0; lightDir = normalize(vec3(gl_LightSource[0].position)); halfVector = normalize(gl_LightSource[0].halfVector.xyz); diffuse = gl_LightSource[0].diffuse; ambient = gl_LightSource[0].ambient; gl_Position = ftransform(); Texcoord = gl_MultiTexCoord0.xy; } frag shder: uniform sampler2D baseMap; varying vec4 diffuse,ambient; varying vec3 normal,lightDir,halfVector; varying vec2 Texcoord; void main() { vec3 n,halfV,viewV,ldir; float NdotL,NdotHV; vec4 color = ambient; vec4 tex = texture2D( baseMap, Texcoord ); n = normalize(normal); NdotL = max(dot(n,lightDir),0.0); if (NdotL > 0.0) { halfV = normalize(halfVector); NdotHV = max(dot(n,halfV),0.0); color += diffuse * NdotL; } gl_FragColor = tex + color; } code to set up lighting glEnable(GL_LIGHTING); glEnable( GL_LIGHT0 ); glShadeModel(GL_SMOOTH); GLfloat Ambient[4]; GLfloat diffuse_light0[] = { 1.0f, 1.0f, 1.0f, 1.0f }; Ambient[0] = 192.0f / 255.0f; Ambient[1] = 192.0f / 255.0f; Ambient[2] = 192.0f / 255.0f; Ambient[3] = 1.0f; glLightfv( GL_LIGHT0, GL_AMBIENT, Ambient); glLightfv( GL_LIGHT0, GL_DIFFUSE, diffuse_light0); every frame i update the light's position with(i have a moving camera): GLfloat position_light0[] = {1.0f,1.0f,1.0f,0}; glLightfv( GL_LIGHT0, GL_POSITION,position_light0 ); as you can see from the first picture the lighting works just fine when i disable the shader but when i enable the shader(pic 2) it's just all bright and wrong. This shader is from lighthouse tut's. anyone notice what i am doing wrong??
  5. Hey Fella's just after some opinions: ok here is what we got. I am doing some bump mapping and in my program i calculate the tangent's and obviouslly pass this onto my shader. Everything works great. ATM i am calculating the binormal in the vert shader by doing a simple "cross(tangent,normal)". Should i continue with this method or is it better to let the CPU calculate the binormal and just pass the binormal to the shader like i do the tangents? the downside to this i see is longer loading time, higher system RAM usage. Calculating the binormal on the GPU obviouslly eats up a few cycles every frame. I know it sounds nit picky even worrying about this but it all adds up and when u have a large amount of mesh files loaded in a scene, the little things can suddenly add up.
  6. i am just trying to convert a cg shader to glsl and cg uses a function called mad....glsl don't have this and i assume it means multiply and add is this correct than? float mad(float a,float b,float c) { return a + (b*c); } //or this: float mad(float a,float b,float c) { return (a*b)+c; } //or perhpas something else?? [Edited by - subi on May 11, 2006 3:35:15 AM]
  7. save yourself the trouble and buy a license for Freeworld3D. It's cheap as....www.freeworld3d.org
  8. yeah i have just renamed them here for clarifaction
  9. i just need a little help workig out the s-tangent in the following case: trying to some some simple bump mapping with GLSL i am drawing a cube and sending the s-tangent through glColor3f to the vert shader glBegin(GL_QUADS); // Front Face glColor3f(?,?,?); //send s-tangent through color glNormal3f( 0.0f, 0.0f, 1.0f); glMultiTexCoord2fARB( GL_TEXTURE0_ARB,0.0f, 0.0f); glVertex3f(-1.0f, -1.0f, 1.0f); glMultiTexCoord2fARB( GL_TEXTURE0_ARB,1.0f, 0.0f); glVertex3f( 1.0f, -1.0f, 1.0f); glMultiTexCoord2fARB( GL_TEXTURE0_ARB,1.0f, 1.0f); glVertex3f( 1.0f, 1.0f, 1.0f); glMultiTexCoord2fARB( GL_TEXTURE0_ARB,0.0f, 1.0f); glVertex3f(-1.0f, 1.0f, 1.0f); // Back Face glColor3f(?,?,?); glNormal3f( 0.0f, 0.0f,-1.0f); glMultiTexCoord2fARB( GL_TEXTURE0_ARB,1.0f, 0.0f); glVertex3f(-1.0f, -1.0f, -1.0f); glMultiTexCoord2fARB( GL_TEXTURE0_ARB,1.0f, 1.0f); glVertex3f(-1.0f, 1.0f, -1.0f); glMultiTexCoord2fARB( GL_TEXTURE0_ARB,0.0f, 1.0f); glVertex3f( 1.0f, 1.0f, -1.0f); glMultiTexCoord2fARB( GL_TEXTURE0_ARB,0.0f, 0.0f); glVertex3f( 1.0f, -1.0f, -1.0f); // Top Face glColor3f(?,?,?); glNormal3f( 0.0f, 1.0f, 0.0f); glMultiTexCoord2fARB( GL_TEXTURE0_ARB,0.0f, 1.0f); glVertex3f(-1.0f, 1.0f, -1.0f); glMultiTexCoord2fARB( GL_TEXTURE0_ARB,0.0f, 0.0f); glVertex3f(-1.0f, 1.0f, 1.0f); glMultiTexCoord2fARB( GL_TEXTURE0_ARB,1.0f, 0.0f); glVertex3f( 1.0f, 1.0f, 1.0f); glMultiTexCoord2fARB( GL_TEXTURE0_ARB,1.0f, 1.0f); glVertex3f( 1.0f, 1.0f, -1.0f); // Bottom Face glColor3f(?,?,?); glNormal3f( 0.0f,-1.0f, 0.0f); glMultiTexCoord2fARB( GL_TEXTURE0_ARB,1.0f, 1.0f); glVertex3f(-1.0f, -1.0f, -1.0f); glMultiTexCoord2fARB( GL_TEXTURE0_ARB,0.0f, 1.0f); glVertex3f( 1.0f, -1.0f, -1.0f); glMultiTexCoord2fARB( GL_TEXTURE0_ARB,0.0f, 0.0f); glVertex3f( 1.0f, -1.0f, 1.0f); glMultiTexCoord2fARB( GL_TEXTURE0_ARB,1.0f, 0.0f); glVertex3f(-1.0f, -1.0f, 1.0f); // Right face glColor3f(?,?,?); glNormal3f( 1.0f, 0.0f, 0.0f); glMultiTexCoord2fARB( GL_TEXTURE0_ARB,1.0f, 0.0f); glVertex3f( 1.0f, -1.0f, -1.0f); glMultiTexCoord2fARB( GL_TEXTURE0_ARB,1.0f, 1.0f); glVertex3f( 1.0f, 1.0f, -1.0f); glMultiTexCoord2fARB( GL_TEXTURE0_ARB,0.0f, 1.0f); glVertex3f( 1.0f, 1.0f, 1.0f); glMultiTexCoord2fARB( GL_TEXTURE0_ARB,0.0f, 0.0f); glVertex3f( 1.0f, -1.0f, 1.0f); // Left Face glColor3f(?,?,?); glNormal3f(-1.0f, 0.0f, 0.0f); glMultiTexCoord2fARB( GL_TEXTURE0_ARB,0.0f, 0.0f); glVertex3f(-1.0f, -1.0f, -1.0f); glMultiTexCoord2fARB( GL_TEXTURE0_ARB,1.0f, 0.0f); glVertex3f(-1.0f, -1.0f, 1.0f); glMultiTexCoord2fARB( GL_TEXTURE0_ARB,1.0f, 1.0f); glVertex3f(-1.0f, 1.0f, 1.0f); glMultiTexCoord2fARB( GL_TEXTURE0_ARB,0.0f, 1.0f); glVertex3f(-1.0f, 1.0f, -1.0f); glEnd(); in the vert shader: vec3 s-tangent = gl_Color.xyz; vec3 normal = gl_Normal.xyz; vec3 t-tangent = cross(s-tangent, normal); //binormal so in the above example how do i calculate the s-tangent for each face of the cube? also is that the correct way to work out the t-tangent in the vert shader too?
  10. Hi Everyone In my current engine i make alot of calls to the standard math function sqrt. i was wondering if it is worth using sse2 instructions and using a bit of assembly to do this instead, i have come up with this and it appears to work. float SSE2sqrt(float src) { float t; _asm { movupd xmm0, src movupd xmm1,t sqrtss xmm1,xmm0 movupd t,xmm1 } return t; } do you think trying a few of these type of optimizations are worth it or just a waste of time?
  11. i create my water grid with basically a brute force terrain way just obviouslly without the height value.
  12. sounds like your culling code is a little too aggressive if you can actually see the terrain getting culled
  13. yep you are dead right, thanks mate...that was the last thing i was thinking about it ...problem solved!! :-)
  14. sorry i didn't explain the rest properly ....the water plane is made up very similiar to brute force like terrain. I am using regular triangle list and it is indexed. when you go very close to the seam, you can see it is caused from the texture coords been distorted. Only prob is i don't know how to get the effect i want without distorting the tex coords.
  15. When i am rendering my water i can see like the edges and they move as the water moves. See Picture in the pixel shader i have tried clamping the Texture coords but that doesn't fix the problem. any suggestions anyone?