Welcome, Guest. Please login or register.

Author Topic: GLFW (OpenGL toolkit) port for AmigaOS  (Read 14766 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline marcus256Topic starter

  • Newbie
  • *
  • Join Date: May 2003
  • Posts: 17
    • Show only replies by marcus256
    • http://glfw.sourceforge.net/
GLFW (OpenGL toolkit) port for AmigaOS
« on: May 12, 2003, 10:17:52 PM »
Hi everybody!

I'm new here, but I thought it's the best place to drop this info and get some feedback...

Anyway, I'm the developer of a portable OpenGL framework (or toolkit, if you like), called GLFW. It started out under Windows, and quickly got ported to Unix/X11. Now, when the API & code has matured a bit I thought it was apropriate to do an AmigaOS port too (after all, I'm an old AmigaOS fan!).

My problem is that I'm a bit rusty, so I would very much like to get some help with some things. Also, I'm conducting all development under WinUAE (since my A3000 does not fit in my tiny computer cabinet, unfortunately), so 68k only and no HW OpenGL support - speed is tremendous though (like 200-300 MHz '040).

Primarily I'm looking for some testers/users that are intererested in using and possibly aiding in the development of GLFW.

Short intro...

GLFW = OpenGL FrameWork

Window management (normal/fullscreen), keyboard/mouse/joystick input, timer (high precision - microsecond class), multi threading support, texture file loading support (TGA).

Of course, everything is 100% portable. Some of the supported OS:es are: Windows 9x/NT/2k/XP, Linux, IRIX, Solaris, QNX, Mac OS X and AmigaOS.

URL = http://glfw.sourceforge.net/

I'm especially interested in AmigaOS 4.0 / MorphOS compability, and support for different GL/Mesa implementations (I currently use StormMesa).
 

Offline JoannaK

  • Hero Member
  • *****
  • Join Date: Dec 2002
  • Posts: 757
    • Show only replies by JoannaK
Re: GLFW port for AmigaOS
« Reply #1 on: May 13, 2003, 02:03:52 AM »
I'm not much of  a coder, but I'm sure there will be increased need for this kind of libraries as soon as these OS:s have their 3D support nicely up and running.

 

Offline Billsey

  • Hero Member
  • *****
  • Join Date: Feb 2002
  • Posts: 1311
    • Show only replies by Billsey
    • http://billsey.christian.net
Re: GLFW port for AmigaOS
« Reply #2 on: May 13, 2003, 02:16:41 AM »
Welcome to the asylum, marcus! :-D

Have you thought about supporting AmigaOS4 and/or MorphOS? They both involve new machines.
\\"The chief tormentor of the damned will be the conscience and it will not be misinformed, and it will not be silenced.\\"     John MacArthur
Salvation is by grace alone through faith alone in Christ alone
\\"I am not ashamed of the Gospel, because it is the
 

Offline Karlos

  • Sockologist
  • Global Moderator
  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 16867
  • Country: gb
  • Thanked: 4 times
    • Show only replies by Karlos
Re: GLFW port for AmigaOS
« Reply #3 on: May 13, 2003, 03:13:59 AM »
Hi there,

I have something that might interest you. I have written a C++ based portability layer (still in development) that encapsulates many things useful for your project

1) Applet based startup (your application is a class and you don't need to define main() anymore). It gets instansiated once all the critical OS initialisation is done.
You can inherit components of the portability system that way (or use a compositional design pattern if you prefer).

2) High performance memory class

3) Abstract input handling - you inherit InputFocus and override only those virtual functions you require as input handlers.

4) Kernel service classes, eg: Thread class, Lockable class, Timers, MilliClock etc.

5) Graphics abstraction layer - Colour, Surface, Display, Rasterizer (using Warp3D), and other classes such as input focus to get input back from a display etc. as well as standard subclasses, eg Window, Screen etc..

6) Audio classes (fell a bit behind there).

For example, if you wanted to write an application that uses a double buffered screen (with input handling)

class MyApplication : private AppBase, FullscreenDB {

};

Does 90% of the work for you :-)

The project is aimed at supporting a lot of platforms though the Amiga68K version is the one most in deveopment just now.

If youre interested, drop me an email...

-edit-

Oh, and the whole thing uses pretty lightweight interfaces because I designed it for multimedia / gaming rather than building in tons of excess bloat in the event some of it might be useful :-)

int p; // A
 

Offline marcus256Topic starter

  • Newbie
  • *
  • Join Date: May 2003
  • Posts: 17
    • Show only replies by marcus256
    • http://glfw.sourceforge.net/
