August 11th - XP-Dev.com

nebraskaslowΛογισμικό & κατασκευή λογ/κού

31 Οκτ 2013 (πριν από 3 χρόνια και 9 μήνες)

117 εμφανίσεις


August 11
th



Tried to implement a signal/slot pattern for interaction between components within
a gameobject.



At the end of the day I noticed how stupid that would be; signals/slots don't use
Messages, so they don't match well with Managers and the exe
cution queue. In
component interaction, data connections are more important than event/action
connections.


August 12
th



Cleaned the mess of the previous day.



Started to implement object templates.



Following the Game Programming Gems 6 article, I gav
e every component a
family. I later realised this is confusing, since you can never be sure that
components in the same family will contain the same attributes, which is crucial. I
then chose to have a ComponentFamily class containing the attributes, which

would
be registered to ComponentFactory, and each ComponentTemplate would depend
on a ComponentFamily on instantation. It sound like overkill, doesn't it? That's why
I threw the whole family concept away. After all, as I see it, you don't need families
wh
en you can have component dependencies, think about it: if you need 3 kinds of
bodies, make them all depend on a basicbody component, and this way all other
components can simply forget about the 3 specific bodies and resort to the
basicbody component.



I
've thought about a way to virtually connect attributes. A component can link its
attributes to those of a required component. Linked components must share type.



I still have to figure out how to let messages be sent from within components.



Each GameOb
jectTemplate and Component store only those values in which they
differ from the default values of their respective predecessors.
TEST IT



Attribute links are stored at the Component. Links are created from
GameObjectTemplate.Create() by invoking Componen
t.LinkAttribute(). When
Component.GetValue() is invoked, the list of links is first cheked. (read on, i
eventually chose not to use this approach, but a more scallable one)



Made an enum for component dependecy modes. (I deleted it. Having an enum for
jus
t Required and Incompatible sounds silly)


August 13
th



I'm thinking that component dependencies and attribute links should be stored only
at the ComponentTemplate. Otherwise, being able to change those links to whatever
attribute you wish on a designer a
pp would most probably throw it all away.



Only virtual attributes can be linked.



I'm using HybridSets now.



Constant attributes ok.
TEST IT



GetValue chain ok, needs testing.
TEST IT



GetTemplate(), both in GameObjectFactory and ComponentFactory, tr
ies to
automatically register the template if necessary. This way, you need never care
about what templates are already registered and which aren't.
TEST IT



GameObjectFactory and ComponentFactory have a Folder property that stores the
path to the folders

where their respective xml template files lie.



August 14
th



Value types of component attributes must:



Be Serializable



Cloneable



Have a valid Equals() method



Set value finished. Needs testing.
TEST IT



I'm thinking: in order to allow dynamic ad
dtion/removal of components to a
GameObject at runtime, Components themselves should be able to react
accordingly if their dependencies are not satisfied. They may stop processing events
or remove themselves from the object... However, even though this sou
nds like a
good and elegant idea from a programmer's POV, I doubt there is a case scenario
where a GameObject should be allowed to keep living when it has lost vital
components / accquired fatal components (maybe editors?)...



I've implemented AddComponen
t and RemoveComponent so that dependencies are
checked there. Dependencies are checked at GameObjectTemplate.Create too.
When a dependency is not met, an exception is thrown.
TEST IT



I think components can be added/removed dynamically now.
TEST IT



Game
Objects store a reference to its OwningSimulation, which is updated at
Simulation.AddObject... and Simulation.RemoveObject



I have just made the first test. Templates, components and objects all work ok! :
-
D
Yeah!!



Template parsing methods are now at fa
ctories.



I have put the right files and classes into the Engine.GameObjects namespace



GameObjects now have a Name property. It can only be set when the object is not
owned by a Simulation. Never returns null, at least "".


August 15
th



Implemented al
l Simulation's GetObject methods
TEST IT



Implemented AddObject and RemoveObject, and event methods for GameObject
Component and Manager.
TEST IT



I'm thinking something: the whole idea about components is that they needn't know
anything about other comp
onents in the object. Thereby, the code shouldn't let you
access other Component instances from within a Component, should it? After all,
that's why I have implemented VirtualAttributes!



I keep fiddling with the idea that when removing a Component from a

GameObject,
all Components that required the removed one should remove themselves too from
the object. But I'm not 100% sure about it; it seems like a better idea not to allow
that to happen, and throw an exception as soon as a required component is lost.



Managers now receive events when components are added to / removed from an
object.



I now remember what I did in python about MessageTemplates' parameters:
MessageTemplates should contain more detailed (and smart) information about their
parameters. Ba
ck in what I did in python, the class Attribute derived from
Parameter. MessageTemplates should store ordered Parameters. This way, you can
even do type
-
checks or ease serializability...



Component is not a sealed class anymore. The same applies to Compon
entTemplate.
Why on earth did I make themsealed in the first place...? Since Components must
support custom behaviours (OnUpdate...), I gave them some virtual methods. And,
since ComponentTemplates must be able to automatically instantiate Components, I
ma
de Create() virtual, so that derived ComponentTemplates can instantiate custom
Components with custom implementations.



Implemented Parameter and made some changes to the way component attributes
were created. Now, anytime an Attribute is created for a te
mplate, it no longer needs
to store information about its type, the way its values should be converted... since
all of that is known by the Parameter that is handed to the Attribute at the
constructor.



I'm going to test adding an object at runtime from a

Manager.


August 16
th


Finally manager to make ArrayParameter.ValueType dynamically return an array of
the ValueType of

its container parameter.


After testing ArrayParameter, I think it’s ok.


All default parameters are now sealed classes. They have only on
e internal constructor
each. The only instances that should exist are contained by DefaultParameters class,
which in fact contains all of these parameters’ classes as nested classes. You can access
default parameters’ instances by using the constant values

at DefaultParameters
(FLOAT, BOOL, SHORT…). This way, only one instance of each Parameter will be
created, which will speed up things and save memory, and make it all more comfortable
(you needn’t create lots of instances anymore).


Added some more methods

to Parameter. Made it an abstract class, not an interface.


Succesful tests of Parameter and ArrayParameter.


Fixed some bugs when an Object is added… After some tests, adding objects to the
Simulation looks pretty much ok.


Decided not to implement both ADD
_COMPONENT_TO_OBJECT and
REMOVE_COMPONENT_FROM_OBJECT messages. GameObject.AddComponent(
) and GameObject.RemoveComponent( ) already trigger events on the Managers of the
Simulation, so using those methods in external code is OK.


REMOVE_OBJECT seems to wor
k.


August 17
th



Managers and Components derive now from IMessageObserver interface. They
must implement ProcessMessage() and a get property called
SupportedMessageTypes



