SDL2

@Capehill

Yeah, after setting 59 back to UNKNOWN, the forward-slash no longer says Unknown Key. The reason I had both 58 and 59 as forward-slash, is because the AmigaOS Keymap wiki says 59 is "/? Brazil (near RShift) and International 1 (Ro)". Is Ro Romania? I hope people using a Brazilian keyboard can still use the forward-slash key, although you said it's hardcoded to 0, so maybe not?

Also when you say scancodes 46 and 48, I assume you're referring to the numbers listed in the scancodes_amiga.h header, since the scancodes that checkkeys outputs don't match (e.g in the header, A, S and D are 32, 33 and 34, but checkkeys says the scancodes are 4, 22 and 7 respectively).

@MickJT

AmigaOS failed to map the rawkey 59 (-> 0). If there are duplicated scancodes listed in the table, the later ones overwrite the earlier mappings.

By scancode 46 and 48 I mean SDL enumerations. Rawkeys are possibly 0xD and 0x1B (according to the Wiki picture). One left to backspace and one left to enter (upper).

@Capehill

May i say thank you to all involved in the SDL2 port and how awesome it is to get the possibility of new ports?

Thank you

@Raziel

Danke! I hope people will find SDL2 useful :)

I'm trying to fix the remaining known bugs, maybe another release will follow after that.

@Capehill
is there any datas of the overhead when using SDL2 vs AmigaOS API? I suppose that using SDL2 is faster than SDL1.

I read in another forum that your SDL2 port use sobjs if true isn't it be better to have it as an Amiga library that way games and apps will be shorter and it's more the Amiga way like on Morphos.

Kamelito

@Kamelito

Since SDL provides abstraction over native API, there is a small function call overhead. I don't have any numbers though.

If you consider CompositeTags features, you can draw faster with native call because there is always one drawcall per "sprite" (or quad) in SDL2 (no sprite batching). Natively you could draw many sprites per one drawcall assuming they use the same texture (sprite sheet).

If you consider OpenGL features, it shouldn't matter if you use SDL or not. SDL is only used to setup the context.

Power of SDL comes from the portability. It's generally very easy to target multiple platforms at once. You can get a simple app running on a new OS in a matter of minutes. It's amazing.

SDL2 is not my port, I am one of the contributors. SDL2 can be linked dynamically or statically. It depends on the developer and end user really doesn't need to care. Also SDL1 was a shared object. Nobody has talked about making an Amiga library so I guess there is no interest, but hey, it's open source.

Personally I don't see a big benefit of .library over .so in this case. If developers link dynamically, binaries are not bigger than with native libraries (why would they be?).

Sadly, you cannot fill modern hard discs with AmigaOS binaries. There is a couple of reasons for that :)

@Capehill

Thanks, I didn't get your last sentence though.
I hope that in the future it will support OpenGL ES and/or Nova.
Kamelito

https://sourceforge.net/projects/tuxfootball/ uses SDL2. We already have older port.

Half Life ..
xash3d

https://github.com/SDLash3D/xash3d
build on LinuxPPc we can gave a try?

@tlosm

That would be interesting.

@Capehill
Are you moving to Lothric anytime soon?

I'll port tuxfootball next week, assuming it's just as easy to port as before.

@Cap

Heh, just finished Dark Souls 3 like a week ago. Phew.

@tlosm:

Half-life engine looks very interesting. What is the status of the project?

@MickJT:

Thanks!

@Capehill

all valves old look like working on adroid too

check:

hl
https://www.youtube.com/watch?v=8m6jpRZmipg
C.S
https://www.youtube.com/watch?v=FQtPnY3cIKk
Blus Shift
https://www.youtube.com/watch?v=FC2lALFw0mA

@Mickjt
you are the man!

I built tuxfootball last night but haven't tested it. I'm going to be away from my Amiga machine for a week so I'll quickly test it tonight and put up a temp link if it seems to work OK.

https://github.com/Raul-Ramos/Gauntlet-II another SDL2 app.

@Capehill

i think this Gaundlet will be hard to port because look like build only for visual c

@tlosm

Its SDL based it should not be a problem,
you need to setup a makefile manually, that’s the work.
Virtual C, just means it where written using virtual studio, it is C++ code.

Etch of .cpp compiled with the "-c" flag and outputted as a .o file. Then all the .o files as to be linked into a executable file.

This mostly just

g++ file1.cpp –o file1.o –c
g++ file2.cpp –o file2.o –c
g++ file1.o file2.o –o game.elf –LSDL –lm

or some thig like that.

Addition definition can be set using the "-D" flag if needed.

@Capehill

Tux Football from git runs (change data_dir to PROGDIR:data in const.h), although there are 2 big problems.

The escape key isn't working properly (can't quit a game, except to quit the whole game via the close gadget), although a sound is heard when you press it, and the "Redefine Keys" menu option freezes the game with an std::bad_alloc exception.

On the upside, the framerate is better, at least in windowed mode.

@LiveForIt

thanks for Geek infos

Liveforit a small ot :
probably i found the way for have the Sheepshaver running on Os4 too.
Can you make this try

the configure will have to build with this flags :

./configure --enable-sdl-audio --enable-sdl-video --without-mon --without-gtk --disable-vosf --enable-ppc-emulator --enable-addressing=direct,0x20000000



it make build and running in emulation mode and emulator work on bigendian too . here in emulation i have a powermac 5100 performance not bad for use most of MacOs 9 software.
check
https://scontent-mxp1-1.xx.fbcdn.net/t ... 4817251034033097009_o.jpg

like this will not need the vm cofiguration present on osx or linux and will make sheepshaver running finally on Os4



i didnt try the jit but probably will found endianess there.