WCM Forum - Einzelnen Beitrag anzeigen

JOBIA · 15.01.2004, 16:26

Hallo Horst und andere (User/Designer) die ev. mal mit Autoasm rumgespielt haben.

Ist ev. interessant da mit diesem Tool ev. die Möglichkeit besteht halbwegs effizient zu einem Straßensystem oder ähnlichem für Deutschland und andere Länder zu kommen.

Zunächst mal zum Problem das bei mir Autoasm Fehler im LWM Poly Code erzeugt. Ich habe z.B immer bei dem mitgelieferten Demoprojekt TS_demo zusätzliche LWM Gewässer in Area 4, 22 der Cells in denen Autoasm regulär richtiges Gewässer aus der TS_demo.bmp ausliest.

Die dazugehörigen VTP2 Uferlinien werden jedoch korrekt erzeugt. Ich gehe daher davon aus das Autoasm selbst zunächst richtig ausliest. Denn sonst müsste es bei VTP2 auch fehlerhaft sein. Irgendwie stimmt hier die Routine für LWM nicht. Fakt ist an den Macros von Richard Ludowise kann es nicht liegen. Denn der Fehler ist in der ASM Datei bereits vor der Kompilierung in die BGL erkennbar. Bei diesem Demofile sind diese zusätzlichen falschen LWM Flächen immer identisch hinsichtlich Vectorpoints. Der Rasterabstand also der Abstand zwischen den Vectorpoints bei VTP2 und LWM ist identisch, nur die Zählweise ist anders, das dürfte für Chris demnach eigentlich dann kein Problem sein. Den wesentlichen Unterschied sehe ich aber bei LWM das man immer die zusätzlichen Eckpunkte der Areaflächen berechnen/definieren muß insofern das LWM Poly Area übergreifend ist. Weiterhin das man um den Crash to Desktop bei Area Fill 1x1 Befehlen zu verhindern, anstatt des Area Fill Ersatzpolys berechen muß. Ich vermute daher das bei diesen oben genannten zusätzlichen Berechnungen etwas in die Hose geht.

Das Projekt selbst ist in Autoasm wie gesagt mitgeliefert. Die Daten sind von Chris voreingestellt so das man hier eigene Fehler quasi ausschliessen kann. Hätte ich was neues gemacht wäre ich zunächst davon ausgegangen das der Fehler bei mir liegt. So vermute ich eher am Programm. Daher würde es mich interessieren wie es bei Dir Horst bzw. bei anderen aussieht die das mal probiert haben.

Ich denke der Rainer hat doch bestimmt auch schon mal mit Autoasm rumgespielt.

Damit Ihr seht was ich meine siehe das Bild im Anhang. Hier habe ich aber aus Platzgründen gleich mehrere Sachen untergebracht. Für das geschilderte Problem zählt der Bereich oben links. Fehlerhafte Flächen bei TS_demo die eigentlich nicht existieren dürften siehe roter Pfeil. Selbstverständlich findet man diese fehlerhaften Gewässer dann auch im FS2004 wieder.

Könnt ja mal checken wie es bei euch aussieht. Wie gesagt ich habe es so wie es der Chris als Demoprojekt angelegt hat laufen lassen. Ich habe an dem Projekt auch schon alles mögliche geändert leider bleibt das Problem unverändert bei diesem TS_demo Projekt inkl. TS_demo.bmp von ihm. Wobei die TS_demo Bitmap von ihm bis auf das wo er drauf hinweist sauber ist. Man kann im Fenster auch erkennen das diese problematischen Bereiche nach dem auslesen noch nicht existieren. Erst wenn er mittels der ausgelesenen Points den ASM Code erzeugt entstehen diese Fehler. Was auch kurios ist, dass diese zusätzlichen Polys außerhalb des Bereiches erzeugt werden den seine Bitmap laut Definition koordinatenmäßig nicht abdeckt.

Irgendwie wird das dazu gemauschelt. So ein Fremdobjekt (dann allerdings in anderer Form) entsteht bei mir auch bei eigenen Projekten. Hier war die Bitmap allerdings absolut sauber. Auch meldete das Diagnose Tool keine Fehler. Alles was aus einer Sicht Probleme bereiten könnte habe ich in der Bitmap verhindert. Trotzdem taucht bei mir wieder eine zusätzliches falsches LWM Poly auf. Erst hatte ich gedacht es ist irgend eine LWM Fläche die im Projekt an anderer Stelle irgendwo ev. auch als Teil einer großen Fläche vorkommt. Dem ist aber nicht so. Auch wenn man es als Negativform auslegen würde passt es nirgends dran. Sehr seltsam das ganze.