Re: GLFW port for AmigaOS
« Reply #4 on: May 13, 2003, 08:11:38 AM »
> Have you thought about supporting AmigaOS4
> and/or MorphOS? They both involve new machines.

Yes, of course. I know these are new machines, but I believe that they are virtually 100% sourcecode compatible (of course I'm using pure OS friendly coding, no HW access, special assumptions etc) - and GLFW is distributed as source code. I read up on MorphOS, so I have actually included some MorphOS specifics regarding task creation (though I have not tested it myself).

I think both platforms are very interesting targets - especially when they get HW 3D support (that is a must for a system to be successful today, IMO). OS4 is rumored to get Mesa 5.0 (OpenGL 1.4 compliant). Does anyone know about HW support? Will it be through some new Warp3D interface?
 

Offline marcus256Topic starter

  • Newbie
  • *
  • Join Date: May 2003
  • Posts: 17
    • Show only replies by marcus256
    • http://glfw.sourceforge.net/
Re: GLFW port for AmigaOS
« Reply #5 on: May 13, 2003, 08:38:16 AM »
> I'm sure there will be increased need for this kind
> of libraries as soon as these OS:s have their 3D
> support nicely up and running.

Yes. I'd like to think of GLFW as a foundation for writing portable interactive 3D applications (most notably: games!). There is already one major application that uses GLFW as its "core", check out http://www.orkysquad.org/main - a very cool game.

The wording goes "Orky can be ported to any platform with GLFW support".

Personally, I think tools like this is absolutely necessary for a small market such as AmigaOS, since very few coders/companies are willing to spend time on supporting a "minority platform". By using portable technologies (OpenGL, GLFW, libMikMod etc), the hazzle of porting to AmigaOS is nearly negligable.

 

Offline marcus256Topic starter

  • Newbie
  • *
  • Join Date: May 2003
  • Posts: 17
    • Show only replies by marcus256
    • http://glfw.sourceforge.net/
Re: GLFW port for AmigaOS
« Reply #6 on: May 13, 2003, 08:57:47 AM »
Hi Karlos,

> I have written a C++ based portability layer (still in
> development) that encapsulates many things
> useful for your project

I believe we are doing pretty much the same thing (at least we have similar goals). GLFW is: portable, minimalist, very compact (a 68k Amiga executable is usually ~25 KB, the Windows DLL is 30 KB), extremely easy to use & powerful.

The major difference, as I see it, is that I use pure C, not C++. I don't like C++ for these kinds of things, since:

1) It's not as portable as C (no, not yet at least)
2) It's quite difficult to turn a C++ interface into a shared library
3) You can't use C++ interfaces from alternate languages (such as Borland Delphi, Visual Basic, Fortran, Python etc)

Maybe we can exchange experiences? You are of course free to "rip" the GLFW code if there is something that you find useful (the GLFW license is extremely liberal).

If you don't feel like downloading the whole pack, you can always browse the Sourceforge CVS tree: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/glfw/


> class MyApplication : private AppBase, FullscreenDB {
>
> };
>
> Does 90% of the work for you

In GLFW you usually do:

------------------------------------------------
glfwInit();
glfwOpenWindow( 640, 480, 8,8,8,0, 24,0, GLFW_FULLSCREEN );
do
{
    glfwSwapBuffers();
    running = !glfwGetKey( GLFW_KEY_ESC ) && glfwGetWindowParam( GLFW_OPENED );
}
while( running );
glfwTerminate();
------------------------------------------------

That's a complete GLFW application with input, double buffering and a "main loop" (you can do it differently too, e.g. with callback functions for input etc). I agree, not very OO, but I believe that it's not too ugly to write a C++ class on top of GLFW, if that suits your project better than the programmatic C interface.

> 6) Audio classes (fell a bit behind there).

Recommendation: stay away from audio! People tend to underestimate the complexity of audio. You have two choices:

1) Make a fullfeatured, complete audio interface (sound samples, MP3, mixing, 3D aureal emulation, music playback, CD music handling etc)

2) Ditch it and use a 3rd party toolkit (libMikMod, FMOD, OpenAL etc)

If you make a simplistic interface (a-la SDL), professional people will not want to use it anyway, rendering your effort useless and the interface bloated.
 

Offline Karlos

  • Sockologist
  • Global Moderator
  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 16867
  • Country: gb
  • Thanked: 4 times
    • Show only replies by Karlos
Re: GLFW port for AmigaOS
« Reply #7 on: May 13, 2003, 12:59:44 PM »
Ah well, I see you have your stuff covered nicely. It was just a thought since we were obviously going for the same goals (nearly)...

