@Capehill What i was fear of , yep.. So , the only solution to do it as done in SDL1 version , as i understand , with that "Screen = SDL_SetVideoMode( 0, 0, 0, SDL_Flags );" , they just recreate window, without destorying context attached to it (or something of that sort ?). Is there anyway it can be done with SDL2 ?
@Capehill Yeah ! It works ! Through found little issue. There is test code i use (just press "space" to switch bettwen resizable/non-resizable window as much as you want till cube rotated).
glClearColor(0.0f, 0.0f, 0.0f, 0.0f); // black
glClearDepth(1.0);
glDepthFunc(GL_LESS);
glEnable(GL_DEPTH_TEST); // enable depth test
glShadeModel(GL_SMOOTH);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
gluPerspective(45.0f, (float) width / (float) height, 0.1f, 100.0f); // set 3d perspective
glMatrixMode(GL_MODELVIEW); // enable 3d mode
}
#ifdef __WIN32__
int WinMain(HINSTANCE, HINSTANCE, LPSTR, int){
#else
int main(int argc, char *argv[]){
#endif
init();
float xrf = 0, yrf = 0, zrf = 0;
bool running = true;
int a = 0;
while(running){
xrf -= 0.5;
yrf -= 0.5;
zrf -= 0.5;
drawCube(xrf, yrf, zrf);
SDL_Event event;
while ( SDL_PollEvent(&event) ){
switch(event.type){
case SDL_QUIT:
running = false;
break;
case SDL_KEYDOWN:
switch(event.key.keysym.sym){
case SDLK_ESCAPE:
running = false;
break;
case SDLK_SPACE:
if (a == 0) { a = 1; SDL_SetWindowResizable(glWindow,SDL_TRUE); break;};
if (a == 1) { a = 0; SDL_SetWindowResizable(glWindow,SDL_FALSE); break;};
break;
}
break;
}
}
Now issue is : if you run that example, then drag the window somewhere on workbench and then press "space" , then, together with adding resizable gadget window jump to the middle of the screen.
And that happens after eacht "2 presses" if you move window after each other to some new place : it then place to the place where was previous window.
And that "non remember of window position on screen" happens only after resizable gadget added. When you press "space" from the pure window (while non resizable gadget added), then it stays on the same position.
@Capehill Yeah, all fine now :) and that pretty nice feature should to say :) We can see of course fast close/opening of window but then that probabaly the only way we can do it on os4, and functionality are how it should be, so all good, thanks a bunch
Btw, have a question : should the window when we add/remove resize gadget jump inside of workbench borders ? I.e. i move for example window out of workbench for half of window, then press "space" in my test case (to enable/disable resize gadget), and then window jump inside of workbench borders.
@Capehill Found today that you implement native threads in SDL2 instead of pthreads, so want to give it a go now. And the question is: are internally any SDL2 apps will use it, or, I need to find particular one which relies on threads to test it? Or it just enough to build any game with native-thread-version to check if that works?
Audio apps will have the second thread always in addition to the main one. SDL comes with tests such as testtimer, testsem, testthread and torturethread.
Some of these test (testsem & torturethread?) are super intensive and take a long time to run: you can decrease their thread count from 10 to a smaller number if you wish to do other things anytime soon.
Testsem requires initial semaphore count, it should be > 0, otherwise you need to break it with multiple CTRL-C.
This patch also improves SDL_GetPerformanceCounter accuracy. On X5000 the clock rate is 50 MHz, so it should provide 20 ns resolution.
@Capehill At least I tried to rebuild diablo with sdl2's native-threads: all works. In diablo, it gives +1 fps for sure (tested many times: the previous version gives 137-138 fps, version with native threads give 138-139 fps). I tested about 5 times different versions after reboots, etc, there always +1fps with "native threads" version.
Also, I can see in the task list that now there are not 2 "pthread" processes as before, but "SDL Thread SDLAudioP1" and "SDL Thread SDLTimer".
@Capehill Do you aware if SDL2 has any kind of global "fps limiter"? Why I ask, is that SDL always hit 100% CPU with many games (probably because want to take maximum fps from it), and so sometime audio may "Sutter" because of that, our whole WB responsibility crawls a bit. So I think about how to limit globally it to at least not hog more than 95% of CPU, and we will have 5% left for "system tasks operational in the same fast speed".
@Capehill I mostly about those ones which we can control via "setenv" from console, so to try to lower a bit speed of games to see if it will then remove 100% cpu loading.
@Capehill Is "SDL_RENDER_DRIVER OpenGL" works as expected? I find out that with DOSBox compiled for SDL2 when I set SDL_RENDER_DRIVER to OpenGL, I just have a white window.
With "SDL_RENDER_DRIVER opengles2" i have a blue color in the place where should be black, and after few seconds just a freeze.
Also, another issue when I compile DOSBox with OpenGL usage and use that for output instead of software, the whole DOSBox starts to be slower on 50% in all operations. Even pure loading of any files, etc.
But as in Dosbox, OpenGL is only used as a Blitter.. So we basically create a texture for every dosbox frame, then update that texture, and simply blit it to the screen. The advantage of OpenGL is free scaling of the picture there (so to fit to fullscreen nicely)... but with the cost of having to update the texture at every frame... But i did't expect 2 times slower FPS, should't it be at least "the same" ?
Is "SDL_RENDER_DRIVER OpenGL" works as expected? I find out that with DOSBox compiled for SDL2 when I set SDL_RENDER_DRIVER to OpenGL, I just have a white window.
Is this the real MiniGL with classical Warp3D? Try SDL2 test programs (testsprite, testdraw2, testscale) with "--renderer opengl".
Quote:
With "SDL_RENDER_DRIVER opengles2" i have a blue color in the place where should be black, and after few seconds just a freeze.
Color channel issue is known but I haven't see a freeze ever.
Quote:
Also, another issue when I compile DOSBox with OpenGL usage and use that for output instead of software, the whole DOSBox starts to be slower on 50% in all operations. Even pure loading of any files, etc.
Do you mean DOSBox creates OpenGL context and calls all the OpenGL functions? Well, similar effect is visible if you compare "compositing" renderer against "opengl" (MiniGL). MiniGL loses in this kind use where texture is streamed. graphics.library bitmap update function is pretty fast and I will buy a beer to whoever wrote it.
Could it be partially due to Warp3D limitation of power-of-two textures? It could complicate texture update with NPOT dimensions.
Is this the real MiniGL with classical Warp3D? Try SDL2 test programs (testsprite, testdraw2, testscale) with "--renderer opengl".
That is real one. SDL2 test programms such as testsprite2, testdraw2 and testscale works fine, but when i run dosbox without config with "opengl" renderer set , then white window. But i assume it can be also bad sdl2 code inside of patch i apply for dosbox. I will later create a repo and we can check if you will have interest in.
Quote:
Color channel issue is known but I haven't see a freeze ever.
I noticed lately that i may have freezes from nothing, so it can be my setup as well.
Quote:
Do you mean DOSBox creates OpenGL context and calls all the OpenGL functions? Well, similar effect is visible if you compare "compositing" renderer against "opengl" (MiniGL). MiniGL loses in this kind use where texture is streamed. graphics.library bitmap update function is pretty fast and I will buy a beer to whoever wrote it.
I tried to build it also over gl4es (so no old warp3d, but new one, which probabaly ok with NPOT), and same issue => slower in 2 times. But it seems that it as it, opengl there is just really nothing, only to make "scalling" be good. I was hope i can have at least the same speed , but better keep software mode in this case.
@Capehill I tested win32 version of dosbox, and there if i set "opengl" to output in config, i didn't have 50% speed drop as we have on os4. Everything the same by speed.
I assume that our 3d drivers still.. still only amiga :)
Maybe its exactly that "non-dma" thing ? I mean, what else it can be , that it _that_ slower in compare with just pure graphics.library functions, which is even known to be non-dma on x5000 at moment..
I firstly think its big-endian issues with dosbox's code, but the man who do PPC JIT saying that he didn't have such issues on his ppc build (macos ppc and linux ppc), so he think that "the incorrect colors are due to the SDL port you're using".
Now .. how you _any_ idea where we can to start a look at and debug things to find what wrong ?
Thanks !
Edited by kas1e on 2020/1/22 19:28:07 Edited by kas1e on 2020/1/22 19:28:37 Edited by kas1e on 2020/1/23 8:11:29
1. That on about fullscreen/window switching. In games such as quake3 and in dosbox switching done via alt+enter. Now, when we use it in quake3 , then it didn't work as it. I.e. first "alt+enter" works. Then next, didn't. You need to realize alt, and press alt+enter again. Then it works.
In dosbox the same issue happens even worse : you hit alt+enter, and then, you can do anything until did't hit and realize alt button alone. Then alt+enter works.
It looks like after swithcing to/from window/fullscreen mode "alt" somehow "holds".
2. Second issue happens when we use native threads. It happens seems on machines such as x1000, sams, i.e. not x5000 ones. Crashlog point out that its nullpointer with 0x0000000 in dar, so i assume something should be opened for the older versions of os (like maybe dos.library again?).
Second issue is harder to track imho, while first one should be easy to reproduce.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
