Reply to Re: PyDink player demonstration
If you don't have an account, just leave the password field blank.
February 13th 2013, 03:55 PM
shevek
It's a bummer that a DMOD that's already being created can't be very easily converted.
I agree. It might be possible to convert all "sane" scripts, but those with weird patterns of jumping through the code, and certainly those with gotos between functions, will be extremely hard to convert. However, it might be possible by duplicating the function that is jumped to instead of jumping to it.
By the way, my engine works slightly different when it comes to execution anyway, so not everything may behave the same, even when writing in PyDinkC and running in PyDink vs a diffeent engine. In particular, PyDink spawns a new script for every callback (which means your previous script doesn't get aborted when the new one starts) and has "static" variables per sprite, not per "script instance". This is often the same thing (a variable can be referenced from both hit and talk, and it will be the same variable), but not always (a script spawned from talk can still access the statics in my engine, but it can't in regular Dink, I think).
So in general, even if decompilation works, you may need to check if the result does what you want. Which means it would be a great benefit if the decompiled code is readable. Not easy at all...
It's fine that they aren't fixed when compiling to an old engine format because, well, that only makes sense.
It does, but if things can be fixed using workaround code, like your missiles fix, I'm happy to include it.
for things like editor sprite limits on a single screen, I guess a warning could be displayed when a screen is no longer compatible with the original Dink Engine
That's not very easy to detect (it would make the editor slow to check this all the time). I'm doing several such checks when compiling into an "old-style" DMod. I have to check it anyway; otherwise the data doesn't fit into the file.
does your engine support strings as variables?
No, it doesn't. It seems impossible to compile that into something that DinkC would understand. And I only recently started adding an engine to PyDink; originally it was only a preprocessor, which was intended to make writing (good) DMods easier, not to add features that weren't possible before. So I didn't implement things that could not be compiled. Since I'm working on the engine, I've added a few of them, but only things that can be mostly ignored. Although I imagine that DMods could make good use of "compare script of inventory item X". Apart from creating an inventory screen, as I did. Even though DMods creating their own custom inventory screen (not just the background, but all of it) was the main reason for moving this stuff out of the engine into a script.
I agree. It might be possible to convert all "sane" scripts, but those with weird patterns of jumping through the code, and certainly those with gotos between functions, will be extremely hard to convert. However, it might be possible by duplicating the function that is jumped to instead of jumping to it.
By the way, my engine works slightly different when it comes to execution anyway, so not everything may behave the same, even when writing in PyDinkC and running in PyDink vs a diffeent engine. In particular, PyDink spawns a new script for every callback (which means your previous script doesn't get aborted when the new one starts) and has "static" variables per sprite, not per "script instance". This is often the same thing (a variable can be referenced from both hit and talk, and it will be the same variable), but not always (a script spawned from talk can still access the statics in my engine, but it can't in regular Dink, I think).
So in general, even if decompilation works, you may need to check if the result does what you want. Which means it would be a great benefit if the decompiled code is readable. Not easy at all...
It's fine that they aren't fixed when compiling to an old engine format because, well, that only makes sense.
It does, but if things can be fixed using workaround code, like your missiles fix, I'm happy to include it.
for things like editor sprite limits on a single screen, I guess a warning could be displayed when a screen is no longer compatible with the original Dink Engine
That's not very easy to detect (it would make the editor slow to check this all the time). I'm doing several such checks when compiling into an "old-style" DMod. I have to check it anyway; otherwise the data doesn't fit into the file.
does your engine support strings as variables?
No, it doesn't. It seems impossible to compile that into something that DinkC would understand. And I only recently started adding an engine to PyDink; originally it was only a preprocessor, which was intended to make writing (good) DMods easier, not to add features that weren't possible before. So I didn't implement things that could not be compiled. Since I'm working on the engine, I've added a few of them, but only things that can be mostly ignored. Although I imagine that DMods could make good use of "compare script of inventory item X". Apart from creating an inventory screen, as I did. Even though DMods creating their own custom inventory screen (not just the background, but all of it) was the main reason for moving this stuff out of the engine into a script.
