On Mon, Nov 08, 2010 at 08:33:52AM +1300, Ralph Versteegen wrote: > 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.
Hmmm... Actually, I can't think of a single solid objection to the incremental approach. Your arguments here make this idea sound a lot better to me. --- James _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
