Questions.
Okay, I've found some interesting things in the source...
1) Why is the maximum number of sprites 10000?
2) Why does the name of a script have to be shorter than 14 characters?
3) Why is the mamimum number of sprites on a screen at once 1000?
4) Why is the number of global variables limited?
5) Why does the map format waste so much memory?
I can't answer these. Can you?
1) Why is the maximum number of sprites 10000?
2) Why does the name of a script have to be shorter than 14 characters?
3) Why is the mamimum number of sprites on a screen at once 1000?
4) Why is the number of global variables limited?
5) Why does the map format waste so much memory?
I can't answer these. Can you?
My guess is Seth did it the easy way instead of using malloc and such for dynamic storage.
I'm suprized it allows that many. The biggest boost would be getting more global variables. I don't think I could need more sprites anyhow.
Actually, more global variables would be nice, but more graphic and sound slots sounds better to me. I know I know, you can swap graphics and sounds in and out but that should be obsolete. What's even more ridiculous is the limit on sprites you can place on a screen. 99 may be the limit, but in some cases 99 is even too much and makes Dink crash. Oh and the limit on tiles sucks as well.
Noticed how I hate limits on modding engines?
Noticed how I hate limits on modding engines?
And yet you knew of all of these limitations before designing your mod, correct? The design must adhere to the inherent limitations of any engine. It would be great fun to put "Make A First Person Shooter" in a design document for a D-Mod, but it sure as hell isn't going to happen.
Of course, the release of the source code promises to remove those limits, but I fail to see why anyone would want to start a huge epic requiring more than the engine could handle back then.
Of course, the release of the source code promises to remove those limits, but I fail to see why anyone would want to start a huge epic requiring more than the engine could handle back then.
dang good point, redink1.
And on the other hand, there are some limitations that clearly could be rectified (though maybe not until Dv2) that didn't make sense. For instance, the inablilty to reposition sprites on the status bar was not a planned 'feature' but rather an oversight most likely influenced by the amount of time the author really wanted to apply. You can always go further, but sometimes it's time to move on.
And on the other hand, there are some limitations that clearly could be rectified (though maybe not until Dv2) that didn't make sense. For instance, the inablilty to reposition sprites on the status bar was not a planned 'feature' but rather an oversight most likely influenced by the amount of time the author really wanted to apply. You can always go further, but sometimes it's time to move on.
The way you explain it, you're assuming the modder knows EVERYTHING about the engine before designing a d-mod.
When I started on LT I didn't know ANYTHING about limits on variables, sprites, etc... and I had to deal with it when the time came.
If I look forward to a new game that will have modding capabilities, is it wrong of me to design a game beforehand, only to be surprised by limitations AFTER you get into modding?
When I started on LT I didn't know ANYTHING about limits on variables, sprites, etc... and I had to deal with it when the time came.
If I look forward to a new game that will have modding capabilities, is it wrong of me to design a game beforehand, only to be surprised by limitations AFTER you get into modding?
