www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - OpenGL GUI or GUI with (renderer/API of choice)?

reply Chad J <Chad_member pathlink.com> writes:

or anything else.  That said, I will need a GUI toolkit for any game I want to
make in D.  It has to use OpenGL, unless someone can tell me how to make OpenGL
and some other GUI lib using a different renderer work in harmony in the same
app, on the same window.  So far I have been unable to find any GUI libs that
will work with both D and OpenGL, and I was wondering if one is available or in
the works.  

If there isn't a good OpenGL GUI around that works in D, I am probably going to
code one myself.  I've decided that it would probably be easier to just port
some C++ code from one of the OpenGL GUI libraries rather than do it from
scratch.  One I am particularly interested in is CEGUI, or Crazy Eddie's GUI
System (http://www.cegui.org.uk/modules/news/).  So far I like it.  It is
skinnable, uses XML for said skinning, seems straightforward enough, and is used
in games.  One thing caught my attention though: CEGUI can use different
renderers to display the GUI.  It made me start to think, why not have a GUI
that can use any renderer or basic API?  I get the feeling that most of the code
in a GUI library deals with its behavior, accepting inputs, and deciding where
to draw images, and only a small fraction is dedicated to actually rendering the
images.  I'm thinking it might be possible to make a layer that would work
between the GUI and the renderer, and allow people to write modules for the GUI
system that tell it how to handle rendering.  That way all of the GUI code would
be reused, and people who want a different API/renderer would just need to tell
the GUI system how to draw an image to the screen.  Another problem I see with
GUI lib reliance on APIs is input.  CEGUI handled that by having the coder
inject mouse/keyboard events into it.  Such a library could have little or no
reliance on any API, native or otherwise.  Please correct me if I'm wrong, or
let me know if this sort of thing is happening already.  

One last thing - I am unable to find a "search" option on this forum/newsgroup.
Is there an easier way to look for things besides looking through the forum one
page at a time?
Dec 14 2005
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Chad J wrote:


 One last thing - I am unable to find a "search" option on this forum/newsgroup.
 Is there an easier way to look for things besides looking through the forum one
 page at a time?


Use a standalone newsreader, Mozilla Thunderbird is not too shabby.

--anders
Dec 14 2005
prev sibling next sibling parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Chad J wrote:



 or anything else.  That said, I will need a GUI toolkit for any game I want to
 make in D.  It has to use OpenGL, unless someone can tell me how to make OpenGL
 and some other GUI lib using a different renderer work in harmony in the same
 app, on the same window. So far I have been unable to find any GUI libs that
 will work with both D and OpenGL, and I was wondering if one is available or in
 the works.  


Well... in the works. I've been working on a 3d game engine for some 
time. Currently it uses OpenGL as its renderer (but I may add D3D later 
on). It's also got an early version of a GUI coded entierly in D. The 
project's forum can be found here:
http://dsource.org/forums/viewforum.php?f=54
There's a link to a GUI demo download, which shows a few of its 
features. The demo is buggy, which can be checked by either using the 
mouse wheel or both mouse buttons to select ListBox items. These were 
really minor and I've eliminated them already, but just be aware that 
the demo may crash.
I'm currently low on free time, so the GUI isn't completely separated 
from my engine, I'm working on enhancing my photon mapper and possibly 
adding some PRT calculation capabilities to it, plus I have to refactor 
some code, while being busy with university stuff. Ahh... lots of things 
on my head, but I'm really looking forward to separating the GUI from my 
engine and making it available to the public.




 One thing caught my attention though: CEGUI can use different
 renderers to display the GUI.  It made me start to think, why not have a GUI
 that can use any renderer or basic API?  I get the feeling that most of the
code
 in a GUI library deals with its behavior, accepting inputs, and deciding where
 to draw images, and only a small fraction is dedicated to actually rendering
the
 images.  I'm thinking it might be possible to make a layer that would work
 between the GUI and the renderer, and allow people to write modules for the GUI
 system that tell it how to handle rendering.  That way all of the GUI code
would
 be reused, and people who want a different API/renderer would just need to tell
 the GUI system how to draw an image to the screen.  Another problem I see with
 GUI lib reliance on APIs is input.  CEGUI handled that by having the coder
 inject mouse/keyboard events into it.  Such a library could have little or no
 reliance on any API, native or otherwise.  Please correct me if I'm wrong, or
 let me know if this sort of thing is happening already.  


AFAIK you're completely right. I've seen CEGUI work with the Ogre 

- On a seminar by a guy from PeopleCanFly (makers of Painkiller). The 
only thing that a GUI really needs is a simple graphics 'driver' which 
would draw a bunch of textured quads (and possibly load these textures 
in a special way) and a means of receiving input, just as you said.



-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d-pu s+: a-->----- C+++$>++++ UL P+ L+ E--- W++ N++ o? K? w++ !O 
!M V? PS- PE- Y PGP t 5 X? R tv-- b DI- D+ G e>+++ h>++ !r !y
------END GEEK CODE BLOCK------

Tomasz Stachowiak  /+ a.k.a. h3r3tic +/
Dec 14 2005
prev sibling next sibling parent "Craig Black" <cblack ara.com> writes:
Noone seemed to like the idea last time I mentioned it, but I think someone 
should port Qt to D.  Qt is full featured, cross platform, and includes good 
support for OpenGL.  I know from experience that it is a very good tool.  In 
fact, I would go so far as to say it is the best quality GUI framework 
available.

-Craig
Dec 14 2005
prev sibling next sibling parent John Reimer <terminal.node gmail.com> writes:
Last I heard, Ant's DUI supported an OpenGL canvas.  It was working on 
Linux and Win32 for awhile.  With the change to dynamic module loaders 
driving DUI, though, I think the OpenGL canvas is incomplete again.

-JJR
Dec 14 2005
prev sibling next sibling parent J C Calvarese <technocrat7 gmail.com> writes:
In article <dnopb0$hq7$1 digitaldaemon.com>, Chad J says...

One last thing - I am unable to find a "search" option on this forum/newsgroup.
Is there an easier way to look for things besides looking through the forum one
page at a time?


Try this page:
http://www.digitalmars.com/advancedsearch.html

Searching for information about D is often an adventure. Here are some tips that
I've compiled: http://www.prowiki.org/wiki4d/wiki.cgi?SearchingTips

jcc7
Dec 14 2005
prev sibling next sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
You can either
A) Try and use DUI over at dsource.org, which is essentially GTK for D
B) Roll out your own and become famous