Sollte das ein Trick eine Art Signatur von ihm sein, das erkenntlich wird die Scenery ist mit Autoasm erzeugt worden? Da es Freeware ist denke ich nicht das dieses der Fall ist.

Diese Problematik wäre aber zu verkraften. Wenn man sein Projekt kennt, könnte man dieses aus dem ASM Code entfernen und neu kompilieren.

Wie gesagt ev. stimmt an meinem PC mit dem ich getestet habe etwas nicht. Ev. ist auch ein Fehler im ZIP File gewesen. Deshalb würde es mich interessieren ob es bei euch bei dem mitgelieferten Demoprojekt TS_demo auch auftritt.

Kommen wir zum nächsten Problem.

Lassen wir dabei die Problematik der aufwendigen Bitmap Vorbereitung außen vor. (ein weiterer Grund der das schnelle automatische erstellen von Bodenscenery etwas behindert. Es sei denn man hat geeignetes Rohmaterial)

Kommen wir zu der anderen Geschichte wo ich momentan sagen würde: "Das was bei mir hinten aus Autoasm rauskommt ist nicht tauglich da es performance verschwendender Code ist".

Da brauche ich auch keine Bitmap zu liefern Horst. Erzeuge Dir eine Bitmap 8Bit Farbtiefe mit einem nackten 1 Pixel breiten geraden Strich der 100 Pixel lang ist.

Wie gesagt da reichen für den FS hinterher von der Theorie her zwei reine Vectorpoints für aus um so eine Linie darstellen zu können. Die Thematik Cell übergreifend, Anfangspunkt usw. außen vor.

Ich habe schwarz als Hintergrund und rot als Strich in der Bitmap. Es liegt damit im Vorgaberahmen von Autoasm. Was dabei rauskommt sieht man im Bild im Anhang. Hier die untere Hälfte des Bildes.

