by randi » Sat Jul 30, 2005 3:27 pm
I like these ideas, and they will see their way to an official ZDoom, but I do not think I will use this specific implementation. Let me elaborate:
You limit each actor to a specific number of extra variables, they are unnamed, and they take up space even in actors that don't need them. We can take advantage of the class information maintained for each actor and extend them with however many additional variables we want at runtime.
As for the expression parsing, I was going to do this eventually. Now I will just have to do it sooner. I am looking at switching state actions into streams of p-code that can do much more complicated things than just calling a single function. All action functions, whether they take arguments or not, could be treated identically. And every function that takes parameters would automatically gain support for expression evaluation once a parser is in place that can generate the codes for them.
I like these ideas, and they will see their way to an official ZDoom, but I do not think I will use this specific implementation. Let me elaborate:
You limit each actor to a specific number of extra variables, they are unnamed, and they take up space even in actors that don't need them. We can take advantage of the class information maintained for each actor and extend them with however many additional variables we want at runtime.
As for the expression parsing, I was going to do this eventually. Now I will just have to do it sooner. I am looking at switching state actions into streams of p-code that can do much more complicated things than just calling a single function. All action functions, whether they take arguments or not, could be treated identically. And every function that takes parameters would automatically gain support for expression evaluation once a parser is in place that can generate the codes for them.