flipCode - Tech File - Conor Stokes [an error occurred while processing this directive]
Conor Stokes
(aka DirtyPunk)
Click the name for some bio info

E-Mail: cstokes@crytek.com
http://www.claustrophobe.8m.com



   08/23/1999, Trials and Tribulations of Being Cerebrally Defunct


My copy of Visual C++ 6 pro this finally arrived last week, and much jubilation was had by me, and those who were glad I was finally using that instead of the non-standard Borland C++ Builder 3.0. As much as I complain about BCB3, it served me well and was incredibly easy to use.

I installed VisualC++ 6.0 on Thursday, and after finishing brushing up for my Physics assesment, I decided to port my OpenGL based 3d Transform driver / Renderer over. It was about 8pm. I got the DLL workspace together, and shock horror, I recieved 300 odd errors. After a few twiddles with the project settings (which I should have done first) I got rid of those, and moved on to linker errors, of which there were about 1000, from the way I dynamically loaded OGL. Sigh.

Friday night late I got on to the OGL linker errors. I first switched to using an import library, just to see if those were the only linker errors. I eventually got that dynamic linking again by slightly changing the file configuration, and introducing the old method I used in LCC, which was using a header file with all the OGL calls externed. It worked straight away.

Then Saturday night late, I got on to porting the 2d driver. I put together the project file, and even with the old method of loading OGL, I found it worked. It worked with the old method of loading OGL, because the 2d driver does not yet include the font or bitmap code, which means it is basically one file which sets up the window or the screen state. That was good.

Then very late Saturday night, I got on to the sample application, which basically initialised the 2d driver, got it to pull up a window (you can set colour bits, z-bits, resolution and fullscreen/windowed) that was OGL friendly and ready to go, initialised the 3d driver, including the geometry memory manager, OGL, GLU etc. Then it de-initialised both.

I got it compiling first time round, no errors, no warnings. Amazing how you learn :) But, then I found that the 2d and 3d driver dlls wouldn't load. I spent Sunday night fixing that. I tried everything I could. It turned out that VC was mangling the exported names (used Borland's IMPDEF style utility). To remedy that problem, I put together a DEF file again using Borlands IMPDEF utility, but this time on the old Borland compiled DLL, with non-mangled names. That seemingly de-mangled the file names. Still, I got errors. Then I realised that I was compiling all the DLLs with __cdecl function calls. Switching to __stdcall it all worked perfectly.

In case your wondering, I normally do all my coding late at night on the weekend. I'm doing some today on Monday in the morning, because I don't have school today (Educator's education day, when all the boffins get together, and further the scholastic technocracy which is the Education system).

Today, I worked out the bugs in the 3d driver. There seems to be none I can find (knock on wood) in the 2d driver. The first problem was an annoying mistake. When I switched to static OpenGL linking, to get the thing to compile first time, I commented out the GLU and OGL dll loading routines from the renderer init procedure. Sigh, and I wondered where all problems were coming from. I sorted it out, and everything seems to be back to where it was under Borland, but with hopefully a lack of bugs, because while getting the 3d driver to work I noticed some errors I had made. I have gone through every line now, and it seems everything is going like it should. So no I have to finish the level compiler, finish the lighting and lightmap handling routines, finish the multi-texture version of the renderer, and hopefully I'll be able to put together a nice demo.

I hope this helps anyone wondering about their DLL errors... Oh, and by the way, the Borland binarys and VC binarys are interchangable now, which is always a good sign.

Oh, and I drafted three docs on some worldspace visibility algorithms I worked out. A few people have the drafts, and the comments seem to be good. I'll try and finalise them and present them properly this week, and get them to Kurt or upload them to my homepage.

Conor "DirtyPunk" Stokes





  • 12/29/2000 - Techfile From Somewhere Different
  • 10/10/2000 - Some Fun, And A Cameo Appearance
  • 08/10/2000 - Déjà vu - And I've Done It Before
  • 07/08/2000 - Various Loose Ends To Hang
  • 05/15/2000 - The Way To Hit A Ball With A Bat. Or Not
  • 03/28/2000 - The Fine Art Of
  • 02/13/2000 - A Life Time of Learning, Teaching and Eating M&Ms
  • 12/09/1999 - Strangeness And Wondering If You Are Taking Innovation A Tad Too Far
  • 11/12/1999 - How to Break Exam Tension? Update Your Techfile
  • 09/14/1999 - Lots of Ramblings, personal things and comments on why SNFU
  • 08/23/1999 - Trials and Tribulations of Being Cerebrally Defunct
  • 07/29/1999 - Quick Update about Stuff and Things
  • 07/25/1999 - I'm Back Baby
  • 07/01/1999 - Is it so? Or am I just a Psycho Babbling Mental Hobo, who's Brain has No Home?
  • 06/25/1999 - Another Couple of Things
  • 06/17/1999 - I Am A Naughty Little Boy ;( But I Have A Way To Make Up
  • 06/16/1999 - What the hell? A new data structure for visibility? I don't know, I haven't heard of it.
  • 06/05/1999 - A Little Right Brained
  • 05/12/1999 - A Couple O Things
  • 05/08/1999 - Pre Computable Nice Visibility Sets
  • 05/04/1999 - More on Volumetrics
  • 04/30/1999 - Generic Update
  • 04/27/1999 - Spherical Volumetric Rendering (Mapping)
  • 04/25/1999 - Fractal Curves, Emulation Of Nature
  • 04/25/1999 - Claustrophobic Irony Level Loading and Manufacture
  • 04/24/1999 - Visibility Ramblings
  • 04/21/1999 - Why Software Rendering Is Not Dead
  • 04/17/1999 - Optimizing For Specific 3D Hardware

  • This document may not be reproduced in any way without explicit permission from the author and flipCode. All Rights Reserved. Best viewed at a high resolution. The views expressed in this document are the views of the author and NOT neccesarily of anyone else associated with flipCode.

    [an error occurred while processing this directive]