Jump to content

  • Log In with Google      Sign In   
  • Create Account


blueshogun96

Member Since 09 Jun 2005
Online Last Active Today, 09:04 PM
****-

#5168198 How dangerous is returning a initialized pointer in C++?

Posted by blueshogun96 on 21 July 2014 - 01:10 PM

Okay, I don't quite understand why you are doing things this way.  You declare a global pointer, then use it to initialize the same global pointer.  Why?  if gEngine is not allocated, then calling ::Create is just going to crash.

 

I use C++ myself, but this is how I would do it instead.

void CreateEngine()
{
   gEngine = new EngineAPI();

   /* Do error checking here */
}

What you are doing appears to be quite unnecessary.  Is there a particular reason you want your engine this way?

 

Shogun.

 

EDIT: One more detail.  If you are returning an initialized pointer from C++ to C#, that is a bad idea.  C++ has it's own code routines for initializing a pointer via "new", whereas C# is undoubtedly different, so calling delete on a C++ pointer in C# is potentially dangerous.  Think of it this way, would you use malloc() for a C pointer, then deallocate it with delete in C++?  That is a VERY bad idea, and I would not recommend it.




#5166241 How much more work is needed for an S or C corp?

Posted by blueshogun96 on 11 July 2014 - 10:21 AM

So far, I have the gist of what makes a corporation different than an LLC, and the main difference between an S corp and a C corp. what I haven't yet grasped is how much more work it takes to run, and maintain a corporation, especially a C corp.

If I may ask, are there any members here that have experience starting and/or running a corporation (especially a C corp)? Thanks.

Shogun.


#5157737 With OpenGL, should I use GLut or SDL?

Posted by blueshogun96 on 03 June 2014 - 01:03 AM

If your ultimate goal is to create games that you want to sell and redistribute, don't use GLUT (unless you absolutely HAVE to), and chances are you will not have any solid reasons to use it.  SDL has much more to offer as a game dev then GLUT does.  As it was already mentioned, GLUT is really old and is not actively maintained.  SDL, however, is and is much more suitable for games as it was largely inspired for such usage.

 

In my experience, I have experienced better control and performance using SDL.  GLUT is widely supported on nearly every OS, but implementing controls using GLUT is not feasible to say the least.  I wrote a very simple game using GLUT on Windows once, and thought it worked fine for the most part, but when I ported it to other OSes, the controls were not nearly as smooth for what a game should have, because they were not suited for games (the keyboard timestamp feature will annoy you and everyone else who plays your game; also, the mouse input is not very smooth or accurate enough).  SDL takes a bit more work to setup, but it's worth it.

 

Lastly, using GLUT, you are limited to legacy OpenGL, afaik.  With SDL 2.0, you can easily create a context for the latest OpenGL version you want/need.  This should be a deal breaker for GLUT in most cases alone.

 

