SDL2

@Capehil
Done: https://github.com/AmigaPorts/SDL/issues/29
Thanks !

@Capehill

https://github.com/AmigaPorts/sdl2-amigaos4
Quote:

So, where can i add new issues?

I still have the crash when quitting ScummVM/ResidualVM in window mode

@Raziel
On the link you quote, right below of phrase about read-only which you quote, new link. And you also can see direct link on issues page in my previous post.

@kas1e

Oh wow...i am so blind...thanks

OS4Depot archive seems to have a wrong URL. https://github.com/AmigaPorts/SDL is the current one, and not only for AmigaOS 4.

@Capehill

I haven't read the whole thread, but do we have AmigaOS specific keyboard fixes in our SDL2 port?

I'm asking because of a bug in ScummVM where there was a SDL1/2 keyboard fix done for macOS which now affects the AmigaOS4 keyboard, namely the numpad, in some games.

The PR that introduced the bug is here.

It affects the AmigaOS4 keyboard in the way that only some of the numpad keys are working at all and the function of said keys are shifted (e.g. the action for key 7 is on key, while key 7 does nothing etc.), so it's not really usable, the number keys beneath the F keys are not affected.

I'd like to know if this is something we need to get fixed or reversed in our SDL port or need to be figured out in the ScummVM source.

See also my bug report for ScummVM here

@Raziel

Does SDL2 assume Unicode is supported by the host system?

@Thematic

whooosh...over my head

I don't have the slightest idea...capehill?

@Raziel

Looking at the PR, does it change anything if NUMLOCK is pressed or not? My default keyboard doesn't have numpad so I haven't tested it myself as far as I can remember.

To be honest I don't know whether SDL2 assumes unicode or not. Anyway, there are separate events for key presses vs. text input (UTF-8). https://wiki.libsdl.org/MigrationGuide#Input

@Capehill

Like i wrote in the ScummVM bug report NUMLOCK has to be set to OFF to make the three keypad keys work et al, NUMLOCK set to ON makes all numpad keys silent/non reacting.

This alone is fundamently wrong imo as NUMLOCK ON *only* should trigger those keys in the first place (as also written in the ScummVM bug report it does exactly that in v1.9.0 - without that PR in place)

At least that is how it works on the other platforms i tried (Windows, Linux)

Maybe you could compile a SDL2 test case for me to try and see where the error happens?
That way i could rule out SD2 or ScummVM.

@Raziel

SDL2 has a test progam called "checkkeys". Please download the binary: http://capehill.kapsi.fi/sdl2/

I tried some Logitech USB keyboard and every key from numpad seemed to report OK values with or without NUMLOCK.

@Capehill
Maybe you can help a little .. I modified opengl(minigl) in SDL2 to be able to use GL4ES with it, and build your version of quake3 over that hacked SDL2. And that what i have when i run q3:

(press to open in new tab for fullsize):



Once i start level, trashing gone.

Changes was almost the same as for SDL1:

http://kas1e.mikendezign.com/aos4/gl4es/sdl2/SDL_os4opengl.c
http://kas1e.mikendezign.com/aos4/gl4 ... l2/SDL_os4openglwrapper.c

And that trashing happens not all the time, but let's say 2 times from 3 runs. And if i move mouse over that trashed screen, it leave garbage.

It seems that i just miss something when hacking SDL_os4opengl.c probably ..

@kas1e

I would guess the problem is outside of SDL. SDL gives you the context and function pointers, drawing happens somewhere else.

If context creation is 100% sane (?), then I'm sure the problem lies elsewhere.

Oh, and you probably don't need to allocate any front/back bitmaps if you let OGLES2 automanage them.

@Capehill
Btw, while trying from where that distortion come in SDL2 version, found that your q3/sdl2 code have some minigl hardcore ifdef:

code/sdl/sdl_glimp.c :



Because of that i at first runs have lots lower FPS than in sdl1 version, but once i comment that workaround for minigl, all start to be fine by fps. Probably there need to replace ifdef not on __amigaos4__ , but on something like "if defined amigaos4 and defined minigl".

@kas1e

There is a typo in MiniGL (extension name is spelled with an extra 's'). Q3 is slower without CVA, on Sam440 MiniGL.

http://www.hyperion-entertainment.biz ... s/updates-kc/src/others.c

If I remember correctly you can disable extension in config file, variable name seems to be "r_ext_compiled_vertex_array".

@Capehill
Sure q3 is slower without CVA everywhere..

What i mean, is that for others renderers (ogles2, gl4es) name spelled correctly, without extra "s", and probably will be better to not do just "#ifdef __amigaos4__", as that minigl only fix, will broke gl4es and ogles2 versions to not have CVA at all, and being disabled , even if you enable it in config. There instead should be something like " #if defened amigaos4 and defined minigl", so when anyone will compile your version over ogles2 renderer, or opengl2 one, that minigl only fix will have no place.

@Capehill

checkkeys work as it should, so it's not a problem in our SDL, but in the ScummVM code, right?

@kas1e
@capehill

May i ask if renderers are supported in SDL2 now?
I thought there is still an enhancement request pending for supporting them in the first place (can't find the link right now)?

@Raziel
You probabaly mean something else, as what i mean is those "general" renderers , i.e. SDL2 support: software, OpenGL, OpenGL ES 2.0 and compositing.

@Capehill
As you know SDL2 build system well, if i will send you SDL_os4gl4es.c and SDL_os4gl4es.h, can you incorparate them to the SDL2, so it will be builds as 5st renderer and which developers can choice from SDL via SDL_SetHint(SDL_HINT_RENDER_DRIVER, "gl4es") ?

@kas1e

Sorry, I misunderstood some of your post.

Regarding Q3, If I understand correctly, there should be a Q3 makefile-level switch for choosing the GL. Or, code could try to look for CVA extension with or without 's'.

Regarding SDL2 renderer hint, I'm not sure which problem you want to solve by using that hint? What benefit gl4es will bring when used as a (2D) renderer, over pure GLES2? As I understand it, gl4es is meant to wrap OpenGL 1.x (MiniGL) calls with OGLES2 ones, but why not use directly OGLES2?

If you want to force opening the correct GL library for OpenGL context instead of, it has to happen by some other means. Please refer to readme document how to select between MiniGL and OGLES2 context. At the moment I don't know what is OpenGL version that gles4 supports - that's one thing that might be used.

Is gl4es a static library, shared or both? Have you added configure support for gl4es? In other words, how to recognize SDL_os4gl4es.c should be compiled? It sounds difficult, because if SDL2 library starts to require symbols from gl4es, then there has to be 3-4 different SDL2 binaries (nightmare). Versions for sdl.a, sdl.so, sdl.a with gl4es.a, sdl.so with gl4es.so.