I keep wondering: should Components be banned from accessing its
OwningObject? As I

see it, they shouldn't have access to it in order to make them
fully modular. That's way I'm going to test this
-
> components now have a public
get property named OwningObjectId, and an internal one called OwningObject; this
way, Component subclasses have

no way of touching its owning object's instance....
After rethinking this, I undo it, thus leaving OwningSimulation public and erasing
OwningSimulationId. I suppose it's up to the programmer not to throw it all to
waste.



GameObjects never receive events

onSimulationStarted, like Managers do, because
they needn't rely on this.



Components don't receive messages about Managers being added/removed.



Components are now registered as message observers.
TEST IT



Managers react to Objects being added/removed
, and spare Components being
added/removed to GameObjects.
TEST IT



Component.Deinialise/Initialise virtual methods done.
TEST IT



GameObject.Clone() is working perfect now :
-
)



events for Component ready
TEST IT



GameObject.GetState / SetState ready.

TEST IT



I think I'm now at a good point to start designing an editor. I'll have to do parser
classes, and think what I will need and I won't.



August 18
th



I've been reading a lot about property grids in .NET. They are quite cool, actually.
However, a
s always with .NET, they suffer from stupid drawbacks caused from
incompetent design. For example, I'll have to do a lot of sh*t in order to allow
dynamic properties and setting properties to readonly on the fly...



I've read a lot of forums/tutorials...
but these 4 are the best:



http://msdn.microsoft.com/en
-
us/library/aa302326.aspx



http://209.85.129.132/search?q=cache%3Ahttp%3A%2F%2Fblog.codinglig
ht.com%2F2008%2F10%2Fchanging
-
attribute
-
parameters
-
at.html&ie=utf
-
8&oe=utf
-
8&aq=t&rls=org.mozilla:es
-
ES:of
ficial&client=firefox
-
a



http://209.85.129.132/search?q=cache%3Ahttp%3A%2F%2Fmastersact.blo
gspot.com%2F2007%2F06%2Fstring
-
collection
-
editor
-
for
-
property.html&ie=utf
-
8&oe=utf
-
8&aq=t&rls=org.mozilla:es
-
ES:official&client=firefox
-
a



http://www.codeproject.c
om/KB/cs/wdzpropertygridutils.aspx



I'm gonna have to implement a model class for each editable object.



Pay attention to user changes: you may have to refactor lots of things, i.e. When a
componenttemplate's name changes.



Always use DefaultValueAttrib
ute.



BTW, I'm doing little tests as I study all of this.



To make an expandable property:



Create the class for the property as usual (gets and sets, attributes...)



(Optional) Give the class a DescriptionAttribute. This will be shown when a
property
of such class is selected in the grid.



Now you have 2 options:



If the class needs no conversion to/from strings or any other, you simply set
its TypeConverterAttribute to ExpandableObjectConverter



If you need conversion:



You create a new class and

have it derive from
ExpandableObjectConverter



set the model class's TypeConverterAttribute to the new converter class.



override CanConvertTo, ConvertTo, CanConvertFrom, ConvertFrom.



To enable custom drop
-
down selection for properties:



create a cla
ss that derives from TypeConverter.



Override GetStandardValuesSupported and always return true.



Override GetStandardValues and return the Icollection of possible choices.



(Optional)Override GetStandardValuesExclusive and return false if you want a
co
mbobox instead of a drop
-
down


the user can write their own text in
comboboxes.



August 19
th



Predefined (code) templates are readonly. They do not show their events/supported
messages.



Seems like I'll have to implement a property class for when we do
n't want to let the
user edit the ComponentTemplate. Call it 'ComponentTemplateNoEditProperty'. Its
collections would be visible but not editable.



Or maybe another class for adding simply the name...



Models shouldn't directly write to the template ever
ytime a value of them is set.
They should rather allow one Save operation, where everything is changed/written
to file.



How can I set DefaultValueAttributes dynamically?



Still don't know how I'll deal with single/array/virtual attributes.



I'm leaving

DescriptionAttributes until the end.



Ok, I've just finished a Dialog that allows the user to pick a collection of
ComponentTemplates. See how it works below.



How to implement custom properties of custom collection types:



Create the form class:



Imp
lement a constructor of the form that receives an input collection.



Implement a property that will be used to get the resulting collection
externally once the user clicks OK.



Create a class and derive it from UITypeEditor.



Override editor's EditValue
( ) method:



Cast the incoming 'value' to the right type of collection (generally, use a
list)



Instantiate the form, passing it the already casted 'values' collection.



Show the form.



Grab the result of the form, and return it.



Set the EditorAttrib
ute of the to the Editor class and UITypeEditor as baseclass.



How do I make DefaultValueAttribute adjust to the default value of the property
dynamically
??



Properties of a PropertyGrid in our project will implement the IjunkEditorProperty
interface.



JunkPropertyGrid is a property grid that contains an instance of
IjunkEditorProperty. It reacts to the events of its instance. It only works with
instances of the said interface.



I'm editing a component template's requirements and incompatibilities OK!



Ça marche!



August 20
th



Wasted some time trying to have disabled (gray) items in
ComponentTemplateCollectionForm.assignableListBox ... I quit after finding out
how unnecessary, ambiguous and relatively tricky it is.



Ok, the whole event cycle of Ijun
kEditorProperty seems to be ok. I tested with
ComponentTemplateProperty and works fine for a save/reset button.



Now I'm going to implement Iparser or whatever, which should be registered to
templates and enable write/read of our engine's classes.



So IP
arser has 2 methods: Parse returns an object, Write receives it. Both of them
need a string that tells them the path of the file to read/write.



IParsers must define a SupportedExtension property that gets the extension of the
file that will be looked for

in the given factory.



IcomponentAttribute did not contain a Description :
-
S it does now.



Support for parsers is ok, now I have to test it by implementing a parser.



I'm defining xml format. Implementing ComponentTemplateParser.



It's becoming obviou
s that I'll have to implement some way to allow custom
Parameters and retrieve them dynamically from the engine...



Said and done: ParameterFactory is implemented. It supports dynamic creation of
default paramters, array parameters, and user
-
created param
eters via a typeName
string.



Hell yeah! I just parsed my first component template! Still have some test to, though
TEST IT



August 21
st



Saving and writing component templates with ComponentTemplateParser works
now!!



Still have to test virtual attrib
utes in ComponentTemplateParser
TEST IT



I have to implement a method for ComponentFactory and GameObjectFactory that
stores the template, whose type is given, at the same filepath that it would be loaded
from. That's easy.... Done!



Implementing Compone
ntAttributeProperty.



