Reply to Proposal for HD and YeOldeDink: a function to check if a feature is supported
If you don't have an account, just leave the password field blank.
I'd like to propose a new feature for DinkHD, YeOldeDink and any future Dink ports.
A comment by RobJ has given me flashbacks to the days of the browser wars. There are already D-mods that refuse to launch on 'wrong' engine, and I fear that we might be heading to future where we have D-Mods that refuse to launch on anything other than Apache OpenDink™, while everyone has been using LibreDink++ Origin™ for years, and LibreDink++ Origin™ live-patches D-mods based on ther dmod.diz to evade "you are using incompatible port" messages.
I suggest a new function, feature_supported, that checks if a feature exists in current port.
The function would have a signature
Here is a piece of code from Hack 'n Slash start.c:
What will happen to D-mods like above if we ever get a new Dink port that gives a different value on get_client_fork()? Either we have to hope that the author is still active and updates the D-mod, the port has to check the D-mod against some list of badly behaving D-mods and live-patch matching D-mods, or the D-mods will just fail to run.
With feature_supported(), D-mod authors could do something like this:
One potential issue with this function is, what happens if the port does not have the feature_supported() function? In this case the game uses last return value of a function, so one should call something that returns 0 immediately before using feature_supported():
A comment by RobJ has given me flashbacks to the days of the browser wars. There are already D-mods that refuse to launch on 'wrong' engine, and I fear that we might be heading to future where we have D-Mods that refuse to launch on anything other than Apache OpenDink™, while everyone has been using LibreDink++ Origin™ for years, and LibreDink++ Origin™ live-patches D-mods based on ther dmod.diz to evade "you are using incompatible port" messages.
I suggest a new function, feature_supported, that checks if a feature exists in current port.
The function would have a signature
bool feature_supported(string name).
Here is a piece of code from Hack 'n Slash start.c:
int &chkv = get_version(); //... if (&chkv <= 108) { &chkv = get_client_fork(); if (&chkv == 3) { say_xy("`%THIS ADD-ON REQUIRES DinkHD to play CORRECTLY", -100, 200); say_xy("`%YEOLDEDINK may not show `0text `9in correct colours.", -200, 260); } else { say_xy("`% THIS ADD-ON REQUIRES DinkHD to play CORRECTLY", 0, 200); wait_for_button(); kill_game(); return; } }
What will happen to D-mods like above if we ever get a new Dink port that gives a different value on get_client_fork()? Either we have to hope that the author is still active and updates the D-mod, the port has to check the D-mod against some list of badly behaving D-mods and live-patch matching D-mods, or the D-mods will just fail to run.
With feature_supported(), D-mod authors could do something like this:
if (feature_supported("png images") == 0) { say_xy("`% THIS ADD-ON REQUIRES PNG IMAGE SUPPORT", 0, 200); wait_for_button(); kill_game(); } if (feature_supported("alpha channels") == 0) { say_xy("`% THIS ADD-ON REQUIRES SUPPORT FOR IMAGES WITH AN ALPHA CHANNEL", 0, 200); wait_for_button(); kill_game(); }
One potential issue with this function is, what happens if the port does not have the feature_supported() function? In this case the game uses last return value of a function, so one should call something that returns 0 immediately before using feature_supported():
//This will make sure that &return == 0 when feature_supported does not exist math_abs(0); if (feature_supported("png images") == 0) { //... }