Weird 3D look in latest builds
Closed this issue · 22 comments
Haven't tested older builds but this is how the delete dialog looks in 4.08:
and this is how it looks in latest build:
Other dialogs (e.g. shutdown) look ever worse.
Do you mean the new 3D look in EmuTOS? But this hasn't anything to do with teradesk builds?
I don't know who's to blame but the point is that the old Teradesk 4.08 doesn't do it, regardless of EmuTOS version (both screenshots were made as started from EmuTOS).
Just had a look at it again, and still don't understand why the two versions behave differently. The background of the dialog title is drawn by ub_title :
teradesk/library/xdialog/xddraw.c
Lines 1467 to 1474 in d558e58
So the color depends on xd_colaes flag and the value returned by xd_get_3d_colour(), which should be xd_ind_col in this case.
Those flags are set here
teradesk/library/xdialog/xdialog.c
Lines 2607 to 2608 in d558e58
teradesk/library/xdialog/xdialog.c
Line 63 in d558e58
Which is the same logic both for 4.08 and the current version.
Unfortunately, i can't compile the original 4.08 version with Pure-C (i did lots of changes afterwards to get it compiled), and as we saw recently, i can't use a gcc-compiled version with SingleTOS either. Any ideas were to look?
i can't compile the original 4.08 version with Pure-C
How so? The original sources were Pure C, weren't they? Or was it AHCC later on? Anyway, it should be still possible to compile the original so you can put some debug output in there.
Maybe the flag is randomly overwritten by something?
I think AHCC was used, but by using some extensions (eg. for the Mint functions) which are not available in the original Pure-C libraries and headers. Try to compile it with Pure-C, and you will get lots of missing/mismatched declarations.
Ok, after some twiddling i got it compiled with Pure-C (although i'm quite sure that will be some problems with functions being wrongly declared). But at least it starts up. However, dialog look like this:
Apart from the wrong font size, they use the same grey background as current version. This was using TOS 3.06 (no aes 3d, no color icons).
Oh. But you do see the original PRG without the 3D effects on the same setup, right?
Don't know which "original program" you tested with. I only have an older version here (4.06), and that looks the same on that setup.
BTW, the shutdown dialog looks like this in current version:
Is that really that bad?
I mean the last official binary released by Djordje: http://solair.eunet.rs/~vdjole/tera408b.zip.
TOS 3.06 + DESKTOPS.PRG of Teradesk 4.08:
TOS 3.06 + DESKTOPS.PRG of one of your snapshots:
So yes, it is really that bad.
... also has grey buttons here. And the source archive (which is also still available there) should be the one which was checked in as our tag VER_4_08 which i used in the tests above.
Your radio buttons are admittedly ugly, but i think this only happens in low resolution.
I could live with a grey button here and there but what is causing the difference in backgrounds and radio buttons then? Do you think that source code released along with it (http://solair.eunet.rs/~vdjole/tera408s.zip) is not matching the binary? That would be rather surprising as your 4.06 exhibits this behaviour, too (and I have never noticed it at all -- and I've been using Teradesk for many, many years).
Yes, i use teradesk too, but only in MiNT environments.
I have no idea why you don't get grey buttons (and some other 3d look). The code is quite clear, the flag is always set with >= 16 colors, and that seem to be the case for quite some time.
Since the binary that i have compiled from the source, and the one from his site behave the same, i don't think it is a mismatch between source & binary.
Only thing that you could maybe try, is to compile the source of 4.08 yourself, and see if that makes a difference. When you do this, make sure that you don't have an include path set in your shell options (the project file uses the one from the include directory, which are not identical to the original ones)
Since the binary that i have compiled from the source, and the one from his site behave the same, i don't think it is a mismatch between source & binary.
So you mean that if you download teradesk 4.08 from his site, run DESKTOPS.PRG, you do see the grey backround in the desktop preferences dialog, too?
I think it's crucial to establish whether it is a difference in our setup or you have just looked at a different dialog and/or in a different resolution.
I boot TOS 3.06, stay in ST-LOW, open Desk preferences and the grey background is there in your builds and not in the official.
Yes i do have grey buttons with his build (the last snapshot was from this program), but only for the buttons, not the dialog itself.
So yes, there must be something different with the setup. So imho the only way to find the cause is that you compile it yourself, then start adding debug printf or whatever to find out what is different.
Having TOS 3.06 and booting into ST-LOW doesn't seem like a lot of room for setup differences - I think we both agree that Hatari can't influence this kind of behaviour. :-P
Sorry, but i'm currently busy trying to fix the quirks in cflib, so that QED works again. Can't you just try to figure it out yourself?
BTW, when you say DESKTOPS.PRG, do you mean the singletos version (its normally named desktos.prg). That behaves slightly different, indeed.
BTW, when you say DESKTOPS.PRG, do you mean the singletos version
Indeed I do. I'll try to find some time later to take a look if you will be still busy.
Ok, there is a difference in behaviour because of a variable that i removed at some time. In the original version, it was queried here:
teradesk/library/xdialog/xddraw.c
Line 351 in d558e58
and it was set here:
teradesk/library/xdialog/xdialog.c
Line 2567 in d558e58
teradesk/library/xdialog/xdialog.c
Lines 2639 to 2650 in d558e58
teradesk/library/xdialog/xdialog.c
Lines 2731 to 2733 in d558e58
Especially the 3rd occurrence was imho nonsense, since the presence of appl_getinfo() does not indicate AES 4.x (WINX also supports appl_getinfo()). But surely that had an influence on the query in xd_is3dobj(). However, reverting it to the previous behaviour i now get
when running EmuTOS, but not when running TOS 3.06. That's not much better...
I guess that is thanks to the fairly recent addition of 3D look support to EmuTOS.
Don't get me wrong, I have nothing against 3D buttons and such but a) I wanted to make sure that it is understood when (and why) the change of 3D has occured and b) that it looks at least equally good.
So far, I'd be totally fine to get the flat look in TOS 3.06 and semi-3D look in EmuTOS (as it is native now).
IMO it would look pretty strange if only Teradesk had some sort of 3D buttons in TOS 3.06 while all other applications would look flat.
I guess that is thanks to the fairly recent addition of 3D look support to EmuTOS.
Yes, for sure. You can see that because the "Open" button is slightly larger.
IMO it would look pretty strange if only Teradesk had some sort of 3D buttons in TOS 3.06 while all other applications would look flat.
Its not unusual that applications draw some elements like buttons with their own functions, and use 3D look for that. But typically they do that only when the AES does it, too. ORCS can also do that, but then either both the background and the buttons are grey, or white, not that strange mix in teradesk.
The patch where i removed that flag tried to simplify things (look at all the flags that are used for this in xddraw.c, that's quite ugly and hard to understand).
Anyway, i think i'll mostly revert that patch, so things will look like before. Teradesk will mostly be used in Multitasking-environments anyway, and there xd_aes4_0 will always be set (because appl_getinfo is present).
Confirmed as fixed, closing.