I'll implement 2 different classes for virtual and single component attributes:
ComponentSingleAttributeProperty and ComponentVirtualAttributeProperty. In the
attributes collection editor, the user will choose if the new attribute wi
ll be virtual or
not when adding it.



I'll implement ComponentVirtualAttributeProperty



Must implement ScriptComponentTemplate, which should be the one and only class
that can be parsed.



Parameters now have another abstract method: GenerateEmptyValue()
. This should
return a valid value. It’s useful for editors, since with this method you’re always
assured that it can be assigned as default value for new instances.



August 22
nd



Saving/editing ComponentTemplates works flawlessly! Events, array and vir
tual
attributes are not implemented for editing, but everything else works perfect :
-
DDDD



I’m going to leave ArrayAttribute and VirtualAttributes for a little later.



ScriptComponentTemplate class created, but not implemented. A
ScriptComponentTemplate
is the same as a ComponentTemplate, but receives
information about events, and should be able to respond to messages in a certain
way. I’ll figure this out later.



I have decoupled property editing for user editable component templates
(ScriptComponentTem
plate) and code templates (not ScriptComponentTemplate).
This way, the user can edit the first, but not the last.



BTW, I had a (F*CKING) issue with svn… damn, it took me some time to solve it.
I lost a couple files, they just disappeared, and I had to re
write them from my
memory :
-
S I’m still wondering what actually happened.



August 24
th



Collection edit forms now appear in the center of the owning control.



I've made sure that unregistering templates will work dynamically. I did it fast, I
didn't dou
ble check, because I have other things to do. So, I may need to come
back to it later.



I changed GameObjectTemplate.GetDefaultValue( ): it doesn't access the
component templates anymore; it simply looks up for its ancestors.
ComponentTemplate.GetDefaultV
alue( ) does it now.



Implemented one thing that I had missed: upon adding a component to an
object,



August 25
th



Whenever a component is added to an object, all required components are added
if necessary.



Required components are added to a game obj
ect automatically when the
original component is added to the object.



When a component is removed from an object, any other components that
depended on it are removed as well.



Ok, it's all quite ok :
-
D



I've documented that templates must not be modif
ied at runtime; they can either
be registered or unregistered, but never modified, because this could cause that
existing component instances that depend on the template behaved strangely.



Modified ~Simulation() so that GameObjects are correctly and safe
ly removed
no matter what.



Implemented a bit of ScriptComponentTemplate and created ScriptComponent
class. Still, I'm not sure what I'm going to do with message processing. Basic
event methods (OnInitialise, OnMapLoaded...) are not tied to an Int32, so h
ow
can ScriptComponents process them? I suppose I'll have to implement
DefaultMessages for those methods too; this way, these events will behave in
message
-
queue fashion.



Spent some hours looking for cool .net controls and components… I found a
handful o
f them that look quite fine. I’ll check them tomorrow.



August 26
th



I don't know why everybody's trying to get a ribbon into their applications... It
just doesn't seem to fit in my editor, too messy.



I'll use DockPanel Suite 2.3.1 for the editor. The
library looks fantastic.



August 27
th



It's sad but true: after experiencing with Unity engine trial yesterday, I've
discovered the many flaws that my implementation has. And know I dunno what
to do: keep going or make drastic changes?



First of all, un
ity doesn't seem to use Managers. There are top level
components... though I suppose there must be some kind of Manager that
controls input, graphics, physics...



Still have to find out how messaging works in Unity.



Unity's layout is great. All panels a
re drag 'n droppable, un/dockable. There are
5 types of panels: project resources, scene graph tree, scene edit, object
properties and game view. I also have console panel.



For implementing custom layout save/load features: DockPanel.Persistor.cs
lines 2
33 and 512. Possible uses of this:



storing camera details fore ach 3d view



storing last loaded scene



Added virtual method Component.OnValueChanged()



I'm doing drastic changes: ComponentTemplate does no longer exist.
IcomponentTemplate will replace

it.



August 28
th



After trying hard to make Component and ComponentTemplate one single
AbstractComponent class, I'm forced to give up on it. How would new custom
templates be instantiated?



I'm planning to leave the design open for people to implement
their own get/set
optimizations.



Created AbstractJunkItem class. Everything in the Application that should
receive an id (components, gameobjects, assets...) should derive from this class.
This class receives an Id, and defines methods Destroy and Clone.



Implemented some methods to compare AbstractJunkItem. I'm not sure if they'll
work right.



August 30
th



Created AbstractSimulation.



I think I'll remove ManagerFactory and ManagerTemplate.



Maybe I don't need Managers... and it all can be done with

components...
-
>
nah, I do need Managers, same as Unity does.



August 31
st



I will make Manager abstract.



Simulation has pointer to non
-
Singleton Application instance that owns it



A Simulation can now be run independently. Applications simply make i
t easier
to handle concurrent simulation executions. In fact, I'm not sure wether
Application should lie in Engine or rather be an external class...



Application has a dictionary for all managers, and another private dictionaries
where each simulation is
given its own thread.



Simulations now have names. However, access to simulations of an Application
via simulation.Name is not yet supported.



September 1
st



Should Simulation have an Update() method? Maybe only managers and
components should… But then,

do all managers and components need an
Update method? Shouldn’t Update be implemented in derived classes?
-
>
Simulation has an abstract Update() method that should return false to signal
that it must be stopped from updating. Component and Manager should
not have
an Update method, at least not at engine level.






September 2
nd



It seems like thread.Abort() was messing it all up…
-
> I don’t use that method
anymore. I simply set the state to DESTROYED or STOPPED. Simulations are
removed from Application’s

dictionaries as soon as they fire the
DestroyRequested, Crashed or Destroyed event. So... what will happen if a
simulation thread hangs in an infinite loop? I create the thread in background
mode, but does that make any difference?



After doing some chec
ks, simulation threads are successfully destroying
themselves fully, even after being removed from the application’s dictionaries,
lazily or not.



some virtual method in AbstractSimulation should return true if the simulation
state should be changed to RE
ADY. This method should be called Setup or
something
-
> I eventually decided to leave the Setup() method for Managers,
and not simulation. A manager should always be setup and cleanedup from
within, so that's part of the engine. However, would it be a good

idea to give
Simulation Setup and Cleanup methods as well?
-
> Events like Started and
Destroyed should be enough for supporting this functionality.



September 3
rd



Access to simulations of an application via name is supported now.





September 15
th



I
t's been a while



Attributes now have a boolean Cached property. This tells whether components
that contain an attribute should always store the value for that attribute, even
though it's default. If an attribute is not Cached, then the component will not

store unnecessary values, thus saving memory, but needing more process time.



I'm working on GraphicsManager. It starts a renderwindow and updates it. This
will not be used in the editor; the editor will have a more sophisticated manager
that deals with
multiple view panels.



