Found issue with recent version: i do not know if it related to the latest changes being made, or it there for a while since 2.0.8 release, but for now, just this simple test fail:
#include <SDL2/SDL.h>
int main(int argc, char *argv[])
{
I compile it, run , and it fail with words : Error initializing SDL2, aborting!
It is SDL_INIT_GAMECONTROLLER which make it fail, but 2.0.8 version works with that test case for sure. Maybe that happens when "PATH" defines was changed ? Or those related to cursor changes ?
And before it fail, last what i see on serial are:
Quote:
[OS4_VideoInit] Called [OS4_InitModes] Called [OS4_LockPubScreen] Public screen 0x6C6B6388 locked [OS4_GetDisplayMode] RTG mode 1342706432: w=1920, h=1080, bits=24 [OS4_CreateDefaultCursor] 0x69E840F8 [OS4_CreateHiddenCursor] Called [OS4_CreateCursor] Surface 0x69E84120, cursor 0x69E84200, hot_x 0, hot_y 0 [OS4_CopyImageData] Copying cursor data 1*1 from surface 0x69E84120 to buffer 0x69E84228 [OS4_GetDoubleClickTimeInMillis] Doubleclick time 1500 ms
@Capehil Found another issue, but dunno if it related to our SDL2 port or to something else, but, in 2 games i have control settings. In which i can choice everything, but when i press "right ctrl", it say me "left ctrl". When i press "left ctrl" it says "left ctrl" as should. For "alt" all is fine, "right alt" is "right alt" and "left right" is "left right".
@Capehill The word "left control" come from SDL2 or from some low-level like keymap.library or something ? I mean, if there is one single control even for aos4 , maybe it better call just "ctrl", without "left" at begining (if that possible of course to do from SDL2 side?)
@Capehill If it not possible from os4 side to detect left and right ctrls, then have just "ctrl" word when press left or right ctrl for sure better than have words "left ctrl" when press both left and right ctrls.
If, of course, is not too boring to change.
Through strange, is it for real that we didnt have rawcode for both left and right ctrl ? I mean its os4 in end, almost everyone use usuall pc keyboards
@Capehill Checked latest commits (Make AmigaInput backend functional again), and all compiles-works as expected now. Thanks !
Btw, what i notice as well, since some time, when one build sdl2, compiled objects placed not only to the "build" directory, but also they copied to the "build/.libs" as well, while before it was like objects to root of "build" , and in ".libs" only ready libs.
Probabaly some changes in configure script done lately cause that. Not that this is _that_ important anyway :)
Usually object files in .libs/ are those compiled with -fPIC, for the .so, and the ones in the parent directory are those without -fPIC, for the .a. The final .so and .a both end up in .libs/. That's the standard autotools+libtool way.
I just broken my head but can't get what it can be with that non-rendering of q3 in a window when it more than workbench size. And only for SDL2 version. With SDL1 vesion no such issues over gl4es or over minigl.
The funny thing is:
When i use or minigl, or gl4es (so warp3dnova/ogles2), over SDL1 , then in both cases all renders fine.
When i use SDL2, then, with minigl version, all renders fine, with gl4es version black screen (but game runs, etc, just nothing renders, i only can see system's mouse cursor). And it only when size of window bigger than workbench. And only in window mode, in fullscreen all fine.
I can think for first about gl4es being guilty : but then it works over sdl1. Then i think maybe there is some hack in the minigl/old warp3d, but then, gl4es works over sdl1 , which mean no minigl/old warp3d involved.
I compare all the debug output of the minigl and gl4es builds over SDL2, they all identical, same values everywhere for all sizes.
What else it can be ?
Hans in another thread wrote that since this involves a width > screen size, it's possible that something like unsigned arithmetic is mucking it up. But then why it works over sdl1 then and for minigl and for gl4es, and why it works for sdl2 only for minigl..
Just dunno where to start. I can put printfs all over the places, just which part need to be debugged..
There is my current version of gl4es's SDL_os4opengl.c (in case you can see something which may cause that):
@Capehill Add some debug code to the gl4es, to see , what differences viewport coming from sdl2 has, and , when i have set in q3 1600x1200 window mode, when my screen are 1920 x 1080, then, with SDL1 viewpoer width and heigh return as expected 1600x1200 , but with SDL2, it return 1600x1048 ! Which is kind of wrong.
Its kind of strange, because i would have thought the viewport to be the size of the entire window (so 1200), and not the visible part 1048 only.
I trying to add hardcore 1600 and 1200 values in the SDL2 inside of OS4_GetWindowActiveSize() , and while gl4es printf out that viewport now 1600x1200, it still render black screen on me, which probabaly mean something else somewhere related to viewport doing things which cause that effect.
Have any idea where to start to debug in SDL2 to see what happens ?
Even if the viewport would be smaller than expected, in my opinion it doesn't explain black display. There should be a smaller image drawn.
It's quite difficult question because, for starters, there are 2 different applications, Q3_sdl1 and Q3_sdl2.
I don't understand from the description how the issue is triggered. Do you get first a working display, then resize using display menu, and then display goes black? Or is the display black from the beginning?
If it didnt, other resolutions will not work, but all works and renders fine till i didnt choice q3s window mode bigger than size of workbench (in fullscreen all fine of course)
I.e if i set worbench to 1920x1080, and then run q3-sdl2-gl4es in window mode with any resolution less than 1920x1080 all fine. But once i change resolution in window mode to 1600x1200, or bigger (i.e. any which bigger than wb) i have black window. If i aply it and quit / run q3 with that resolution being set, i even didnt see "id" logo animation, just black window.
It should'nt be exactly 1920x1080 for workbench and 1600*1200 window mode in q3, it can be any resolution of wb and bug will be triggered when i will choice any resolution in q3 window mide bigger than wb.
And it didnt happen with sdl1 version of q3 compiled or for minigl, or for gl4es, and only happen with sdl2 version, and only when compiled for gl4es.
Its all sounds like in case with sdl2, minigl do something (or not do), which make rendering of bigger that wb window modes renders fine, but in case with gl4es/ogles/warp3d nova and sdl2 code of q3 it seems do something different.
Just how to understand what and where, and where put more debugs to sdl2 to find more info
Did you check also viewport's X/Y parameters? Are they sane in the oversized window case?
When MiniGL is used, SDL always blits the whole buffer to the window (0,0 ... w, h). You are letting OGLES to manage the buffers so I'm not sure what we could check in SDL2 side at the moment.
Can you try some hellotriangle example with OGLES using over-sized window? Everything fine?
EDIT: have you tried glGetError() at the end of the frame?
Did you check also viewport's X/Y parameters? Are they sane in the oversized window case?
Yeah, in SDL1 and in SDL2 versions all the time 0,0 too.
Quote:
You are letting OGLES to manage the buffers so I'm not sure what we could check in SDL2 side at the moment.
I just thinking about viewport only because i find out difference only there.. It can be anything else of course. I can understand if it didn't works with sdl1 and sdl2, but it didn't with sdl2 only , and only with gl4es , with minigl still fine.
Quote:
Can you try some hellotriangle example with OGLES using over-sized window? Everything fine?
You mean inside of the q3 code, or inside of sdl2 ? I only tried so far doing this inside of createcontext() in the sdl2:
dprintf("OpenGL ES 2 context %p created for window '%s'\n",
data->glContext, window->title);
// Some games (like q3) doesn't clear the z-buffer prior to use. Since we're using a floating-point depth buffer in warp3dnova,
// that means it may contain illegal floating-point values, which causes some pixels to fail the depth-test when they shouldn't,
// so we clear the depth buffer to a constant value when it's first created.
// Pandora may well use an integer depth-buffer, in which case this can't happen.
// On MiniGL it didn't happens as there is workaround inside of old warp3d (and probabaly inside of MiniGL itself too).
// in SDL1 with gl4es (so warp3dnova/ogles2, where no such workaround) it didn't happens probabaly because SDL1 doing something like that (but not glClear).
} else {
dprintf("Failed to create OpenGL ES 2 context for window '%s' (error code %d)\n",
window->title, errCode);
SDL_SetError("Failed to create OpenGL ES 2 context");
return NULL;
}
return NULL;
}
It create oversized window, saying me for viewport valud 1600x1048, x=0,y=0 , and then draw the quad as expected, wait 10 seconds and then , when "ID" anymation should starts : black window :)
Quote:
EDIT: have you tried glGetError() at the end of the frame?
Do you mean in q3 code, or inside of SDL2 , right after aglSwapBuffers() ?
Perhaps it draws in screen's bitmap not the window one. I mean as window is bigger it must have a separate bitmap (dont have a shared bitmap for dcreen and bitmap) Search for "->bitmap" use in sources
@theiller Then why it happens only with Q3, and not with another game, where i set oversized window ? It should be in any game then be like this, not only in Q3.
@Capehill Tried your "control-key" branch as well : at moment in the game i linked with new sdl2 library it still writen left ctrl. Probably needs changes in all the game's codes as well. For example in one i have in one game:
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
