ok, i was thinking....

two main facts about the way TPT is coded have been itching in my head these last days....

first, it's current architecture prevents modding without recompiling the whole thing... no "addons"
second - it would run oodles faster (and i mean ~10x more FPS) if instead of the large amount of if-else blocks, function pointers were used to define particle behaviours.....

needless to say, we're talking about a full rewrite, which is by no means an easy feat - but... i've been leaning towards the challenge for a while....

so, when i finnaly muster enough "umphf" to bite that bullet, this is my plan:



firstly, 'ill be going C++ - we need classes so that function pointers become easier to handle (don't worry, no VTables)

another fundamental thing - we need an SDK, which would allow for mods to be easilly created and installed, no need to rebuild the whole thing....

then, we use DLL's ("boo-hoo it's not platform-independent" - you can't have everything) - particles types (one or more) are defined inside DLL's - which pass in function adresses for use inside the main loop

some key functions come to mind:

- attach -
this is where each module is bound to the simulation, only occurs at load-time, but that's where the API main class is "delivered" - to prevent "dll hell" situations, the module interface functions are all inside a class which can be simply "pointed" at startup - this should eliminate the need for imp-libs as well, making mod compilation a little easier

- registerElementType -
this is where you'd pass in a struct defining a new type of particle, that should contain all the needed info for general particle behaviour as well as the adresses for the "create" and "update" functions


other API methods must also provide polling of other (already loaded) particle types and allow modules to control further aspects of the simulation....

now, to minimize the load (whatever that could be) when "calling" particle update functions, those oughta be defined without taking in arguments - needed paramenters should come in the form of context-based static API variables, which are set during the course of the main loop and should be just as readily available to the module functions as regular arguments would....


lastly, a .cfg file should define the order in which modules should (or not) be loaded and define a bunch of other tweaks and info that can be read by the sim AND by addon modules - this should help largely for configuring things such as window size and whatnot....


well, that's my first mental draft of what i would do.... another idea would be to use a separate thread for rendering... dunno, i still gotta dwell on that a bit more....


another point worth reviewing is the interface.... i was thinking it would be so much more convenient if the 1-10 keys would act as a "pallete" - to which elements and stamps could be assigned for quick switching....

that's also something that still needs a little more brain, i guess....



for now, that's what i've got.... let me hear any additional thoughs you might have....

strange - that sounds somewhat counter-intuitive... how was it that this was implemented? it doesn't seem quite right that a long list of conditional checking is faster than to fetch and jump to an address....

are you saying it cannot be done?