September 21
st



I have quit using the PluginHandler class. Not using the Application class
anymore, neither. These were design concepts that I was confident I'd
implement, and I thought they would make a big difference of this engi
ne over
any other. But I'm not sure of it at all now.



September 22
nd



GameObject templates are identified by the name of the GameObject instance in
the GameObjectFactory, instead of an artificial Type string.



September 25
th



I have made Components id
entifiable by their class Type, not an artificial string.



I have removed Parameter and ComponentAttribute classes.



Deleted IComponentTemplate. Its methods are now part of Component.



Deleted Managers
-
> this is good, very good.



Messages were delete
d a long time ago... I suppose direct method calls are OK.
I'll have to implement something similar to Unity's, which use
yield

and all that
jazz. Anyway, that code should lie at Rubbish, not directly at the component
system.



Stopped using Application. I

was hoping to implement a multithreaded platform
for running many simulations at a time. However, I don't think it's really
necessary to run them in many threads. Updating them in an external loop might
do just fine.



Deleted PluginHandlers. These depend
ed on Application. Custom plugins can
be handled in custom code, there’s really no need for unified classes that handle
all plugins… that’s overkill.



September 30
th



Created RubbishObject.



Components are now instantiated automatically within the engin
e. There's no
need for a factory. Every Component must contain an empty constructor, which
will be used in order to instantiate the new components.



I have realised that, if components are identified by their class Type, then how
are XML components going
to be identified?



Implemented quick get properties for managers of the simulation, and for
typycal sibling components.



RubbishSimulation.TimeDelta returns the amount of elapsed seconds since the
last update.



October 1
st



I'm SO happy today! I've cle
aned up the whole engine enourmously!



Implemented ComponentType, the unified way of identifying the type of
components, which will let the engine support components of any possible type:
code, script and xml.



Included three new events at GameObject tha
t let you respond to
required/incompatible components being added/removed.



Component templates are stored at RubbishComponent. ComponentFactory is
gone!! Sweet :
-
D



October 2
nd



IComponentParser implemented. Now RubbishComponent stores a list of
ICompo
nentParser that it uses to parse components on demand.



GameObject.Duplicate() now creates new instances by using the empty
constructor of the Type. No need to override duplicate, your derived classes of
GameObject will be instantiated with the same Type
when using Duplicate. That
means, you still get your custom events and other overridden fields.



I've given a OnPhysicsTick() event to RubbishComponents. This event is fired
from the PhysicsManager.



Started to work on ReflectionComponent.



October 5
th



ComponentDefaultValueAttribute implemented.



CompiledComponent ready :
-
)



October 6
th



RubbishObject templates working.



Implemented ComponentAttributeInfo, which is abstract at RubbishComponent.
This method will be used by the editor when loading C
omponents at the
property view.



October 7
th



RubbishComponent has a virtual string get property Category. It returns
“General”, and can be overridden at will. In the editor, components will be
grouped by category.



October 7
th



GraphicManager can now
handle any number (greater than zero) of so called
GraphicViews.



October 12
nd



GraphicViews are now known as SimulationViews and are contained by
Simulation.



The editor is working with one sceneview and one gameview. However, floating
windows are not
supported yet, and more than one sceneview makes the editor
crash. Moreover, sceneviews that were open before starting the simulation do
not render.



October 16
th



Lots of things have happened. I simply haven't written them here ^__^U



CompiledComponent

now only executes GetAttributesInfo once, thus saving
tons of time.



Static attributes work flawlessly :
-
D






October 18
th



Scene graph panel is working. Objects can be removed and added and it works
ok, dynamically, recursively… Yeah




October 19
th



Properties are updated correctly in the UI if they change at runtime.
-
> However,
while updating, the items cannot be edited at the propertygrid, so this is useless



October 20
th



Vector3 values supported. I tried 2 different ways of editing them: by
writing the
coords in a string, and in a expandable structure with items X Y and Z. The
latter is more attractive, but is tougher to achieve elegantly. I eventually chose
the string value mode.



November 1
st



GameManager.SaveScene( ) implemented. Now I a
m implementing
GameManager.LoadScene( ), and will have to deal with parent/children nodes,
assigning component attributes of type RubbishComponent by the ID…



Novem
ber 5
th



Component attributes now support RubbishComponents types. This way, you can
assign
references to other objects in the simulation. However, the engine does not
handle that, when the component is removed, the attribute is set to null. You should
control this manually, e.g: by reacting to ComponentRemoved event.



Created SimulationSettings c
lass. Simulation constructor now asks for an instance
of that class.



Implemented IPausable. RubbishComponents that implement this interface will
only be updated if Enabled returns true. Additionally, those components will not be
updated when the simulation

is paused; all others will be updated.



November 9
th



When a SceneViewPanel is closed, its SimulationView is removed from the
Simulation. However, some unstability still occurs: moving panels around and
docking it in different positions makes the panels s
top rendering. This probably
happens due to the parent form or handle changing.



Improved the feel of the camera for scene edit panels.



November 11
th



I've spent a while trying to figure out how to hide the mouseCursor at will. It turns
out that Win32 inpu
t is SH1T, and so is System.Windows.Forms.Cursor! I
implemented MouseCursorVisibility; that should be the only way of showing/hiding
the cursor. I wasted some time too because OIS expects a Topmost form's handle for
InputManager; therefore, handling embedd
ed render windows via OIS events is
hell...



Can release input focus from the Game View by pressing Ctrl+Alt+Tab. However,
this doesn't work perfectly: the mouse cursor shows the 2
nd

time you do this.



November 12
th



I'm modifying IParser so that it support
s loading from assemblies
-
> Done.






Un parser deberia ocuparse de las assemblies actualmente cargadas; Otro parser
deberia encargarse de cargar los componentes de assemblies; Otro parser deberia
interpretar XML.
-
> De este modo, sencillamente estas emp
leando parsers, y no hay
codigo de pegote.
-
> At RubbishComponent.ParseComp..... the eligibleFiles array
should be removed. IParsers should only use FindAndParse, and then, it should be
IParsers the ones who tried to find the eligible files.
-
> SupportedE
xtensions is
useless now, and so is the old Parse method.




I'm enabling automatic parsing of component templates on
ComponentTemplatesFolderChanged :
-
)




I'm assuming that multiSelection will be supported.






Form.HandleCreated/HandleDestroyed events
could come in handy when trying to
implement support for floating windows and drag/dropping windows.
-
> See this
whole thread
http://www.ogre3d.org/addonforums/viewtopic.php
?f=8&t=7697&start=15

,
Seemingly, you must give OIS the handle of the TopMost window. Thereby, I think
you can solve it by using
(Form as DockContent).DockPanel.Parent
instead of
Form.Parent

