Advertisement Jump to content


This topic is now archived and is closed to further replies.

Fred S

NeHe's basecode with OOP

This topic is 6149 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi there! I was wondering if anyone has ported NeHe''s basecode to full OOP C++? I''m writing an ApplicationManager class right now, but it would be interesting to someone else''s implementation too, might give me some ideas. Anyone? Cheers Fred S

Share this post

Link to post
Share on other sites
um, I suppose you''re talking about NeHeGL1 and 2 Basecodes. As far as I could see they''re not OOP, only modularization of regular C code.
I did however check out the code for Ngine (also on NeHe''s site), and that is fully OOP but HEAVILY optimized, and thus kinda hard to read.

Share this post

Link to post
Share on other sites
Part of that hard-to-readness comes from the coding style. We plan to convert it to a more traditional hungarian-style notation coding standard to make it more readable.

[edited by - terminate on March 22, 2002 5:29:32 PM]

Share this post

Link to post
Share on other sites

I took a look at Ngine, and didn''t like what I saw. First, the D3D renderer and the implementation of a renderer in general seems like a joke to me. D3D is not the same as GL, and using a GL interface to use it is inefficient and ugly. Many classes deal with data not really related to them. Certainly not something I would consider exemplary OOP code. The basecode is plain structured code.

This is not to say that the code or GL is bad. I''m beginning to like GL more and more over D3D, and I''ve adapted my framework to work with GL. I''m currently working on a GL tunnel demo, and I''ve ported D3DFont with some enhancements to GL.

I didn''t exactly port NeHe''s code to OOP, but here''s what I have. A driver .exe is an MFC app that takes care of window, graphics and input init and does the dirty work like checking for input. Presently, D3D, GL, and DInput are supported. I threw out window init stuff because MFC already does this. Based on the options requested, different init is performed. I separate D3D and GL functions into their own files, but I don''t have a "common" interface to both.

The plugin, which is implemented as a COM dll, does the fun stuff. It mostly just renders and handles input. Plugin specifies which renderer it wants, but it directly accesses whichever functionality it wants.

At startup, driver looks into registry and enumerates all registered plugins. Then, it pops a dialog asking the user to choose a plugin. Then, the plugin is asked for the features it wants to use (D3D/GL/DI). The selected features are initialized, and driver enters the game loop. From there, plugin''s Update and Render methods are called. Plugin can obtain useful information from the driver, such as current time.

The result is that plugin dlls are very small and share almost no code. There''s also a "core" dll implementing things like cameras, all kinds of timers, fps counters, image loading, font drawing, and so on.

I can send you the code if you''re interested, but it''s somewhat large and sometimes not commented. It may be worth something from the academic point of view, but because it''s a work in progress, it has broken parts. For example, D3D plugins aren''t working now at all after I made global cleanups/restructuring for GL support. Also, I use MFC/ATL whenever possible.

I''m also interested to hear about other people''s OOP implementations.

Share this post

Link to post
Share on other sites

  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!