15.01.2004, 16:26	#17
JOBIA Inventar Registriert seit: 02.01.2002 Alter: 61 Beiträge: 4.238	Hallo Horst und andere (User/Designer) die ev. mal mit Autoasm rumgespielt haben. Ist ev. interessant da mit diesem Tool ev. die Möglichkeit besteht halbwegs effizient zu einem Straßensystem oder ähnlichem für Deutschland und andere Länder zu kommen. Zunächst mal zum Problem das bei mir Autoasm Fehler im LWM Poly Code erzeugt. Ich habe z.B immer bei dem mitgelieferten Demoprojekt TS_demo zusätzliche LWM Gewässer in Area 4, 22 der Cells in denen Autoasm regulär richtiges Gewässer aus der TS_demo.bmp ausliest. Die dazugehörigen VTP2 Uferlinien werden jedoch korrekt erzeugt. Ich gehe daher davon aus das Autoasm selbst zunächst richtig ausliest. Denn sonst müsste es bei VTP2 auch fehlerhaft sein. Irgendwie stimmt hier die Routine für LWM nicht. Fakt ist an den Macros von Richard Ludowise kann es nicht liegen. Denn der Fehler ist in der ASM Datei bereits vor der Kompilierung in die BGL erkennbar. Bei diesem Demofile sind diese zusätzlichen falschen LWM Flächen immer identisch hinsichtlich Vectorpoints. Der Rasterabstand also der Abstand zwischen den Vectorpoints bei VTP2 und LWM ist identisch, nur die Zählweise ist anders, das dürfte für Chris demnach eigentlich dann kein Problem sein. Den wesentlichen Unterschied sehe ich aber bei LWM das man immer die zusätzlichen Eckpunkte der Areaflächen berechnen/definieren muß insofern das LWM Poly Area übergreifend ist. Weiterhin das man um den Crash to Desktop bei Area Fill 1x1 Befehlen zu verhindern, anstatt des Area Fill Ersatzpolys berechen muß. Ich vermute daher das bei diesen oben genannten zusätzlichen Berechnungen etwas in die Hose geht. Das Projekt selbst ist in Autoasm wie gesagt mitgeliefert. Die Daten sind von Chris voreingestellt so das man hier eigene Fehler quasi ausschliessen kann. Hätte ich was neues gemacht wäre ich zunächst davon ausgegangen das der Fehler bei mir liegt. So vermute ich eher am Programm. Daher würde es mich interessieren wie es bei Dir Horst bzw. bei anderen aussieht die das mal probiert haben. Ich denke der Rainer hat doch bestimmt auch schon mal mit Autoasm rumgespielt. Damit Ihr seht was ich meine siehe das Bild im Anhang. Hier habe ich aber aus Platzgründen gleich mehrere Sachen untergebracht. Für das geschilderte Problem zählt der Bereich oben links. Fehlerhafte Flächen bei TS_demo die eigentlich nicht existieren dürften siehe roter Pfeil. Selbstverständlich findet man diese fehlerhaften Gewässer dann auch im FS2004 wieder. Könnt ja mal checken wie es bei euch aussieht. Wie gesagt ich habe es so wie es der Chris als Demoprojekt angelegt hat laufen lassen. Ich habe an dem Projekt auch schon alles mögliche geändert leider bleibt das Problem unverändert bei diesem TS_demo Projekt inkl. TS_demo.bmp von ihm. Wobei die TS_demo Bitmap von ihm bis auf das wo er drauf hinweist sauber ist. Man kann im Fenster auch erkennen das diese problematischen Bereiche nach dem auslesen noch nicht existieren. Erst wenn er mittels der ausgelesenen Points den ASM Code erzeugt entstehen diese Fehler. Was auch kurios ist, dass diese zusätzlichen Polys außerhalb des Bereiches erzeugt werden den seine Bitmap laut Definition koordinatenmäßig nicht abdeckt. Irgendwie wird das dazu gemauschelt. So ein Fremdobjekt (dann allerdings in anderer Form) entsteht bei mir auch bei eigenen Projekten. Hier war die Bitmap allerdings absolut sauber. Auch meldete das Diagnose Tool keine Fehler. Alles was aus einer Sicht Probleme bereiten könnte habe ich in der Bitmap verhindert. Trotzdem taucht bei mir wieder eine zusätzliches falsches LWM Poly auf. Erst hatte ich gedacht es ist irgend eine LWM Fläche die im Projekt an anderer Stelle irgendwo ev. auch als Teil einer großen Fläche vorkommt. Dem ist aber nicht so. Auch wenn man es als Negativform auslegen würde passt es nirgends dran. Sehr seltsam das ganze. Sollte das ein Trick eine Art Signatur von ihm sein, das erkenntlich wird die Scenery ist mit Autoasm erzeugt worden? Da es Freeware ist denke ich nicht das dieses der Fall ist. Diese Problematik wäre aber zu verkraften. Wenn man sein Projekt kennt, könnte man dieses aus dem ASM Code entfernen und neu kompilieren. Wie gesagt ev. stimmt an meinem PC mit dem ich getestet habe etwas nicht. Ev. ist auch ein Fehler im ZIP File gewesen. Deshalb würde es mich interessieren ob es bei euch bei dem mitgelieferten Demoprojekt TS_demo auch auftritt. Kommen wir zum nächsten Problem. Lassen wir dabei die Problematik der aufwendigen Bitmap Vorbereitung außen vor. (ein weiterer Grund der das schnelle automatische erstellen von Bodenscenery etwas behindert. Es sei denn man hat geeignetes Rohmaterial) Kommen wir zu der anderen Geschichte wo ich momentan sagen würde: "Das was bei mir hinten aus Autoasm rauskommt ist nicht tauglich da es performance verschwendender Code ist". Da brauche ich auch keine Bitmap zu liefern Horst. Erzeuge Dir eine Bitmap 8Bit Farbtiefe mit einem nackten 1 Pixel breiten geraden Strich der 100 Pixel lang ist. Wie gesagt da reichen für den FS hinterher von der Theorie her zwei reine Vectorpoints für aus um so eine Linie darstellen zu können. Die Thematik Cell übergreifend, Anfangspunkt usw. außen vor. Ich habe schwarz als Hintergrund und rot als Strich in der Bitmap. Es liegt damit im Vorgaberahmen von Autoasm. Was dabei rauskommt sieht man im Bild im Anhang. Hier die untere Hälfte des Bildes.