As for portability, my layer does work nicely on other platforms (but as I said theyre slow to catch up because I don't work on them much) principally because it doesn't use any 'wobbly' C++ features internally, namely

namespaces
exceptions (you should see the problems that gave in a multithreaded environment)
RTTI
templates

Actually there are some *very* simple templates (things like protected inegers), nothing that didn't compile everywhere I tried.

However, it is a link library so I don't get quite the compactness you do. I am thinking to make a shared library implementation of the internals that will shrink the link library to a stub but that will take some work (and redesign of the class internals).

Creating an application is extremely simple and fairly robust - if some essential stuff cant be set up, your actual application is never even created.

Anybody whos ran my tests for the 3D card has already used it...twice :-)
int p; // A
 

Offline marcus256Topic starter

  • Newbie
  • *
  • Join Date: May 2003
  • Posts: 17
    • Show only replies by marcus256
    • http://glfw.sourceforge.net/
Re: GLFW port for AmigaOS
« Reply #8 on: May 13, 2003, 02:19:23 PM »
> However, it is a link library so I don't get quite the compactness you do.

Actually, my lib is a static link library too. Under Windows I made it a DLL too (so you can select what suits your project the best). The 25 KB Amiga executable includes the GLFW static link library.

Ah, there's a question: How do you handle things like double floats as input/output arguments in an AmigaOS shared library??? I remember the ieeedoubbas libraries using dual 32-bit integer registers for passing 64-bit floats, which I don't find too appealing. Can't you mandate using the FPU registers? (the lib will probably not be used on non FPU-equipped CPUs anyway). How are the GL/Mesa shared libraries implemented under AmigaOS (they too use doubles)?
 

Offline Karlos

  • Sockologist
  • Global Moderator
  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 16867
  • Country: gb
  • Thanked: 4 times
    • Show only replies by Karlos
Re: GLFW port for AmigaOS
« Reply #9 on: May 13, 2003, 03:14:32 PM »
Yup, this is a problem, but only for 68K libraries as far as I know.

The problem is that standard library interfaces work (as I'm sure you know) by passing arguments in registers, either d0-d7 for ints etc and a0-a3 for pointers.

Passing FPU stuff in fp0-fp7 isn't supported IIRC.

The simplest approach is to pass floats / doubles by reference.

-edit-

I think you can also pass 32-bit floats in registers d0-d7 too. Youd need something like

void myfunc(REGD0 float fval);

where REGD0 is some convenient macro abstraction for specifying a register argument using d0...

-endi edit-

This only affects your actual library interface to the outside world. Normal C conventions apply to internals so there's no reason why functions internal to your library can use floats/doubles as args normally.

-another edit-

Incidentally, are you using MesaGL? You may want to look at MiniGL for performance under current apps. It's a bit of a whopper static link library though...
int p; // A
 

Offline marcus256Topic starter

  • Newbie
  • *
  • Join Date: May 2003
  • Posts: 17
    • Show only replies by marcus256
    • http://glfw.sourceforge.net/
Re: GLFW port for AmigaOS
« Reply #10 on: May 14, 2003, 01:59:50 PM »
> Yup, this is a problem, but only for 68K libraries as far as I know.

So how are things supposed to work under OS4, for instance?

What shared library standards exist except the old AmigaOS style (D0-D7,A0-A3 - I though A5?).

> I think you can also pass 32-bit floats in registers d0-d7 too

Obviously. It's just  a calling method - the caller & procedure just have to agree on the conventions. As I said, the old double precision IEEE libraries used two 32-bit integer registers per 64-bit float.

I'm also considering using referenced arguments (e.g. A0 pointing to a double). That does not go well with the GLFW API specification, but I suppose I can make wrapper macros or whatever.

I just thought that some new standard might have emerged, since the AmigaOS style does not accomodated for:

1) Floating point values
2) 64-bit floats/ints
3) Many arguments (exceedeing the number of available processor registers)

> Incidentally, are you using MesaGL? You may want to look at MiniGL for performance under current apps.

Does MiniGL work with WinUAE (i.e. without HW 3D acceleration)?

Worth supporting though - since some people seem to prefer it. Just wondering if I can test it myself. I have #ifdef:ed everything that is specific to the GL/Mesa implementation (currently only StormMesa), so that support for different implementations is just a matter of a simple #define or compiler-switch.
 

Offline alx

Re: GLFW port for AmigaOS
« Reply #11 on: May 14, 2003, 02:38:20 PM »
Quote
So how are things supposed to work under OS4, for instance?


Here's an extract from the OS4 features list about the new library model:

Quote
New library model

