2010/1/22 James Paige <[email protected]>: > On Thu, Jan 21, 2010 at 02:01:34PM +1300, Ralph Versteegen wrote: >> 2010/1/21 James Paige <[email protected]>: >> > On Thu, Jan 21, 2010 at 11:46:48AM +1300, Ralph Versteegen wrote: >> >> The sprite editor needs to be updated to: >> >> -use Frames instead of the old modex crud >> >> -support 256 colour palettes >> >> -support resizing frames from within the editor >> >> -work on elements of SpriteSets instead of old-style frame arrays >> >> -completely decouple from the current spriteset browser, which will be >> >> thrown out >> >> -variable resolution support would be nice >> >> >> >> At least it looks like sprite_editor is already mostly separated from >> >> the sprite set browser, and everything is nice subified. But I don't >> >> know how to answer this: >> >> >> >> Would it be easier to make these changes incrementally, or to start >> >> from scratch and gradually update and move over components of the >> >> existing editor? >> > >> > Good question. I normally favor incremental cleanup, but I think the >> > sprite editor might be a case where we will be better off with a >> > rewrite. >> > >> > I was thinking about using a saved slice collection to re-impelement the >> > sprite editor's interface, but we don't have finalized slice collection >> > saving/loading support yet... >> >> Neat. That should mean automatic resolution independence as slices are >> aligned to the sides of the screen, right? I think that was the whole >> point of Seth originally using them in FMF. > > Speaking of resolution independance, what are your goals for that?
Honestly, just to do something interesting for a couple days. I'm not even aiming to finish this by the next release, although it's moving along well. Feeling a bit bored, I decided to start on a whole lot of big wishlist features at once. Haven't thought too hard about detailed goals for this. We could do with a Plan. > Some things you said earlier made me think you were talking about > changing the resolution while the program is running, which I am > uncomfortable with. Yes, but only in certain circumstances: -running/quitting a game -menus in Custom which have been written to handle it (and if they can handle it, it would be nice to keep the ability to resize the window as you can currently do with !+r. It seems that this is actually pretty easy to do if you plan ahead. However, adding the same resizability to all the other backends will probably be hard/impossible. But that doesn't matter, it would only be an optional feature anyway.) Changing the resolution in the middle of a game is just for debugging. > I am also worried about large resolutions, because those could become a > problem on some platforms that I would like to target in the future. For > example, iPhone has a max rsolution of 480x320 in landscape mode > (although it might have some hardware scaling support that would > midigate that) and the Wii has a max resolution of 640x480 (I think). > Also, the max resolutions on android phones seem to vary, but are still > pretty low compared to desktops. Are we going to choose a maximum? If > so, what should it be, and how do we handle platforms that can't support > it? (Maybe in Custom, on the screen where you choose your game's > resolution, it could show a list of supported platforms capable of the > resolution you requested?) That is exactly what I wanted to do. I think that if someone has a good reason to use a higher resolution, we shouldn't really set an artificial limit preventing it. They would know exactly they're giving up in exchange (though it would help if we actually had ports to some of these platforms :). >> > And I haven't worked on slice collection saving and loading because I >> > haven't heard any agreement on declaring the RELOAD format stable or >> > not. >> > >> > (Incidentaly that is the same thing that is stopping me from working on >> > the new SAV format and working on the Editor Editor) >> > >> > --- >> > James Paige >> >> I'm pretty sure that the file format and loading/saving functions is >> done. What's not is some of the rest of the API (particularly RPath?). >> I don't know if this is actually a problem. Whenever I have an excuse >> to use RELOAD (which was going to be for the new map format, but >> that's stalled due to lack of feedback), I'll just finish off bits of >> RELOAD as I need them. Also, the TODO list on RELOAD page on the wiki >> looks out of date. > > Ah, okay. Well, as long as the core format and the saving and loading > are stable, I can start working with that. I don't actually undertsand > RPath well enough to know whether I would want to use it :) Well I imagine that RPath would be the main way to find something in an RELOAD document. I guess its not so necessary if you're processing the whole thing. >> Also, I meant to say: because we couldn't come to agreement on the new >> file formats for sprites & animations, I may just whip up something >> temporary while I play around with it. I ought to try to write the >> competing proposals up simply rather than leaving people to dig >> through that enormous talk page on the wiki. > > I don't have any strong preferences for the sprite and animation > formats. A format with a working implementation is worth more than two > better formats that are still in planning :) > > --- > James > _______________________________________________ > Ohrrpgce mailing list > [email protected] > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
