On Sat, Jan 23, 2010 at 05:25:28AM +1300, Ralph Versteegen wrote: > 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.
Fair enough :) > > 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 That make sense. > -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.) Like for a bigger map editor, right? > Changing the resolution in the middle of a game is just for debugging. Okay, that is good. My main concern about that was that resolution changing can wreck havoc with full-screen mode, even between well-supported resolutions. > > 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 :). Yes :) "Warning: Your chosen resolution of 800x600 will prevent your game from running on certain platforms... hypothetically in the future probably" > >> > 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. So is RPath just a way of asking for the node at /Nodename/Nodename/Nodename ? --- James Paige _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
