Rethinking Hungarian Notation, and Joel on Software
erawtfoS no leoJ dna ,noitatoN nairagnuH gniknihteR
rss

Hungarian notation has always sat wrong with me. So has some of Joel on Software’s views in the past. I’m currently revisiting both opinions.

Firstly, Hungarian notation. For those of you not in the know, Hungarian notation is a coding convention that’s been around for a long time. It gets a lot of flak - and in my opinion, usually quite rightly.

You see, the idea in the Windows headers, was to encode the variable type into the variable itself, to great detail. For example, in windows, you’ll often see something like this:

 

  1. // Function passing in a variable that’s a long pointer to a zero-terminated string
  2. MyFunction(lpszBar);

This, in my opinion, is wrong. C++ is already a strongly typed language, so you’ll get a compiler error if you pass in an item of the wrong type, so of what benefit is it to store the variable type in the name?

I always assumed that this was the “only” type of Hungarian notation, and I spurned the idea on the whole because of it.

Reading a post on Joel on Software’s website with great skepticism, I actually ended up changing my mind.

Joel brought to my attention that there’s actually two ‘types’ of Hungarian notation. One of which is called “System Hungarian”, and “Application Hungarian”. The difference is that the former encodes the data type into the variable, whereas the latter encodes the domain-level usage into the variable.

I won’t describe the difference between the two, as I think both Joel’s article and WikiPedia’s do a fantastic job bringing both to light (Joel’s is a good read for the skeptic who wants a narrative to follow, WikiPedia’s is a good reference for those pressed for time). I will however talk about what brainstorm this set off in my head.

I now think that Application Hungarian is a good thing, but the difference I outlined above is huge:

Systems Hungarian is easier to define, because it’s domain agnostic. Application Hungarian is domain-specific.

Take for example Joel’s example of needing to Encode() strings before sending them to a webpage. That’s a domain-specific example. Building a game in C++ doesn’t have the same requirement, so using his ’s’ and ‘us’ prefix doesn’t make sense.

It might even change from application-to-application, depending on what happens. This means you can’t have a blanket statement like “Always prefix [insert-domain-specific-kind-of-type-here] with [prefix]” between projects, unless they have a similar domain, and set of constraints.

I’m trying to think of places where this matters in code. I already do a modified form of “Hungarian” (prefixes such as: ‘m_’ for member variables, ‘b’ for boolean values, ‘p’ for pointers and ‘k’ for constants), but this is project-agnostic (perhaps I’ll call it Eddie Systems Hungarian :) ). I have yet to see a need for integrating domain-specific/application-specific Hungarian in the games I program, but at least this gives me pause to think about usages for it. If anybody thinks of any, please let me know.

Popularity: 35% [?]


OpenGL vertex buffer objects tutorial
lairotut stcejbo reffub xetrev LGnepO
rss

I’ve been dabbling in graphics programming a bit, mostly OpenGL glBegin/glEnd schtuff lately. A friend pointed me to vertex buffer objects (VBO’s) as a better alternative, so I decided to learn a bit about them. That said, I couldn’t find a tutorial that suited my needs, so I thought I’d offer one here.