-
> But then again, how am I going to handle input for child pan
els?




A MouseGesture might return null at End



SelectionGesture should record what RubbishObject was pressed when the gesture
started, and checkthat when the button is released the RubbishObject is the same.
This gesture should also create a box for mul
tiselection. You should distinguish
between SelectionGesture and MultiSelectionGesture. Both should create different
transactions.


I think the m_simulationUpdateTimer should tick more often.




Para probar la sentencia yield, reimplementa el metodo
Editor
Form.simulationUpdateTimer_Tick de manera que cada vez que se invoque
se continúe la iteración de un bucle.





EditorManager.SelectedObject should be SelectedObjects instead.



If Shift is pressed when clicked on an object, then add it to SelectedObjects





A progress bar should be updated in transactions.




The projectExplorerPanel should react to ProjectStarted and set the content of the
treeview accordingly.


I’ll have to make a custom class for treeviewNode, that implements IEditorProperty
or someth
ing… probably IEditorProperty is unnecessary



The Chaser component isn't OK yet...
The propertyGrid doesn't show the combobox
with eligible gameObjects ok, and if double clicked or written to it crashes.



Currently, a project's folders are relative to Ed
itor.exe, and that should not be so.
Make it so that paths are relative to the folder where the project file lies.




RubbishComponent.ReloadTemplates( ) should search all assemblies, trying to find
subclasses of RubbishComponent. Then, they should be regi
stered as templates.




DoubleClick on an object in the hierarchy
-
> focus on it in the current sceneView.




MessageBox
.Show(
"the simulation should never actually be destroyed. Simply stop it...
destroying it would be followed by leaving th
e application."
);




Test IPausable. Make Chaser IPausable and try with PhysicsManager.




Project must contain a SceneEditSession. All that is done to the scene and the
Simulation inside the Editor is done by Transactions:



StartSceneTransaction



CloseScene
Transaction




Project must define a Resources folder too, and so should Simulation.
Mogre.ResourceGroupManager will load the 'ALL' resource group from that folder
recursively.
-
> you should store these in a SimulationConfig instance.
-
> Or maybe in a
Sett
ingsManager, or ConfigManager, which all other Managers must require. This
manager should handle any necessary refresh when the values change.
-
> When this is
done, it would be more elegant to have the scenes and templates folder outside of the
resources f
older.



If a resource file is modified from outside the editor, reload the resource
-
>
http://www.ogre3d.org/wiki/index.php/Advanced_Tutorial_1





MeshRenderer should keep a referen
ce to the “Mesh” resource, not to the entity. Then,
another component should take that 'Mesh' resource and use it to create the entity.




You should not use Mogre.Vector3, but Rubbish.Vector3, and Rubbish.Quaternion.
Creating custom types would allow maki
ng conversiones more easily.



The way it is done now, loading/saving scenes will crash in case the default value of a
component attribute of type RubbishComponent is not null.
-
> All component attributes
of type RubbishComponent (or derived) must have a ‘
null’ as default value.


Vector3 should be written like 0.0 12.0 3.0 … I mean, manually.



Try the Chaser component. It has an attribute of type NodeComponent.



GameManager.SaveScene stores game objects ok! :
-
D



GameManager.SaveScene should use GameObjec
t.GetState for finding out the values
that have changed from the default one.



The inputManager should store and update a dictionary of presed keys/buttons. This lets
you forget about what the FocusedView is, and you could make it so that it can tell you
if the key/button was just pressed/released or was already pressed.




The ids of the game objects must be taken into account when loading the scene file.
-
>
In LoadScene, the vectors will have to be parsed … And gameobject Ids too.




Cambia los eventos d
e Project
-
> New
-
> Project a Project
-
> New , y lo mismo para
Project
-
> Load



I was starting NewProjectDialog implementation.
-
> It works flawlessly :
-
D. Now just
show it when necessary.



I'm thinking that scenes should not be created/loaded from the Fil
e menu. They should
be added at the Project explorer panel. The project should contain a list of scene files, or
a string with the path to the scenes folder.



Project.lastsavedscene



Settings object should never be added to the objects list. It should be

controlled
specially.



Simulation can be started paused



Not all rubbishcomponents should have 'enabled'. It should be an interface that lets
them them be enabled. When a Simulation is Paused, it doesn't update 'enableable'
components.


Necesito que se

ejecute de manera guay... estabas haciendo los metodos LoadProject y
CloseProject



Buscar cuadros de formas geometricas !!!
-
> pag 222 volumen I de Arte en el siglo XX



There’s plenty of good things at MMOC sample. For example, how to initialize mogre
p
rogrammatically.



Ventanita para New Project, la tienes escrita en el cuaderno.



In ogre 1.6.4 binaries:



Entity.NormaliseNormals doesn’t exist. Why?



Node.WorldOrientation and Node.WorldPosition do not exist.







Los atributos de componente que sean de ti
po RubbishComponent han de tener una manera
especial de ser fijados en el PropertiesPanel. Deberia mostrarse un combobox y poder elegir
entre todos los componentes del tipo indicado.
-
> Simulation ha de contener metodos para
pillar todos los componentes de

un ComponentType.
Ea.





There is no support for NodeComponents that change parent. If the parent changes, an
event should be fired. The user should be able to move objects from one parent to
another, and the scene graph panel shoud show that.



IJunkEdi
torProperty should actually be a subclass of GenericProperty. It should have a
custom way of firing an event when the property value changes, and of course it must
implement NeedsSave, Save and Reset.



Component values should update automatically if they
change during runtime. How
should this be done? Responding to some event? Pooling every update?
-
> pooling
looks right to me.
-
> Remember that IJunkProperty has an event for signalling edit
operations, so that's what you should use, isn't it?
-
> Maybe Rub
bishComponent should
have an event called 'ValueChanged', that gets invoked whenever the value changes...
dunno... for compiled components, this would mean that the person who codes the
subclass must remember firing the event everytime the value changes, a
nd that's
impractical.




PropertiesPanel contextmenu makes the simulation freeze.






IEditorProperty should watch IGenericProperty.PropertyValueChanged. :
-
)




set the grid on SceneViews. Also, disable fog, weather effects and sky for sceneviews.





Co
mponentAttributeProperty and all other subclasses of IEditorProperty do not define
NeedsSave and all that jazz... don't forget to implement that






I think TimeManager.FixedUpdateDelay is not working ok, at least not for physics.
Physic bodies should mo
ve equally fast no matter the value of FixedUpdateDelay, but
that is not happening.



The Rubbish.Managers.InputManager should contain a collection of commands (or
whatever name you finally choose). These commands are checked if the active view
processes i
nput. Else, it does nothing...
-
> Maybe when the view changes to one that
doesn't process input, all commands should be disabled as if the key/button was
released.




