I'll use this reply to reply to all the replies.

"ElfQT" <dethjunk@yahoo.com> wrote in message news:ddv0k9$2bni$1@digitaldaemon.com...
> Well I'm also interested in D and DirexctX, as you probably know.
> About nonagon I'm curious, but a closed source engine in the making
> without
> proper documentation is less interesting for me than to learn the the full
> 3d and DX stuff myself.
> What I accomplished by now, I've ported the first five C++ D3D tutorials
> to
> D... I guess I'm behind you a few years ;)
> Also, I don't wan't to use D3DX, so I had to write a texture loader.
> Right now I'm stuck with loading X. files. Seems a hard one for me.

Without proper documentation?  Well, I guess that invalidates the days I spent writing what I thought were thorough docs for every single function and member of every class in nonagon!  ;)  What do you think is missing from the docs?

Good luck on that X loader.  Oh man, you'll have a hell of a time, since you're not using D3DX; you won't even be able to use the ID3DXFile interface!


"Mike Parker" <aldacron71@yahoo.com> wrote in message news:ddv1la$2clj$1@digitaldaemon.com...
> I would be extremely interested if it were API agnostic. Such a strong dependency on D3D is not something I'm a big fan of. Not knocking D3D, as it's usually a better choice on Windows than OpenGL, but such a dependency pretty much negates the possibility of cross-platform functionality. And even if that weren't an issue for me, the dependency on a specific version of D3D and D3DX is icky. In the context of games, the D3D9 market is a small segment of the overall market. For AAA developers releasing boxed titles, that's no big deal. But for indies distributing online, it's huge. While some have moved to D3D8, others are still using D3D7.
>
> It's a great effort you've got going, and I wish you success with it. But you are really limiting your user base by locking in to D3D9.

The difference between D3D7 and D3D8 is literally like night and day.  If I were to make a version of nonagon that was DX7-based, so much would change internally that it would be almost a completely different engine.  I'm planning on rolling back the fixed-function pipeline to D3D8, meaning that the fixed-function nonagon lib would be entirely DX8-compatible (as long as I found the d3dx8 lib and dll).  But that's going to be a huge undertaking in and of itself, and not something that I'm really worried about right now.


"Mike Parker" <aldacron71@yahoo.com> wrote in message news:ddvcq9$2o40$1@digitaldaemon.com...
> There's always going to be a price to pay for abstraction, from performance penalties to memory costs. But look at some of the professional engines used in games out there - every version of the Unreal Engine, Gamebryo (formerly NetImmerse) and Renderware, for example, have been used in mutliple titles and are all API agnostic. The penalty for abstraction exists, but is negligible. I recommend you read the book 3D Game Engine Architecture by Davd Eberly. It explains the design philosopy behind his WildMagic engine, which is based on his work with NetImmerse (he was one of the original architects of that engine). The benefits of API independence far outweigh the detriments and is a driving reason behind third party engine market.
>
> Anyway, I'm not criticizing Nonagon at all. I think it's a great effort. But it's not for me because the dependence on Direct3D 9 puts it squarely in a high end (hardcore) gamer market segment and restricts the ability to port it to other platforms D might make it to. Maybe that's what Jarret's goal is, and if so, more power to him ;)

I'd like to make nonagon API-independent, but at the moment, I'm still learning DirectX for the most part.  When I'm done (?!) with nonagon, I'd most likely make a new, more advanced engine using the experience that I will have gained from making nonagon, but for now, I'm keeping it simple.

Another problem that will arise next year is Windows Vista.  Vista will come out with DirectX 10, which is basically an entirely new API, rewritten from the ground up, and with it will come new hardware that supports the new, simpler, but more strict spec.  The fixed-function pipeline will go away, and with it, so will native hardware support for OpenGL in Vista.  It will just be too hard to support OpenGL in its current form on the new hardware. So making an API-agnostic engine now might be kind of a dumb idea in a year, when Direct3D and OpenGL will be so wildly different that it would be far too prohibitive to try to make it work on both APIs.  Personally, I think it'd be a good idea to wait a few years, and see if OpenGL 2 will finally come out ;)  And it will have to, if it wants to survive.

> Without proper documentation?  Well, I guess that invalidates the days I spent writing what I thought were thorough docs for every single function and member of every class in nonagon!  ;)  What do you think is missing
from
> the docs?

Sorry I simply missed the .chm.
ElfQT

"ElfQT" <dethjunk@yahoo.com> wrote in message news:ddvgtc$2sg9$1@digitaldaemon.com...
>> Without proper documentation?  Well, I guess that invalidates the days I spent writing what I thought were thorough docs for every single function and member of every class in nonagon!  ;)  What do you think is missing
> from
>> the docs?
>
> Sorry I simply missed the .chm.
> ElfQT

That's OK.  :)

Jarrett Billingsley wrote:

> The difference between D3D7 and D3D8 is literally like night and day.  If I were to make a version of nonagon that was DX7-based, so much would change internally that it would be almost a completely different engine.  I'm 

Abstract interfaces! There are plenty of OpenSource engines out there that abstract different versions of DX, OGRE, Irrlicht, and I believe Crsytal Space, off the top of my head.

 > I'd like to make nonagon API-independent, but at the moment, I'm still
> learning DirectX for the most part.  When I'm done (?!) with nonagon, I'd most likely make a new, more advanced engine using the experience that I will have gained from making nonagon, but for now, I'm keeping it simple.

I can surely understand that. It takes a bit of time and experience to fully understand these APIs.

> 
> Another problem that will arise next year is Windows Vista.  Vista will come out with DirectX 10, which is basically an entirely new API, rewritten from the ground up, and with it will come new hardware that supports the new, simpler, but more strict spec.  The fixed-function pipeline will go away,

