I've been thinking about this too. There's an in-progress file IO abstraction system (lumpfile.bas) that's not yet used (also, implementing your own polymorphism in FB is really unpleasant). I've recently been looking into how IPC could be used to allow Game and Custom to run on the same file, sending notifications to Game when something is edited.
On 7 November 2010 18:45, David Gowers (kampu) <[email protected]> wrote: > On Sun, Nov 7, 2010 at 2:07 PM, James Paige <[email protected]> wrote: >> On Sat, Nov 06, 2010 at 05:16:03AM -0700, Jay Tennant wrote: > managed by the >>> backend, but doing so would allow edits in Custom to be immediately >>> visible in Game. Even if you want to do this only for graphics, I don't think the grpahics backend is the place for this. There already is a sprite cache which handles that kind of stuff (we already have a function to instantly reload all in-use palettes from the RPG file. There's no function to do the same for sprites, because it's not needed yet). >>> I'm not sure of the practicality of that, but it's an idea. >> >> While I can see the appeal of being able to test in real-time, I think >> the complexity of that task is waaay to large in comparison to the >> benefit it would provide. I think it would be a great deal of benefit. For example, being able to test battles is a pretty frequent request. Simply being able to open working.tmp in Game would already be quite useful. I think it would be enormously easier to read lumps out of working.tmp, and have the next spawned battle loaded from that, than to import the battle system into Custom. >> And remember, it is not just about updating graphics. What about maps >> updates? Hero enemy attack and item updates? Running scripts? Displaying >> of text boxes? Would we want to be able to reload a textbox or shop or battle, etc., while inside? I say no: those would all be a lot of work to support, and simply exiting and reentering the textbox, shop, or battle to see updates sounds useful enough to me. We could always add code to handle reloading attacks in the middle of a battle, for example, as we see the need and find the time to do so. Incidentally, when it comes to running scripts: I am going to attempt an in-game console which allows you to type and run statements, and also to reimport (selected?) scripts from your .hss file. I was going to do this soon, but maybe I should wait for the better organisation that the new interpreter should have. > I think Jay was talking about graphics because (providing their size > does not change, as is currently implicitly enforced) they have no > side effects -- if a graphic changes, reloading it doesn't require > anything else to be reloaded. > I haven't dug into the OHR sprite caching code recently, but IIRC this > should be true (unsure what the situ is regarding tilemaps). > > Anyway I agree it's inappropriate to implement merely *some* > refreshing -- if there is refreshing at all it should be on all > possible data types, which is exceedingly complex even with a good > framework (like recording an md5sum for each record so you can tell > when it actually changes) As you say, making everything refreshable would be exceeding difficult, which is why I disagree. Rather, I propose just working towards that goal incrementally. Let people know that not everything will work, and make it clear what does and doesn't. I was imagining manual options (in some debug menu) for reloading data for which we support doing so, rather than having everything immediately and automatically refresh. If there's no option for it, and it's not something which you can exit and reenter like a shop, then it's not supported. We could also have an option to do immediate and automatic refreshes which are just equivalent to running the manual refresh when a relevant lump changes. Another possibility would be to make an RPG refresh equivalent to saving and loading parts of the game state corresponding to lumps that have changed, by actually calling some of the RSAV save/load routines. That'll help us test that we add save/load functionality in a robust way. _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
