amigaos4: missing background textures in intro and in tittle menu
kas1e opened this issue · comments
As topic says , on amigaos4 we have problems with missing background images in the intro of game, and some images missing in the tittle menu (like sprite of the player at the left bottom side).
So create ticket there, to discuss only that issue.
Just to understand what is wrong, can you change in src/wid_intro_demo.c line 491 from
wid_fade_in(w, 2000);
to
wid_fade_in(w, 0);
and see if 1st background of the intro is there?
Nope, still not there..
Found something interesting, if i change the line above that one (490 one):
wid_move_delta_pct_in(w, 0.0f, -0.3f, duration);
to
wid_move_delta_pct_in(w, 0.0f, 0.3f, duration);
I.e. remove "-" , then, i can see the background , but it move down (i.e. background texture slowly moving down). But it start to be visibly.
Maybe it's something about compiler flags use with ? I have those ones : -ffast-math -fsingle-precision-constant -ftree-vectorize
And set that part instead of -0.3f to 0.0f , make background be visibly as expected. Strange !
So the -0.3f value doesn't work correctly? Interresting, I'll check how this could break...
In src/wid.c, line 10408, can you add
printf("%g/%g (%d/%d)\n", x, y, global_config.video_gl_width, global_config.video_gl_height);
And give me a few values on the 1st demo screen?
So the -0.3f value doesn't work correctly? I
-0.1f also didn't work,i.e. any negative values
And give me a few values on the 1st demo screen?
Strange but when demo1 screen appear, no values prints. They only prints when i go to the menu (maybe becaues of needs for something like fflush(stdout)? )
So when i go to menu, those values dums:
-1310.56/0 (1008/672)
16.0359/0 (1008/672)
1538.24/0 (1008/672)
-20.7205/0 (1008/672)
768.442/0 (1008/672)
436.099/0 (1008/672)
-1006.34/0 (1008/672)
and so on
Now when i add fflush(stdout); , then it prinfs right before background should be show and that what i have:
intro1: 0/-201.6 (1008/672)
intro2: 0/-201.6 (1008/672)
intro3: 0/-67.2 (1008/672)
something like that
Yeah, maybe some flush is needed.
Another test: in the wid_move_delta_pct_in call of line 490, can you remove the f in the float value, to have double instead of float?
Ah ok, so the x/y values seems correct.
Removing "f" but keeping -0.3, make no differences.
Interesting, that if i put instead of -0.3 , 0.0 , and then run it with your prinf, then itsays 0/0 (1008/672). I.e. no negative value, and texture visibly
Do you think its something about double/float replacements ?
Maybe something with SDL2 even ..
I think something doesn't want to blit the texture if it's partly out of screen. But I'm not sure yet.
Here, another test:still in src/wid.c, line 8888, insert:
printf("wid \"%s\"(%s) : %d/%d-%d/%d\n", w->name, w->logname, tlx, tly, brx, bry);
Maybe add a fflush also.
That will print quite some stufff.
I'm interested in this line:
wid "intro1"(intro1[0x7884240]) : 0/-19-800/703
The "intro1" should be the widget than contains the background texture. Your values will be different (because we don't have the same screen resolution).
And a last test, still in the same file, can you comment the whole glScissor command, lines 9088-9093
The first time when i have "wid "intro1" , give me that:
wid "intro1"(intro1[0x5512d5d8]) : 0/-30-1008/981
Then there is some other"wid intro1" strings come too, but probabaly first one is the one you interested in ?
And a last test, still in the same file, can you comment the whole glScissor command, lines 9088-9093
Commenting out scissoring part, behave like that : intro texture shown full fast, then black screen, then when scrollling happens , i can see the background textures only under the part where text scrolls. But , at least i can see parts of background textures for sure.
Ok, interresting.
Line 9087, can you add
printf("scissor=%d/%d/%d/%d\n", tlx / global_config.xscale, global_config.video_pix_height - ((tly + clip_height) / global_config.yscale), clip_width, clip_height);
So we can see what value it tries to create scissor...
mm, wait, there are some float that need casting.
Try this one instead:
printf("scissor=%d/%d/%d/%d\n", (int)(tlx / global_config.xscale), (int)(global_config.video_pix_height - ((tly + clip_height) / global_config.yscale)), clip_width, clip_height);
Well , hard to notice what printfs come for what, there is many, but at least i can see lines with negative values (dunno if they related to our part, but at least visually they come when intro going):
0/-311/1008/1011
Yeah, my guess is negative value brake you glScissor.
mm... how to test it easyly now so i can report issue to glScissor()..
Lest's prove it: here is a change for the glScissor command for Amiga:
#ifdef __amigaos4__
int sx = (int)(tlx / global_config.xscale);
int sy = (int)(global_config.video_pix_height - ((tly + clip_height) / global_config.yscale));
int sw = clip_width;
int sh = clip_height;
if (sx<0) {sw+=sx; sx=0;}
if (sy<0) {sh+=sy; sy=0;}
glScissor(sx, sy, sw, sh);
#else
glScissor(
tlx / global_config.xscale,
global_config.video_pix_height -
((tly + clip_height) / global_config.yscale),
clip_width,
clip_height);
#endif
I'll do a workaround in gl4es while you wait for a fix on your side.
Mmm... sadly but nope :( still same black screen !
Oh, is it? Strange. Can you printf sx, sy, sw and sh ?
But its definately something with scissor. As while that ifdef didn't fix intro background, it fix to have the left-bottom character in the menu ! As well as it fix the scrolling of those "hero-sprites" when i choice "play game" !
Maybe just another glScissor call somewhere need to be ifdefed too.
This one for sure fix not intro-backgrounds, but sptrites in menu and in "play-game" selection, that for sure. And they moves now as should , etc
A little futher in code (500 lines down) there is another glScrissor call, maybe that one ?
Why not, but I'm working on a workaround in gl4es for now (at least for negative x/y value).
As for creating a sample to reproduce the bug, just take a sample that show a texture triangle, and apply a glScissor with a negative y value, that should be enough.
Hm, nope, ifdefed second glScissor didn't fix background textures in intro for sure..
So, added printfs, and there is no negative values anymore. But some are offten 0 , so maybe not only negative ones, but also 0 ?
will try to put 1 instead of 0 now
nope, setting 1 for sx and sy didn't fix background texture in intro too..
I probably need to reupload repo, and rebuild it with new gl4es with workaround, so we can see how and what changes.
Maybe there we lucky to have 2 issues with glScissor, one are negative values one, another something else :) Will try to play with "sw" and "sh" values.
Just to test, try this one:
#ifdef __amigaos4__
int sx = (int)(tlx / global_config.xscale);
int sy = (int)(global_config.video_pix_height - ((tly + clip_height) / global_config.yscale));
int sw = clip_width;
int sh = clip_height;
if (sx<0) {sx=0;}
if (sy<0) {sy=0;}
glScissor(sx, sy, sw, sh);
#else
glScissor(
tlx / global_config.xscale,
global_config.video_pix_height -
((tly + clip_height) / global_config.yscale),
clip_width,
clip_height);
#endif
(not adjusting sw or sh)
Nope, same black :( And now even in menu half of things are black too.
Interestingly, that if i change in previous variant , to something like:
if (sx<0) {sw+=sx; sx=0;}
if (sy<0) {sh+=sy; sy=0;}
glScissor(sx, sy, sw, 50);
Then, while i didn't see first "loading" screen, fully, just a little line, i can see in intro that i have half of texture shown, as well as scrolled font. The more increase i that value, to more i see.
With setting it to 500, i can see almost whole texture, but this time , not text visibly.
Setting it to 600, make "loading" screen be almost non visibly, can't see text in intro, but background almost full shown. Then 650 its almost full , then 670 very close.
And last one, 672 (that the value of my window height choicen - i can't see loading screen, can't see any text, but whole background texture there, whole menu there (without text too).
Then 673 (to be a 1 pixel bigger than window width : no background texture , just a black screen.
Put printf for that "sh" value, and can see that it starts from 699, then 700, 701 and more when we in intro. So, there something with "when it bigger that actual window heigh, then black screen".
In menu all visibly fine, because it always heigh less than window heigh (i see only values line 672, but not more).
So for sake of tests i do that:
if (sx<0) {sw+=sx; sx=0;}
if (sy<0) {sh+=sy; sy=0;}
if (sh>672) {sh=672;}
glScissor(sx, sy, sw, sh);
Then all fine, intro there, background texture there, texts scrolls, and all fine.
So we are lucky to have 2 bugs then ?
I am about to send a mail to Daniel with bug report, so is it fine enough ?:
first issue are "negative sx/sy value" broke scissoring on our side. Everything start to be black (on win32/opengl and on pandora/gl4es same code fine of course).
second issue about "h" , once it bigger than actual window heigh, then also black screen (while on win32/opengl and on pandora/gl4es same code works too).
So doing that fix it for all window height:
if (sx<0) {sw+=sx; sx=0;}
if (sy<0) {sh+=sy; sy=0;}
if (sh>global_config.video_gl_height) {sh=global_config.video_gl_height;}
glScissor(sx, sy, sw, sh);
That second issue probabaly not exactly glScissor code only, and it can't be workarounded in gl4es as it seems involve native window size, etc ?
Tried to use last gl4es with workaround : it crashes right after it open ogles2 library, in gl_init() calling NewGLState() . Can ignore that crash (so it seems not something very heavy), and can see that workaround for negative values works.
I think I fixed the crash and pushed the fix.
Now yes, glscissor seems to not work on amigaos4 if any of the dimension is outside the screen / viewport (not sure).
I'll try to improve the gl4es workaround by checking width/height against the current viewport size...
Yeah, crash fixed
And I pushed the improved workaround for glScissor
And yes, that did the trick ! :) That was intersting bug-huntings, thanks !
I also got an answer from Daniel, he says that it mostly his fault, as its he in ogles2 driver should clamp the values for too big, for negative ones, etc ,etc. So, next version of ogles2.library will containt a fix , but until then le'ts workarounds be in place.
So we can close that ticket and back to previous one probabaly .. :)
Yep.