James Paige wrote:
On Thu, Oct 02, 2008 at 06:32:14PM -0400, Mike Caron wrote:
Yup, I agree with all that.
And a real biggie will be
.type (or whatever we name it)
I envision a SELECT CASE block in the slice drawing code that does
different drawing behaviour for each slice.
Here are the slice display types I can think of off the top of my head.
None - for container slices like the root slice
Map layer - .num element holds layer number
Box - .num element holds style
Sprite - .num element holds... hrm... probably better to have .img AS
GraphicPair element.
Actually, now that I type this, why should the slice drawing behaviour
be modal? I'm not sure what benefit that holds. No reason a single slice
couldn't draw both a box and a sprite. Since each of the modes needs its
own meta-data, it may be better to dispense with the modes entirely, and
just have the meta-data, with default values that indicate offness.
Anyway
Map layer
Box style
Sprite
String
... hrm
Boy, I love thinking while typing.
Special slice draw modes DO make since for some things, like:
Draw all NPCs
Draw all heroes
Draw a whole text box
Draw a whole custom menu
Those are all cases where re-creating a complex drawing routine is
*possible* using the tree of primitive slice visuals, but for transition
purposes we really want to be able to say "go run the old NPC drawing
code with this x,y offet provided by a slice." or "go run the old text
box drawing code with this x,y offset provided by a slice"
That functionality will be invaluable for a smooth incremental
don't-bite-off-more-than-we-can-chew-all-at-once kind of transition.
I'm done for now :)
I was thinking about doing something like this:
Type Slice
'all the stuff we previously discussed
SliceType as integer 'type of slice
SliceData as Any Ptr 'generic, slice specific data
Draw as SliceDrawingFunctionPtr
End Type
Where SliceDrawingFunctionPtr is a function that knows how to interpret
.SliceData
Sub DrawSlice(s as slice ptr)
'first, draw this slice
if s->Visible then
s->Draw(s)
'draw its children
dim ch as slice ptr = s->FirstChild
do while ch <> 0
DrawSlice(ch)
ch = ch->NextSibling
Loop
end if
end sub
With that sub, you can draw everything without clunky Selects and such.
The "differentiation" is offloaded to whoever creates the slice.
ooh. Very object orienty. I like. I guess I didn't really think about
function pointers. I have never used them in FreeBasic before.
That plan sounds like the next best thing to real type inheritance.
And, when we do get real type inheritance (*pause while waiting for
laughter to stop*), we can switch over to that!
To go hand-in-hand, I'm envisioning Functions like this:
Function NewRectangleSlice(parent as slice ptr) as slice ptr
dim ret as slice ptr = NewSlice(parent)
dim dat as RectangleData ptr = new RectangleData
' fill in dat
ret->SliceType = slRectangle
ret->SliceData = dat
ret->Draw = @DrawRectangleSlice
return ret
end function
Actually, thinking about it, we'd also need cleanup functions too, like
.Dispose(), which is responsible for freeing the data in .SliceData.
This is important, for reasons I will illustrate with outlandish
examples that will never show up in practice:
DECLARE FUNCTION NewVideoStreamSlice(parent as Slice ptr) as Slice Ptr
DECLARE FUNCTION NewWebBrowserSlice(parent as Slice ptr) as Slice Ptr
DECLARE FUNCTION New3dRenderingSlice(parent as Slice ptr) as Slice Ptr
Of course. Gotta clean up what you allocate. No outlandish illustrations
were necessary. Although I did enjoy them :)
Etc. I will put these concepts to digital pen and paper... after dinner.
Then eat well!
Actually, I'm a liar as much as I am a genius (not to mention
egotistical!), as I am eating dinner *and* working on this at the same time.
_______________________________________________
Ohrrpgce mailing list
ohrrpgce@lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