As for a newsreader, go to mozilla.com and grab a hold of Thunderbird, 
it has search functionality and makes the newsgroup readable.

If you decide to roll your own, here are some more options

1) Work with the dsource.org community to try and make a standard OpenGL 
GUI for D. This way other D programmers interested in the same thing can 
give you support and be your advanced beta testers. I'll promise you at 
least two people will be interested in it. ;)

2) Make bindings for an already existing D OpenGL GUI. You can get C and 
C++ libraries to work in D, albeit C++ takes a little more effort as you 
bind from C++ --> C --> D.

Goodluck, for whichever path you may choose.
~ Clay
Dec 14 2005
next sibling parent reply John Reimer <terminal.node gmail.com> writes:
clayasaurus wrote:

 You can either
 A) Try and use DUI over at dsource.org, which is essentially GTK for D
 B) Roll out your own and become famous
 
 As for a newsreader, go to mozilla.com and grab a hold of Thunderbird, 
 it has search functionality and makes the newsgroup readable.
 
 If you decide to roll your own, here are some more options
 
 1) Work with the dsource.org community to try and make a standard OpenGL 
 GUI for D. This way other D programmers interested in the same thing can 
 give you support and be your advanced beta testers. I'll promise you at 
 least two people will be interested in it. ;)
 
 2) Make bindings for an already existing D OpenGL GUI. You can get C and 
 C++ libraries to work in D, albeit C++ takes a little more effort as you 
 bind from C++ --> C --> D.
 
 Goodluck, for whichever path you may choose.
 ~ Clay


What about Terra? It is a GUI framework done fully in OpenGL, I believe. 
The project looked like it was getting off to a good start.  Maybe 
that's of interest here?

-JJR
Dec 14 2005
parent reply clayasaurus <clayasaurus gmail.com> writes:
John Reimer wrote:

 clayasaurus wrote:
 

 You can either
 A) Try and use DUI over at dsource.org, which is essentially GTK for D
 B) Roll out your own and become famous

 As for a newsreader, go to mozilla.com and grab a hold of Thunderbird, 
 it has search functionality and makes the newsgroup readable.

 If you decide to roll your own, here are some more options

 1) Work with the dsource.org community to try and make a standard 
 OpenGL GUI for D. This way other D programmers interested in the same 
 thing can give you support and be your advanced beta testers. I'll 
 promise you at least two people will be interested in it. ;)

 2) Make bindings for an already existing D OpenGL GUI. You can get C 
 and C++ libraries to work in D, albeit C++ takes a little more effort 
 as you bind from C++ --> C --> D.

 Goodluck, for whichever path you may choose.
 ~ Clay


 
 
 What about Terra? It is a GUI framework done fully in OpenGL, I believe. 
 The project looked like it was getting off to a good start.  Maybe 
 that's of interest here?
 
 -JJR


Well, I did say 'work with the dsource.org community and try to make a 
standard OpenGL GUI for D,' Terra would certainly pertain to this. The 
ownly downside is that I assume Trevor is busy with Titan (kernel) and 
that Terra's SVN doesn't contain anything ATM.
Dec 14 2005
parent clayasaurus <clayasaurus gmail.com> writes:
clayasaurus wrote:

 John Reimer wrote:
 

 clayasaurus wrote:


 You can either
 A) Try and use DUI over at dsource.org, which is essentially GTK for D
 B) Roll out your own and become famous

 As for a newsreader, go to mozilla.com and grab a hold of 
 Thunderbird, it has search functionality and makes the newsgroup 
 readable.

 If you decide to roll your own, here are some more options

 1) Work with the dsource.org community to try and make a standard 
 OpenGL GUI for D. This way other D programmers interested in the same 
 thing can give you support and be your advanced beta testers. I'll 
 promise you at least two people will be interested in it. ;)

 2) Make bindings for an already existing D OpenGL GUI. You can get C 
 and C++ libraries to work in D, albeit C++ takes a little more effort 
 as you bind from C++ --> C --> D.

 Goodluck, for whichever path you may choose.
 ~ Clay




 What about Terra? It is a GUI framework done fully in OpenGL, I 
 believe. The project looked like it was getting off to a good start.  
 Maybe that's of interest here?

 -JJR


 
 
 Well, I did say 'work with the dsource.org community and try to make a 
 standard OpenGL GUI for D,' Terra would certainly pertain to this. The 
 ownly downside is that I assume Trevor is busy with Titan (kernel) and 
 that Terra's SVN doesn't contain anything ATM.
 


Another thing I forgot to add, he wants an API independent GUI lib. 
Wouldn't a GUI lib in Terra force API dependence on Terra? What if he 
wants to use it with SDL or GLFW?
Dec 14 2005
prev sibling parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
clayasaurus wrote:

 You can either
 A) Try and use DUI over at dsource.org, which is essentially GTK for D
 B) Roll out your own and become famous


I don't get it. Why are you suggesting DUI ? Chad was certainly asking 
about a GUI that draws in a 3D api, not a general purpose system-level 
GUI like GTK or DWT, etc. Something just like CEGUI, Terra's GUI or my own.


