Try adding:


#pragma comment (lib, "glu32.lib")
#pragma comment (lib, "opengl32.lib")
#pragma comment (lib, "glaux32.lib")
#pragma comment (lib, "roguelib.lib")
#include < gl/glaux.h >
#include < gl/gl.h >
#include < gl/glu.h >


to the top of your header file so the user also doesn't have to include lib's and h's too much.
Also, what is the model3ds* data type in the 3ds loading functions? How can I implement these functions.



Open mouth, insert foot

Edited by - oglman on November 27, 2000 10:17:56 PM

thanks for the tip, oglman. I somehow had it in my head that this way it wouldn''t include things they don''t want to include, but heh they have to include them anyway!

I thought that would be self-explanatory, so I didn''t explain it well enough, sorry. You must first create a model3ds handle. Then call Load3ds passing the model path and the handle address. To render, just call Render3ds() passing the model handle. Animated 3ds files are incomplete, though...

I am sorry the documentation is so skimpy, I promise to get it togethor soon

L8r,
The Rainmaker

that demogl is nice, though more focused on making screensavers effects i believe.

personally for the rogue lib i''ld ditch all that drawing stuff eg drawLine( ptA -> ptB ) its easy enuf in gl to do it plus more flexible and concentrate on doing some other things
eg a few suggestions
* camera
* skybox
* HUD
* billboards
* octree making (and scene culling of course)
* particle system
* loading of textures
* loading of models (some guy has just posted info on loading the md2 format on flipcode)
hmm the more u add the more it starts to sound like a scenegraph


http://members.xoom.com/myBollux

In layman''s terms, what is the advantage of using Roguelib over using simple GLUT and OpenGL? Will the finished product look something like VRML? with Sky, Billboard, Animation ...etc nodes? Or is it something more or something less?

Is it something to help out the newbe or on the contrary, should it be avoided until one has a firmer grasp of OpenGL?

Thanks for the suggestions, zedzeek. I will be sure to add that in! Of course, there is a simple bmp texture loader and a 3ds loader, but I will expand apon that in due time.

keermalac those are some excellent questions (just what I wanted to hear). My intentions are actually to support people of any skill level(thus the wimpy line funcs). I actually plan to continue as I am now, with useful functions that make game creation easier. I hope to make it so easy, you could be a newbie and still program a small game. Watch for alpha 5. As soon as I finish the world creator, it will be released.

L8r,
The Rainmaker

The question keermalec asks is the key to what you should implement...

It boiles down to: "what is overhead and should be done by a lib using one or 2 calls, and what should be done by the programmer himself". So in fact: your lib should provide functionality to create the platform the gameprogrammer can build his game on, without the hassle to setup windows, regulate texturemanagement, handle windowmessages, handle resolution / bitdepth crap, put up a console for debuginfo (thus make realtime debugging easier), handle gamedevice input etc...

When you do all that, the answer to keermalec''s question is clear: your lib provides the functionality that will allow the programmer to create the best platform for gamedevelopent: the programmer can start programming the GAME and focus on the GAME, instead of hassling all other kind of stuff.

Glut just creates a window with less functions.

To use demogl as a metaphore: demogl lets the programmer focus on the effects he wants to show, everything else is handled. Still the programmer has to program the effect totally by himself using opengl.

Now... your lib should provide the same kind of platform for a gamedeveloper: the developer still has to write the game in opengl but can use your lib''s functionality to just get stuff done: like "create an overlay" with 1 functioncall and let the developer render stuff on that overlay in a breeze. (so gameinfo can be drawn easily without the hassle to keep the gamegraphics separated from the gameinfo graphics.)

To give you a tip: in demogl I use effectclasses that can be put on layers. So to project that on a game: you could have 1 effectclass render the gamegfx on layer 1 and another one on layer 2, which lays on top of layer 1, that renders the gameinfo.

because the effects in my lib are fairly separated and the programmer has to set up communication between the effects himself it''s not that usable for games. You could f.e. implement AND the layer stuff AND do it in a way that the source of all data is coming from 1 central store (i.e. the gamedata) and still you have complete separated rendercode that can be placed on diffrent layers easily.

That way, a gamecoder can get productive way faster using your lib than f.e. using glut or write his own rendermanager lib thingy.

nice sideeffect is that you have instantly a selling point for your library to gameprogrammers

--

Get productive, Get DemoGL: http://www.demogl.com