Daytona675x wrote:
Damn! So, what am I supposed to do to get the desired behaviour (= without black border)?
Shall I use GL_CLAMP_TO_EDGE although it produces artifacts on some machines right now?
Or is there a reliable glGetString I can use to select the appropriate wrap-mode depending on driver-version and card-type?

struct Resident *morphos;

morphos = FindResident("MorphOS");
if (morphos && (morphos->rt_Flags&RTF_EXTENDED) && morphos->rt_Version == 3 && morphos->rt_Revision <= 4)
{
   /* Set flag here that makes your code swap GL_CLAMP and GL_CLAMP_TO_EDGE */
}

9. TinyGL IV:
GLASetSync has no effect. No matter if I use a screen-context or window-context and no matter when I call GLASetSync, it has zero effect, the GL output is always not vsynced. Is this a known limitation/bug on my Radeon9000-system? Or is there some additional setup I need to do?
As a workaround I tried WaitTOF, but this seems to misbehave just like it does on AmigaOS4/RadeonHD: it doesn't do a real vsync but just seems to wait for some 1/70 seconds or so (you can spot a nice tearing moving down the screen), not useful at all.

        struct TagItem tgltags[] =
        {
                { 0, 0 },
                { TGL_CONTEXT_STENCIL, TRUE },
                { TAG_DONE }
        };

[...]

                                        if (screen)
                                        {
                                                tgltags[0].ti_Tag = TGL_CONTEXT_SCREEN;
                                                tgltags[0].ti_Data = (ULONG)screen;
                                        }
                                        else
                                        {
                                                tgltags[0].ti_Tag = TGL_CONTEXT_WINDOW;
                                                tgltags[0].ti_Data = (ULONG)window;
                                        }

                                        r = GLAInitializeContext(__tglContext, tgltags);

It will be fixed starting with MorphOS 3.5, so you could do something like...

Make sure that you actually create a screen context, otherwise it won't work.

Quote:
But I thought only the R200-driver was buggy? Such a snippet would toggle the behaviour on all systems ver 3.0 - 3.4.

Quote:
Unfortunately it definitely is a correct screen-context
But besides the fact that GLASetSync seems to be broken on my system: so for window-contexts GLASetSync should indeed have no effect and one is supposed to use WaitTOF or so instead?

Well, it does look like I managed to replicate that behaviour in the R300 driver too :)

Well, basically, full screen double buffering is always vsynced.

You should never, ever use WaitTOF().

I think that Enhanced Layers has some fancy way to ensure vsynced updates to window contents

Daytona675x wrote:
10. ASL screen mode requester
ASLSM_MinDepth is ignored on my system. I explicitely request screen-modes with a depth of at least 16 bits through that attribute, but the requester also shows 8 bit palette modes. System bug?

11. Mouse Capture
Is there a better way to capture the mouse to stay inside the application's main window than to reposition it via DoIO? At least on my system this results in a huge performance penalty (in fullscreen mode this is not needed and therefore no issue, luckily).
Answer: Install an interrupt-handler to catch the IECLASS_RAWMOUSE events before they are delivered to the normal event-handler. Extract the x/y deltas and then set the event's coordinates to zero, which will effectively cancel any mouse-pointer movement. Check FodQuake sources, file in_morphos.c

#define WM_ObtainEvents (WM_Dummy + 2)
/* BOOL. Obtains the events for the screen the window is at.
** This is an equivalent of installing your own, high priority
** inputhandler to capture input events. All IDCMPs will
** be sent to your window. Clicking outside of your window
** will not send events to other windows or cause their activation.
** Intuition menus will not be opened. The mouse pointer will use
** whatever your window has set, even if your window was not
** active when you obtained the pointer. Use this solely for the
** purpose of letting user pick a window, mark some area for
** snapshoting, etc. Will return FALSE if another window
** currently owns the events or your window already owns them.
** If the method returns true, you are the pointer owner and
** MUST match the call with WM_ReleaseEvents after you are done.
** For security reasons, if your application crashes or refuses
** to reply to IDCMP messages, the event ownership might be
** silently revoked. If a new window opens or gets activated
** while you have the ownership, it will be revoked and you
** will receive an IDCMP_INACTIVEWINDOW idcmp (even if your window
** is still active or was inactive before obtaining the pointer).
** The IDCMPS that your window will actually capture are:
** IDCMP_MOUSEMOVE, IDCMP_MOUSEBUTTON, IDCMP_RAWKEY,
** IDCMP_VANILLAKEY, IDCMP_INTUITICKS */

#define WM_ReleaseEvents (WM_Dummy + 3)
/* void. Releases the events obtained with WM_ObtainEvents. You MUST
** always call it after WM_ObtainEvents returned TRUE. It is safe
** to call it in case your events ownership was revoked by the
** system */

System bug. It looks like ASLSM_MinDepth only sets minimum depth to the depth slider. It does not filter any screenmodes according to MinDepth/MaxDepth setting.

There is another solution that might be useful to you: WM_ObtainEvents/WM_ReleaseEvents in intuition/intuition.h

Make sure that you actually create a screen context, otherwise it won't work.

Disabling vsync via GLASetSync essentially works, the context doesn't get synced anymore, but it also produces massive black-triangle-shaped-flickering and is therefore unusable.
As a workaround I can of course do as I did before by accident: use a window-context in fullscreen mode. [...] But it would be interesting to know, if that's a known problem of GLASetSync in combination with a screen-context.

Well, basically, full screen double buffering is always vsynced. However, TinyGL has the possibility to not wait for a buffer to have been fully displayed before swapping to the next buffer, which removes the waiting for benchmark purposes, but isn't the same as non-vsync on f.ex. Linux or Windows.

Also, you should keep in mind that using a window-style context incurs a performance hit

I just ask myself, why GLASetSync isn't doing something useful

Yes, of course. But if people decide to turn off vsync in fullscreen-mode this is normally because they got a slow machine that can't deliver the frames fast enough for proper vsync, and in such a case turning of vsync will usually speed up things - trading tearing for speed
That's actually the only reason why I wanted to have that switch.

It does do something useful. It makes benchmarking possible ;)

Disabling vsync doesn't improve speed on any machine, slow or fast

In my case here it does. Fullscreen-vsynced is significantly slower than Fullscreen-Window-not-synced under certain circumstances.

Although this is rather academic: if the game runs that slow it won't become really playable by that. Nevertheless here it makes the difference between about 25 fps (unplayable synced) and about 35 fps (a bit less unplayable, unsynced ) when I torture my antique Mac with the highest quality settings.

In SDL I am calling GLAReinitializeContextWindowed() on window resize.