ExecSG sports a new model for shared libraries. The old model will remain to support 68k libraries. PPC native libraries will be organized slightly different: The library base is still there (and looking the same as before) but the jump table only contains 68k functionality (for compatibility). PPC native functionality is provided by Interfaces:

 An Interface can be thought of as a separate jumptable, containing pointers to the actual library functions.

 An Interface can have its own data area in addition to that of the library base.

 An Interface can be shared among tasks (like a library) but may also be created as a private
instance, allowing instance data to be stored in it (similar to the old SAS/C method of duplicatingthe library base). A task can also create multiple instances of the same interface with each interface having its own data (essentially like real objects).

 Reference counting is used to work around stale pointer problems.

 A library can export any number of interfaces. For example, ExecSG exports the interfaces
"main", "utility" and "mmu", which represent the main API, the integrated utility.library and the
special MMU interface.

 A library can export the same interface in multiple versions thus allowing for full backward
compatibility.

 Interfaces can be modified with SetMethod (like SetFunction), allowing "morphing" interfaces
that can efficiently adapt to internal state changes. For example, expansion.library uses this in its PCI interface to adapt a PCI interface to the actual hardware.

 Interfaces can also be created in such a way that they are protected against patching. This is
essential for services like SSL (or any security-sensitive service).

 Interfaces can be used to write Object-oriented libraries.

 Interfaces are conceptually similar to component programming models.


That's not very detailed, and seeing as I've never done any programming on AmigaOS, I've no idea if that'll be any use to you.

Offline marcus256Topic starter

  • Newbie
  • *
  • Join Date: May 2003
  • Posts: 17
    • Show only replies by marcus256
    • http://glfw.sourceforge.net/
Re: GLFW (OpenGL toolkit) port for AmigaOS
« Reply #12 on: May 18, 2003, 08:43:26 PM »
I suppose that's one way to go (at least for AOS4 it's probably the prefered way). Another way is to ignore  the way the 68k assembly interface looks: write a library interface with "nonsense" arguments (e.g. D0/D1 = 64-bit float, or A0 points at function return value, etc), and write a wrapper C language interface library (libglfwsh.a or glfwsh.lib - sh = shared) that hides the library interface from the programmer.

More questions: For the multi threading part of GLFW I had to use the tc_UserData field of the Task structure for each GLFW thread (including the main thread, which is the one calling glfwInit()).

I know this is not good practice, but I see no other solution (each thread requires a lot of state that I have to store somewhere, and I do it in a struct pointed to by tc_UserData). If the GLFW program only uses GLFW threads, and not any custom AmigaOS tasks/processes etc, this will be no problem. Can anyone think of a situation where it COULD  be a problem???
 

Offline 4pLaY

  • Hero Member
  • *****
  • Join Date: Apr 2002
  • Posts: 779
  • Country: no
  • Gender: Male
    • Show only replies by 4pLaY
    • https://www.amigalife.org
Re: GLFW (OpenGL toolkit) port for AmigaOS
« Reply #13 on: May 18, 2003, 09:09:19 PM »
 Considered a port to AROS? :).

Offline Karlos

  • Sockologist
  • Global Moderator
  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 16867
  • Country: gb
  • Thanked: 4 times
    • Show only replies by Karlos
Re: GLFW (OpenGL toolkit) port for AmigaOS
« Reply #14 on: May 18, 2003, 09:35:37 PM »
Hi marcus,

The only problem would be if you mixed up a normal thread with one one of your GLFW ones and proceeded to use it as if it were.

My Threadable service class (base for all threaded objects, wraps a task) uses the same strategy as you describe.

On creation of the task I set tc_UserData to point to the actual Threadable class that encapsulates it.

To avoid problems in cases where other threads that use the same field for their own purposes, the Threadable class has an identifer member value inside used to identify it as a 'Threadable' class object. This is basically an integer which must match a defined value 'IS_THREADABLE'

So, to get the current Threadable object for which the code is executing uses a static function thus

Threadable* Threadable::getCurrent()
{
  Task* who = FindTask(NULL);
  if (who)
  {
    // this is the dodgy bit, we cast to Threadable and see if the id matches
    Threadable* thread = (Threadable*)(who->tc_UserData);
    if (thread && thread->identity == IS_THREADABLE)
      return thread;
  }
  return 0; // not a Threadable thread
}


I certianly haven't ran into any problems with this approach. You could just put a check like the one above use identifier field in your structure. If you ever do somehow handle a thread which is not one of your GLFW ones, it can be differentiated easily by seeing if the data pointed to has this identifier.

Works for me :-)
int p; // A