But it's wrong to assume that all platform behave identically. For example, not every target support all accelerations. Some have Altivec, for example.
@Capehill Yeah indeed.. Through that test code works not only on win32, but also on linux and macos, only fail like that on amigaos4.
Anyway, even if we have SDL_PREALLOC flag set for us as aos4 only thing, it still shouldn't skip the calling of resizewindow in the sdl's code when SDL_OPENGL | SDL_RESIZABLE flags set together with SDL_PREALLOC ?
@Capehill Have another question, related to SDL1/SDL2 differences.
For SDL1 to get list of screenmodes we use something like:
SDL_ListModes();
Now, for SDL2, we use something like this (to have analogue):
SDL_GetNumDisplayModes() + SDL_GetDisplayMode()
Question now is:
For SDL1 return of screenmodes is sorted by height. For SDL2 return of screenmodes is sorted by width. I.e. when i do printf for what i have in return, then for SDL1 i have:
more_num: 0, w = 1920, h = 1200 more_num: 1, w = 1600, h = 1200 more_num: 2, w = 1920, h = 1080 more_num: 3, w = 1440, h = 900 more_num: 4, w = 1024, h = 768 more_num: 5, w = 1280, h = 720
And for SDL2:
more_num: 0, w = 1920, h = 1200 more_num: 1, w = 1920, h = 1080 more_num: 2, w = 1600, h = 1200 more_num: 3, w = 1440, h = 900 more_num: 4, w = 1280, h = 720 more_num: 5, w = 1024, h = 768
See for SDL1 order of screenmodes is sorted by height, while for SDL2 buffer of screenmodes is sorted by width.
I checked win32 version of the same code, and there SDL1 sort the output the same as in SDL2 : by width.
So, if i understand right, it is bug in SDL1 , right ?
@Capehill Yeah current SDL1 already much better than old 1.2.13 and can be released as it already. Its not only bugs fixed by original authors, but also many amigaos4 bugs was fixed since as well (by you lately, but also in previous years by others) , also those new features (iconify, compositing, etc), code now cleaner and so on. Huge task, worth of release :)
Maybe only need to be released also as SDL2 with plain and debug libraries, so all will be same for both SDLs, as well as probabaly need to be merged with latest changes from main authors too (there was some fixes lately (like 10 days ago some buffer overflow fixed in SDL_pixel.c in both SDL2 and SDL1))
I just found out why EasyRPG had no 2x zoom when started in windowed mode. The current_w and current_h fields of the SDL_VideoInfo structure wasn't filled in with the desktop resolution. https://github.com/AmigaPorts/SDL/pull/66
This is just like television, only you can see much further.
I do hve a question...if i open the "tests" directory (i have unpacked it in ram: i get a AmigaDOS requester telling me to
Please instert volume Hibernated: in any drive
Process: 89 "Workbench"
I didn't know that simple files could trigger AmigaDOS meessages...
EDIT: Nevermind, i had an .adf mounted earlier and it seems the system was still looking for it, although it was already unmounted from Diskimage.device
On my system the testgl example crash if i try to start two session of it
Quote:
Crash log for task "testgl" Generated by GrimReaper 53.19 Crash occured in module minigl.library at address 0x6D00EE94 Type of crash: DSI (Data Storage Interrupt) exception Alert number: 0x80000003
Yes, i can reproduce it also with SDL1 debug version. I do some test and i can say that i have atleast two kind of results when i run a second instance of that demo, or a freeze or a DSI crash and these seems happen randomly
As you may think it's probably caused by MiniGL, actually i'm using a beta version of MiniGL 2.23 (not yet publically released)
Crash log for task "testgl" Generated by GrimReaper 53.19 Crash occured in module minigl.library at address 0x6F8840B4 Type of crash: DSI (Data Storage Interrupt) exception Alert number: 0x80000003
Well, the crash is inside of MiniGL.library. You need to ask the person who made MiniGL 2.23 where / why it crashes. The library you provided doesn't have debug symbols.
Based on the first stack trace it seems to have happened during MGLUpdateContextTags() call. That's where SDL part points to.
If i remember correcly the version i have was the one compiled by HunoPPC for his Warp3D "GUI" project ... it should be based on an interim revision of 2.23 from the official repo, so not the very latest
I read that you are still trying to compile the very latest build now, maybe i can retry with the latest official build as soon as you release it, so eventually we can see if the bug i have on this SDL1 demo is an "official" bug or if it was just the interim version of MiniGL compiled by Huno to be blamed