SEAL Forum Index SEAL
The SEAL Forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Graphics API planning
Goto page 1, 2, 3  Next
 
Post new topic   Reply to topic    SEAL Forum Index -> Seal 3.0 Development
View previous topic :: View next topic  
Author Message
orudge
Administrator


Joined: 07 Oct 2001
Posts: 1332
Location: United Kingdom

PostPosted: Thu Jun 13, 2002 12:53 pm    Post subject: Graphics API planning Reply with quote

This thread is for planning the graphics API - both the high-level API and the low-level API. Text drawing, etc, is included in the graphics API. You may want to base the API on the Allegro functions, perhaps.
_________________
Owen Rudge
http://www.owenrudge.net/

Currently Playing (last time I was online, anyway):
Back to top
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger
WinstonEwert



Joined: 11 Jun 2002
Posts: 27
Location: Bug Land

PostPosted: Mon Jun 17, 2002 8:38 pm    Post subject: Reply with quote

I guess we want to do something like this:

Allegro/Hand Made Driver
Seal Standard Gfx System
Gfx api available to programs (same as above?)
Allegro to std gfx (make it easier to port allegro progs.
Back to top
View user's profile Send private message
_xduffy_
Administrator


Joined: 15 Mar 2002
Posts: 894
Location: Sweden

PostPosted: Sat Jun 29, 2002 3:50 am    Post subject: Reply with quote

Ok. Since we gonna be portable beyond allegro we have to define our own bitmap and stuff, right?

I think we should mimic allegro behaviour... but not too much... it should be fairly easy to use some other graphics lib too...

Maybe use allegro code and transform into C++?
_________________
http://xduffystuff.sourceforge.net/Desktop/
www.xduffy.com
Back to top
View user's profile Send private message Send e-mail Visit poster's website MSN Messenger
llogiq



Joined: 05 Jul 2002
Posts: 52
Location: Germany

PostPosted: Mon Jul 08, 2002 5:28 am    Post subject: Loose coupling Reply with quote

I gather the plan is to decouple SEAL from Allegro. Good. Why not decouple it even further? To make iSEAL as portable as possible, the layer approach should not end at the drawing functions. What if someone has an embedded device with a laser-light-show style display? Or what if I want my cool SEAL apps through telnet (Yeah, aalib is my friend... )

It's in the intermediate layer, which sits between the low-level-gfx and the gfx API. And I think this layer is also affected by skinning. Or should be.

Therefore I propose the following layers:
Application
SEAL logical UI API
Skinning engine
SEAL high-level gfx API
SEAL physical gfx engine (which will wrap the low level gfx)
low level gfx (Allegro or whatever)

Where each layer only sees the next/previous. Actual implementations are bold, the rest are interfaces.

Non-SEAL-apps can use other methods, but will not be skinnable this way. An Allegro layer that allows Allegro apps to run in window mode would be awesome, but is not a neccessity.
Back to top
View user's profile Send private message
_xduffy_
Administrator


Joined: 15 Mar 2002
Posts: 894
Location: Sweden

PostPosted: Mon Jul 08, 2002 7:05 am    Post subject: Reply with quote

Im not sure I follow you right now... Could you give any example?`
(I lag badly in sleep right now)
_________________
http://xduffystuff.sourceforge.net/Desktop/
www.xduffy.com
Back to top
View user's profile Send private message Send e-mail Visit poster's website MSN Messenger
llogiq



Joined: 05 Jul 2002
Posts: 52
Location: Germany

PostPosted: Mon Jul 08, 2002 1:19 pm    Post subject: Example? Lemme try... Reply with quote

_xduffy_ wrote:
Im not sure I follow you right now... Could you give any example?`
(I lag badly in sleep right now)

Who doesn't? Anyway, lemme try:

Application wants to draw a menu:
Code:
SEALlogicDrawMenu(menu)

Skinning engine does the layout etc.
Code:
SEALgfxDrawLine(...); SEALgfxDrawLine(...); // etc.
SEALgfxDrawText(menu->textEntry[0]); // ...

Physical gfx engine does the drawing
Code:
PutPixel(...); //...

which is in turn translated to an Allegro call or whatever.

I hope this code fragments make my ideas clearer. If not, feel free to ask
Back to top
View user's profile Send private message
_xduffy_
Administrator


Joined: 15 Mar 2002
Posts: 894
Location: Sweden

PostPosted: Tue Jul 09, 2002 10:56 am    Post subject: Reply with quote

Well I actually thought about what you said earlier and got to the same conclusion as the one you just presented here

I agree totally... in that way we can make Seal run on just about anything Even our old Volvo Mr Green
_________________
http://xduffystuff.sourceforge.net/Desktop/
www.xduffy.com
Back to top
View user's profile Send private message Send e-mail Visit poster's website MSN Messenger
llogiq



Joined: 05 Jul 2002
Posts: 52
Location: Germany

PostPosted: Tue Jul 09, 2002 12:20 pm    Post subject: Decouple structure (logic) from behaviour (view) Reply with quote

We should plan the APIs by looking at existing ideas. First, we agree that we have a tree-like structure. So we can use a lot of research that has gone into the Document Object Model which in fact represents a modifiable tree of lists (of trees of... - you get the idea). We do not want to go as far as mozilla - at least if we don't plan to create the ultimate performance hog .
Interfaces should have a lean core (which is everything that has to be implemented in the next layer) and a clean grouping of specialized functions (which can rely on the core functions and are therefore perfectly portable).
Back to top
View user's profile Send private message
WinstonEwert



Joined: 11 Jun 2002
Posts: 27
Location: Bug Land

PostPosted: Thu Jul 11, 2002 8:00 am    Post subject: Reply with quote

how about:
class GfxBitmap
{
public:
// whatever
};
class GfxMode
{
public:
GfxBitmap * get_bitmap() = 0; // Abstract
};

Class AllegroGfxMode : public GfxMode
{
// implements above stuff
}

Class AllegroGfxBitmap : pulic GfxBitmap
{
}
Back to top
View user's profile Send private message
llogiq



Joined: 05 Jul 2002
Posts: 52
Location: Germany

PostPosted: Thu Jul 11, 2002 8:16 am    Post subject: Reply with quote

That's roughly the idea. The GfxBitmap would be one low-level interface which could be implemented by using Allegro. If you like it, you can build your way up to an interface that suits the skin designers (and would consist of things like Draw(Horizontal/Vertical)Line, ShadeRect, and your BitMap.draw() function)

Let's say I come from the top with a logic interface, for example
Code:
class ScrollBar {
 void draw(Rectangle where) = 0;
 void onClick(Point cursor) = 0;
 void onDrag(Point from, Point cursor) = 0;
 // ...
}

and you come from the bottom. When we both design sanely, the skinning ppl will have little to do to bridge the gap between us. And we don't want them to overwork, do we?
Back to top
View user's profile Send private message
_xduffy_
Administrator


Joined: 15 Mar 2002
Posts: 894
Location: Sweden

PostPosted: Thu Jul 11, 2002 2:38 pm    Post subject: Reply with quote

I thought about something like this...

Code:

class cGObject:public cObject
{
  protected: 
    int x, y, width, height;
    int visible;
    const char *Title;
  public:
    cGObject();
    cGObject(int x, int y, int width, int height, int visible);

    int getWidth();
    void setWidth(int w);
    int getHeight();
    void setHeight(int h);

    int getXPos();
    int getYPos();
    void setPosition(int x, int y);

    void setTitle(const char *Title);
    const char *getTitle();

    void Show();
    void Hide();
    int IsVisible();
    void bringtoTop();

    virtual int NeedUpdate()=0;
    virtual BITMAP* Render()=0;
};

_________________
http://xduffystuff.sourceforge.net/Desktop/
www.xduffy.com
Back to top
View user's profile Send private message Send e-mail Visit poster's website MSN Messenger
llogiq



Joined: 05 Jul 2002
Posts: 52
Location: Germany

PostPosted: Fri Jul 12, 2002 2:14 am    Post subject: Let me have a look at your code line by line: Reply with quote

First, I tried to infer from the code what CGObject *should* do, but remain puzzled.

1. Your CGObject is rectangular. What about arbitrary-shaped objects? (You are right about most of our objects being rectangular, but that doesn't mean they have to be.).
2. Why should each and every CGObject have a title???
3. You have read an OO book and followed the advice of always encapsuling your data - even if it's read/write anyway. I must admit that we can use the write methods to constrain the values or propagate the change. The getters however can be refactored out by making all members public after making sure everyone uses the setters instead of writing directly. Yep, that's not good OO design, but it saves RAM and thus time.
4. Does an CGObject need to know of its visibility? Why?

Where does the CGObject belong, in the low gfx layer or the high-level-logic-layer? Or should it be used in both?

Whew, a whole lotta questions...
Back to top
View user's profile Send private message
_xduffy_
Administrator


Joined: 15 Mar 2002
Posts: 894
Location: Sweden

PostPosted: Sat Jul 13, 2002 2:57 pm    Post subject: Reply with quote

*lol* sorry about any inconvinence (whatever) I may have given you

You're questions are in place...

This code was a try to give something to think about...

The code i submitet comes from a gui I wrote in school for a project, and it wasnt necessarly the best solutions, and the code you actually can see is somewhat modified when I was halv-sleep halv-awake...

I apologize
_________________
http://xduffystuff.sourceforge.net/Desktop/
www.xduffy.com
Back to top
View user's profile Send private message Send e-mail Visit poster's website MSN Messenger
_xduffy_
Administrator


Joined: 15 Mar 2002
Posts: 894
Location: Sweden

PostPosted: Sat Jul 13, 2002 3:45 pm    Post subject: Reply with quote

well I was so ashamed over my initial class post so I sat down and wrote this:

Code:

class stkPoint
{
   public:
   int x, y;
   stkPoint();
   stkPoint(int x, int y);
   virtual void Render();
};

class stkRect:stkPoint
{
   public:
   int widht, height;
   stkRect();
   stkRect(int x, int y, int width, int height);
   virtual void Render();
};

class stkCircle:stkPoint
{
   public:
   int radius;
   stkCircle();
   stkCircle(int x, int y, int radius);
   virtual void Render();
};

class stkPolygon:stkPoint
{
   public:
   sdkList *xList, *yList;
   stkPolygon();
   stkPolygon(int x1, int y1, int x2, int y2, ...);
   virtual void Render();
};

_________________
http://xduffystuff.sourceforge.net/Desktop/
www.xduffy.com
Back to top
View user's profile Send private message Send e-mail Visit poster's website MSN Messenger
_xduffy_
Administrator


Joined: 15 Mar 2002
Posts: 894
Location: Sweden

PostPosted: Sun Jul 14, 2002 2:29 pm    Post subject: Reply with quote

Well I have been rethinking the idea of yours about not having methods for manipulation of the properties of the object. And I think you are fundamentally wrong about it... The cost for the processor is not big but the debugging gain is huge... I am sure you know all that... Seal is not famous for it's clean interface (sorry, but that's the truth) Many of the people that are apps developers that are eager to write things the day Seal 3 ships are mostly (or at least many of them are) newbies and people that are learning things... I know that's not the only good argument... But look at Beos... Beos's written in C++ and use methods for manipulation of objects... that's the safest way when we go with threads... The object needs the possiblity to get locked... why? Because in a multithreading system it can be really painfull for the system if you do not lock the object during some operations... Quite obvious really...

Code:

class stkPoint
{
   protected:
      int x, y;
   public:

      int setPosition(int x, int y);
      int getPosition(int &x, int &y);
     
      stkPoint();
      stkPoint(int x, int y);
      virtual void Render();
};

class stkRect:stkPoint
{
   protected:
   int widht, height;
   public:

      int setArea(int width, int height);
      int getArea(int &width, int &height);

   stkRect();
   stkRect(int x, int y, int width, int height);

};

class stkCircle:stkPoint
{
   protected:
      int radius;
   public:

      bool setArea(int radius);
      bool getArea(int &radius);

   stkCircle();
   stkCircle(int x, int y, int radius);
};

class stkPolygon:stkPoint
{
   protected:
      sdkList *xList, *yList;
   public:

      bool setPolygon(sdkList *xList, sdkList *yList);
      bool getPolygon(sdkList *xList, sdkList *yList);

   stkPolygon();
   stkPolygon(sdkList *xList, sdkList *yList);
};

_________________
http://xduffystuff.sourceforge.net/Desktop/
www.xduffy.com
Back to top
View user's profile Send private message Send e-mail Visit poster's website MSN Messenger
Display posts from previous:   
Post new topic   Reply to topic    SEAL Forum Index -> Seal 3.0 Development All times are GMT - 7 Hours
Goto page 1, 2, 3  Next
Page 1 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group