I have already downloaded MMOC, but it needs MET. Visit this page and download
Mogre Edit
able Terrain Manager! ! ! !
http://www.ogre3d.org/wiki/index.php/MOGRE_Editable_Terrain_Manager





ReloadTemplates must still be implemented...




Simulation should store a list with available scenes.
-
> not really. Simulation should
contain Factories for

components, objects and scenes... and maybe more things.
-
>
those Factories parse templates automatically when created.
-
> implementing
ObjectFactory, implement ComponentFactory later.





Use Control.ContainsFocus instead of Focused or other things…





Watch the order that ViewDeinitialised event is being called in.





integrate met and mmoc instead of bbox raypicks!






Compiled components, or maybe rubbish components, should set their values to default
in its constructor!!! Or maybe on added to simul
ation...?
-
> nope, I think it's better in
constructor.
-
> Can't do it in the constructor. From the RubbishComponent's constructor,
you cannot know about the subclass and thus you can't access their ResetToDefault
method. And, resetting to default when the
component is added to the simulation, I don't
like it. We want to be able to add components with custom values. So... I eventually
decided to leave it as it is: if an attribute has a DefaultValue it doesn't mean that its
initial value is the default; you h
ave to explicitly set the value at the component's
constructor.



I've just realised that subclassing Simulation really shouldn't be needed. Simulation
class contains plenty of events, and, after all, Components should already handle all
custom functionali
ty. So, maybe having a virtual CustomUpdate makes no sense. Think
about it.



Should GraphicsManager.OnTick be called every update? Aren't other managers more
important?





mogre 1.6.4 binaries are out... should swap to them







Some components' (and ma
nagers') OnRemovingFromSimulation methods have
not been implemented yet.




MogreNewt.Debugger.Instance isn't working. When I add the PhysicsManager to the
simulation, the debugger is initialised. When removed from the simulation, it is
deinitialised. When

trying to initialise the instance again, an exception occurs.






el editor deberia tener un proyecto abierto en todo momento tu sabes


estabas editando ProjectSettings ... crea otra clase que se llame Project, y asi puedes meterle metodos y
tal. Lo suyo

es que permitas especificar un parser de proyectos, para que los ficheros cargados/guardados
sean distintos



en el editor, inicializa el motor al cargar una escena... no? no del tirón... digo yo




Remember that you finally (somehow) managed
to make TecnoFreak's graph controls
work. You could use them for something, for example AI behaviour trees.



El parseo de componentes y objetos, que se hace desde RubbishComponent y
RubbishObject, deberia utilizar las carpetas del Mogre.ResourceManager, n
o? Vamos,
digo yo que seria lo suyo. O mejor aun, el ResourceManager deberia localizar dichas
plantillas como recursos, y que permitiera hacer ResourceManager.get(“component”,
“RotatorTest.component”);





Some method should enable showing render stats, li
ke so (or displaying in the
window):


RenderTarget
.
FrameStats

stats = GetRenderWindow(0).GetStatistics();


Logger
.Info(
"LastFPS: "

+ stats.LastFPS +
", TriangleCount:"

+ stats.TriangleCount +
", BatchCount:
"

+ stats.BatchCount);





Right click on gameobject
-
> addComponent


Config files paths should be passed to Managers by Properties or something, not
hardcoded within the managers.



swim through the TODO tasks, and/or start implementing the editor.



DefaultComponentValueAttribute
should only be assignable to Properties. Regular
fields should read their default values like in Unity, e.g: public float myFloat = 0.5f; =>
the default value is 0.5f ; if it isn't done this way, then how are you going to control that
the user does not as
sign values in the constructor, for example?



Obviously, NodeComponent.SceneNode must be an internal property. It must not be
visible in the editor. The editor should show the same fields as Unity's transform
component.



I'm not sure if SetValue should r
eturn a bool if the value changed. After all, you can
already react to value changes by using properties, and you could send messages / fire
events from there.



About implementing CompiledComponents:



Use BrowsableAttribute to show/hide the property



ge
tValue setValue... those methods should lie in rubbishComponent, same as
GetValueDescriptions, which should return some ComponentValueDescription or
something...
-
> I have already moved those methods from Component to
RubbishComponent. I still have to impl
ement the GetValueDescriptions, or
GetAttribute...



Reflection should only be done once for every method. When the code first invokes
RequiredSiblings, the returned collection is stored privately, so that it is returned
thereafter.



I could have all attr
ibutes merged into one Attribute class.



These are C# predefined attributes:



DisplayName
. Sets the name that will be shown in the PropertyGrid.



DescriptionAttribute
. Sets the text for the property that is displayed in the description help
pane below
the properties. This is a useful way to provide help text for the active property
(the property that has focus). Apply this attribute to the MaxRepeatRate property.



CategoryAttribute
. Sets the category that the property is under in the grid. This is use
ful
when you want a property grouped by a category name. If a property does not have a
category specified, then it will be assigned to the
Misc

category. Apply this attribute to all
properties.



BrowsableAttribute



Indicates whether the property is show
n in the grid. This is useful
when you want to hide a property from the grid. By default, a public property is always
shown in the grid. Apply this attribute to the
SettingsChanged

property.



ReadOnlyAttri bute



Indicates whether the property is read
-
onl
y. This is useful when you
want to keep a property from being editable in the grid. By default, a public property with
get and set accessor functions is editable in the grid. Apply this attribute to the
AppVersion

property.



DefaultComponentValueAttri but
e



Identifies the property's default value. This is useful
when you want to provide a default value for a property and later determine if the property's
value is different than the default. Apply this attribute to all properties.



DefaultPropertyAttri bu
te



Identifies the default property for the class. The default
property for a class gets the focus first when the class is selected in the grid. Apply this
attribute to the
AppSettings

class.



RequiredComponentAttri bute





Incompati bleComponentAttri but
e





EditorAttri bute







RigidBody and collider are not working. Test/fix them.


XmlComponents and ScriptComponents should keep a reference to their source file.
They should periodically check the file for changes, and refresh themselves.



I'll need an
other way of defining componentType, other than
ComponentTypeByType(typeof(CLASS)) ... designers would not like that
-
> The most
obvious need for this is at RequiredSiblings and IncompatibleSiblings. External coders
should not have to deal with setting the
m directly, but with C# attributes instead.


