SDL2

@kas1e

On my system, I wasn't able to see difference when running

testgles2 --fullscreen --vsync

with compositing on / off. Also FPS is pretty close to 60. How about you?

@Capehill
Maybe it not just compositing, but together with drop-shadows. Better to test it build SDL2 with SA_LikeWorkbench and without, so to see if there differences between those two. Not just by disabling/enabling compositing in GUI.

But it can be that such a simple test case will not show an issue, will check anyway.


EDIT: ok, tested. With vsync difference probably not very well noted, but without you can see it pretty well. While FPS kind of the same (just with compositing false a bit faster), but visually you can see how it differs pretty well. With compositing on, it like some kind of vsync or dunno what applied. Like something makes it draws slower. While with compositing false, things look "very fast" and as expected. And, with compositing false, we also have +30 fps more.

@kas1e

You are correct. I tested it more and with compositing enabled, FPS decreased by about 1% so there is a small impact when FPS count is high. As testgles2 runs at 3000 FPS on my system the impact is about 20 frames.

So SA_Compositing is now disabled in master branch.

@Capehill
Find out today that one of my testcases (no sound, simple SDL2 + ogles2 test) crashes on exit with INewLib error when i build it statically with latest SDL2. Commenting out inewlib stuff in the os4_library.c of SDL2 did the trick. Do i need to upload test case somewhere ? It just looks like that for static builds there should't be open of INewLib happens for some reassons

@kas1e

Please share the source code and binaries if possible. Maybe there is some shutdown order issue.

@Capehill
It seems to happen only with my gl4es changes inside of SDL2, while didn't happen with the original Minigl's code.

I will update my GitHub today/tomorrow with forked SDL1/SDL2 and adding gl4es changes in one commit (so all changes can be seen), maybe it will bring some light on as well...

@Capehill

For first making (at last) public repos with your latest SDL1 and SDL2 + gl4es changes:

https://github.com/kas1e/SDL1_GL4ES
https://github.com/kas1e/SDL2_GL4ES

Gl4ES changes added in each repo in one single commit, so you can see the whole picture/code.


And there is a test case:

http://kas1e.mikendezign.com/aos4/sdl2/newlib_crash_test.lha

Just unpack, type "make", and after run "example01". It will compile code using libraries in an archive, show the rectangle, and crash in newlib on exit.

Example uses SDL2, so for Gl4ES changes in SDL2 see that commit: https://github.com/kas1e/SDL2_GL4ES/co ... f714af20a8bdfed757831b1d5

@kas1e

GL4ES has also destructor and there is no priority set in either SDL or GL4ES so I'm guessing SDL destructor ran first and cleared INewlib, then GL4ES tried to print something and it crashed. In stack trace you can see LogPrintf which is part of GL4ES.

It's probably wisest to remove INewlib from static builds at least and otherwise make SDL destructor more robust if INewlib is still required when loading libSDL2.so using elf.library.

EDIT: pushed a commit to the master branch, maybe it helps with that issue.

@Capehill

I found something really odd today, while testing out some cleanup changes in ScummVM.

