Re: [gluon] GluonGraphics and physics

[idk <istdasklar@xxxxxxxxx>]

About Engine, Imagine you want to create a 2d games with a 2d map. Imagine the nintendo DS with 2 screen. Then I imagine gameEngine and mapEngine. But maybe I m wrong...

Purpose for physics class usable as component in Gluon Creator:

GluonPhysics::Body

GluonPhysics::World

But I don't understand how a developpers will use physics in a qt only application. 

Currently it's very simple :

KGLPhysicsItem * item;

KGLPhysicsEngine->add(item)..

So what do you suggest now if you would like to have physics engine separated from gluonGraphics?

About the renaming , this is my purpose for common class: 

GluonGraphics

KGLPoint -> GluonGraphics::Vertex

KGLPointList -> GluonGraphics::VertexList

KGLPainter->GluonGraphics::GLPainter   // Or only Painter

KGLWidget -> GluonGraphics::GLWidget  // or only Widget

KGLBaseItem->GluonGraphics::BaseItem

KGLItem->GluonGraphics::Item

KGLProgram->GluonGraphics::Program // will be replaced by QGLProgram

KGLShader->GluonGraphics::Shader // will be replaced by QGLShader

KGLFx->GluonGraphics::Fx

KGLEngine->GluonGraphics::Engine

KGLTexture->GluonGraphics::Texture

{too many class?

GluonGraphics::Resolution

GluonGraphics::Screen

GluonGraphics::Display

}

extra class: 

GluonGraphics::LineItem

GluonGraphics::RectItem

GluonGraphics::CircleItem

GluonGraphics::PolygonItem

GluonGraphics::PixmapItem

GluonGraphics::ShadowItem

GluonGraphics::AnimationItem

GluonGraphics::VertexGridItem

GluonGraphics::ParticlesItem

PhysicsItem ??

extra widget :

GluonGraphics::SettingsWidget

GluonAudio:

KALBuffer -> GluonAudio::Buffer

new : GluonAudio::Source wrap of alSource

KALSound->GluonAudio::Sound

KALDevice->GluonAudio::Device

KALMusic->GluonAudio::Music

KALCapture->GluonAudio::Capture

KALEngine->GluonAudio::Init

KALSoundReader->GluonAudio::SoundReader

extra widget :

GluonAudio::SettingsWidget

GluonAudio::PlayerWidget

GluonInput:

GluonInput::DetectAbstract {GluonInput::DetectWin, GluonInput::DetectLinux, GluonInput::DetectMac}

GluonInput::Input {GluonInput::InputWin,GluonInput::InputLinux,GluonInput::InputMac}

KCLCode -> GluonInput::KeyCode

KCLCustomInput -> GluonInput::CustomInput

GluonInput::Keyboard

GluonInput::Mouse

GluonInput::Joystick

GluonInput::Tablet

GluonInput::Acelerometer for maemo

extra widget:

GluonInput::SettingsWidget

GluonInput::DeviceListWidget

GluonInput::InputButton

So, I invite everybody to help us in gluon qt only renaming : http://gitorious.org/gluon/gluon_qt4-6/

2010/1/10 Arjen-Wander Hiemstra <djfreestyler@xxxxxxxxx>

On Sunday 10 January 2010 04:43:06 idk wrote:
> So, what do you plan for physics api ?
>

The plan was to have it component-based only. I think we may still need some
glue-code but that is something to look into for whoever will work on the
components.

> So, I have done some work on gluon qt only. Currently we have some class
> like :
>

> GluonGraphics::GLWidget , and GluonGraphics::Engine

>
> It works like this :
>
> GluonGraphics::Item * item ...
> engine->addItem(item);
> view->setEngine(engine);
>

Hmm, no offense, but why?

If Engine is a singleton (like we discussed on the meeting) then you can
remove the last two lines as both Item and Widget, because those can be
handled internally.

So instead of:

GluonGraphics::Item * item ...
engine->addItem(item);

You get:

GluonGraphics::Item *item

Item::Item() // Item ctor
{
       ... init code ...
       Engine::instance()->addItem(this);
}

Making the actual usage API cleaner.

Also, might it be an idea to remove the "GL" from GLWidget"? Library users
really shouldn't care too much about such implementation details.

> So, now how do you want to use physics ? Would you like to give me a shema
> about it ?

Basically, we need some components like PhysicsBodyComponent,
CircleCollisionComponent and others.

---
+----------------------------------------------+
Gluon is a high-level game development library for the KDE desktop enviornment.
http://gluon.tuxfamily.org/
http://gitorious.org/gluon