At the beginning of development, my aim was to make everything instantiatable from
Xml files. Even components. That is why I needed ComponentAttribute and Parameter,
classes that helped store the type and defau
lt value and such other things about each
component's attribute. Lately, I've been relying more and more on code reflection,
making components very oriented towards programming and scripting, not really data
-
oriented. However, I can still implement a varia
tion of Component that can be created
from a Xml, uses ComponentAttribute and contains a cache of values, doing recursive
value lookups, and generally all of the other things that I had already implemented at
previous stages of development.
-
> Make Compone
ntType class the unique way to
identify a component. Component class should define an abstract getter called Type.
ComponentType should be able to compare itself to other instances of
ComponentType. This way, you can have both code and XML gameobjects ide
ntified
by type (this would need gameobjectfactory or something similar).
-
> The way I'm
looking at this, ComponentType is an abstract property of Component. It could return
an object, which is checked in custom code. Thus, in Rubbish, the code would check

if
the ComponentType instance is of type Type or String, and act accordingly.




For editing component values at the Editor, I’ll use the code from codeproject called
PropertyGridContextMenu. The classes that go in the propertyGrid derive from
GenericProp
erty and contain a component as a field. It looks easy.




I don't know how useful JunkPieces would be, so don't pay too much attention to this
paragraph. However, you need to study WHY JunkPieces should be good.

Unite objects and components in a same inte
rface called JunkPiece:



Simulation contains a list of JunkPieces



JunkPiece contains Id. Not all JunkPieces have a name. But then... how would you
access prefabs by name? In unity, component names are the same of their
ownigObject



VisibilityFlags are
part of JunkPiece



TypeDescriptor has many methods that I should use for code reflection.



Simulation RemoveObject and DoRemoveObject are change to Remove and
DoRemove, and of course the methods accept JunkPiece instances and Ids
-
> this
may not be a goo
d idea; in unity, these methods are contained by the objects and
components (and other assets) themselves.



DoRemove is public



Unity assigns an Id to all assets. There's not a concept of factories. Every asset can
be duplicated. That's the beauty of Uni
ty component system, which works similarly
to the resource system.







Before releasing, you have work to do on the following aspects:



Editor:



Write ALL DescriptionAttributes



Write all &text in menuItems



status tips for all controls (lines in the

status bar)



work hard on tooltips:
everything
should have a tooltip message



set correct TabOrder values !








Switch to C5 collections instead of Iesi... contains efficient
MultiDictionaries (MultiMaps), Sets...






when the object Id counter rea
ches a limit (high number), gather a
stack with free Ids. From then on, assign those ids instead of
increasing the counter.










What about gameObjects' parents (templates)? How am I going to implement it? In
unity they use the
prefab

and
prefab instan
ce

words for parents and children. And I
think that unity doesn't support more than one level of inheritance. Achieving that in my
engine would be superb.