-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d-pu s+: a-->----- C+++$>++++ UL P+ L+ E--- W++ N++ o? K? w++ !O 
!M V? PS- PE- Y PGP t 5 X? R tv-- b DI- D+ G e>+++ h>++ !r !y
------END GEEK CODE BLOCK------

Tomasz Stachowiak  /+ a.k.a. h3r3tic +/
Dec 14 2005
parent reply John Reimer <terminal.node gmail.com> writes:
Tom S wrote:

 clayasaurus wrote:

 You can either
 A) Try and use DUI over at dsource.org, which is essentially GTK for D
 B) Roll out your own and become famous


 
 I don't get it. Why are you suggesting DUI ? Chad was certainly asking 
 about a GUI that draws in a 3D api, not a general purpose system-level 
 GUI like GTK or DWT, etc. Something just like CEGUI, Terra's GUI or my own.
 
 


Because of this line:

"It has to use OpenGL, unless someone can tell me how to make OpenGL
and some other GUI lib using a different renderer work in harmony in the 
same app, on the same window."

It was just ambiguous enough so that we thought he meant a GUI that 
could access opengl.  Otherwise I agree... he was quite plain about what 
he really wanted.

-JJR
Dec 14 2005
parent reply clayasaurus <clayasaurus gmail.com> writes:
John Reimer wrote:

 Tom S wrote:
 

 clayasaurus wrote:


 You can either
 A) Try and use DUI over at dsource.org, which is essentially GTK for D
 B) Roll out your own and become famous



 I don't get it. Why are you suggesting DUI ? Chad was certainly asking 
 about a GUI that draws in a 3D api, not a general purpose system-level 
 GUI like GTK or DWT, etc. Something just like CEGUI, Terra's GUI or my 
 own.


 
 Because of this line:
 
 "It has to use OpenGL, unless someone can tell me how to make OpenGL
 and some other GUI lib using a different renderer work in harmony in the 
 same app, on the same window."
 
 It was just ambiguous enough so that we thought he meant a GUI that 
 could access opengl.  Otherwise I agree... he was quite plain about what 
 he really wanted.
 
 -JJR


Yes, and DUI may suit his purposes especially if he is doing a level 
editor. The more options he has the better.
Dec 14 2005
parent reply Chad J <gamerchad2.no-ip.org/email.txt LeftOfAtSignForEmail.meh> writes:
Interesting.  Yes it needs to be good for games.  This means skinnable 
and I'm also thinking it will need to be capable of HUD (heads up 
display) type functionality (alpha blending perhaps?), incase the player 
wants to put widgets/icons/whatever ontop of the game's viewport.  It 
also needs to be fast.  I am really hoping for something that is 
strictly a GUI system, not an API.

Now I haven't given an entirely thorough look at all of the suggestions, 
but I did give a glance.  I still have plenty of reading to do.  Anyhow, 
here are my impressions:

DUI - Yeah seems too system oriented.  If it meets some of the other 
criteria though, I wonder how difficult it would be to add on some 
game-developer friendly code in there?  Perhaps add the option to make 
it function like I suggested in my original post: let the person using 
it plug in their own API for it to work ontop of.

Terra - I am having trouble understanding what exactly its intent is.  I 
probably just haven't read the forum on dsource enough.  I read Trevor's 
welcoming post and he said this "Terra is not meant for game 
development, it's meant for application development. It is not so 
different from SDL or GLFW, spare the fact that it's written in D, 
instead of being a binding to a compiled C library."  He then said that 
a GUI toolkit could be built ontop of Terra and OpenGL.  That would 
suggest that it is primarily an API... I get the feeling I am wrong 
about this though.

Qt - Qt looks BIG.  It is probably far more than I could port or 
replicate.  If I had plenty of help though it might be possible.  It 
also looks expensive (at least for my bedroom programmer/college student 
budget), unless the D version could be made free somehow.  And it seems 
to want to be an API as well as a GUI, and I dunno how problematic that 
may or may not be.  Those things aside though, it looks very impressive.


crashed :/  It gave me the same error that the Mirrors demo gave JJR. 
Mirrors also crashed for me in the same way.  FYI I am using a Radeon 
9500 PRO / 9700 on a Windows XP SP2 system.  I may try running it on 
another system to try and get it to work.  It sounds very close to what 
I need.

If I were to make my own or port/bind something from C++, my initial 
instinct is to model it after CEGUI and make it strictly a GUI, and 
nothing else.  Then hopefully other things could be built ontop of it, 
underneath it, or... or even next to it!, ideally with a minimum of 
hassle for whoever uses it.  I am not sure I'd be able to do that 
though, and I might have to settle for a pretty minimalistic GUI 
subsystem.
Dec 14 2005
parent reply Tom S <Tom_member pathlink.com> writes:
In article <dnqi4p$269s$1 digitaldaemon.com>, Chad J says...


crashed :/  It gave me the same error that the Mirrors demo gave JJR. 
Mirrors also crashed for me in the same way.  FYI I am using a Radeon 
9500 PRO / 9700 on a Windows XP SP2 system.  I may try running it on 
another system to try and get it to work.  It sounds very close to what 
I need.


Sorry for that. It happens on most ATI cards. Not entirely my fault. It crashes
on DSL initialization when SDL_HWSURFACE is passed to the window's initializer.
Not sure why. Try testing it on an nVidia. I'll put an updated executable online
today.

--
Tomasz Stachowiak a.k.a. h3r3tic
Dec 14 2005
parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Tom S wrote:

 In article <dnqi4p$269s$1 digitaldaemon.com>, Chad J says...
 


crashed :/  It gave me the same error that the Mirrors demo gave JJR. 
Mirrors also crashed for me in the same way.  FYI I am using a Radeon 
9500 PRO / 9700 on a Windows XP SP2 system.  I may try running it on 
another system to try and get it to work.  It sounds very close to what 
I need.


 
 
 Sorry for that. It happens on most ATI cards. Not entirely my fault. It crashes
 on DSL initialization when SDL_HWSURFACE is passed to the window's initializer.
 Not sure why. Try testing it on an nVidia. I'll put an updated executable
