On Fri, Jan 29, 2010 at 12:31:08AM +1300, Ralph Versteegen wrote: > On 28 January 2010 07:53, James Paige <[email protected]> wrote: > > > > The Load Game Screen template would require a slices marked as > > "sl_load_new_button" "sl_load_exit_button" and "sl_load_grid" (not sure > > about the names, I am just making them up at the moment) > > I assume these would not all be mandatory
I guess the templates need a few different levels of reuirement for the included elements * Mandatory - Template will produce a run-time warning if it lacks this. * Suggested - Template will produce a save-time warning in the editor if it lacks this * Optional - Has meaning for this template, but isn't required. > This GridSlice sounds like a good idea (although something big remains > unexplained when going from "Children of the grid automatically get > moved" to "The Load Game Info Panel would be fit into the grid slots") I am working on an implementation now. My plan is that children of the grid will be positioned relative to a grid cell instead of relative to the whole parent. That means that children with Fill enabled will automatically fill the grid cell. Cells will be numbered like 0 1 2 3 4 5 6 7 8 If the grid has more children than it has cells, the extra children will be treated as if they are "hidden" (although their visible property will not actually be changed) It remains to be seen if the Grid will have reasonable performance or not, but I am optimistic, at least for moderately sized grids. > But I think that in the case of the load/save menus, would you would > want is yet another type of new slice: a MenuSlice. Recall that we > planned to increase the number of save slots on the load/save menu. > MenuSlices can have an unlimited number of children, of which a > limited number are displayed at once, in a grid. They might have > scroll bars, and the order in which items are traversed is selectable > (row major or column major). We could allow scrolling smoothly instead > of in jumps. There is currently a partial implementation of something called a MenuSlice. I think Mike wrote it. I understand it to be for reproducing menus, although I am not sure if those should be hard-coded into slices.bas or done as compound slices Andyway, I like the idea of a ScrollingSlice. I was indeed thinking of the ability to show more than 4 save slots on the save/load screens, although at the moment I had been envisioning just making them more compact. > I think what really needs discussing is how to go from slice > collections to replace builtin menus. Labelling slices to give them > special meaning seems like a good idea, but I'm also envisioning > 'protoslices' - (noneditable?) placeholder slices added to a slice > collection which ingame are replaced by one or multiple slices - in > your load menu, the grid slice might have one child marked "<Saved > Game Panels>". Yes, that sounds a lot like what I have in mind. A protoslice would be a placeholder for an engine-created slice or an instance of some other slice template. I am still waffling a bit over whether these slices should be labelled with strings or with slice lookup constants. I am leaning towards constants. > Also, I was planning to add something like a 'View' or 'Clipping' > slice, which clips the drawing of its children to a rectangular area, > using view frames. Not sure if it's the most elegant solution, but it > seems like a simplest way to enable drawing just part of a sprite or a > mapslice. Split screen would be achieved by parenting slices for two > different maps to two different view slices. But... how on earth would > you show two parts of the same map at once? That would be great! In fact, with a ClippingSlice, the ScollingSlice would be super-easy to make. --- James _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
