SoftPixel Sandbox
-
Hallo Leute,
ich arbeite nun schon seit ein paar Monaten an einem World Editor für meine 3D Engine: die SoftPixel Sandbox.Vor ein paar Tagen habe ich die erste ALPHA version (0.1) hochgeladen.
Diese World Editor soll auch für die nutzbar sein, die nicht meine 3D Engine verwenden.
Für das LevelFile Format gibt's in meinem Forum eine Spefizikation.Denkt daran: das ist noch eine ganz frühe ALPHA version und da ist noch einiges dran zu tun.
Den Download gibt's hier.
Gruß,
Lukas
-
Sehr schön, gefällt mir. Weiter so!
-
Dein Code ist schon viel besser als letztes mal.
Aber:
- Viele Memberfunktionen sind inline.
- Zu viel protected. (Member sollten niemals protected sein, Methoden nur, wenn sie aus der abgeleiteten Klasse aufgerufen werden sollen. Um zu überschreiben, reicht private.)
- Ich sehe zu viele Dtoren. Vermutlich eine Folge von zu viel manueller Speicherverwaltung. Ich habe übrigens beim drübersehen keinen einzigen Smartpointer gesehen.
- Ich sehe zu viele rohe Zeiger. Auch hier sollten bei besitzenden Zeigern Smartpointer her.
- Wozu die FileSystem Klasse? Auch solltest du statt openFile und closeFile RAII verwenden.
- Der Zweck deiner Stringklasse ist mir immer noch ein Rätsel.
- Dein MemoryManager ist immer noch unnötig.Insbesondere auf Smartpointer haben ich und joke dich im IRC ja hingewiesen, die hast du dir offenbar nicht angesehen
-
es sieht mir bei einigen dingen eher danach aus, als ob es grobe frameworks sind fuer das wofuer sie spaeter benoetigt werden, von daher kann man noch nicht sagen, ob ein memory manager usw. sinn macht.
was mir ein wenig verbesserungswuerdig scheint ist das hardgecodete bei den UI resourcen, bei einem guten editor, moechtest du normalerweise, dass du dinge an der engine aendern kannst, ohne noch n-stellen im code zu suchen um sie daran anzupassen, von daher sollten die elemente deiner engine selbst reflektieren was fuer properties sie haben.
dafuer empfehle ich "3D Games: Realtime rendering and technology" von policarpo
ISBN10: 0201619210
ISBN13: 9780201619218
-
rapso schrieb:
es sieht mir bei einigen dingen eher danach aus, als ob es grobe frameworks sind fuer das wofuer sie spaeter benoetigt werden, von daher kann man noch nicht sagen, ob ein memory manager usw. sinn macht.
So ein MemoryManager, der überhaupt nichts managed macht keinen Sinn.
Edit: Ich vermute mal, dass es exakt die selbe Klasse (Klasse!) ist, wie die hier: http://softpixelengine.sourceforge.net/docu/classsp_1_1_memory_manager.html
-
314159265358979 schrieb:
rapso schrieb:
es sieht mir bei einigen dingen eher danach aus, als ob es grobe frameworks sind fuer das wofuer sie spaeter benoetigt werden, von daher kann man noch nicht sagen, ob ein memory manager usw. sinn macht.
So ein MemoryManager, der überhaupt nichts managed macht keinen Sinn.
Selbst dann kann er Sinn machen. Wenn du z.B. Allokationen zentralisierst, kannst du spaeter die Allokationsstrategie ganz leicht austauschen (gegen Pooling etc.).
-
Sieh dir bitte erstmal seinen Code an, bevor du antwortest. Sein MemoryManager hat nicht im entferntesten was mit dem zu tun, wovon du gerade sprichst.
-
314159265358979 schrieb:
rapso schrieb:
es sieht mir bei einigen dingen eher danach aus, als ob es grobe frameworks sind fuer das wofuer sie spaeter benoetigt werden, von daher kann man noch nicht sagen, ob ein memory manager usw. sinn macht.
So ein MemoryManager, der überhaupt nichts managed macht keinen Sinn.
sorry, aber ich sehe keinen sinn darin ueber etwas unfertiges als sinnvoll/sinnfrei zu urteilen.
vieles in meinen engines faengt genau so an, und wenn der bedarf kommt, bau ich es bedarfsentsprechend aus. Es ist gut von anfang an solche interfaces/wrapper zu haben, die ueberall genutzt werden, denn dann kann man an einem punkt etwas aendern und muss nicht quer durch das projekt refactorn. Gerade gutes memory management ist nicht trivial im nachinein einzubauen.Edit: Ich vermute mal, dass es exakt die selbe Klasse (Klasse!) ist, wie die hier: http://softpixelengine.sourceforge.net/docu/classsp_1_1_memory_manager.html
sieht doch ok aus, wenn man erstmal alle memory management operationen darueber laufen laesst, kann man das ding gut an die beduerfnisse erweitern/anpassen die man hat.
-
rapso schrieb:
sorry, aber ich sehe keinen sinn darin ueber etwas unfertiges als sinnvoll/sinnfrei zu urteilen.
vieles in meinen engines faengt genau so an, und wenn der bedarf kommt, bau ich es bedarfsentsprechend aus. Es ist gut von anfang an solche interfaces/wrapper zu haben, die ueberall genutzt werden, denn dann kann man an einem punkt etwas aendern und muss nicht quer durch das projekt refactorn. Gerade gutes memory management ist nicht trivial im nachinein einzubauen.Offenbar ist das nicht so rübergekommen: Ich rede hier von _seinem_ MemoryManager, nicht von Speichermanagement im allgemeinen. Selbst da würde ich aber auf Smartpointer anstatt irgend eine Singleton-Klasse oder sowas setzen.
rapso schrieb:
sieht doch ok aus, wenn man erstmal alle memory management operationen darueber laufen laesst, kann man das ding gut an die beduerfnisse erweitern/anpassen die man hat.
Das Ding ist ein Design-Fail zum Quadrat.
-
Halt doch bitte einfach mal die Klappe.
Kann ein Mod diesen ganzen Müll bitte löschen?
-
Warum? Weil du mich nicht magst?
-
314159265358979 schrieb:
Warum? Weil du mich nicht magst?
Es mögen dich hier einige nicht. Falls du es noch nicht bemerkt hast...
-
Wie du mir, so ich dir. Ich habe übrigens sehr viel Spaß daran, euch durch sachliche gehaltene Beiträge auf die Eier zu gehen.
-
314159265358979 schrieb:
Wie du mir, so ich dir. Ich habe übrigens sehr viel Spaß daran, euch durch sachliche gehaltene Beiträge auf die Eier zu gehen.
Also ich mag dich
-
Habe gerade ein kleines Update rausgebracht (0.1.1 alpha).
Und hier ein neues Beispiel Bild:
http://softpixelengine.sourceforge.net/gallery/ProjectSandbox2.png
-
rapso schrieb:
vieles in meinen engines faengt genau so an, und wenn der bedarf kommt, bau ich es bedarfsentsprechend aus. Es ist gut von anfang an solche interfaces/wrapper zu haben, die ueberall genutzt werden, denn dann kann man an einem punkt etwas aendern und muss nicht quer durch das projekt refactorn. Gerade gutes memory management ist nicht trivial im nachinein einzubauen.
Auch wenn etwas hinterher nicht rivial einzubauen ist, sollte man immer vorsichtig sein, was man am Anfang einbaut und was nicht. Komplizierterer Code kostet nicht nur Arbeit, er erhöht auch immer das Fehlerrisiko. Deshalb sollte man nicht zusätzliche Klassen einführen oder etwas komplizierter machen, als im Moment nötig, nur um irgendwelche Hooks/Interfaces/Möglichkeiten zu erhalten, die man vielleicht am Ende garnicht braucht. Keep it as simple as possible.
-
LukasBanana schrieb:
http://softpixelengine.sourceforge.net/gallery/ProjectSandbox2.png
schaut sehr cool old-school aus
da werden erinnerungen wach.@pumuckl
jap, die zwei schlechten seiten gibt es, a) jetzt zeit verschwenden mit etwas was man spaeter nicht braucht und b) spaeter vieles neuschreiben weil keine interfaces am anfang da waren.ich hatte lediglich gesagt, dass jeder sein gift waehlen sollte, anhand der paar zeilen code von lukas kann man jetzt nicht wirklich viel ueber den sinn fuer die zukunft von manchem geruest sagen. er wird sich schon seine gedanken gemacht haben.
-
rapso schrieb:
LukasBanana schrieb:
http://softpixelengine.sourceforge.net/gallery/ProjectSandbox2.png
schaut sehr cool old-school aus
da werden erinnerungen wach.Bin zwar gerade erst aufgestanden und eig. ist es auch nicht soooo relevant aber...
"Loaded scene sucessful" ist doch falsch. Ebenso wird "Waypoint" zusammengeschrieben.
etc.
*mublemuble :D*
-
Eben gerade habe ich die neue Version des Editors hochgeladen: SoftPixel Sandbox - v.0.1.2 alpha mit dem neuen ShaderDesigner (Zur Zeit nur für GLSL aber Cg wird folgen).
-
Die Version 0.2 alpha des Editor ist jetzt zum Download verfügbar
-
also ich wuerde erwarten, dass du dem sonst gaengigen prozedere folgst und die changelist mit postest
