Pandora This Could Run On Your Pandora

[otaco]

"gloost is an open source, plattform independent set of classes for openGL demo programming. It contains well documented wrappers like Texture, Shader, FBO, Matrix, Vector, a.s.o. . gloost comes with codeblocks projects and makefiles for linux and win."

I compiled the gloost examples for windows with a window size of 800x480. Most of the stuff (with some optimisations) should run on pandora. Most of the demos are using Shader 3.0 and glut or SDL. A openGL|ES port or extension of gloost should be simple and is planed.

Sorry for the incomplete stardust demo. I just started it this afternoon and the ship is not rotating properly... I added it anyway because it should be one of the interesting ones for Pandora Gamer . There will be an update soon.

Checkout gloost at berlios.de to get involved ...

See some screenshots here...

Download: gloos demos, compiled for win32 (12 MB)* (Updated on 27.05.08)

*You need at least a gfx card with Shader 3.0!
-> ATI Radeon 1000 Series or higher
-> NVIDIA GForce 6600 orhigher

 

[icurafu]

Sounds very cool!

The shadow map one looks the best.

 

[Lineus]

**jaw hits the floor**
How come nobody has mentioned this yet?!

Well, that'll put the skeptics to rest.

 

[ldesnogu]

Well, that'll put the skeptics to rest.

What skeptics? This is an OpenGL demo library, and so needs porting, so you must be talking about something else than Pandora

 

[atomicthumbs]

I think your rar's MIME type is messed up: it's showing it as plaintext in my browser.

Edit:

Here:

http://bunnitude.com/misc/files/gloost_dem...in32_080526.rar

 

[otaco]

QUOTE
This is an OpenGL demo library...


Oh its not. Its a framework, build around openGL (and SDL) for fast demo and game programming. And it is really fast and easy to develop something with it. The volume rendering demo was written by steppobeck and me in about 3 houres. The worm was made in 1/2 h and the shadowmap and particles demo took about 4 h.

You can add shadowmapping within every of your gloost application with about 10 lines and GLSL shader functionality with about 5 lines ...

It is really easy to compile gloost on linux and windows. On windows you just have to checkout gloost from the cvs and open the examples workspace in your codeblocks.

Here are the explanations from the included README.TXT to give you an idea:


03. How to start


Getting started with gloost is as easy as it can gets. For Windows we provide project files for the popular Codeblocks IDE and all necessary libs with headers and binaries. For Linux there are makefiles to build the lib and all demos at ones. Just read the following chapters (03.1 for windows, 03.2 for Linux) to learn more.


///////////////////////////////////////////////////////////////////////////////


03.1 How to start with windows


On windows, you need the newest version of the free Codeblocks IDE from

http://www.codeblocks.org/

with a mingw environment. All required libs and headers are included within gloost and can be found in gloost/win32/contrib. This package includes SDL, SDL_image, libJpeg, libPng, tinyXML, glut, glu, glaux, glext, wglew, glew, wglext, ... . With these and Codeblocks, gloost should compile out of the box. If not, let me know (thesleeper@gmx.net).

To run the demos, just go the examples folder located in gloost/tutorials/examples and open the examples.workspace with Codeblocks. Compile and run the demos on by one. The binaries will be created in gloost/win32/bin, where hopefully all necessary *.dll file are located too.


///////////////////////////////////////////////////////////////////////////////


03.2 How to start with linux


gloost currently depends on OpenGL, GLEW, GLUT, SDL and SDL_image.
In order to start with gloost you should verify that your linux box matches these dependencies by locating the following files:

On your bash you should "find" the following libraries:
$ locate libGL.so libGLU.so libglut.so libGLEW.so libSDL.so libSDL_image.so

...and the corresponding headers:
$ locate gl.h glu.h glew.h glut.h SDL.h SDL_image.h

If you are lucky just go to the directory linux/bin and make all examples:
$ cd linux/bin && make

You will find all demos within the bin folder you are in now. Run them with like this:
$./stardust_demo

Have a lot of fun

 

[PoisonedV]

I just might have to play around with this. Looks amazing.

 

[otaco]

I updated the stardust demo:

Download: gloos demos, compiled for win32 (12 MB)* (Updated on 27.05.08)

 

[Sdw]

How does the functionality/fillrate/etc. of these demos compare to what we know the Pandora will be capable of? If it can run stuff like this at a reasonable framerate, it would be really nice!

 

[otaco]

On the the functionality side there is not muche of a difference between openGL/c++/SDL to pandoras openGL|ES/c++/SDL. openGL|ES seems to be a subset of the openGL without fixed function pipeline.

Fillrate depends mostly of the complexity of the shader. Shadowmapping is a good example for this because you need additionally to your normal shader the shadowmap transformation plus a texture lookup. Will see how the PowerVR handle the shaders.

I have no experience with openGL|ES but I cross reed the GL|ES and GL|ES shading language spec. I can't say anything about the speed right now but the stuff you saw in the demos should run.

Hand me over a dev unit please

 

[PoisonedV]

There IS a stickied thread up there. Although, I think they are only looking for already established GP2X devs within the community. Not sure though.

 

[yosh64]

hey

Oh its not. Its a framework, build around openGL (and SDL) for fast demo and game programming.

A framework? I took a look at the code the other day, and the demos or whatever directly used OpenGL, so how can you call this a framework?

Anyhows maybe I'm missing something?

edit
I mean if you went to port these onto a different platform that used a different rendering API then you would have to rewrite the code for every demo, rather than just update the framework.

cyas

 

[Prophet]

There IS a stickied thread up there. Although, I think they are only looking for already established GP2X devs within the community. Not sure though.

Not necessarily.

