Your opinions on libGDN
Author
If you don''t know anything about libGDN, it''s an API independent (meaning it could convievably use any API/OS you want) game development library. Go here to learn more.
So anyway, I have about two weeks here where I can''t do too much significant work on the library because I''m not near my compilers. We just released a new version a few days ago and had a large spike in downloads. I''d like to get some opinions on how it looks so far (early still though), and where it needs to go from those who have or are going to look at it. We''re here to cater to you, so I''ll take all your suggestions to heart.
Gamedev for learning.
libGDN for putting it all together.
An opensource, cross platform, cross API game development library.
Author
Has anyone actually LOOKED at it? 
Gamedev for learning.
libGDN for putting it all together.
An opensource, cross platform, cross API game development library.
Gamedev for learning.
libGDN for putting it all together.
An opensource, cross platform, cross API game development library.
I''ve looked at it a little bit, but I can''t really figure out its purpose. Is it just a DX/OGL wrapper? What''s it do?
And I looked at some of the code and its so heavily C++ i couldn''t even understand it. Most Linux folks are going to be using C, not so much C++, so I doubt this will be very apealing to us.
But i still can''t really tell much about it right now. It may turn out to be really useful. I just can''t tell yet.
And I looked at some of the code and its so heavily C++ i couldn''t even understand it. Most Linux folks are going to be using C, not so much C++, so I doubt this will be very apealing to us.
But i still can''t really tell much about it right now. It may turn out to be really useful. I just can''t tell yet.
Ok, it''s too much of a good thing to be ignored here, but unfortunately I don''t have many suggestions, or comments on it''s current state.
A standard win32 wrapper of sorts would be usefuful on the dependant side of things.
I see you''re planning audio/input libraries, so I would urge you to finish those soon.
A particle engine?
That''s all I got
[My site|SGI STL|Bjarne FAQ|C++ FAQ Lite|MSDN|Jargon]
Ripped off from various people
A standard win32 wrapper of sorts would be usefuful on the dependant side of things.
I see you''re planning audio/input libraries, so I would urge you to finish those soon.
A particle engine?
That''s all I got
[My site|SGI STL|Bjarne FAQ|C++ FAQ Lite|MSDN|Jargon]
Ripped off from various people
Here''s some stuff that''d be cool:
1. A VERY customizable GUI engine. Buttons, scrollbars, tabs, basically enough functionality to do RollerCoaster Tycoon style stuff.
2. An SDL style platform abstraction layer, although SDL does such an awesome job at that it''d be REALLY hard to do any better.
3. An installer system. Games gotta be installed, right?
4. A physics engine
5. A network engine (just make sure its easier to use than DirectPlay)
6. A package file loader (customizable, of course) for loading .mpq, .wad, etc style stuff.
And the most important part is making it modular. If I don''t want to use the physics engine I shouldn''t have to. It should be very easy to pick and choose EXACTLY what I want and don''t want, and it should also be easy to override certain stuff with my own stuff.
There''s some suggestions. Better get started!
1. A VERY customizable GUI engine. Buttons, scrollbars, tabs, basically enough functionality to do RollerCoaster Tycoon style stuff.
2. An SDL style platform abstraction layer, although SDL does such an awesome job at that it''d be REALLY hard to do any better.
3. An installer system. Games gotta be installed, right?
4. A physics engine
5. A network engine (just make sure its easier to use than DirectPlay)
6. A package file loader (customizable, of course) for loading .mpq, .wad, etc style stuff.
And the most important part is making it modular. If I don''t want to use the physics engine I shouldn''t have to. It should be very easy to pick and choose EXACTLY what I want and don''t want, and it should also be easy to override certain stuff with my own stuff.
There''s some suggestions. Better get started!
quote:
2. An SDL style platform abstraction layer, although SDL does such an awesome job at that it''d be REALLY hard to do any better.
Yeah, I''m writing a OS-independant (well, it could be if someone wrote Linux stuff) simple wrapper - basically, just holding HWNDs (or linux equavilent) and responding to events (there''s an OS-indie event class).
does bool GDNmain() sound familiar?
Once that''s written, I already have code for multi-adaptor and multi-head rendering systems.
Basically, it''s easy to extend: you can alias all the renderer objects to one, so every time you call LoadTexture() it loads the texture across all multi-adaptors (but not multi-heads
). Then you can specify if you want it to be spread over all screens, or present different things on different screens.To long have the multi-monitor world been ignored!
Actually it was very easy to write once I got rid of the singleton mentality...
-----------------------------
Gamedev for learning.
libGDN for putting it all together.
Author
Well Well Well,
I think we some of that stuff already coming
It''s not really a wrapper as much as a generic system for for wrapping up an API you wish. Could be DX, could be GL, could be GDI or a software renderer. Whatever. As soon as documentation starts to come out you''ll see how it goes.
BradDaBug:
1. We have a low level OS indie windowing system coming soon. Simple to use. No more writing WinMain or WndProc. No higher level stuff coming out right now, but, given that this library is not really bounded, I wouldn''t count it out.
2. As I said before, the abstraction is in the form of policy classes so basically, you have a generic component that does the basic work, and then the policy class gets handed the API work. So it''s extremly flexible. Right now we already have an easy to use renderer class with DirectX specializations (GL may come soon). See the MatrixStack sample in the latest release to see it in action (3 lines for initialization).
3. Installer System. Hmm. This one is not planned but very easy to implement in the basic sense (copying/decompression of files), since we already have the OS indie file management code down with a windows implementation on what needs it.
4. Maybe later, not planned now, though I''ll keep it in mind.
5. A certain someone on the IRC channels has notified me that he is making a very robust cross platform Networking library based on the STL streams paradigm for us. Given that he has a LOT of previous experince with this, I expect it will be very good.
6. A Package File loader that will probably be more than you expect is implemented but package type loader incomplete right now. It''s a class called Archive. You register classes that do all the package loading for a given type with a singleton Generic Factory and away you go. Archive archive("Hello.zip"); It''s extenable beyond the implemented types by simply making and registering a new loader class for a specific type. We also have a resource manager for virtual file system mapping.
wild_pointer
Win32 wrapper..see above
Input/Sound libraries - Planned but I think we''re focusing on graphics first. Shouldn''t be tooo far away though.
Particle Engine - My favorite - planned and I''m doing it. Better than my last one, with an editor planned to (That uses the library to be OS indie). Previous One.
The code and it''s use m,ight be a little unclear right now. Be assured documentation is coming soon.
Gamedev for learning.
libGDN for putting it all together.
An opensource, cross platform, cross API game development library.
I think we some of that stuff already coming
It''s not really a wrapper as much as a generic system for for wrapping up an API you wish. Could be DX, could be GL, could be GDI or a software renderer. Whatever. As soon as documentation starts to come out you''ll see how it goes.
BradDaBug:
1. We have a low level OS indie windowing system coming soon. Simple to use. No more writing WinMain or WndProc. No higher level stuff coming out right now, but, given that this library is not really bounded, I wouldn''t count it out.
2. As I said before, the abstraction is in the form of policy classes so basically, you have a generic component that does the basic work, and then the policy class gets handed the API work. So it''s extremly flexible. Right now we already have an easy to use renderer class with DirectX specializations (GL may come soon). See the MatrixStack sample in the latest release to see it in action (3 lines for initialization).
3. Installer System. Hmm. This one is not planned but very easy to implement in the basic sense (copying/decompression of files), since we already have the OS indie file management code down with a windows implementation on what needs it.
4. Maybe later, not planned now, though I''ll keep it in mind.
5. A certain someone on the IRC channels has notified me that he is making a very robust cross platform Networking library based on the STL streams paradigm for us. Given that he has a LOT of previous experince with this, I expect it will be very good.
6. A Package File loader that will probably be more than you expect is implemented but package type loader incomplete right now. It''s a class called Archive. You register classes that do all the package loading for a given type with a singleton Generic Factory and away you go. Archive archive("Hello.zip"); It''s extenable beyond the implemented types by simply making and registering a new loader class for a specific type. We also have a resource manager for virtual file system mapping.
wild_pointer
Win32 wrapper..see above
Input/Sound libraries - Planned but I think we''re focusing on graphics first. Shouldn''t be tooo far away though.
Particle Engine - My favorite - planned and I''m doing it. Better than my last one, with an editor planned to (That uses the library to be OS indie). Previous One.
The code and it''s use m,ight be a little unclear right now. Be assured documentation is coming soon.
Gamedev for learning.
libGDN for putting it all together.
An opensource, cross platform, cross API game development library.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement