Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: killface on April 26, 2008, 06:39:17 pm
-
I was looking over the dev roadmap for 3.6.10 and saw this little gem:
"dynamicification' of MAX_PARSE_OBJECTS (Goober)"
I was wondering what exactly 'dynamification' refers to.
-
The ongoing effort to remove hard limits from the game.
-
An effort that sadly, won't be over anytime soon :(
-
I've coded quite a bit of C in college, and one thing that baffles me is why professional programmers still code in so many hard limits. Is it really that hard to make it all dynamic the first time around? Or is it just a 'this needs to be done yesterday, cut corners' thing?
-
i hate programming for dynamic memory. and i figure other programmers do too. :v:'s goal was to make a game, which they did. it was not to make a game engine. when you look at idtech engines you find that since its primarily a game engine that is being sold and not just the game (which in id's case is usually to market the engine), there are very few hard limits. hard limits are just easier to program that dynamic limits. so when you're out to just make a game (you don't plan to sell the engine), you tend to favor the faster easier solution.
-
Though I bet that once you find an effective way to dynamicify some limits you will be able to apply the same technique to the rest.
-
It's not finding a way to do it that's the problem. It's editing hundreds of references to the old way of doing it that is the pain in the arse. :D
-
For those us of not well-versed in programming (i.e. maybe just me), what would the removal of hard limits mean for the actual in-game experience?
-
In an unmodded game? Nothing. It's for mods that it really matters. It means they can have more ships, more types of weapons, that sort of thing. The inferno builds, for example, were made to circumvent a hard limit as their mod has more ships than the game allows. Dynamic limits would eliminate the need for special (and incompatible) builds for that sort of thing.
-
I know that a mutable array would solve the problem, but I'm sure there are drawbacks to mutable arrays (I'm not even quite sure how they work).
-
I know that a mutable array would solve the problem [...] (I'm not even quite sure how they work).
Then how on earth do you know they would solve the problem? :rolleyes:
It's easier, faster, and less bug-prone to use hard-coded limits, so they're heavily favored in game design. However, if you want to make an engine, not just a game, flexible limits are worth the effort, as Nuke said.
FYI, the MAX_PARSE_OBJECTS limit prevented any mission from having more than 100 ships (aside from additional wing waves, which are just clones of the first wave).
-
Then how on earth do you know they would solve the problem? :rolleyes:
I've worked with mutable arrays before. They seem to get the job done.
Though if they work the way I think they do, then they are performance hogs.
The only other solution I can think of is going through the tables (or whatever) twice. Once to count the number of entries, and second to parse them.
-
The only other solution I can think of is going through the tables (or whatever) twice.
Linked lists.
-
Counting the entries doesn't do you much good, it would still have to be a dynamic value since the max isn't known at compile time. So if you're going to have to make it dynamic, Shade's right, a linked list is the way to go. It's just hard to switch all that code over like they're saying.
-
The only other solution I can think of is going through the tables (or whatever) twice. Once to count the number of entries, and second to parse them.
thats the way i used to parse models in my own engine, then i rewrote it to allocate a block, and reallocate when that becomes full as data is loaded from file. but it turns out that it is not the best way to do things. so im thinking about dynamically allocating memory to store the whole file as text, then go through it twice, once to count, allocate memory, once to store data. then the text block is freed and the load is complete.
i dont know how freespace parses its files, but i hear that it is a convoluted mess.