I'm pretty sure Craig would consider anyone with something useful to offer. Afterall, we can always use MORE good developers!

 

[yosh64]

hey

Just me again...

Anyhows I took another quick look at ya code, and I wonder why ya use Display lists for models?

I thinks ya should use Vertex Arrays or Vertex Buffer Objects at least .

But yea, ya seem to have a nice collection of classes, but I'd rather use my own .

edit
I was wondering what technique ya used for ya shadow mapping? well haven't seen the demo yet. Anyhows from what I know shadow mapping can be very tricky for use in games, alot of issues with graphical artifacts and bad AA in certain situations or when the camera is in extreme positions relative to the object casting the shadow, but I dunno. Well I've yet to use shadow mapping, but I've looked into it a bit and the best technique I know of is the Parallel Split Shadow Maps, but I think games today use a combination of several different techniques.

another edit
Another thing is because you also directly use opengl in your classes (I mean classes that depend on a rendering API) you would have to rewrite a specific copy of all your classes if you wanted to add support for another rendering API , this is somewhat like my old lib. My newer lib that I'm currently working on takes things a step further in which I have a renderer base class, and so you can derive a specific renderer class for each rendering API you would like to support .

and another
I just wanted to mention that I don't mean to say you should rewrite your lib or whatever, I'm sure lots of folks would find it very handy . I mean, if you ever wanted to make any major changes to the design I think you should start a new project, and keep this lib going separetly, as it still would be quite handy to folks.

and antoher...
Hehe, took another look... it's darn cool how you made a raytracer on the GPU, I really gotta check that out . Also, I think you just use regular shadow mapping? but for point light? do you render depth maps for each direction for point lights? might have to check ya shader code.

BTW, ya should add support for normal mapping, and also parallax and relief bump mapping . Ya know parallax is quite easy to implement once ya got normal mapping, and relief mapping isn't much harder also. There are some nice examples at http://www.codesampler.com (the ones I'm talking about might be in the user section, not exactly sure). The thing with most of these bump mapping examples is that they don't show ya how to actually calc the tangents/bitangents for ya verts, but maybe ya already know how todo this.

cyas

 

[yosh64]

hey

Made so many edits I thought I might make another post, hehe.

Anyhows maybe you meant it's a framework for "fast demo and game programming"? if you can say such a thing, hehe.

But yea, usually I think you build a framework that is independent from other things. I mean, although SDL and OpenGL is supported on alot of platforms (I'm not sure where OpenGL ES fits into things here), you don't have the option to use something else instead of SDL or OpenGL. So if someone wanted to make a specialised framework using the Win32 API then they couldn't, or they wanted to use Direct3D, or a software rasterizer or raytracer then again they couldn't, well not without alot of work, hehe.

Anyhows I still think it's pretty cool and if ya want to learn graphics programming then ya better off using these than some big engine, so I thinks anyhows.

cyas

 

[otaco]

@yosh64

Thanks for so many replies, here are some answers/comments:

I don't know what you understand under the word "framework" but I and wikipedia mean this:

"A software framework is a re-usable design for a software system (or subsystem). A software framework may include support programs, code libraries, a scripting language, or other software to help develop and glue together the different components of a software project. Various parts of the framework may be exposed through an API." http://en.wikipedia.org/wiki/Framework
I think what you mean is (game-)"engine".



QUOTE
Anyhows I took another quick look at ya code, and I wonder why ya use Display lists for models?
I thinks ya should use Vertex Arrays or Vertex Buffer Objects at least


Your are right! But gloost is very new and many (I mean many many) stuff Is on the to-do-list. To feature VBO or Vertex Arrays I first have to separate the OBJ functionality from the geometry so the geometry is just a container. I have other priorities at the moment, but hey, its open source so just do it yourselfe and send a Mail


QUOTE
Another thing is because you also directly use opengl in your classes (I mean classes that depend on a rendering API) you would have to rewrite a specific copy of all your classes if you wanted to add support for another rendering API


We don't want to. openGL is fine for most of the tasks and is available on all mayor platforms (MAC, LINUX, WIN ) and gloost compiles on all of them (We don't have a Mac Developer at the moment to manage the OSX tree) (PANDORA will be supported shortly after if I get one). gloost is not a "engine" its just a collection of classes that makes your life a bit easier.

QUOTE
BTW, ya should add support for normal mapping, and also parallax and relief bump mapping smile.gif. Ya know parallax is quite easy to implement once ya got normal mapping, and relief mapping isn't much harder also.


We do not support special shader techniques we just support shaders. If you want to have a special shader, write it yourselfe. To get your uniforms to your shader, you can create and configure yourselfe a gloost::UniformSet. The shaders in the shader folder are just examples, not the stuff we support.

I have a nice tangent space normal mapping shader I will add along with a nice example. The Obj::drawTangent() methode provides the tangent information in the rgb values of the diffuse color of the vertices... (this a the strange color of the ship you see in the stardust demo)


QUOTE
... you don't have the option to use something else instead of SDL or OpenGL. So if someone wanted to make a specialised framework using the Win32 API then they couldn't, or they wanted to use Direct3D, or a software rasterizer or raytracer then again they couldn't, well not without alot of work, hehe.


We don't want to use Win32 API or Direct3D or other of Microsoft proprietary stuff, EVER! The stuff we do has always be portable because I use Windows and Ubuntu and steppobeck is using Fedora. I also have no intention to provide VisualStudio projects along with gloost, just because its not open. And again: it is no game engine of some sort, its a framework.


After reading your comments and questions I understand that I really have to setup the gloost homepage with lots of documentation, so people can understand what gloost is. What use has the coolest open source project if nobody knows what it is or how to use it.