Differences

This shows you the differences between two versions of the page.

--- documentation:engineworkbench [2013/06/12 17:06] – [TODO: organize :)] mhgamework
+++ documentation:engineworkbench [2024/08/26 13:25] (current) – external edit 127.0.0.1
@@ Line 5: / Line 5: @@
   * I just realized: if i add some dependencies to gameplay.dll, and hotload gameplay dll, can't i consider the dependencies as being hotloaded too? Is this an easy way to allow split dll hotloading?
-  * Let hotloading work on fields instead of properties? Or should these properties remain forced public as to force the coder to see these as possible access paths?
   * Support multiple gameplay dlls. (Also note the one core plugin loader idea)
   * Note that the original idea was to have hierarchial hotloading, where not every subpart is hotloaded, in my quickfix above everything is relinked.
   * Maybe support multiple gameplay dlls, to allow faster compiling, and put each testcase in a seperate dll.
-  * Let wizards engine compile, disable edit and continue in vs, this could potentially allow continuous debugging!!!
-  * Create a 'kill-thread' which monitors the thread that runs gameplay simulation (maybe even the rendering thread), and aborts it when it fails to send regular heartbeats.
-  * Thoroughly check hotloading and removal of objects , something
 ===== TW.Data: Modelobject system, create, remove, changes =====
@@ Line 46: / Line 42: @@
 ===== User interface =====
-  * Engine Add savestate to engine ui, instead of requiring to exit the program :)
   * Engine: allow resizing the engine, just keep aspect ratio of rendering and add some extra info below, so we can attach it to the side of the screen :)
   * Engine: implement some form of autosaving, eg on switching tests.
@@ Line 52: / Line 47: @@
   * Support premodifying of models (custom model format?) (it is currently not possible  to scale imported models, since physx does not support dynamic scaling)
   * Fix switch desktops for engine
-  * Disable simulation when engine is not active window (with optional button)
 ===== TODO: organize :) =====
+Engine Automatic invariants: readonly fields are invariant? Think more closely: some fields are not supposed to change during runtime, but this is not always determined during compile time. Eg you could be using a class with a property which you set once and you know you don't want it to change during runtime, but that same class could be used somewhere entirely different where this is possible. Find a convention for this?
+Engine Another hotloading idea: you can easily hotload at interface boundaries, by using a dynamic proxy that adapts to new interface implementations.
+Engine Another style hotloading: make test setup deterministic, and use a ID that is counted using the object creation to identified identical objects.
+Engine New style hotloading: per class! use a dynamic assembly, detect changes to a source file. Attempt to compile this sourcefile while referencing the old assemblies. Then only replace the changed class.
+ Engine Disable simulators option for debugging at runtime
+Engine Show the contents of the line at which the error occured. This is a crazy usefull function when resolving nullreference exceptions due to missing windsor dependencies. Other idea is to simply use postsharp to say dependencies are not correctly set.
+Engine replace the singletons and static classes (TW,...) with dependency injection. Eg make public property public TW TW {get;set;}
+ Engine Further look at the domain specific languages in visual studio. Can be used for all sorts of tasks to link between code and data outside of visual studio (eg assets to properties). Or can be used to compose entities? (eg put physical + itemstorage + model together visually)
+Engine Make test classes also modelobjects?
+Engine Modelviewer for the engine? Load model, exact visual as in engine, customizable environment, customizable lights.
+Engine Game loop improvements!
+http://lspiroengine.com/?p=378
+http://gafferongames.com/game-physics/fix-your-timestep/
+http://www.koonsolo.com/news/dewitters-gameloop/
 Engine: Idea: can make implicit conversions from objects to objectparts and back??
 Engine Add automatic utilities for objectParts
 Engine architecture: http://www.terathon.com/architecture.php
 http://forum.dronprogs.org/files_for_my_posts/books/GEA.pdf
-Engine BUG Still errors in the serializer/deserializer (i mean not catching all errors)
 Engine Work out the part mechanism in more detail.
 Engine Add a groupsimulator?
 Engine Let the automated testing detect changes to objects (by creating wrappers for these objects perhaps?), then show a UI that allows checking all object interactions
-Coding rules: it always seems to come back to TDD, when design problems occur. This leads to the mhgw design methodology. Note that the core of scalability is adding features without breaking other features. TDD provides a fool proof method of allowing scalability.
 Engine Idea: use the expression framework for binding properties! (eg (o) => o.Value = repository.get(o).Value). It should be possible to create getters and setters from this using the Expression thing from c#
 Engine Idea: combining compile time code with run time created additional info: Add a GUID in code to a object, for which properties are set in code. At runtime this object can be changed, but its info is stored with the guid, so that next time the program starts these code and runtime elements can be recombined!
@@ Line 127: / Line 134: @@
 Note that the current goal is to persist everything, simulators should be able to fix any discrepancies due to persistance.
 Add some way to provide ordering rules for simulators. Maybe even do automatic ordering in the engine.
-BUG Modelobject with a property of type List<> crashes on serialization when there is null in the property.
 TODO: test this => In the VSDebugAttacher, check if attached already right before attaching!
 The current modelobject part's mechanism is a form of multiple inheritance through composition/adaption
 dd a gamemaker 'sprite' concept (entity template or smth). Support a simple in-engine editor to put markers and things like that.
 Support 3D text rendering (billboard)
-Using consts causes crashes? Why is the serializer still causing crashes??
 RULE A test should not change TW.Data,only the setup part should!
 DATA Maybe add a mechanism to prevent changes to TW.Data
@@ Line 140: / Line 145: @@
 Provide intellisense support for assets by autogenerating classes using T4 templates?! Note that missing assets will prevent compiling if this is used. Maybe take a step in between by creating a 'sprite' layer, for which files are small and can be included in the source.
 HOTLOADING The main thing that is required for hotloading is, a way to identified instances after the hotload and link them to instances before the hotload! If we know this, we can start mapping old data to the new structure!.
+  * Let wizards engine compile, disable edit and continue in vs, this could potentially allow continuous debugging!!!
+* Disable simulation when engine is not active window (with optional button)
+* Maybe automatically restart debug
+Maybe even add global hotkeys to the engine for when it is not active?
+Fix nunit slorping up errors
+When throwing exceptions in getters, the exception is displayed using the IErrorLogger.
+URGENT NUnitTestRunner add use of the ExceptionLogger!!!! (DI move to core)
+Bug: Fixed WorldMatrix = matrix.identity missing from physical
+ * Let hotloading work on fields instead of properties? Or should these properties remain forced public as to force the coder to see these as possible access paths?
+ * Create a 'kill-thread' which monitors the thread that runs gameplay simulation (maybe even the rendering thread), and aborts it when it fails to send regular heartbeats.
+ * Fix resharper settings. + syncing of templates