online
 today.


Ok... here's a link (3MB):
http://158.75.59.9/~h3/download/smallTest.rar

It's not the same app as in test5.rar nor is it my most recent code. The 
latest code doesn't work, because of me doing some hack'n'slash on it ;)
It should work on ATI carts, at least it worked when I tested it :). Oh, 
and make sure to extract files to a directory without a space in its 
path. I'll make a workaround later.


-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d-pu s+: a-->----- C+++$>++++ UL P+ L+ E--- W++ N++ o? K? w++ !O 
!M V? PS- PE- Y PGP t 5 X? R tv-- b DI- D+ G e>+++ h>++ !r !y
------END GEEK CODE BLOCK------

Tomasz Stachowiak  /+ a.k.a. h3r3tic +/
Dec 15 2005
parent reply Chad J <gamerchad2.no-ip.org/email.txt LeftOfAtSignForEmail.meh> writes:
Tom S wrote:

 Tom S wrote:
 

 In article <dnqi4p$269s$1 digitaldaemon.com>, Chad J says...



 crashed :/  It gave me the same error that the Mirrors demo gave JJR. 
 Mirrors also crashed for me in the same way.  FYI I am using a Radeon 
 9500 PRO / 9700 on a Windows XP SP2 system.  I may try running it on 
 another system to try and get it to work.  It sounds very close to 
 what I need.




 Sorry for that. It happens on most ATI cards. Not entirely my fault. 
 It crashes
 on DSL initialization when SDL_HWSURFACE is passed to the window's 
 initializer.
 Not sure why. Try testing it on an nVidia. I'll put an updated 
 executable online
 today.


 
 
 Ok... here's a link (3MB):
 http://158.75.59.9/~h3/download/smallTest.rar
 
 It's not the same app as in test5.rar nor is it my most recent code. The 
 latest code doesn't work, because of me doing some hack'n'slash on it ;)
 It should work on ATI carts, at least it worked when I tested it :). Oh, 
 and make sure to extract files to a directory without a space in its 
 path. I'll make a workaround later.


Still crashes, unfortunately.  Same error.  Crashes after printing 
"Creating a Window".  The directory it's under is 
C:\Loadz\D_Language\heretic\smallTest\  where _ IS an underscore, so no 
spaces.
Dec 15 2005
parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Chad J wrote:

 Tom S wrote:

 Ok... here's a link (3MB):
 http://158.75.59.9/~h3/download/smallTest.rar

 It's not the same app as in test5.rar nor is it my most recent code. 
 The latest code doesn't work, because of me doing some hack'n'slash on 
 it ;)
 It should work on ATI carts, at least it worked when I tested it :). 
 Oh, and make sure to extract files to a directory without a space in 
 its path. I'll make a workaround later.


 
 
 Still crashes, unfortunately.  Same error.  Crashes after printing 
 "Creating a Window".  The directory it's under is 
 C:\Loadz\D_Language\heretic\smallTest\  where _ IS an underscore, so no 
 spaces.


