fade_down engine differences fix
In vanilla 1.08 and YeoldeDink: Fades the entire screen down, including the status bar, and text sprites are still fully read-able.
In FreeDink: Fades the entire screen down, including the status bar, and text sprites are only readable, unless you play in Full Screen mode or re-size the window in window mode, then you can get un-readable text.
Dink Smallwood HD: Fades the playable area of the screen down, not the status bar(unless &update_status = 0), and text sprites do not show up at all.
Not very consistent. For any author wanting to assure some form of consistency, no matter what engine a player plays their dmod in, I wrote a custom fade_down and fade_up procedure you can easily call with external(), to replace the normal fade_up and fade_down.
For this you will need to make sure you have a 640x480 sprite completely filled black, make one or download it here: cover sprite
Put that in your graphics folder, you don't need to add anything to dink.ini, I named it title-02, to just add it as a frame in the already loaded title sequence.
Now, download this script and put it in the story folder: fade.c
Now to fade down in a script all you do is:
to fade up:
This will completely fade the screen down in all engines, including the status bar and all text will be read-able. Added bonus is text in whatever colour. Usually on fade_down all text appears white.
There are some extra arguments you can pass to slightly alter how the cover sprite works, you can look at fade.c if you ever want to use those, but you shouldn't need to.
In FreeDink: Fades the entire screen down, including the status bar, and text sprites are only readable, unless you play in Full Screen mode or re-size the window in window mode, then you can get un-readable text.
Dink Smallwood HD: Fades the playable area of the screen down, not the status bar(unless &update_status = 0), and text sprites do not show up at all.
Not very consistent. For any author wanting to assure some form of consistency, no matter what engine a player plays their dmod in, I wrote a custom fade_down and fade_up procedure you can easily call with external(), to replace the normal fade_up and fade_down.
For this you will need to make sure you have a 640x480 sprite completely filled black, make one or download it here: cover sprite
Put that in your graphics folder, you don't need to add anything to dink.ini, I named it title-02, to just add it as a frame in the already loaded title sequence.
Now, download this script and put it in the story folder: fade.c
Now to fade down in a script all you do is:
external("fade", "fade_down");
to fade up:
external("fade", "fade_up");
This will completely fade the screen down in all engines, including the status bar and all text will be read-able. Added bonus is text in whatever colour. Usually on fade_down all text appears white.
There are some extra arguments you can pass to slightly alter how the cover sprite works, you can look at fade.c if you ever want to use those, but you shouldn't need to.
>and text sprites do not show up at all.
Would be worth nagging Seth about, as the "text in the dark" technique is a fairly common one, and I haven't noticed any previous discussion about this, suggesting that it's something that broke more recently.
Would be worth nagging Seth about, as the "text in the dark" technique is a fairly common one, and I haven't noticed any previous discussion about this, suggesting that it's something that broke more recently.
Hmm, so we want text sprites (and choice menu text?) to always be visible even during a fade down effect?
Anyone know a DMOD that has an intro using this so I can see and test it easier?
I don't remember changing that specifically in the past, but it could have happened in DinkHD as a bi-product of some related changes I see:
------ Change log for 2.02 ---------- (November 2023)
* say() text is now drawn under choice menus rather than above, previously dmods that used sp_kill to make text permanent could cause visual problems in choice menus (Robj)
* Overlapping text is easier to read now, for two reasons, the main problem was Proton SDK does batching under the hood (this didn't exist when the original Dink HD was made) and it was trying to batch all the the text backgrounds together on the same layer which isn't what we wanted, and two, I made the bg slightly darker
Anyone know a DMOD that has an intro using this so I can see and test it easier?
I don't remember changing that specifically in the past, but it could have happened in DinkHD as a bi-product of some related changes I see:
------ Change log for 2.02 ---------- (November 2023)
* say() text is now drawn under choice menus rather than above, previously dmods that used sp_kill to make text permanent could cause visual problems in choice menus (Robj)
* Overlapping text is easier to read now, for two reasons, the main problem was Proton SDK does batching under the hood (this didn't exist when the original Dink HD was made) and it was trying to batch all the the text backgrounds together on the same layer which isn't what we wanted, and two, I made the bg slightly darker
I just created a one screen dmod to test it easily: fade.dmod
Start the Dmod and talk to the rock.
The normal expected Dink engine behaviour as per the DinkC ref is that all text will appear white and all white pixels remain visible. I have the differences in Dink HD listed on that page of the reference, but will remove them when it gets fixed.
So that means the choice meanu graphics themselves should not appear in front of a fade down, but the text should. Which when testing in another engine yielded that result. This is a choice menu during fade down in FreeDink for example: choice menu during fade down
I guess authors don't usually throw up choice menus on a faded_down screen, but it's common to do text.
EDIT: As a side note. In that fade.dmod I just posted, I just noticed that the text is outta bounds of the DinkHD "dark text background" on the left too: Text outta bounds slightly on left
Start the Dmod and talk to the rock.
The normal expected Dink engine behaviour as per the DinkC ref is that all text will appear white and all white pixels remain visible. I have the differences in Dink HD listed on that page of the reference, but will remove them when it gets fixed.
So that means the choice meanu graphics themselves should not appear in front of a fade down, but the text should. Which when testing in another engine yielded that result. This is a choice menu during fade down in FreeDink for example: choice menu during fade down
I guess authors don't usually throw up choice menus on a faded_down screen, but it's common to do text.
EDIT: As a side note. In that fade.dmod I just posted, I just noticed that the text is outta bounds of the DinkHD "dark text background" on the left too: Text outta bounds slightly on left
Thanks! Ok, fixed it up, looks right to me. Updated the web build to 2.06.
Also tweaked text to fit in the box, wasn't able to find the actual bug (possibly something to do with how the font engine handles kerning) but worked around it by just adding a bit more space. I'll release the Windows 2.06 soon.
Also tweaked text to fit in the box, wasn't able to find the actual bug (possibly something to do with how the font engine handles kerning) but worked around it by just adding a bit more space. I'll release the Windows 2.06 soon.
Hmmm, is there a way of not having the status bars show after a fade down() and fade_up()? For a cut scene to play without that stuff showing?
I thought you could do that back in the day.
But now you don't have to call draw_status() after a fade up, as the draw_screen() does that, even if &update_status is set to 0 again during a game.
I thought you could do that back in the day.
But now you don't have to call draw_status() after a fade up, as the draw_screen() does that, even if &update_status is set to 0 again during a game.
Hmmm, is there a way of not having the status bars show after a fade down() and fade_up()? For a cut scene to play without that stuff showing?
You can still do that. The way to accomplish it, I believe is the same in all engines (at least 1.08+ I dunno about pre 1.08). After fading down, do a fill_screen(0) to fill the entire screen black, just make sure to do draw_background, which will bring the rest of the screen back, except the status bar. The status bar won't come back until draw_status() is called, even in DinkHD.
I believe the only difference with fade_down in DinkHD now is that you must set &update_status to 0 before a fade_down to make the status bar fade down, otherwise only the screen will. Which isn't a big deal, I think, in fact it gives the option now to only fade_down the playable area if you don't set that, which i guess you couldn't do before.
You can still do that. The way to accomplish it, I believe is the same in all engines (at least 1.08+ I dunno about pre 1.08). After fading down, do a fill_screen(0) to fill the entire screen black, just make sure to do draw_background, which will bring the rest of the screen back, except the status bar. The status bar won't come back until draw_status() is called, even in DinkHD.
I believe the only difference with fade_down in DinkHD now is that you must set &update_status to 0 before a fade_down to make the status bar fade down, otherwise only the screen will. Which isn't a big deal, I think, in fact it gives the option now to only fade_down the playable area if you don't set that, which i guess you couldn't do before.
Thanks,
wrote a test script and works the way I wanted
wrote a test script and works the way I wanted
int &omap = &player_map; &update_status = 0; script_attach(1000); freeze(1); fade_down(); &player_map = 752; wait(200); fill_screen(0); load_screen(); draw_screen(); draw_background(); //draw_status(); fade_up(); freeze(1); wait(3000); fade_down(); &player_map = &omap; wait(200); load_screen(); draw_screen(); draw_status(); &update_status = 1; fade_up(); wait(1000); unfreeze(1); kill_this_task();