Quasar
Moderator
Posts: 4613
Registered: 08-00 |
Graf Zahl said:
My main issue with EDF is how the frames are defined... There really shouldn't be any need to link the sequence manually... (Even the simple solution of omitting the 'nextframe' keyword to advance to the following frame in the definition would help a lot)
I already have special frame linking keywords on my TODO list for EDF 1.1, actually. However, leaving out the nextframe field makes it default to S_NULL, and it's too late to go back on that decision. It's more likely to be something similar to "nextframe = @next", as I intend to make identifiers starting with @ reserved.
Graf Zahl said:
Another issue is that the frame definition is quite verbose (mainly because there are so many of them)... Furthermore it should be possible to specify the spriteframe parameter as the frame letter in the sprite lump because that's the only reference a designer has.
Yes, I haven't really liked the frame situation myself. What you've made me interested in trying is enabling a "frame metalanguage", where you specify the basic frame fields in a single, short-hand field, like this:
code:
frame S_BLAH { short = "PUNG 4 A Punch" }
It might be possible to allow all the fields in the string, but I'm not sure yet. I don't want to REQUIRE them to all be there, since that defeats the purpose, but it's also not possible to allow skipping of any either, since that would really complicate the parsing code. Note that libConfuse can't handle a simple loose string like you showed in your example. That would be nice, but there's nothing in the parser that will make room for it. There would have to be some kind of field name in front, as I've shown.
I already have allowing letters in the spriteframe field on my TODO list. But it's really not a necessary feature. The translation from letters to numbers is hardly difficult (A = 0, etc.). But I do want EDF to be easy and convenient, so I think it's worth the trouble.
Graf Zahl said:
Third, the 'spritenames' definition should be optional. It should be easy enough to add new sprites dynamically when they are encountered for the first time. 'spritenames' should be used for Dehacked ordering only.
This I take issue with. I don't really see the relevance or any reason for it. Addition list syntax makes it deathly simple to add your own sprite names wherever you so wish. If you don't know what I'm talking about, it's this:
code:
spritenames += { FOO1, FOO2 }
If you don't know what that does, please re-read the EDF docs, because I do mention it in there. You can always just add a single sprite name right before the frames that use it. If I allow dynamic introduction of sprite names, I would either have to build a preprocessor to scan for them (which would be horribly slow and possibly not even doable), or I would have to place limitations on where you could put structures that reference the sprite, such as sprite-based pickup item definitions. That complicates the language. It's just not worth it, sorry.
Graf Zahl said:
Last, allow specifying the speed of missiles as floats. Fixed numbers are very hard to read without a calculator at hand.
That's a good idea. I might be able to do it with a parser callback function.
Last edited by Quasar on 08-31-03 at 06:14
|
08-26-03 10:25 
