Reply to Re: New *WORKING* cross-platform editor
If you don't have an account, just leave the password field blank.
October 4th 2011, 03:42 PM
shevek
I read the if problem was only when using if (a) if (b) ...
Anyway, I'll just add the braces.
Yeah there could be a problem with hitting the concurrent variable limit this way, hadn't thought about that yet.
I don't think that should be a problem. The temporaries are reused for every expression. Only when putting complex expressions in a very big choice statement, could things get out of hand (all choice conditions are computed before choice_start()). Some optimizations would be possible for that. How big is the limit anyway? I'd like to add an error message for it.
Speaking of optimizations, there is obviously more room for them. Constants don't need to be put into a variable before being used. An operation on two constants can be performed compile-time instead of run-time. Just to name a few.
Is this slower than raw dinkC? Yes, a bit. Is Python slower than assembly? Yes, a bit more. Do I want to write assembly if speed isn't absolutely essential? No, thank you.
Actually, is there a chance you'd consider changing this limit in the FreeDink code to accomodate this?
I don't really have a problem changing FreeDink to be more sane, and it should be pretty easy (although the source is not very nice). However, I consider it pretty high priority to allow dmods written with this editor to be playable by others without extra effort. Installing a special version of FreeDink (or even the standard version) does seem too complicated to me. So I'd prefer to stick to the limits of dink.exe, to stay compatible, even if FreeDink would be changed.
Anyway, I'll just add the braces.
Yeah there could be a problem with hitting the concurrent variable limit this way, hadn't thought about that yet.
I don't think that should be a problem. The temporaries are reused for every expression. Only when putting complex expressions in a very big choice statement, could things get out of hand (all choice conditions are computed before choice_start()). Some optimizations would be possible for that. How big is the limit anyway? I'd like to add an error message for it.
Speaking of optimizations, there is obviously more room for them. Constants don't need to be put into a variable before being used. An operation on two constants can be performed compile-time instead of run-time. Just to name a few.
Is this slower than raw dinkC? Yes, a bit. Is Python slower than assembly? Yes, a bit more. Do I want to write assembly if speed isn't absolutely essential? No, thank you.
Actually, is there a chance you'd consider changing this limit in the FreeDink code to accomodate this?
I don't really have a problem changing FreeDink to be more sane, and it should be pretty easy (although the source is not very nice). However, I consider it pretty high priority to allow dmods written with this editor to be playable by others without extra effort. Installing a special version of FreeDink (or even the standard version) does seem too complicated to me. So I'd prefer to stick to the limits of dink.exe, to stay compatible, even if FreeDink would be changed.