Right, but DX is always backwards compatible. You will still be able to run older DX apps, and develop for them. It's going to take some time for the market to transition to Vista and DX10 after they are released, so targeting them at release has little benefit for anyone.


> and with it, so will native hardware support for OpenGL in Vista.  It will just be too hard to support OpenGL in its current form on the new hardware. So making an API-agnostic engine now might be kind of a dumb idea in a year, when Direct3D and OpenGL will be so wildly different that it would be far too prohibitive to try to make it work on both APIs.  Personally, I think it'd be a good idea to wait a few years, and see if OpenGL 2 will finally come out ;)  And it will have to, if it wants to survive. 

I see you've fallen victim to the FUD surrounding Vista and OpenGL! OGL isn't going away. What's happening is that, currently in the beta, when you run a Windowed OpenGL app using the hardware OpenGL drivers, the new Aeroglass window compositing feature turns off - which means the user's desktop loses the nifty D3D accelerated special effects Vista offers and looks like XP. Fullscreen OpenGL apps won't have to worry about this. That's why MS is offering OGL 1.4 implemented on top of D3D for Windowed mode OpenGL apps. So native hardware support isn't going away (if it did, there would be a great many high end graphics software developers who would be up in arms with MS over it - many of whom MS wooed over from other platforms over the years). You'll just have angry users if you run hardware accelerated OGL drivers in Windowed mode! Hopefully NVidia, ATI, and 3DLabs will get things sorted for us before the final release.

"Mike Parker" <aldacron71@yahoo.com> wrote in message news:ddvodg$1f9$1@digitaldaemon.com...
> Right, but DX is always backwards compatible. You will still be able to run older DX apps, and develop for them. It's going to take some time for the market to transition to Vista and DX10 after they are released, so targeting them at release has little benefit for anyone.

I'm not sure how well the new programmable hardware will emulate the fixed-function pipeline, though.  Hopefully the shader capabilities will be good enough to support the entire FF pipeline in shaders.

> I see you've fallen victim to the FUD surrounding Vista and OpenGL! OGL isn't going away. What's happening is that, currently in the beta, when you run a Windowed OpenGL app using the hardware OpenGL drivers, the new Aeroglass window compositing feature turns off - which means the user's desktop loses the nifty D3D accelerated special effects Vista offers and looks like XP. Fullscreen OpenGL apps won't have to worry about this. That's why MS is offering OGL 1.4 implemented on top of D3D for Windowed mode OpenGL apps.

I heard that when that happens, the performance of OpenGL will be reduced significantly.  I also heard that there will be no support for extensions. Announcement from the admin at OpenGL.org: http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=12;t=000001

Will these issues only exist for windowed apps or what?

Jarrett Billingsley wrote:

> "Mike Parker" <aldacron71@yahoo.com> wrote in message news:ddvodg$1f9$1@digitaldaemon.com...
>> Right, but DX is always backwards compatible. You will still be able to run older DX apps, and develop for them. It's going to take some time for the market to transition to Vista and DX10 after they are released, so targeting them at release has little benefit for anyone.
> 
> I'm not sure how well the new programmable hardware will emulate the fixed-function pipeline, though.  Hopefully the shader capabilities will be good enough to support the entire FF pipeline in shaders.

I did this in my master thesis (only the geometrical part of it, chapter 7 in the OGL spec, if I remember correctly). Worked like a charm. Actually it was sortof an emulator, as it based on the GL state, generated vertex programs. It was a proof of concept, but internally on all newer GPUs, this is the way it is done. There are no more FF pipelines in these, just programmable ones. And since these functions are the most important ones, the GPUs are optimized for them.

Lars Ivar Igesund

"Lars Ivar Igesund" <larsivar@igesund.net> wrote in message news:de00mg$88f$1@digitaldaemon.com...
> I did this in my master thesis (only the geometrical part of it, chapter 7
> in the OGL spec, if I remember correctly). Worked like a charm. Actually
> it
> was sortof an emulator, as it based on the GL state, generated vertex
> programs. It was a proof of concept, but internally on all newer GPUs,
> this
> is the way it is done. There are no more FF pipelines in these, just
> programmable ones. And since these functions are the most important ones,
> the GPUs are optimized for them.

Really?  That's amazing!  I guess there wouldn't be much trouble with emulating the FF pipeline then with the next-gen cards.

Jarrett Billingsley wrote:
> 
> I heard that when that happens, the performance of OpenGL will be reduced significantly.  I also heard that there will be no support for extensions. Announcement from the admin at OpenGL.org: http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=12;t=000001
> 
> Will these issues only exist for windowed apps or what? 

It's hard to separate fact from fiction in the threads I've read regarding it, but it seems pretty certain to only affect windowed apps that use the 1.4 D3D implementation. You still have the option to use hardware drivers. The issue is that it turns off Aeroglass features when you do so. opengl.org is where I first heard about it, and I can't remember if it was that thread or one at another site (maybe gamedev.net or indiegamer.com) but someone from there were posts from 3DLabs and ATI employees saying they are working to get this resolved. Obviously it's a bad thing if an app ruins the user's desktop experience, and I can see how most users will likely claim the application 'broke windows'. No one needs that sort of word-of-mouth.

I've also read that MS is planning to include some extensions in the D3D implementation. I don't know which ones, or how many, or even if that info came from a reliable source. In the end, I think all of this will prove to be a non-issue. There's quite a lot of money invested in OpenGL software on the Windows platform (think CAD, high end modelling, scientific data display, etc...) and I just don't see the developers (or even the users) of such software sitting still on an issue like this. Nor do I see MS alienating them.