First off, there are tutorials out there, just not what I need/want. Let me list them.

  • NeHe, purveyor of all things graphical has a great tutorial (#45), that I even used as a reference for mine.

The problem for me was that it came with way more than what I wanted to learn at this point (heightmaps and the like), and I just wanted a focused example on VBO’s without having to worry about setting everything up “just right”.

  • DevMaster, my surrogate home, had a decent tutorial that was brief (here), but had various errors and didn’t compile out of the box. It also didn’t work, at least not for me!

So here I decided to cobble together a working demo (once I figured out how), and post it up for all the world to see.

Now keep in mind a few things about this:

1.- I might have my terminology messed up. I keep hearing people refer to this as DrawArrays, Vertex Buffer Objects, Vertex Array something-or-other, etc. If someone can clear this up for me, I’d be happy to hear from you.

2.- I don’t do a lot of error checking in this demo. It’s definitely bad practice, but I wanted to keep things brief. There’s a couple of comments in there noting where I should be, and there might be a few places that I should mention these things.

Anyhow, without further ado, here’s the demo. I hope it helps someone.

Download: KickingDragon_VBODemo.cpp
  1. /**
  2.   * Vertex Buffer Objects (herein after referred to as VBOs) demo.
  3.   *
  4.   * Author: Eddie Parker
  5.   * www.kickingdragon.com
  6.   *
  7.   * This demo is a really simple example of how to use VBOs [1].
  8.   *
  9.   * Why would you use VBOs? Because the data is uploaded an manipulated
  10.   * on the graphics card RAM instead of system RAM, therefore it's faster,
  11.   * and doesn't clog up your BUS, and keeps your whites whiter.
  12.   *
  13.   * [1] http://steinsoft.net/index.php?site=Programming/Code%20Snippets/OpenGL/no11
  14.   *
  15.   */
  16.  
  17. #define WIN32_LEAN_AND_MEAN
  18. #include <windows.h>
  19.  
  20. #include <SDL/SDL.h>
  21. #include <SDL/SDL_main.h>
  22. #include <GL/gl.h>
  23. #include <GL/glu.h>
  24.  
  25. /**
  26.   * glext.h snippet
  27.   *
  28.   * glext.h isn't always found in people's distributions.
  29.   * I've copied the parts we need here -- if you have it available,
  30.   * it would be better to include it directly.
  31.   *
  32.   * Basically, we have a couple of defines that are used later on for
  33.   * glBindBufferARB and glBufferDataARB calls, as well as typedefs
  34.   * that specify the function signatures for the functions we plan on using.
  35.   *
  36.   * Why do we need the typedefs?
  37.   *
  38.   * Quite simply, because the OpenGL Architecture Review Board (ARB) has
  39.   * created these functions as 'extensions' - that is, they're not part
  40.   * of the 'official' library, and therefore might or might not be
  41.   * available. At runtime, it's necessary to crack open the OpenGL
  42.   * DLL and retrieve the function pointers, assign them, and
  43.   * then we're able to use them in our application.
  44.   *
  45.   * For more information, see [1].
  46.   *
  47.   * [1] http://www.opengl.org/resources/faq/technical/extensions.htm
  48.   */
  49. #define GL_ARRAY_BUFFER_ARB 0x8892
  50. #define GL_STATIC_DRAW_ARB 0x88E4
  51. typedef void (APIENTRY * PFNGLBINDBUFFERARBPROC) (GLenum target, GLuint buffer);
  52. typedef void (APIENTRY * PFNGLDELETEBUFFERSARBPROC) (GLsizei n, const GLuint *buffers);
  53. typedef void (APIENTRY * PFNGLGENBUFFERSARBPROC) (GLsizei n, GLuint *buffers);
  54. typedef void (APIENTRY * PFNGLBUFFERDATAARBPROC) (GLenum target, int size, const GLvoid *data, GLenum usage);
  55. /**
  56.   *
  57.   * END glext.h snippet
  58.   *
  59.   */
  60.  
  61. /**
  62.   * Allocate four function pointers on the data segment so we can assign to them later,
  63.   * if we have them available.
  64.   */
  65. PFNGLGENBUFFERSARBPROC glGenBuffersARB = NULL;
  66. PFNGLBINDBUFFERARBPROC glBindBufferARB = NULL;
  67. PFNGLBUFFERDATAARBPROC glBufferDataARB = NULL;
  68. PFNGLDELETEBUFFERSARBPROC glDeleteBuffersARB = NULL;
  69.  
  70. /**
  71.   * Initialization function to set up our requisite libraries.
  72.   */
  73. int Initialize()
  74. {
  75.     SDL_Init(SDL_INIT_VIDEO);
  76.     SDL_SetVideoMode(640, 480, 32, 2);
  77.    
  78.     //! @TODO: I should check for the availability of DrawArrays and
  79.     // check for failure to load these functions.
  80.     glBindBufferARB = (PFNGLBINDBUFFERARBPROC)wglGetProcAddress("glBindBufferARB");
  81.     glGenBuffersARB = (PFNGLGENBUFFERSARBPROC)wglGetProcAddress("glGenBuffersARB");
  82.     glBufferDataARB = (PFNGLBUFFERDATAARBPROC)wglGetProcAddress("glBufferDataARB");
  83. }
  84.  
  85. int main(int argc, char **argv)
  86. {
  87.     // Setup our required libraries.
  88.     Initialize();
  89.    
  90.     // Set up OpenGL
  91.     glMatrixMode(GL_PROJECTION);
  92.     glLoadIdentity();
  93.    
  94.     // Initialize a perspective.
  95.     gluPerspective(45.f, 640.f / 480.f, 1.f, 512.f);
  96.    
  97.     // Set our clear colour to black
  98.     glClearColor(0.0f, 0.0f, 0.0f, 1.0f);
  99.    
  100.     // Set up a purdy triangle as our vertex data.
  101.     GLfloat vertexData[] =    { 0.f, 1.f, 0.f
  102.                             , -1.f, -1.f, 0.f
  103.                             , 1.f, -1.f, 0.f
  104.                             };
  105.    
  106.     // Set a lovely teal with some Gouraud shading for
  107.     // our triangle.
  108.     GLfloat colourData[] =    { 0.f, 0.f, 1.f
  109.                             , 0.f, 1.f, 1.f
  110.                             , 1.f, 1.f, 1.f
  111.                             };
  112.    
  113.     // Create some 'ids' for the buffers.
  114.     GLuint vertexBuffer = 0;
  115.     GLuint colourBuffer = 0;
  116.    
  117.     // 1.- Generated a buffer name for our vertex buffer,
  118.     glGenBuffersARB(1, &vertexBuffer);
  119.    
  120.     // 2.- Set our current 'in-use' buffer to our vertex buffer.
  121.     glBindBufferARB(GL_ARRAY_BUFFER_ARB, vertexBuffer);
  122.    
  123.     // 3.- Fill out the data buffer using our initialized values.
  124.     glBufferDataARB(GL_ARRAY_BUFFER_ARB, sizeof(vertexData), vertexData, GL_STATIC_DRAW_ARB);
  125.    
  126.     // Same as steps 1, 2 and 3 above, but using colour data.
  127.     glGenBuffersARB(1, &colourBuffer);
  128.     glBindBufferARB(GL_ARRAY_BUFFER_ARB, colourBuffer);
  129.     glBufferDataARB(GL_ARRAY_BUFFER_ARB, sizeof(colourData), colourData, GL_STATIC_DRAW_ARB);
  130.    
  131.     // Initialize the ability to use vertex arrays and colour arrays.
  132.     // I should really be making sure I have this capability and use
  133.     // glIsEnabled first.
  134.     glEnableClientState(GL_VERTEX_ARRAY);
  135.     glEnableClientState(GL_COLOR_ARRAY);
  136.    
  137.     bool bRunning = true;
  138.     SDL_Event event;
  139.    
  140.     while (bRunning)
  141.     {
  142.         if(SDL_PollEvent(&event))
  143.         {
  144.             if(event.key.keysym.sym == SDLK_ESCAPE)
  145.             {
  146.                 bRunning = false;
  147.                 continue;
  148.             }
  149.         }
  150.        
  151.         // Clear our depth buffer and color bit
  152.         glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
  153.        
  154.         // Reset our view
  155.         glMatrixMode(GL_MODELVIEW);
  156.         glLoadIdentity();
  157.        
  158.         // Move back a bit to see our triangle in it's glory.
  159.         glTranslatef(0, 0, -5);
  160.        
  161.         // --- VBO's in action.
  162.         // Set the vertexBuffer as the current buffer.
  163.         glBindBufferARB(GL_ARRAY_BUFFER_ARB, vertexBuffer);
  164.        
  165.         // Specify that it's data is vertex data.
  166.         glVertexPointer(3, GL_FLOAT, 0, 0);
  167.        
  168.         // Set the colourBuffer as the current buffer.
  169.         glBindBufferARB(GL_ARRAY_BUFFER_ARB, colourBuffer);
  170.        
  171.         // Specify that it's data is colour data.
  172.         glColorPointer (3, GL_FLOAT, 0, 0);
  173.        
  174.         // Tell OpenGL to draw what it sees. ;)
  175.         glDrawArrays(GL_TRIANGLE_STRIP, 0, 3);
  176.         // --- End VBO's in action.
  177.        
  178.         // Swap buffers!
  179.         SDL_GL_SwapBuffers();
  180.     }
  181.    
  182.     // Disable the client states.
  183.     glDisableClientState( GL_VERTEX_ARRAY );
  184.     glDisableClientState( GL_COLOR_ARRAY );
  185.    
  186.     //!TODO: Free the buffers created in glBufferDataARB
  187.    
  188.     return 0;
  189. }

Popularity: 71% [?]


Run Batch Files Without A Console Popup
pupoP elosnoC A tuohtiW seliF hctaB nuR
rss

RAWC: Run Applications Without a Console: RAWC.zip

This application will basically run a batch file of the same name whenever it starts up, but masking it’s console that would normally pop up.

That is, if you take the RAWC.exe, and run it as is, it will attempt to run RAWC.bat. Rename the .exe to whatever you like, say “foobar.exe” and it’ll try to run “foobar.bat”. It will also pass any command line parameters to it, should you like.

Please note: if you like this application, please don’t link to it directly, instead link to this page so people can be aware of any updates.

The history:

I wrote the original source code, and a mysterious benefactor by the name of DrV rewrote it in C to make the executable smaller.

Future plans for this is to rewrite it in assembly using masm, and see if I can make the executable smaller. Who knows.

Source code:

Download: rawc.c
  1. /**
  2. * Author: DrV    (http://drv.nu)
  3. * Modified by: Eddie Parker (http://www.kickingdragon.com/2006/07/04/run-batch-files-without-a-console-popup/)
  4. */
  5. #define WIN32_LEAN_AND_MEAN
  6. #include &lt;windows.h&gt;
  7.  
  8. #include &lt;stdio.h&gt;
  9.  
  10. static STARTUPINFO si = { sizeof(STARTUPINFO) };
  11. static PROCESS_INFORMATION pi;
  12.  
  13. unsigned int strlen(char * pStr)
  14. {
  15. unsigned int count = 0;
  16.  
  17. while(*pStr != 0)
  18. {
  19. ++count;
  20. ++pStr;
  21. }
  22. return count;
  23. }
  24.  
  25. void strcpy( char * pDestination, char * kpSource)
  26. {
  27. for(unsigned int i = 0; i &lt; strlen(kpSource); ++i)
  28. {
  29. pDestination[i] = kpSource[i];
  30. }
  31. }
  32.  
  33. int main(int argc, char **argv)
  34. {
  35. char applicationName[MAX_PATH + 1];
  36. char *pDot;
  37.  
  38. GetModuleFileName(NULL, applicationName, sizeof(applicationName));
  39.  
  40. pDot = applicationName;
  41.  
  42. // Fast forward to the NULL.
  43. while (*(pDot++))
  44. ;
  45.  
  46. // Move back until we find the start of the extension.
  47. while (*(--pDot) != '.')
  48. ;
  49.  
  50. // Add a '.bat' to the extension.
  51. pDot[1] = 'b';
  52. pDot[2] = 'a';
  53. pDot[3] = 't';
  54.  
  55. char commandLine[MAX_PATH + 1];
  56. char * pEndPoint = &amp;commandLine[0];
  57.  
  58. strcpy(pEndPoint, applicationName);
  59. pEndPoint += strlen(applicationName);
  60.  
  61. {
  62. int i = 0;
  63. for(i = 1; i &lt; argc; ++i)
  64. {
  65. pEndPoint[0] = ' ';
  66. ++pEndPoint;
  67.  
  68. strcpy( pEndPoint, argv[i] );
  69. pEndPoint += strlen(argv[i]);
  70. }
  71. }
  72.  
  73. pEndPoint[0] = 0;
  74.  
  75. si.dwFlags = STARTF_USESHOWWINDOW;
  76. si.wShowWindow = SW_HIDE;
  77.  
  78. printf("Running %s.", &amp;commandLine[0]);
  79. CreateProcess(applicationName, &amp;commandLine[0], NULL, NULL, FALSE, 0, NULL, NULL, &amp;si, π);
  80.  
  81. return 0;
  82. }

Popularity: 50% [?]