Before I wrap up my response, I will give a small defense for GLUT.  I actually have my latest game using GLUT atm.  The reason why I chose GLUT (at the time at least) was because it was easy to setup, and my game in particular with it's mechanics were much easier to get up and running using GLUT.  Another reason is that GLUT's borderless window was proven invaluable when deving and debugging on MacOSX.  Lastly, I initially started writing my game on MacOSX, not knowing much of anything about OpenGL for Mac.  GLUT just felt right at that moment, and it ultimately saved me much time, energy, frustration and needless hassle (there are some features in my game I never would have considered if I didn't use GLUT), but ultimately, using GLUT in a commercial game comes with a price.  Since GLUT is not actively maintained, you are risking future compatibility with new OSes.  The same old glut32.dll or GLUT.framework is not guaranteed to be working on the next Windows or MacOSX, respectively, due to possible removal of a specific API or something.  That probably won't happen, but it can, and it's not worth the risk, IMO.  When it's time for the release, I will likely switch to SDL to avoid that potential land mine.

 

My recommendation to you is to learn the basics of SDL 2.0.  Don't bother with the deprecated SDL 1.x, and it's easy to get the two confused as many things have changed for the better, causing some functionality not to work (Example, if you want SDL 2.0 controller functionality, use this, not the legacy stuff because it won't work).

 

Don't worry about GLUT or legacy OpenGL.  If your card/drivers support it, start learning OpenGL 4.1 or later.

 

Shogun.




#5155027 Templates causing linker errors.

Posted by blueshogun96 on 21 May 2014 - 04:37 AM

It's not missing, but I solved the problem though.

 

The template functions needed to be moved from a .cpp to a .inl and the functions needed to be inlined.  Then include the .inl instead of .hpp, and that solved everything.

 

Shogun.




#5147453 .so file can't be loaded!

Posted by blueshogun96 on 16 April 2014 - 01:58 PM

Okay, finally fixed it following these instructions:  http://stackoverflow.com/questions/5210107/prevent-manually-added-libraries-from-being-deleted-by-ndk-build

 

It's really annoying that my .so files are automatically deleted when placed in the armeabi folders.  But now it works, and that's all that really matters.  Thanks alot.

 

Shogun.




#5147287 .so file can't be loaded!

Posted by blueshogun96 on 16 April 2014 - 12:43 AM

I've spent roughly 1/3 of my day searching for a solution for this, and haven't found a darn thing so far.  My app uses the NDK and the main game library is dependent on another library, OpenAL Soft.  I've tried including it in multiple ways and no matter what happens, my app crashes because it can't find it.

 

This is my Android.mk file if it helps.

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE    := Looptil
LOCAL_CFLAGS    := -Wall -Wextra
LOCAL_C_INCLUDES += $(NDK_APP_PROJECT_PATH)/../../source/vectormath
LOCAL_C_INCLUDES += $(NDK_APP_PROJECT_PATH)/../../source/enet-1.3.6/include/
LOCAL_C_INCLUDES += $(NDK_APP_PROJECT_PATH)/../../source/enet-1.3.6/include/enet
LOCAL_C_INCLUDES += $(NDK_APP_PROJECT_PATH)/include/
LOCAL_SRC_FILES := ../common/game.c jni.c 
LOCAL_SRC_FILES += ../../../source/stbi.c 
LOCAL_SRC_FILES += ../../../source/ezxml.c 
LOCAL_SRC_FILES += ../../../source/linkedlist.c 
LOCAL_SRC_FILES += ../../../source/spline.c 
LOCAL_SRC_FILES += ../../../source/math.cpp 
LOCAL_SRC_FILES += ../../../source/debug.cpp
LOCAL_SRC_FILES += ../../../source/input.cpp
LOCAL_SRC_FILES += ../../../source/rng.c
LOCAL_SRC_FILES += ../../../source/ogldrv.cpp
LOCAL_SRC_FILES += ../../../source/leaderboard.cpp
LOCAL_SRC_FILES += ../../../source/menus.cpp
LOCAL_SRC_FILES += ../../../source/profile.cpp
LOCAL_SRC_FILES += ../../../source/aldrv.cpp
LOCAL_SRC_FILES += ../../../source/wavstream.c
LOCAL_SRC_FILES += ../../../source/game.cpp
LOCAL_SRC_FILES += ../../../source/net_put.cpp
LOCAL_SRC_FILES += ../../../source/netplay.cpp
LOCAL_SRC_FILES += ../../../source/ndk_util.c
LOCAL_SRC_FILES += ../../../source/jo_jpeg.cpp
LOCAL_SRC_FILES += ../../../source/enet-1.3.6/callbacks.c
LOCAL_SRC_FILES += ../../../source/enet-1.3.6/compress.c
LOCAL_SRC_FILES += ../../../source/enet-1.3.6/host.c
LOCAL_SRC_FILES += ../../../source/enet-1.3.6/list.c
LOCAL_SRC_FILES += ../../../source/enet-1.3.6/packet.c
LOCAL_SRC_FILES += ../../../source/enet-1.3.6/peer.c
LOCAL_SRC_FILES += ../../../source/enet-1.3.6/protocol.c
LOCAL_SRC_FILES += ../../../source/enet-1.3.6/unix.c
LOCAL_LDLIBS := -lGLESv2 
LOCAL_LDLIBS += -lopenal

include $(BUILD_SHARED_LIBRARY)

Initially, I was including the library directly by using $(NDK_APP_PROJECT_PATH)/lib/libopenal.so, but that didn't work either, so I moved it to the main library folder.  Everything builds fine, and no linker errors show up.  And yes, I did attempt to call System.loadLibrary as so:

try 
{
	System.loadLibrary("openal");
	System.loadLibrary("Looptil");
}
catch( UnsatisfiedLinkError e )
{
}

I've also tried changing the file name to libopenal.so, adding a full path, and tried every suggestion I've found on google; nothing works.  This REALLY sucks.  Any ideas?  Thanks.

 

Shogun.

 

EDIT: If it helps, this is the build of OpenAL-Soft I'm using: https://github.com/apportable/openal-soft




#5143390 What should my priority be for my game now?

Posted by blueshogun96 on 31 March 2014 - 12:26 AM

So, given a handful of variables, I'm trying to think of what my main focus should be for my game atm.  I'm throwing a few scenarios out there now, and giving you all a chance to give me a few ideas.  I ask because I'm a bit stuck, mentally.  There's much to be done, but what to tackle first, and in what order... decisions, decisions.

 

Should I be... 

  1. Polishing up my game for iFest (Seattle) before May 3rd?
  2. Porting my game to Android? (I already have Mac, Win32, and iOS done)
  3. Working on a trailer?
  4. Focusing on a press kit?
  5. Creating a demo for Steam?
  6. Updating the website with UTD information about my game?
  7. Finishing up the HTML5 browser demo of my game?
  8. File for the LLC (I've been putting that off for a bit too long)?

Or what?  My game's progress was moving along rather fast, until I had to take a day career again.  Before then, I'd spend at least 60+ hours a week working on this, from sun up till sunset.  Now I'm fortunate to get at least 20, even on the weekends, assuming I can focus outside of work.

 

This is the order I'm guessing I should do things: 6, 1, 7, 3, 4, 5, 8, 2.

 

What do you suggest?  Thanks.

 

Shogun.




#5140244 HTML5: Broken lines...

Posted by blueshogun96 on 19 March 2014 - 01:10 AM

Okay, fixed it!

 

I honestly forgot to take your last bit of advice.  Moving beginPath(), lineWidth and stroke() outside of the loop did it.  Now that I have better understand of how these functions work, hopefully I won't abuse it in the future.

 

The function now looks like this:

function draw_trails()
{
    var game_canvas = document.getElementById("game_canvas");
    var context = game_canvas.getContext("2d");
    
    /* Draw all trails */
    context.beginPath();
    for( var i = trails.length; i--; )
    {
        if( i === trails.length )
            context.moveTo( trails[i].x1, trails[i].y1 );
        else
            context.lineTo( trails[i].x1, trails[i].y1 );
        context.lineTo( trails[i].x2, trails[i].y2 );
    }
    context.lineWidth = 2;
    context.stroke();
}

Thanks again.

 

Shogun.




#5139326 HTML5: Broken lines...

Posted by blueshogun96 on 15 March 2014 - 04:55 PM

As of late, I've been creating an HTML5 version of my game (with basic functionality).  I'm new to HTML5 game dev, so I'm still learning the ropes here.  What I'm trying to do is leave a line/trail behind the user's movement.  In C/C++, everything works fine, but in HTML5/Javascript, the trail is broken and not every line gets drawn.

 

Screen Shot 2014-03-15 at 3.31.21 PM.png

 

No idea why.  This is the first time I've run into this issue.  Windows, MacOSX, iOS, no problems on the native side.

 

The relevant bits of my code below:

/* Trails */
function trail_t( x1, y1, x2, y2 )
{
    this.x1 = x1;
    this.y1 = y1;
    this.x2 = x2;
    this.y2 = y2;
    this.intersection = false;
    this.alpha = 255;
}

var trails = [];


function draw_user()
{
    var game_canvas = document.getElementById("game_canvas");
    var context = game_canvas.getContext("2d");
    
    /* Draw the asterisk */
    context.translate( user.x, user.y );
    context.rotate( user.rot );
    context.drawImage( small_asterisk_image, -8, -8, 16, 16 );
    context.rotate( -user.rot );
    context.translate( -user.x, -user.y );
    
    user.rot += 5.0/(360.0/(Math.PI*2));
    
    /* Add trails */
    add_trail();
}

function add_trail()
{
    /* Add a new line */
    var t = new trail_t( user.x, user.y, user.lx, user.ly );
    trails.push(t);
}

function draw_trails()
{
    var game_canvas = document.getElementById("game_canvas");
    var context = game_canvas.getContext("2d");
    
    /* Draw all trails */
    for( var i = trails.length; i--; )
    {
        context.beginPath();
        context.moveTo( trails[i].x1, trails[i].y1 );
        context.lineTo( trails[i].x2, trails[i].y2 );
        context.lineWidth = 2;
        context.stroke();
    }
}

function update_trails()
{
    /* Update all trails */
    for( var i = trails.length; i--; )
    {
        trails[i].alpha -= 5;
        if( trails[i].alpha < 5 )
        {
            trails.splice( i, 1 );
        }
    }
}

Everything goes smoothly, except for that.  No idea why.  Any ideas?  Thanks.

 

Shogun.




#5135886 Game Trailer Pages?

Posted by blueshogun96 on 02 March 2014 - 12:51 PM

I'm not sure if I used the right words to describe what I'm talking about.  I already tried Googling this, but nothing related to what I'm searching for comes up, so I'll have to give an example.  Take a look at this page created by a member of gamedev.net (who's name I can't remember because he only appeared once on the chat):

 

http://runordiegame.com/

 

Now, there are handfuls of pages on the net about making a trailer, advertising, monetization and what not, but I can't seem to find any articles on what makes a good page designed for a game trailer.  My assumptions would be this, as a starting point at least:

 

- The page should be a subdomain.[your domain].com/net

- Have a decently sized and polished trailer in the center.

- A short but precise written description of the game.

- Links to social networking pages (i.e. twitter, facebook, linked-in, google+, tumblr, youtube, blogger, etc.) with appropriate icons.

- Icons symbolizing what platforms it will be available for.

- Copyright and legal information at the bottom.

- Link to the main website.

- Links to a kickstarter (if applicable).

- Optimizations for mobile devices?

 

That's all that I can think of off the top of my head, since I'm actually about to leave rather soon.  I'm sure there's much more to it than this though.  So, any ideas?  Thanks.

 

Shogun.




#5135656 Large textures are really slow...

Posted by blueshogun96 on 01 March 2014 - 10:24 AM

 


I have yet to compress the texture (haven't looked into how to do so yet).

It is literally dead simple. Fire up texturetool on the command line, and profit.

 

I've never heard of texturetool.  Does it come with XCode or something?  Let me google that.

 

Shogun.




#5135537 Large textures are really slow...

Posted by blueshogun96 on 28 February 2014 - 06:56 PM

1st gen iPads are a nightmare for fill-rate. Switching to PVRTC will help.

 

If your texture allows it, then identify areas which don't need to be filled, and use trade extra geometry for less fill-rate. You could even take that to an extreme, assuming we're talking about concentric hexagons visible in this image (http://shogun3d.net/images2/looptil/04.jpg), then the performance will be massively better if they are rendered as geometry with no texture whatsoever. A thousand or so extra triangles is nothing compared to the hundreds of thousands of pixels you'll avoid filling.

What I ended up doing was rendering 4 quads to avoid drawing the area that was fully transparent.  Now I get 60fps majority of the time.

 

 

 


I'm going to try compressing it to use PVRTC soon, because I'm using RGBA8, which i know isn't too optimal, especially since it's black and white.

If that texture is greyscale + alpha, you are currently using 2x the memory bandwidth by loading it as a RGBA8. The win from downsizing that to 2 channels is likely to overshadow any gains due to texture compression.

 

Convert to a LUMINANCE_ALPHA 2-channel setup, and compress it, and you should be cooking (although, as other posters have mentioned, any large holes should be created with geometry, not alpha).

 

 

I have yet to compress the texture (haven't looked into how to do so yet).  The large hole created with geometry worked.

 

 

You said "overlay" which implies you are blending the whole thing on top after the rest of the stuff.  Instead render it as a background, glDisable(GL_BLEND).

And then make the yellow bar and whatever else glEnable(BLEND), you will be blending much much less pixels. And even your black text, obviously nothing blends with black, so when drawing black objects dont blend with the background. You should see the same exact results.

That defeats the purpose of the overlay image altogether.  Without the alpha blending, it looks awkward and isn't desirable.

 

 

Also as the other guy suggested about holes:  Any 100% transparent pixels should be alpha tested out so that they dont blend in. use GL_ALPHA_TEST and GL_BLEND together.

Alpha testing on mobile devices is generally slower, and should be avoided.  This is what I've read many times while googling iOS optimizations.  Second, I'm using OpenGL ES 2.0, and it doesn't appear that GL_ALPHA_TEST is supported.  Gives me an error when I try to enable it because it's not defined.

 

Anyway, it's working at acceptable speeds now.  Next I'll do some further optimizations such as texture compression, etc.

 

Shogun.




#5135414 Large textures are really slow...

Posted by blueshogun96 on 28 February 2014 - 11:30 AM

One of my main game features (visually) is the overlay texture I'm using.  This overlay texture is full screen, and covers the entire screen which gives it a nice transparent pattern.  On my PC and Mac builds, the impact to my framerates are minimal at best.  On my iPad, I lose 15fps automatically.

 

I did some google searching, but didn't quite find a solution yet.  The overlay image is 1024x768 and fits the entire iPad screen nicely.  At first I assumed it was because the texture wasn't POT.  So I tried splitting it into two textures: 1024x512 and 1024x256.  Still to slow.  So I tried googling some more.  It turns out that the fill rate for mobile devices (especially a 1st Gen iPad) isn't nearly as fast as a PC or Mac video card.  That's understandable because the entire quad uses alpha blending and the entire screen has to be processed by the fragment program, but I still haven't quite found a solution yet.  

 

One idea I had was to render a few rows of 32x32 textured quads.  The other idea is to get a new iPad.  Tbh, I was trying to hold off on getting a new iPad because I'm saving for other hardware as well as licenses (fortunately for me, I can save up more than $1000 USD per month easily).  On top of that, I want my game to work at proper speeds on an iPad2.  When my game is ready, I will likely make it iOS7 exclusive anyway.  And lastly, I plan on presenting this game at a public event in Seattle in early April, so I have to get the frame rates working acceptably before then (nobody wants to spend too much time on fixing a minuscule problem when there are other features that need to be finished).

 

I'm sure someone else has had the same problem here, but I still haven't managed to google any solutions.  This sucks.  Any ideas?  Thanks.

 

Shogun.




#5124767 Vertex normal calculation for triangle strips?

Posted by blueshogun96 on 18 January 2014 - 09:49 PM

Oh, and another thing, this is my attempt to calculate them here.  What I did was take each surrounding value and form triangles with them.  Then I calculate the face normals of the resulting 8 triangles, then add the normals together, then average them out.  It's buggy, but it's better than nothing, that's for sure.

void calculate_normal( int x, int y, int polygon_offset, float* n_out )
    {
        int tris = 0; /* Triangles formed */
        float center[3];
        float vertices[8][3];
        float fnormals[8][3];
        
        /*x = X;
         y = get_height( X, Y );
         z = Y;*/
        
        /* Calculate the center */
        center[0] = x;
        center[1] = get_height( x, y );
        center[2] = y;
        
        /* Right */
        vertices[0][0] = x+polygon_offset;
        vertices[0][1] = get_height(x+polygon_offset, y);
        vertices[0][2] = y;
        
        /* Right bottom */
        vertices[1][0] = x+polygon_offset;
        vertices[1][1] = get_height(x+polygon_offset, y-polygon_offset);
        vertices[1][2] = y-polygon_offset;
        
        /* Bottom */
        vertices[2][0] = x;
        vertices[2][1] = get_height(x, y-polygon_offset);
        vertices[2][2] = y-polygon_offset;
        
        /* Left bottom */
        vertices[3][0] = x-polygon_offset;
        vertices[3][1] = get_height(x-polygon_offset, y-polygon_offset);
        vertices[3][2] = y-polygon_offset;
        
        /* Left */
        vertices[4][0] = x-polygon_offset;
        vertices[4][1] = get_height(x-polygon_offset, y);
        vertices[4][2] = y;
        
        /* Left top */
        vertices[5][0] = x-polygon_offset;
        vertices[5][1] = get_height(x-polygon_offset, y+polygon_offset);
        vertices[5][2] = y+polygon_offset;
        
        /* Top */
        vertices[6][0] = x;
        vertices[6][1] = get_height(x, y+polygon_offset);
        vertices[6][2] = y+polygon_offset;
        
        /* Right top */
        vertices[7][0] = x+polygon_offset;
        vertices[7][1] = get_height(x+polygon_offset, y+polygon_offset);
        vertices[0][2] = y+polygon_offset;
        
        /* Generate face normals */
        for( int i = 0; i < 7; i++ )
        {
            float temp[3];
            int i2 = (i+1) < 7 ? i : 0;
            
            cross( center, vertices[i], vertices[i2], temp );
            normalize( temp, fnormals[i] );
            memcpy( n_out, fnormals[i], sizeof( float ) * 3 );
        }
        
        /* Average out normals */
        n_out[0] /= 8.0f;
        n_out[1] /= 8.0f;
        n_out[2] /= 8.0f;
    }

The results:

 

Screen Shot 2014-01-18 at 7.48.48 PM.png

 

Any ideas?  Thanks.

 

Shogun.




#5124755 Vertex normal calculation for triangle strips?

Posted by blueshogun96 on 18 January 2014 - 08:09 PM

I understand that calculating a normal is a rather simple concept, but for some reason, I can't wrap my head around generating normals for a triangle strip.  What I have is a heightmap and I need normals for lighting.  The whole thing is rendered using triangle strips.

 

Just in case you need a visual, take a look at this code I used to generate vertices and texture coordinates.

void heightmap_t::build_vertices()
{
    float X, Y;
    float x, y, z;
    bool switch_sides = No;
    
    /* Sanity check */
    if( !m_height_data )
        return;
    
    /* 
     * First Pass: determine total number of vertices needed
     */
    m_vertex_count = 0;
    
    for ( X = 0; X <= m_width; X += m_polygon_scale )
    {
        /* Are we switching sides? */
        if( switch_sides )
        {
            for( Y = m_height; Y >= 0; Y -= m_polygon_scale )
            {
                m_vertex_count += 2;
            }
        }
        else
        {
            for( Y = 0; Y <= m_height; Y += m_polygon_scale )
            {
                m_vertex_count += 2;
            }
        }
        
        /* Switch the direction the columb renders to allow fluid tri-strips */
        switch_sides = !switch_sides;
    }
    
    /*
     * Second Pass: Allocate and generate vertices
     */
    
    switch_sides = No;
    m_vertices = new float[m_vertex_count*3];
    m_texcoords = new float[m_vertex_count*2];
    int v = 0;
    
    for ( X = 0; X <= m_width; X += m_polygon_scale )
    {
        /* Are we switching sides? */
        if( switch_sides )
        {
            /* Columns */
            for( Y = m_height; Y >= 0; Y -= m_polygon_scale )
            {
                /* Bottom left vertex */
                x = X;
                y = get_height( X, Y );
                z = Y;
                
                /* Set texture and vertex coordinates */
                m_texcoords[(v*2)+0] = ( x / float( m_width ) ) * 50.0f;
                m_texcoords[(v*2)+1] = -( z / float( m_height ) ) * 50.0f;
                m_vertices[(v*3)+0] = x;
                m_vertices[(v*3)+1] = y;
                m_vertices[(v*3)+2] = z;
                v++;
                
                /* Bottom right vertex */
                x = X + m_polygon_scale;
                y = get_height( X + m_polygon_scale, Y );
                z = Y;
                
                /* Set texture and vertex coordinates */
                m_texcoords[(v*2)+0] = ( x / float( m_width ) ) * 50.0f;
                m_texcoords[(v*2)+1] = -( z / float( m_height ) ) * 50.0f;
                m_vertices[(v*3)+0] = x;
                m_vertices[(v*3)+1] = y;
                m_vertices[(v*3)+2] = z;
                v++;
            }
        }
        else
        {
            for( Y = 0; Y <= m_height; Y += m_polygon_scale )
            {
                /* Bottom right vertex */
                x = X + m_polygon_scale;
                y = get_height( X + m_polygon_scale, Y );
                z = Y;
                
                /* Set texture and vertex coordinates */
                m_texcoords[(v*2)+0] = ( x / float( m_width ) ) * 50.0f;
                m_texcoords[(v*2)+1] = -( z / float( m_height ) ) * 50.0f;
                m_vertices[(v*3)+0] = x;
                m_vertices[(v*3)+1] = y;
                m_vertices[(v*3)+2] = z;
                v++;
                
                /* Bottom left vertex */
                x = X;
                y = get_height( X, Y );
                z = Y;
                
                /* Set texture and vertex coordinates */
                m_texcoords[(v*2)+0] = ( x / float( m_width ) ) * 50.0f;
                m_texcoords[(v*2)+1] = -( z / float( m_height ) ) * 50.0f;
                m_vertices[(v*3)+0] = x;
                m_vertices[(v*3)+1] = y;
                m_vertices[(v*3)+2] = z;
                v++;
            }
        }
        
        /* Switch the direction the columb renders to allow fluid tri-strips */
        switch_sides = !switch_sides;
    }
    
    /* Use the vertex data to generate a VBO */
    glGenBuffers( 3, m_vbo );
    glBindBuffer( GL_ARRAY_BUFFER, m_vbo[0] );
    glBufferData( GL_ARRAY_BUFFER, m_vertex_count*3*sizeof(float), m_vertices, GL_STATIC_DRAW );
    glBindBuffer( GL_ARRAY_BUFFER, m_vbo[1] );
    glBufferData( GL_ARRAY_BUFFER, m_vertex_count*2*sizeof(float), m_texcoords, GL_STATIC_DRAW );
}

This is based off of an old tutorial from gametutorials.com.  A bit of a shame that they didn't calculate normals in the heightmap tutorial...

 

My initial idea was to take each triangle individually, and calculate face normals first.  Then I get confused after the 2nd part.  Do I like go each vertex and  match up vertices with matching coordinates, add the normals and re-normalize?  That's the part I'm having trouble wrapping my head around.  My brain is a bit fried at the moment, and I'm in a 24-hour coding competition right now.  Any ideas?  Thanks.

 

Shogun.






PARTNERS