reverting to default values (parent's values)



overriding certain attributes (thus making them cac
hed, not affected by changes in
the parent)



Connect/disconnect/reconnect a gameObject to another one.



In unity, adding or removing components and/or children gameObjects (nodes)
make the GameObjects lose the reference to their parents. If I could manag
e to
avoid that inconvenience, it would be awesome.



In the editor, you can know when a duplicated object has changed and such stuff.



How to do this: GameObjects should have a pointer to their original GameObject.
When you duplicate an object, the new
instance stores the pointer to the original.
This way, But, what about multiple inheritance?



Custom components will support Attributes of both typeS:



class fields, e.g:
public float size = 0f;



class properties, e.g:
public float Size

Properties can
be get/set, and react when being read/set. The default value for property
attributes will be reached via
default
keyword, or it can be set using a C# attribute.


Unity uses C# Attributes in order to define many ways Components should behave/be
shown/create
d/store values... That is great, I had already thought of using C# Attributes
for those things.






GameObjectTemplate, as it is now, stores values of its component definitions in a
dictionary. If values don't change from default, then they're not stored.

The way it's
done in Unity, gameObjectTemplates do not exist; whenever you need a copy, you
simply call Duplicate(). The problem is, in Unity all values are stored. Currently, the
engine relies heavily on Factories for instantiating things automatically.


Future hopes: loading assemblies, supporting various namespaces...



Physics aren't working when outside the scene... or in negative positions...


Clearcomponents must still be implemented, though I don't think it's too important




should managers keep
track of all their function
-
related components contained by the
simulation? Like, PhysicsManager stores references to RigidBody and that sort of
components...




Are both stopped and destroyed states still necessary? Think about it






Explain that Compon
entAdded events cannot be watched by the added component, but
only externally.





visibilityflag needs to be supported




hey, Mogre has no SceneNode.userAny attribute!! It would be great if I could have the
nodeComponent stored in the SceneNode's any...
:'
-
(




Node Listener contains events that could be useful for SceneNodeComponent.



the game should use time slicing to update the simulation. Rendering (via
graphicsManager) every update is not necessary, and other managers (physics/game/AI)
need differe
nt update frequencies.


Use IConvertible interface for knowing if an attribute can be used. Look at Int32
metadata, and look at its implemented interfaces.






Document that Start, Pause... methods fire the right events.

Document that Update fires other e
vents as well.





events for ComponentTemplate registered and unregistered!! other methods
for other types of templates, too.




Logger should use FileStream class, which allows concurrent writes to file quite easily.
There’s already some code there, thou
gh commented.



Objects are not being added nor removed in a thread safe way.






A method should make it possible to Stop a Simulation /Application drastically, just
in case something bad happens.
-
> Sure thing. That’s what
RemoveSimulationImmediately an
d ShutdownImmediately do
-
> Still, I have to
change it so that there is only one Shutdown method, which receives an int with the
maximum timeout before the simulation is drastically aborted. I will have to do this
for RemoveSimulation too!
-
> Ok, that has
been done, though it needs to be tested.
-
> Shutdown and RemoveSimulation methods should require a bool parameter called
runOnBackground. If true, these methods start a thread where they work. If false,
the calling thread waits for the method to finish.
-
>

Shutdown() is done; it asks for a
timeOut value. It tries to remove all simulations simultaneously by running one
thread for each simulation. However, runOnBackground functionality is still
missing.



Think about Application.StopSimulation()... what if th
e simulation freezes and does
never stop?








From unity's Object class documentation
-
> “Any public variable you make that derives
from Object gets shown in the inspector as a drop target, allowing you to set the value
from the GUI.”





Should I sched
ule method executions for later? How is it done in unity? Are
methods executed immediately? What about invoke methods (there are some in unity)?
-
>
Read Jason Gregory's GDC 2009 talk. His implementation focuses on making Processes
instead of GameObjects. I
t's quite interesting to read.





Explain how open my design is when compared to unity's.



Static attributes, unity supports them.




Load all templates at startup?



All component should have an internal list of instances of it. this way you can easily

update all instances in case the type changes... is this worth the effort?





In Unity, a prefab cannot derive from another prefab. This is the same as a (deprecated)
GameObjectTemplate having a parent template.




In unity:



Can prefabs contain other p
refabs? This would make template loading/saving much
more difficult.



what about automatic reload of resources when modified externally? How's that
done? :
-
S Unity3d does it, so it's possible.



How does yield work? I mean, how does it know where to conti
nue execution?
When is it called every frame? JetPackParticleController has a while(true) loop in
its Start() method, so is Start invoked every frame? It seems so.



Use expression trees for defining game rules. You could write game rules in a
document, th
en read them from the document and compile the functions. That would
allow designers to get MAXIMUM flexibility.

http://kartones.net/blogs/jadengine/archive/2009/03/31/193
-
rboles
-
de
-
expresiones.aspx






Check the 3d platformer sample project for unity. Ch
eck the assets and all. See if you
can recycle any of the scripts (for example, the CharacterController scripts,
ThirPersonPlayerAnimation... study them).





Study how pathfinding is done by these guys
-
>
http://209.85.129.132/search?q=cache:http://www.pa
thengine.com/

















EDITOR ANNOTATIONS






DockPanel can only be mdi




Hey, in the editor, it might be great to have a Component of type 'editorProperty'
automatically added to each GameObject. This component should contain the
IJunkEditorPrope
rty related to the GameObject. This way, there can only be one
property item for each object, and we can access the property from the object and
viceversa. EditorFlags must be supported, so that this component isn't saved nor shown.
-
> I'd rather have a pr
operty class that receives a RubbishObject and adjusts itself to it.





features for the editor:



in the editor, right click on an object's attribute for a component, then click reset,
just like in unity.
-
> This is all already done in the codeproject s
olution
PropertyGridContextMenu.



Instances of free (not template based) objects are shown in black text. Instances of
objects that come from a template are shown in blue text. Instances of objects that
come from a template but have been modified are show
n in dark green text.



A button (or item in a contextMenu) should allow to create a template from a given
gameobject, or update it.



Context menu item and toolbar button for focusing the scene view on selected
object.



Some way of distinguishing default

components from custom ones.



unity automatically creates Mesh and Animation and Whatnot components when
assigning a mesh asset to an object. It even creates child objects for subentities...



in unity you can drop a component in the scene view and it i
nstantiates an object
with the component and required components


and, presumably, a transform
component too.



The project explorer must include component templates, object templates, scene
definitions, other assets (like meshes, textures and sounds)



A
dd filter buttons to the project explorer and the scene explorer, and maybe a
textbox for filtering based on resource name



everything that is saved in the editor is stored to files (usually xml, except e.g.
Scripts) in the right folders.



Cannot modify
templates written in code.



Mouseover info for everything!!



Progress bar / clock icon...



Engine level data (basic events, basic messages...) are shown in green; custom data
is shown in black; unmodifiable fields are shown in grey.



Should be able to
load assemblies and grab custom Component classes and stuff
from there.



Text / table fields in the editor could be hyper
-
linked to their objects... Like double
clicking the name of a required component and opening this one in the editor...



Paths for ev
erything: config.ini, templates, scripts, etc.



Whenever a component is selected, required components are shown in some colour.



Double click on a GameObject (and some other actions too) opens the GameObject
edit dialog.



If the user wants to modify a t
emplate upon which others depend (required,
contained component, parent template...), the application must warn the user that
these may be affected by the changes.



The console should have some toggle buttons around it that trigger showing Critical
messag
es, debug, TODO... and stuff like that.



The context menu on components should have an option 'See template' that opens
up a panel or something where you can see required and incompatible components,
if it is a script component or a compiled one, etc.



T
he sceneGraph should show checkboxes. If an object's checkbox is true, then the
object is enabled (RubbishObject.Enabled).



a console panel in the editor will:



show Logger messages



show help messages for what the user has just done in the editor



ena
ble script writing during runtime of the simulation.




ComponentTemplateProperty.Required/IncompatibleTemplates should be strings. There
should only exist one instance of each property grid item at any given time. This way,
the editor doesn't ask you for
saving every time you modify an item; save/reset buttons
are enabled/disabled .. ... ..
-
> DO YOU THINK THIS IS THE BEST? Maybe items
should automatically save themselves...?



Some Editor Documentation:



ribbon for winforms
-
>
http://www.codeproject.com/K
B/toolbars/WinFormsRibbon.aspx




look at this
http://aspalliance.com/652_Review_Free_Components_for_ASPNET_11.1




http://www.codeproject.com/KB/miscctrl/shellcontrol.aspx



http://www.litobyte.com/some.png



propertygrid
http://msdn.microsoft.com/en
-
us/l
ibrary/aa302326.aspx



http://www.codeproject.com/KB/miscctrl/shellcontrol.aspx



http://sourceforge.net/forum/forum.php?forum_id=402316



http://www.codeproject.com/KB/vb/DockPanelSkin.aspx?msg=2793566



http://www.codeproject.com/KB/tabs/Dynamic_Property
grid.aspx?fid=1434
93&fr=14



http://www.codeproject.com/KB/vb/PropertyGridEx.aspx?fid=286800&fr=2
6&df=90&mpp=25&noise=3&sort=Position&view=Quick



http://blog.codinglight.com/2008/10/changing
-
attribute
-
parameters
-
at.html



http://stackoverflow.com/question
s/313822/how
-
to
-
modify
-
propertygrid
-
at
-
runtime
-
add
-
remove
-
property
-
and
-
dynamic
-
types
-
enum



http://dotnetfacts.blogspot.com/2008/06/how
-
to
-
set
-
propertygrid
-
as
-
read
-
only.html



http://www.codeproject.com/KB/cs/wdzpropertygridutils.aspx?fid=85101&f
r=26



htt
p://mastersact.blogspot.com/2007/06/string
-
collection
-
editor
-
for
-
property.html



http://msdn.microsoft.com/en
-
us/library/aa302326.aspx#usingpropgrid_topic6








registering/unregistering component templates could cause virtual attributes to go to
mess? M
aybe not, because after all, required templates would not be lost, because
the garbage collector wouldn't delete them. I suppose required templates should be
registered/unregistered immediately, so that they can be registered anew, and all
components creat
ed thereafter follow the new rules. And what about un/registering
game object templates? I think that, similarly to what I have said about component
templates, child object templates should be unregistered when the parent is
(recursivity :
-
D)















ERROS OR CONS ABOUT THE IMPLEMENTATION



Simulation should be global or singleton.



Component templates and GameObject templates should be handled as Ogre
resources. This would make the editor much easier too, just like in Unity.



Should have used TypeConver
ter for all usable types... shouldn't I? The way
Vector3, Quaternion and MeshName are converted looks so dirty...



Component type should be string. Using ComponentType only complicates
things.