Damn. I thought this version worked with ATIs :( If I only had one at 
home... This must still be a problem with SDL vs ATI drivers. It worked 
on ALL nVidia cards I could test it with, from TNT2 to GF6800.
You might try reinstalling your drivers or getting a more recent SDL 
version (1.2.7 is packaged with the demo - the most recent is 1.2.9).
Sorry for it :/ BTW the space-in-path problem is also only indirectly 
related to my engine. I'm using DMD for shader compilation and IIRC dmd 
doesn't like to be in a path with spaces. Or was it about build... I 
dunno. Nevertheless it would complain about being unable to compile a 
shader if that was the issue. Now it seems as SDL is still causing me 
trouble.
Can anybody else test it on an ATI card ?


-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d-pu s+: a-->----- C+++$>++++ UL P+ L+ E--- W++ N++ o? K? w++ !O 
!M V? PS- PE- Y PGP t 5 X? R tv-- b DI- D+ G e>+++ h>++ !r !y
------END GEEK CODE BLOCK------

Tomasz Stachowiak  /+ a.k.a. h3r3tic +/
Dec 15 2005
next sibling parent reply Chris Lajoie <ctlajoie yahoo.com> writes:
 Still crashes, unfortunately.  Same error.  Crashes after printing
 "Creating a Window".  The directory it's under is
 C:\Loadz\D_Language\heretic\smallTest\  where _ IS an underscore, so
 no spaces.
 


 Damn. I thought this version worked with ATIs :( If I only had one at
 home... This must still be a problem with SDL vs ATI drivers. It
 worked
 on ALL nVidia cards I could test it with, from TNT2 to GF6800.
 You might try reinstalling your drivers or getting a more recent SDL
 version (1.2.7 is packaged with the demo - the most recent is 1.2.9).
 Sorry for it :/ BTW the space-in-path problem is also only indirectly
 related to my engine. I'm using DMD for shader compilation and IIRC
 dmd
 doesn't like to be in a path with spaces. Or was it about build... I
 dunno. Nevertheless it would complain about being unable to compile a
 shader if that was the issue. Now it seems as SDL is still causing me
 trouble.
 Can anybody else test it on an ATI card ?
 Tomasz Stachowiak  /+ a.k.a. h3r3tic +/


I tried it on my 9800 pro and it crashed. Have a look at my post about the 
5 games written in D (a reply to Chad's original post). It has an SDL interface 
that works great on my card. Hopefully it works just as well on nVidia cards. 


Chris
Dec 15 2005
next sibling parent Chris Lajoie <ctlajoie yahoo.com> writes:
 Damn. I thought this version worked with ATIs :( If I only had one at
 home... This must still be a problem with SDL vs ATI drivers. It
 worked
 on ALL nVidia cards I could test it with, from TNT2 to GF6800.
 You might try reinstalling your drivers or getting a more recent SDL
 version (1.2.7 is packaged with the demo - the most recent is 1.2.9).
 Sorry for it :/ BTW the space-in-path problem is also only indirectly
 related to my engine. I'm using DMD for shader compilation and IIRC
 dmd
 doesn't like to be in a path with spaces. Or was it about build... I
 dunno. Nevertheless it would complain about being unable to compile a
 shader if that was the issue. Now it seems as SDL is still causing me
 trouble.
 Can anybody else test it on an ATI card ?
 Tomasz Stachowiak  /+ a.k.a. h3r3tic +/


 I tried it on my 9800 pro and it crashed. Have a look at my post about
 the 5 games written in D (a reply to Chad's original post). It has an
 SDL interface that works great on my card. Hopefully it works just as
 well on nVidia cards.


I've been trying to get it to run for a while now, I can't figure it out. 
let me know if you want me to test it again. I'm interrested in this as well....

Chris
Dec 15 2005
prev sibling parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Chris Lajoie wrote:

 I tried it on my 9800 pro and it crashed. Have a look at my post about 
 the 5 games written in D (a reply to Chad's original post). It has an 
 SDL interface that works great on my card. Hopefully it works just as 
 well on nVidia cards.
 
 Chris


Thanks for the info. I'll take a look at these games' source (I hope 
they are open source)


-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d-pu s+: a-->----- C+++$>++++ UL P+ L+ E--- W++ N++ o? K? w++ !O 
!M V? PS- PE- Y PGP t 5 X? R tv-- b DI- D+ G e>+++ h>++ !r !y
------END GEEK CODE BLOCK------

Tomasz Stachowiak  /+ a.k.a. h3r3tic +/
Dec 16 2005
prev sibling parent reply Chad J <gamerchad2.no-ip.org/email.txt LeftOfAtSignForEmail.meh> writes:
Tom S wrote:

 Chad J wrote:
 

 Tom S wrote:


 Ok... here's a link (3MB):
 http://158.75.59.9/~h3/download/smallTest.rar

 It's not the same app as in test5.rar nor is it my most recent code. 
 The latest code doesn't work, because of me doing some hack'n'slash 
 on it ;)
 It should work on ATI carts, at least it worked when I tested it :). 
 Oh, and make sure to extract files to a directory without a space in 
 its path. I'll make a workaround later.




 Still crashes, unfortunately.  Same error.  Crashes after printing 
 "Creating a Window".  The directory it's under is 
 C:\Loadz\D_Language\heretic\smallTest\  where _ IS an underscore, so 
 no spaces.


 
 
 Damn. I thought this version worked with ATIs :( If I only had one at 
 home... This must still be a problem with SDL vs ATI drivers. It worked 
 on ALL nVidia cards I could test it with, from TNT2 to GF6800.
 You might try reinstalling your drivers or getting a more recent SDL 
 version (1.2.7 is packaged with the demo - the most recent is 1.2.9).
 Sorry for it :/ BTW the space-in-path problem is also only indirectly 
 related to my engine. I'm using DMD for shader compilation and IIRC dmd 
 doesn't like to be in a path with spaces. Or was it about build... I 
 dunno. Nevertheless it would complain about being unable to compile a 
 shader if that was the issue. Now it seems as SDL is still causing me 
 trouble.
 Can anybody else test it on an ATI card ?
 
 


OK I ran techdemo5, publicRelease (mirror one), and smallTest on another 
computer.  The other comp is an ATI All-in-wonder 9600.  Techdemo and 
publicRelease seemed to run fine.  smallTest crashed however, and the 
error is a different one.  It went like this:
...
Renderer initialized
compiling shaders\simpleHFileter.shader
retcode: 1

********** Heresy Engine Error Handler **********

*Exception caught (CompileException) : Compilation error. See 
shaders\simpleHFilter.compile.log for details

Hey if you happen to use AIM or ICQ instant messagers, you could message 
me when I'm around and whenever you have a new compilation that needs 
testing.  As long as I'm not too busy or afk I can give it a whirl.  My 


The GUI looks nice, and I am really liking what I see of the heresy 
engine.  Sounds like it's very open source too.  Have you decided on a 
license for it?  If so, which one?
Dec 16 2005
parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Chad J wrote:

 OK I ran techdemo5, publicRelease (mirror one), and smallTest on another 
 computer.  The other comp is an ATI All-in-wonder 9600.  Techdemo and 
 publicRelease seemed to run fine.  smallTest crashed however, and the 
 error is a different one.  It went like this:
 ...
 Renderer initialized
 compiling shaders\simpleHFileter.shader
 retcode: 1
 
 ********** Heresy Engine Error Handler **********
 
 *Exception caught (CompileException) : Compilation error. See 
 shaders\simpleHFilter.compile.log for details


Just check the log file. It will probbly complain about being unable to 
find a file. If that's true, then you've probably extracted the demo to 
a directory whose path contains a space. I'm running DMD from within the 
engine in order to dynamically compile shaders and either DMD doesn't 
like spaces or I'm doing something wrong with it ;)




 Hey if you happen to use AIM or ICQ instant messagers, you could message 
 me when I'm around and whenever you have a new compilation that needs 
 testing.  As long as I'm not too busy or afk I can give it a whirl.  My 



My ICQ == 315344462
Thanks for offering help :)



 The GUI looks nice, and I am really liking what I see of the heresy 
 engine.  Sounds like it's very open source too.  Have you decided on a 
 license for it?  If so, which one?


Not sure about it yet. I've heard the Zlib is nice. Any suggestions ?


-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d-pu s+: a-->----- C+++$>++++ UL P+ L+ E--- W++ N++ o? K? w++ !O 
!M V? PS- PE- Y PGP t 5 X? R tv-- b DI- D+ G e>+++ h>++ !r !y
------END GEEK CODE BLOCK------

Tomasz Stachowiak  /+ a.k.a. h3r3tic +/
Dec 16 2005
parent reply Chad J <gamerchad2.no-ip.org/email.txt LeftOfAtSignForEmail.meh> writes:
 Just check the log file. It will probbly complain about being unable to 
 find a file. If that's true, then you've probably extracted the demo to 
 a directory whose path contains a space. I'm running DMD from within the 
 engine in order to dynamically compile shaders and either DMD doesn't 
 like spaces or I'm doing something wrong with it ;)


Hehe yep that's it.  Got me :)  Well, I did away with the spaces and got 
another error for you:

retCode: 0
~Camera
Scene Loaded
CPU Speed: 3.00 GHz
calling shader.fillCache (obj-c54a00, params=c58a00)
Access Violation
filling the index cache
Exception caught while executing a pipeline node: DrawOp

********** Heresy Engine Error Handler **********

*Exception caught (Exception) : Access Violation


 Not sure about it yet. I've heard the Zlib is nice. Any suggestions ?


Nope sorry.  I'm still pretty new to this, so I only know it from the 
consumer point of view - get license name, look it up, and try for an 
explanation or else read the legalese.
Dec 16 2005
parent Trevor Parscal <Trevor_member pathlink.com> writes:
I just wanted to clarify some things about Terra...

The point of Terra is to make it easy to make an application that uses 2D and or
3D (together). It has advanced systems for loading and displaying images,
loading fonts and rendering text and it's all designed for high performance
apps.

I say APPLICATION because Terra is designed to have 1 or more windows which
interact with other windows in a desktop gui, like file and internet browsers or
whatever. SDL handles windows like crap. There are no platform independent ways
to do allot of really common and needed things when making a Windowed
application. They say this is so it can be SUPER CROSS PLATFORM - but it's lame
to bother with Amiga compatibility when you are programming a 3D app that needs
a modern graphics card, which Amiga does NOT support.

NOW - Terra has an interface system, meaning it has a basic WIDGET class and an
INTERFACE class which contains a tree structure of WIDGETs.. You can make your
own WIDGETS, and as I develop Terra the widget's become easier and easier to
make as I am simplifing common tasks into object oriented solutions. If someone
wanted to make some widgets for Terra, they would only need to know OpenGL if
they wanted to do something more advanced than drawing images and text.

ALSO - I am of course working on Terra and Titan at the same time, and the lack
of source in the SVN was originally a mishap - but now I am working on another
(perhaps one of the last) major modifications to the system, allowing ANYTHING
to be animated without any unnessecary additional overhead, using advanced
time-scaled tweening and a new system for connecting VALUE classes, which are
templated numeric values with common functionality built in and the ability to
link things together and keep sync throughout the app without any addition
programming. Its a complex problem I have been solving with a simplified
solution, and pending a few more glitches to work out, the system should prove
massively beneficial to making a Terra GUI dramtically more dynamic with very
little additional effort by the developer.

Other things that are cookin in my lab over here are to do with Titan, and the
newly developed Titan Planning Committee
(http://www.sequenceartworks.com/labs/titan/index.php) where people like us can
get together and come to a consnsus on whats the best idea for each step of the
way. Because I am not stupid enough to think I know how to write the perfect
kernel on my own, much less plan it all out on my own. Planning is a BIG step
and I value the views of others, and have so far used almost every idea I have
been given. THANK YOU to those who are helping and THANK YOU in advance for
those who ever will.

FINALLY - I have been working on some very ground breaking physics experiments
which could be very usefull if my designs pan out.

Thanks for reading this crap - hope it lets you all in on what's goin down and
what Terra is and is not...

Thanks,
Trevor Parscal
Dec 17 2005
prev sibling next sibling parent reply James Dunne <james.jdunne gmail.com> writes:
Chad J wrote:


 or anything else.  That said, I will need a GUI toolkit for any game I want to
 make in D.  It has to use OpenGL, unless someone can tell me how to make OpenGL
 and some other GUI lib using a different renderer work in harmony in the same
 app, on the same window.  So far I have been unable to find any GUI libs that
 will work with both D and OpenGL, and I was wondering if one is available or in
 the works.  
 
 If there isn't a good OpenGL GUI around that works in D, I am probably going to
 code one myself.  I've decided that it would probably be easier to just port
 some C++ code from one of the OpenGL GUI libraries rather than do it from
 scratch.  One I am particularly interested in is CEGUI, or Crazy Eddie's GUI
 System (http://www.cegui.org.uk/modules/news/).  So far I like it.  It is
 skinnable, uses XML for said skinning, seems straightforward enough, and is
used
 in games.  One thing caught my attention though: CEGUI can use different
 renderers to display the GUI.  It made me start to think, why not have a GUI
 that can use any renderer or basic API?  I get the feeling that most of the
code
 in a GUI library deals with its behavior, accepting inputs, and deciding where
 to draw images, and only a small fraction is dedicated to actually rendering
the
 images.  I'm thinking it might be possible to make a layer that would work
 between the GUI and the renderer, and allow people to write modules for the GUI
 system that tell it how to handle rendering.  That way all of the GUI code
would
 be reused, and people who want a different API/renderer would just need to tell
 the GUI system how to draw an image to the screen.  Another problem I see with
 GUI lib reliance on APIs is input.  CEGUI handled that by having the coder
 inject mouse/keyboard events into it.  Such a library could have little or no
 reliance on any API, native or otherwise.  Please correct me if I'm wrong, or
 let me know if this sort of thing is happening already.  
 
 One last thing - I am unable to find a "search" option on this forum/newsgroup.
 Is there an easier way to look for things besides looking through the forum one
 page at a time?
 
 


Check out this C version of something close to what you're looking for. 
  The code is almost guaranteed not to compile as-is, but it is valid 
code taken straight from a project of mine.  I can provide you the 
entire project (I've been meaning to release it open-source anyway) soon 
if you're interested.

The main stuff you'll want to check out is in glwindows.c, which has all 
the OpenGL calls to render the windows, controls, handle clicks, push 
buttons, call event handlers - everything.  It's not as nice as I 
would've liked it to be, but it definitely got the job done for my 
purposes (a map editor which was really quite impressive).

It sports a very rudimentary set of controls: button, label, panel, 
checkbox, radiobutton, and window.  It is all mouse-driven, no keyboard 
event handler yet since there isn't any control which requires keyboard 
input.  I meant to add a textbox control in order to get basic keyboard 
support in...  Also, the code is not dependent on any API for mouse 
events - there is an 'OnMouseDown' function and an 'OnMouseUp' function 
which should be called when the mouse click goes down and when the mouse 
click is released, respectively.

The glwindows.h header declares three extern variables which must be 
defined: 'GUITexture', 'Window', and 'Mouse'.

The 'GUITexture' is simply a GLUint which is a texture handle generated 
from glTexImage2D and the like.  Gen some textures, load em up, and set 
that ID.

The 'Mouse' is a simple struct defining X and Y coords for the mouse 
cursor and the button status.  These fields are to be set by the host 
application whenever the appropriate mouse move and click events are 
received.

The code is attached with most of the supporting files.  I'll see what I 
can do in the mean time about porting it to D; it doesn't look that hard.

P.S. - it's "skinnable" in that you can load up different textures to 
define how the controls and windows appear (see GUIwood.tga vs. 
GUIstone.tga).  Hope this helps.

P.P.S. - the image files will be attached in a reply-to post.
Dec 14 2005
parent reply James Dunne <james.jdunne gmail.com> writes:
James Dunne wrote:

 Chad J wrote:
 

 I have decided that I want to write my computer games in D, instead of 

 or anything else.  That said, I will need a GUI toolkit for any game I 
 want to
 make in D.  It has to use OpenGL, unless someone can tell me how to 
 make OpenGL
 and some other GUI lib using a different renderer work in harmony in 
 the same
 app, on the same window.  So far I have been unable to find any GUI 
 libs that
 will work with both D and OpenGL, and I was wondering if one is 
 available or in
 the works. 
 If there isn't a good OpenGL GUI around that works in D, I am probably 
 going to
 code one myself.  I've decided that it would probably be easier to 
 just port
 some C++ code from one of the OpenGL GUI libraries rather than do it from
 scratch.  One I am particularly interested in is CEGUI, or Crazy 
 Eddie's GUI
 System (http://www.cegui.org.uk/modules/news/).  So far I like it.  It is
 skinnable, uses XML for said skinning, seems straightforward enough, 
 and is used
 in games.  One thing caught my attention though: CEGUI can use different
 renderers to display the GUI.  It made me start to think, why not have 
 a GUI
 that can use any renderer or basic API?  I get the feeling that most 
 of the code
 in a GUI library deals with its behavior, accepting inputs, and 
 deciding where
 to draw images, and only a small fraction is dedicated to actually 
 rendering the
 images.  I'm thinking it might be possible to make a layer that would 
 work
 between the GUI and the renderer, and allow people to write modules 
 for the GUI
 system that tell it how to handle rendering.  That way all of the GUI 
 code would
 be reused, and people who want a different API/renderer would just 
 need to tell
 the GUI system how to draw an image to the screen.  Another problem I 
 see with
 GUI lib reliance on APIs is input.  CEGUI handled that by having the 
 coder
 inject mouse/keyboard events into it.  Such a library could have 
 little or no
 reliance on any API, native or otherwise.  Please correct me if I'm 
 wrong, or
 let me know if this sort of thing is happening already. 
 One last thing - I am unable to find a "search" option on this 
 forum/newsgroup.
 Is there an easier way to look for things besides looking through the 
 forum one
 page at a time?


 
 Check out this C version of something close to what you're looking for. 
  The code is almost guaranteed not to compile as-is, but it is valid 
 code taken straight from a project of mine.  I can provide you the 
 entire project (I've been meaning to release it open-source anyway) soon 
 if you're interested.
 
 The main stuff you'll want to check out is in glwindows.c, which has all 
 the OpenGL calls to render the windows, controls, handle clicks, push 
 buttons, call event handlers - everything.  It's not as nice as I 
 would've liked it to be, but it definitely got the job done for my 
 purposes (a map editor which was really quite impressive).
 
 It sports a very rudimentary set of controls: button, label, panel, 
 checkbox, radiobutton, and window.  It is all mouse-driven, no keyboard 
 event handler yet since there isn't any control which requires keyboard 
 input.  I meant to add a textbox control in order to get basic keyboard 
 support in...  Also, the code is not dependent on any API for mouse 
 events - there is an 'OnMouseDown' function and an 'OnMouseUp' function 
 which should be called when the mouse click goes down and when the mouse 
 click is released, respectively.
 
 The glwindows.h header declares three extern variables which must be 
 defined: 'GUITexture', 'Window', and 'Mouse'.
 
 The 'GUITexture' is simply a GLUint which is a texture handle generated 
 from glTexImage2D and the like.  Gen some textures, load em up, and set 
 that ID.
 
 The 'Mouse' is a simple struct defining X and Y coords for the mouse 
 cursor and the button status.  These fields are to be set by the host 
 application whenever the appropriate mouse move and click events are 
 received.
 
 The code is attached with most of the supporting files.  I'll see what I 
 can do in the mean time about porting it to D; it doesn't look that hard.
 
 P.S. - it's "skinnable" in that you can load up different textures to 
 define how the controls and windows appear (see GUIwood.tga vs. 
 GUIstone.tga).  Hope this helps.
 
 P.P.S. - the image files will be attached in a reply-to post.


As promised, the related image files.
Dec 14 2005
parent Chad J <gamerchad2.no-ip.org/email.txt LeftOfAtSignForEmail.meh> writes:
James Dunne wrote:

 James Dunne wrote:
 

 Check out this C version of something close to what you're looking 
 for.  The code is almost guaranteed not to compile as-is, but it is 
 valid code taken straight from a project of mine.  I can provide you 
 the entire project (I've been meaning to release it open-source 
 anyway) soon if you're interested.

 The main stuff you'll want to check out is in glwindows.c, which has 
 all the OpenGL calls to render the windows, controls, handle clicks, 
 push buttons, call event handlers - everything.  It's not as nice as I 
 would've liked it to be, but it definitely got the job done for my 
 purposes (a map editor which was really quite impressive).

 It sports a very rudimentary set of controls: button, label, panel, 
 checkbox, radiobutton, and window.  It is all mouse-driven, no 
 keyboard event handler yet since there isn't any control which 
 requires keyboard input.  I meant to add a textbox control in order to 
 get basic keyboard support in...  Also, the code is not dependent on 
 any API for mouse events - there is an 'OnMouseDown' function and an 
 'OnMouseUp' function which should be called when the mouse click goes 
 down and when the mouse click is released, respectively.

 The glwindows.h header declares three extern variables which must be 
 defined: 'GUITexture', 'Window', and 'Mouse'.

 The 'GUITexture' is simply a GLUint which is a texture handle 
 generated from glTexImage2D and the like.  Gen some textures, load em 
 up, and set that ID.

 The 'Mouse' is a simple struct defining X and Y coords for the mouse 
 cursor and the button status.  These fields are to be set by the host 
 application whenever the appropriate mouse move and click events are 
 received.

 The code is attached with most of the supporting files.  I'll see what 
 I can do in the mean time about porting it to D; it doesn't look that 
 hard.

 P.S. - it's "skinnable" in that you can load up different textures to 
 define how the controls and windows appear (see GUIwood.tga vs. 
 GUIstone.tga).  Hope this helps.

 P.P.S. - the image files will be attached in a reply-to post.


 
 As promised, the related image files.


Cool thanks.  Keep me posted on how the C -> D conversion goes.
Dec 15 2005
prev sibling next sibling parent reply Sebastian Beschke <s.beschke gmx.de> writes:
Of course, there is derelict providing bindings to the famous SDL 
libraries.  Since they lack GUI functions (although there are GUI libs 
for SDL that you might create bindings for) it probably isn't what you want.

-Sebastian

Chad J schrieb:


 or anything else.  That said, I will need a GUI toolkit for any game I want to
 make in D.  It has to use OpenGL, unless someone can tell me how to make OpenGL
 and some other GUI lib using a different renderer work in harmony in the same
 app, on the same window.  So far I have been unable to find any GUI libs that
 will work with both D and OpenGL, and I was wondering if one is available or in
 the works.  
 
 If there isn't a good OpenGL GUI around that works in D, I am probably going to
 code one myself.  I've decided that it would probably be easier to just port
 some C++ code from one of the OpenGL GUI libraries rather than do it from
 scratch.  One I am particularly interested in is CEGUI, or Crazy Eddie's GUI
 System (http://www.cegui.org.uk/modules/news/).  So far I like it.  It is
 skinnable, uses XML for said skinning, seems straightforward enough, and is
used
 in games.  One thing caught my attention though: CEGUI can use different
 renderers to display the GUI.  It made me start to think, why not have a GUI
 that can use any renderer or basic API?  I get the feeling that most of the
code
 in a GUI library deals with its behavior, accepting inputs, and deciding where
 to draw images, and only a small fraction is dedicated to actually rendering
the
 images.  I'm thinking it might be possible to make a layer that would work
 between the GUI and the renderer, and allow people to write modules for the GUI
 system that tell it how to handle rendering.  That way all of the GUI code
would
 be reused, and people who want a different API/renderer would just need to tell
 the GUI system how to draw an image to the screen.  Another problem I see with
 GUI lib reliance on APIs is input.  CEGUI handled that by having the coder
 inject mouse/keyboard events into it.  Such a library could have little or no
 reliance on any API, native or otherwise.  Please correct me if I'm wrong, or
 let me know if this sort of thing is happening already.  
 
 One last thing - I am unable to find a "search" option on this forum/newsgroup.
 Is there an easier way to look for things besides looking through the forum one
 page at a time?
Dec 15 2005
parent Chad J <gamerchad2.no-ip.org/email.txt LeftOfAtSignForEmail.meh> writes:
Sebastian Beschke wrote:

 Of course, there is derelict providing bindings to the famous SDL 
 libraries.  Since they lack GUI functions (although there are GUI libs 
 for SDL that you might create bindings for) it probably isn't what you 
 want.


I am actually using derelict.  It is great, has a lot of good bindings 
in one spot.  So yeah, I pretty much have my API/renderer (SDL/OpenGL) 
chosen already and am looking for a GUI lib that will work with that.
Dec 15 2005
prev sibling parent Chris Lajoie <ctlajoie yahoo.com> writes:
 If there isn't a good OpenGL GUI around that works in D, I am probably
 going to code one myself.  I've decided that it would probably be
 easier to just port some C++ code from one of the OpenGL GUI libraries
 rather than do it from scratch.  One I am particularly interested in
 is CEGUI, or Crazy Eddie's GUI System
 ...


http://www.asahi-net.or.jp/~cs8k-cyu/index_e.html
there are 5 games on this site coded in D, and they all come with full source 
code. He uses and SDL library ported to D. The game Gunroar compiles easily 
with the latest version of dmd, but the other games used older versions of 
the compiler and don't compile without changing the code a little bit. 

I don't know the legality of using this code, you probably need to contact 
the guy who wrote them.

P.S. Tumiki Fighters is fun ;)

Chris
Dec 15 2005