The SDL2 compile suffers from a real bad music playback hiccup everywhere (no matter if it's midi over hardware or sound files from hdd).

It's really bad, it slows down everything, mostly in video sequences, like intros.

And now for the strange part, SDL1 is fine!
Same sources, same build date.

I haven't really tested any game for quite some time, so it might very well be a regression in ScummVM, or in SDL2 (where more work was done than in SDL1).
I'd point my finger at SDL2, because even the OGLES2 SDL2 build suffers from it.


Do you have any idea what could be the cause?

Changing options in the launcher or for the games doesn't matter, it's always the same.

Help, please

Edit:

Seems to be a priority problem (race condition?) between animation and sound.
As soon as there is some drawing/animation going on the music is slowed down (actually both).
It nearly looks like as if they were running on the same thread.

And that is with a year long implemented engine (scumm)

@Raziel

Are compiler optimizations enabled?

@Capehill

You mean -O2?

Yes, the same since ages.

I can't do a 4regression check because all of versions of SDL2 doesn't have SDL_OpenUrL

@Raziel

-O2 should be fine.

SDL2 uses audio thread priority 5 while SDL1 uses 15 so there is already some potential explanation.

Can you check if audio buffer size setting changes anything? https://github.com/scummvm/scummvm/blo ... er/sdl/sdl-mixer.cpp#L158

@Capehill

Nope, that was one of the first (easy to change) options i tried.
Didn't change anything, taking the option out, enhancing the option to 2 MB, nothing helps

@Capehill

Ah, setting the audio buffer to the highest possible (32768) makes the audio hiccup go away, but the animation is still lagging

edit:

Yeah, no, not really, as soon as there is sound and speech it's back to lagging

@Raziel

What games I could use to reproduce the issue?

@Capehill

Any.

https://www.scummvm.org/games/

Beneath a Steel Sky
- You can already see video slowdowns while fading in and out
- As soon as the old man speaks, there are also sound dropouts in sync with the video slowdowns (unless you enhanced the audio buffer to 32768)

But, as i said, all games show that behaviour

Hi all

I am trying to compile this little game

https://github.com/landersson/roketz3d

It was written for SDL1.2, now I migrated them to SDL2

However when I try to compile it, I get these errors

compiling with g++ or adding
#include <cstring> to source code

does not work..

Sinan@LENOVO /amiga/roketz3d
$ ppc-amigaos-gcc -athread=native *.cc -o roketz.3d -lGL -lGLU -lSDL2 -lSDL2_mixer -lSDL2_image -lplib -ljpeg -lpng -lz -lm -lc -lpthread -lstdc++
test_png.cc: In function ‘void png_mem_write_data(png_structp, png_bytep, png_size_t)’:
test_png.cc:31:5: error: ‘memcpy’ was not declared in this scope
31 | memcpy(buf->buffer + buf->offset, data, length);
| ^~~~~~
test_png.cc:11:1: note: ‘memcpy’ is defined in header ‘<cstring>’; did you forget to ‘#include <cstring>’?
10 | #include <zlib.h>
+++ |+#include <cstring>
11 |
test_png.cc: In function ‘int compress_png(unsigned char**, int, int, uint8_t*, int)’:
test_png.cc:63:5: error: ‘memset’ was not declared in this scope
63 | memset(&png_buf, 0, sizeof(png_buf));
| ^~~~~~
test_png.cc:63:5: note: ‘memset’ is defined in header ‘<cstring>’; did you forget to ‘#include <cstring>’?
test_png.cc: In function ‘int main()’:
test_png.cc:125:5: error: ‘memset’ was not declared in this scope
125 | memset(data, 0, width * height * 3);
| ^~~~~~
test_png.cc:125:5: note: ‘memset’ is defined in header ‘<cstring>’; did you forget to ‘#include <cstring>’?
threads.cc: In constructor ‘ImageData::ImageData(uint8_t*, int, int)’:
threads.cc:18:62: error: class ‘ImageData’ does not have any field named ‘_size’
18 | ImageData(uint8_t *data, int wid, int id) : _data(data), _size(size), _id(id) { }
| ^~~~~
threads.cc:18:68: error: ‘size’ was not declared in this scope
18 | ImageData(uint8_t *data, int wid, int id) : _data(data), _size(size), _id(id) { }
| ^~~~
threads.cc: In function ‘int jpeg_writer_thread(int)’:
threads.cc:46:1: warning: no return statement in function returning non-void [-Wreturn-type]
46 | }
| ^

@SinanSam460

Try to
#include <string.h>
in test.png.cc

The threads error is of a different kind

Seems "size" parameter is missing in source code. Possibly there should be "wid" but that's a guess. However, in the same file there is only one call for that constructor and "0" is passed as size:

https://github.com/landersson/roketz3d/blob/master/threads.cc#L61

So Sinan may use a simple workaround by hardcoding the constructor like:

ImageData(uint8_t *data, int wid, int id) : _data(data), _size(0 /* was size */), _id(id) { }

Thanks..

I solved problems in threads.cc and test_png.cc

Now I get this error:


$ ppc-amigaos-g++ -athread=native *.cc -o Rocket -lGL -lGLU -lSDL2_mixer -lSDL2 -lSDL2_image -ltiff -lpng -ljpeg -lmikmod -lmodplug -lFLAC -lvorbisfile -lsmpeg2 -lsmpeg -lvorbis -logg -lwebp -lpthread -lmpg123 -lz -lm
In file included from /usr/local/amiga/ppc-amigaos/SDK/local/newlib/include/plib/sg.h:29,
from main.cc:23:
main.cc: In function ‘int write_to_jpeg_file(int, int, unsigned char*, FILE*, int)’:
main.cc:354:39: error: invalid conversion from ‘int’ to ‘boolean’ [-fpermissive]
354 | jpeg_set_quality(&cinfo, quality, TRUE);
| ^~~~
| |
| int
In file included from main.cc:17:
/usr/local/amiga/ppc-amigaos/SDK/local/common/include/jpeglib.h:991:31: note: initializing argument 3 of ‘void jpeg_set_quality(j_compress_ptr, int, boolean)’
991 | EXTERN(void) jpeg_set_quality JPP((j_compress_ptr cinfo, int quality,
| ^~~
In file included from /usr/local/amiga/ppc-amigaos/SDK/local/newlib/include/plib/sg.h:29,
from main.cc:23:
main.cc:361:33: error: invalid conversion from ‘int’ to ‘boolean’ [-fpermissive]
361 | jpeg_start_compress(&cinfo, TRUE);
| ^~~~
| |
| int
In file included from main.cc:17:
/usr/local/amiga/ppc-amigaos/SDK/local/common/include/jpeglib.h:1010:34: note: initializing argument 2 of ‘void jpeg_start_compress(j_compress_ptr, boolean)’
1010 | EXTERN(void) jpeg_start_compress JPP((j_compress_ptr cinfo,
| ^~~
threads.cc: In function ‘int jpeg_writer_thread(int)’:
threads.cc:46:1: warning: no return statement in function returning non-void [-Wreturn-type]
46 | }