@Capehill, Raziel Just to let you both know: that fix for issue with stretching textures which Capehill find out to be fixed just by replacing "&&" to "||" in the glTexImage() was added by Daniel to the minigl repo, as well as he fix the same issue with glCopyTexImage2D().
-- Fixed crash when resuming game from saved state when viewing a design. -- Add call to SDL_DestroyRenderer and SDL_DestroyWindow, rather than just relying on SDL_Quit (so no VRAM leaks on amigaos4) -- If playing with nukes disabled, more sectors can now instead build spaceships.
Not played but just tried to iconify/deiconify the game while the audio output was busy by TuneNet, after 2 or 3 attemps i got a crash
-----------
Crash log for task "gigalomania" Generated by GrimReaper 53.19 Crash occured in module gigalomania at address 0x6BA198E0 Type of crash: DSI (Data Storage Interrupt) exception Alert number: 0x80000003
@samo79 Why i not surprised :) If you want to test something give it to samo79 : on his machine everything crashes always and always no reproducable test-case ?:)
Tried to reproduce it on x5k here,and can't :( Running tunenet to play some audio for a while, and then iconify/deiconfigy about 30 times, without crash.
1 - Open TuneNet and play somethings ... maybe a streming radio 2 - Then start the game, then go into any area that play an audio (intro is ok too) 3 - Try to iconify/deiconify the game
If not reproducible at first attempt, try again 2 or 3 times ..
@samo Still can't.. It can be easyly reproducable on your one as maybe it have less ram (both and gfx and system one)..
Maybe somehow tunenet settings related somehow ?
Also, are you sure there is needs for iconify/deiconify ? I mean, when you iconify/deiconify game, it "pause" (you can heard "put on a hold" voice). So maybe you need to try just pressing "p" many times.
Is it crashes when you deiconify , or when you iconify ?
@samo79 I got a crash one time now, when tunenet runs, i run game, and while game loaded, i move volume slider of tunenet => crash. Kind of strange, but so amiga when you do something in one programm, but another one crashes because of it :))
@samo79 Dunno what to say, its very strange, and happens only when tunenet plays.. Maybe tunent trash some memory ? Are you able to reproduce it without tunenet running ?
@Capehill Btw, in your quake3 SDL2 port , did you add any other specific changes to the rendering part (or maybe blitting or something?) which can cause that effect:
? I just trying to understand from where start to find out the roots of that distortion. With minigl all is ok through, it is with gl4es (while, quake3 which i port from another repo which use SDL1 , works fine and over minigl and over gl4es).
@Capehill Is it only file which is related to how create context and handle all the stuff for opengl are SDL_os4opengl.c and SDL_os4openglwrapper.c ? I mean, can it be somewhere else in SDL2 something, done specially for minigl only, which, in turn, can cause that, when used not minigl, but any other version of opengl ?
ps. In latest versions of SDL2 , i also had to fix in SDL_os4video.c, that part:
static int
OS4_LoadGlLibrary(_THIS, const char * path)
{
dprintf("Profile_mask %d, major ver %d, minor ver %d\n",
_this->gl_config.profile_mask,
_this->gl_config.major_version,
_this->gl_config.minor_version);
I had to comment out check on OS4_IsMiniGL(), as you hardcode there 1.3 version, while GL i used with SDL2 are 2.x. I mean as it now, it is like any version of GL which will be used with SDL2 , mean to be minigl and be 1.3.
And probabaly OS4_SetMiniGLFunctions() name, can be rename to OS4_SetOpenGLFunctions() , so it will be logical when one will want to use in SDL2 something else instead of MiniGL
If we will find some reproducable test case with tunenet's volume slider, we can made a proper bug report. If we can't find reproducable test case, it will be not fixed then :(
If we will find some reproducable test case with tunenet's volume slider,
Looking at the TuneNet source code I can see that the volume slider is an instance of sliderbar.gadget (i.e. not the standard OS slider.gadget). So the reasonable first step to take is to determine whether the problem is actually caused by TuneNet, or by the sliderbar.gadget class.
Ask Andy to replace the sliderbar by the original slider gadget (the code is still there, commented out) and if the problem disappears, then we know we need to have a close look at the sliderbar.
@Capehill Yeah, i stripped it for release, as without it can be 2-3 times bigger. But can build debug version for tests of course.
Just if samo79 says,that tunenet's new slider sometime cause "unstability of system" just by itself (wihotut anything else running), then.. But will build debug version of gigalomania anyway.
@Capehill Checked very latest SDL2, and can confirm that issue with "white dot" are fixed. Also all compiles fine over public SDK now as well. Thanks !