SDL2

@MickJT

Esc might be a bug. I see game uses:

https://sourceforge.net/p/tuxfootball/ ... e/src/gameengine.cpp#l115

SDL_GetKeyboardState returns array that should be indexed with SDL_ScanCodes. So m_quitKey should be SDL_SCANCODE_ESCAPE.

bad_alloc...can you find out the line?

I don't recall it saying a line number before. It's just a complete system freeze now when I go to "Redefine Keys". No shell output. That's the last testing I can do for a week. The game doesn't take long to port though if you want to grab the git repo and have a look.

Edit: Very quickly rebuilt with SDL_SCANCODE_ESCAPE and now the escape key works. Got the bad_alloc message back now:

terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc

I could edit the source and see exactly where it breaks or freezes, but I don't have the time now, and for a little while.

By the way, are you sure that SDLK_ESCAPE needed to be changed and not an indication of a larger problem? If I recall correctly, checkkeys didn't report the Key Pressed/Released (or maybe it was the "Text:" line it didn't show) when pressing Escape, unlike any other character.

Edit 2: It's the "Text:" line that doesn't show, but it looks like that's probably normal (Cursor Keys & Enter don't show it either). Gotta go now!

@MickJT

Yes, documentation is here https://wiki.libsdl.org/SDL_GetKeyboardState

Checkkeys also reports escape pressed/released. But what it should report for text?

Regarding bad_alloc, it's also game issue that it doesn't try-catch the error. However, we have to debug why allocation failed.

r135 is supposed to merge 2.0.4 modifications into our branch. Patch was 7 megabytes (pain) so I expect there to be new issues.

One obvious problem is that .so is not generated at the moment. As a workaround, remove -no-undefined from generated makefile (libtool's flag). Hopefully we could get rid of pthreads dependency with SDL2.

Testautomation seems to give some failures and there are probably some unimplemented backend functions but they will be added later.

@Capehill


Great!

Hope to try soon.

@Capehill

Here you are, found another game that has the "shift to the right" issue

Mystery House SDL1 Correct Alignment


Mystery House SDL2 Shifted Alignment

(PuTTy log)



The Kite SDL1 Correct Alignment


The Kite SDL2 Shifted Alignment

(PuTTy log)

@Raziel

Thanks for log. How much shift you get? Any chance for a screenshot? Did you say it doesn't happen always?

@Capehill

I updated the post above to show what the difference is.

I found another one and probably will find even more games with this issue

It happens every time with at least the two games mentioned above.

In the other thread where i said it didn't happen anymore i was using the SDL1 build for testing

@Raziel

Finally checked those logs. It looks like SDL2 opens a new screen but when window is created, it uses some strange x/y coordinates for position (would have expected 0,0). I have to do some fullscreen tests.

@Capehill

Thanks a lot

@Raziel

When programmer passes SDL_WINDOWPOS_CENTERED parameter, SDL2 most likely uses the information of the first stored display, which on our system is probably your Workbench screen. Then it calculates new window coordinates based on the dimensions of your WB screen, which might not match the application's expectations...that explains funny readings in the serial log.

For now, it looks as if the most simplest solution would be to ignore SDL2's window centering code and center the window on AmigaOS backend side. This solution needs a bit more testing before commit.

As a workaround, you can try to pass X=0, Y=0 for your window.

@Capehill

I wouldn't know how to do that...i can't code

@Raziel

Here https://wiki.libsdl.org/SDL_CreateWindow

Try locating that function call from your game code and replace x and y parameters with zeroes.

Alternately please compile r139 and tell me if problem still there..

@Capehill

Thank you

The in source change to 0, 0 made the game screen start at, of course, 0, 0

But there are still important portions cut off as you can see in the picture


I haven't tried building SDL2 myself as i wouldn't know how to properly create libraries, i leave that to the pros to not stir up any more dust when reporting errors i made myself on the way of building sdl2

@Raziel

Looking at the earlier serial log, we can observe that window width was less than 640. I am not sure why is that, did game want it or did SDL2 screw it somehow?

Please, if you have time, try compiling r139. I know that Davide can build SDL2 without issues, for example. It should work, unless your SDK is somehow broken. (ok, .so build is currently broken, it's a known issue)

I hope we could have another SDL2 release this year, but there are still some open issues.

@Capehill

I will compile R139 asap.

@thread


Capehill released version 164.

Works very well.

Can't wait to have a system opengles2 compatible to test.


Don't forget to support the projects.

@AmigaBlitter

Released where ?
Officially still the old r119 on Sourceforge, atleast you mentioned the progressing internal version to compile

On sourceforce there is R164.
Tomorrow will be on os4depot, i guess.

@samo79

Guess he was talking about the code revision in trunk.

There wasn't a build released for some time now