S'orlok Reaves wrote:
About this part. Wouldn't it be easier to do:
Type Slice
Parent as Slice Ptr
FirstChild as Slice Ptr
NextSibling as Slice Ptr
PrevSibling as Slice Ptr
NumChildren as Integer
'whatever else
End Type
This is (very roughly) what the OHRRPGCE FMF is aiming
for with menu slices. Some benefits & ideas:
1) Having "PrevSibling" and "NextSibling" allow easy
re-ordering of Slices. This allow, say, the "Use Item"
dialog to pop up above the Item menu.
2) Don't just store x/y co-ordinates. Store
currX/currY and hintX/hintY. Then, add another item,
"anchor" which can be a bitflag like RIGHT|TOP. Now,
it's much cleaner to anchor, say, the spells menu's
right half to the right half of the screen:
.xHint = .yHint = -5; //5 pixels of buffer space
.anchor = RIGHT|VCENTER; //anchor to the right
(Of course, "currX/currY" are updated to store the
screen co-ordinates of each component every time one's
position changes).
3) Make global "find" functions that help you find a
node without knowing about the tree structure. If the
tree is well-structured, searching won't be too slow.
Then, for example, we can have MS-Word-style MOVE
functions:
Hangle h = findNPCSlice(1, 1); //Find the first
instance of NPC 1
Handle g = findNPCSlice(2, 1);
moveUp(h);
moveDown(h);
moveToTop(h);
moveXAboveY(h, g);
bool b = isXAboveY(h, g);
I guess... you guys will have to refine that idea a
bit...
4) As for pointers & handles, I like James' "extra
level of indirection" thing. But... I _don't_ like
storing everything in a big array. Can you do
something like in C++, where you put everything in an
array and just MAKE a reference? E.g.
MY_UDT[500] slices; //Make an array of custom structs
slices[0].x = 1;
slices[0].y = 2; //Just fill out the info
return &slices[0]; //Now we have a "pointer" that
won't likely cause trouble, and needn't be freed.
I suggested objects to James, but he said FreeBasic
doesn't have any working inheritance. So, I guess in
that case you can simply use bitflags to define object
polymorphism. Have a UDT for each slice with a
variable called "type". Now, let's say you want all
slices to be able to DRAW_MY_BORDER, but you later
decide that text slices should NOT do this, and should
add the ability to DRAW_MY_TEXT. Now, you've can chain
these together:
s1.type = DRAW_MY_BORDER; //Standard slice
s2.type = DRAW_MY_TEXT; //Text box
s3.type = DRAW_MY_BORDER | DRAW_MY_TEXT; //Later, you
find one case where you need both. Considered a "text
box".
Sorry to ramble; what I mean to say is that I think
you don't want OOP, you just want polymorphism. That
way, you can keep most of your code for "any slice"
inside the main program loop, and delegate the details
for "this slice" to a more narrow band of code. Since
you guys already have a very clear view of what
behavior is and is not needed by GAME's rendering
loop, I think you will be able to successfully
implement polymorphic behavior using bitflags. Or, you
could use function pointers, if FreeBasic has those.
In closing, consider the Win32 C++ programming
library. It's really a C-style library; it's all
structs, constants, and pointers, with no objects, and
it's still very elegant and powerful. Keep that as a
source of inspiration.
All the best,
-->Seth
Er, you may want to read the rest of this discussion.
_______________________________________________
Ohrrpgce mailing list
ohrrpgce@lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
