Banner left   Banner center   Banner right

Germanenglish Home · News · Diary · Screenshots · Documentation (Wiki) · Downloads · Guestbook · Forum

Home · Benutzer registrieren · Suchen · Statistik · FAQ · Benutzerliste

Zur Zeit online: keiner ausser dir

 X-Force - Fight For Destiny - Forum —› Quellcode / Programmierung —› [Rewrite] Planung + Organisation

Seite: << [1] ... [9] 10 [11] [12] [13] [14] [15] [16] [17] [18] [19] .. [22] [23] >>

Autor Mitteilung
verfasst am: 22.06.2015, 18:20 · Edited by: Kamor
Registrierdatum: 20.07.2005, 00:01

 Beiträge: 203
So meine Versuchsreihe geht weiter.

Ich habe mir jetzt mal Monogame angeschaut. Sie sagen selber von sich „MonoGame | Write Once, Play Everywhere“. Das scheint auch so zu stimmen, wenn man dann einige Abstriche in Kauf nimmt.

Ein Dateihandling wie ich es in meiner Testumgebung einsetze gibt es da natürlich nicht. Wie auch, Dateihandling auf Win, Linux, Mac, Android können einfach nicht identisch sein. Monogames setzt auf eine Contentpipeline, seit Version 3.4, vorher behalf man sich noch mit der XNA content pipeline.
Per Default existiert ein vorgegebener Ordner, in den die Daten abgelegt werden. Diese werden dann über den Content-Manager eingeladen. Eine Dynamik geht für mich dabei aber verloren, sprich von außen mod-bare Spiele rein auf der Contentebene werden schon schwieriger. Hier gibt es garantiert Möglichkeiten zu dynamisieren, aber dann dürfe die „Write Once, Play Everywhere“-Aussage nicht mehr so 100% zutreffen. Soweit, wie ich das überblicke, dürfte dann hier auch für unterschiedliche Systeme individueller Programmieraufwand notwendig werden. Also zusätzlicher Aufwand für Cross-Compiling wird definitiv entstehen, wenn man etwas komplexer, sprich dynamischer vorgehen will.

Desweiteren kann man Monogame auch wie einen Rewrite von XNA sehen. XNA selber scheint von Microsoft mit Version 4.0 nicht mehr weiter entwickelt zu werden, diesbezüglich scheint also diese Lücke Monogame aufzufüllen. Das Fensterhandling ist recht simpel, Fullscreen geht da per Flag und applychanges ein und auszuschalten. Bitmaps wie ich sie kenne, werden da so leider nicht unterstützt, das dessen wandert alles, was mit 2D zu tun hat in das Format Texture2D. Das lässt sich dann relativ simpel über spriteBatch aufn Bildschirm werfen. Über die Performance der Engine kann ich noch nichts sagen, weil wie ich schon oben anmerkte die Vorgehensweise über eine Contentpipeline mich einfach nur abstößt. Klar es gibt nicht schnelleres wie per Drag and Drop seine Content-Datei in den Content-Ordner zu schieben und die dann mit einem Befehl von dort zu laden. Mir gefällt dieser Ansatz meinen ganzen Content zwingend durch so ein enges Rohr (Pipeline) zu schicken aber nicht. Ich brauche da mehr Dynamik, sowohl vom Dateipfad, wie auch vom Dateiformat. Später sollen da sowieso auch eigene Gamepacks entstehen. Wir wollen modbar und scriptbar programmieren.

Komme ich nochmal zu meinen Projektansatz rein auf C# und den vorhandenen Framework. Da muß ich mir leider eingestehen, das ein Fensterrendering auf Basis von Forms und GDI nicht so performant ist, wie ich mir das gewünscht hätte. Auch wenn ich durch die hohe Abstraktionsebene ein Schlaraffenland an Möglichkeiten habe, bezahle ich das doch mit höherer Prozessorlast. Dabei ist es noch nichtmal meine Backgroundbuilderklasse, vielmehr der Aspekt das ich zum Teil bis zu 60 mal in der Sekunde mein Fenster auffordere sich neu zu zeichnen, schlägt bei immer größer werdenden Fenster, alleine durch Veränderung am Rezise immer mehr in die Prozessorlast. Deshalb wollte ich mir Monogame mal angeschauen. Primär um eine Alternative zum Forms-Fenster zu testen, sekundär um eine Alternative zur GDI zu haben.

Da ich mich aber von meinem Ansatz noch nicht trennen will und Mono mich bisher nicht überzeugt, werde ich im nächsten Ansatz noch tiefer gehen und mir mal die SharpDX (Managed DirectX API) anschauen. Ich brauche Schnelligkeit für mein Rendering, will aber den Luxus des ganzen Frameworks nicht verlieren. Übrigens scheint Mono auch auf SharpDX zu basieren.

Und dann noch was aus dem Duden.

http://www.duden.de/rechtschreibung/naiv
verfasst am: 22.06.2015, 21:03
Registrierdatum: 20.07.2005, 00:01

 Beiträge: 203
Zitat: sujin
Zunächst muss ich formell Beschwerde einreichen gegen die Idee, eine Programmiersprache hätte eine Eigenschaft namens "Geschwindigkeit". Man kann fast alles in fast allen Sprachen tun, inklusive der meisten Optimierungen.


Natürlich hat eine Programmiersprache eine „Geschwindigkeit“. Für alle Programmiersprachen gilt am Ende das gleiche Gesetz. Sie müssen in ausführbaren Code übersetzt werden, sprich reinen Maschinencode. Auf dieser Ebene kostet jeder Befehl Zeit. Ob ein Prozessorregister direkt z.B. in einer Testschleife zigmal beschieben wird oder ob in dieser Schleife erst noch jedesmal ein Unterprogramm aufgerufen wird, macht schon Unterschiede. In diesem Beispiel kommen "nur" zwei neue Befehle (JSR und RTS) dazu, was aber in diesem simplen Beispiel, schon fast zur Verdopplung der Programmlaufzeit führt. Jede höhere Programmiersprache dürfte wahrscheinlich später zu Ketten von JSR und RTS Befehlen führen. Weiterhin entstehen neue virtuelle Adressierungen von Speicher und Prozessor. Variablen, Arrays, Listen werden am Ende auch durch Speicherreservierung und Speicherzugriffen umgesetzt.

Und C wird durchaus als schnelle Programmiersprache angesehen.

Zitat Wikipedia

Wegen der hohen Ausführungsgeschwindigkeit und geringen Codegröße werden Compiler, Programmbibliotheken und Interpreter anderer höherer Programmiersprachen (wie z. B. die Java Virtual Maschine) oft in C implementiert.

Warum ist C schneller? Das könnte daran liegen, das C näher an der Maschine ausgelegt ist. Direkte Speicherprogrammierung und Einsatz von Zeigern ist hier durchaus noch übliche Vorgehensweise. Weiterhin ist die Übersetzung in Maschinencode noch nicht so "aufgebläht", wie bei neueren(höheren) Programmiersprachen. Ob ich in Assembler ein Prozessorregister mit dem Wert 0 lade oder ob ich eine Variable deklariere und mit 0 initialisiere, dürften in Sachen Geschwindigkeit schon Welten sein.

Wenn ich jetzt auch noch daherkomme und eine Hochsprache auf Basis einer nicht ganz so hohen Sprache, die selber evtl. über eine maschinennahen Sprache dann Finale in Maschinencode gewandelt wird, dann gibt es da schon gewaltige Unterschiede in der Ausführungsgeschwindigkeit. Ich habe da jetzt nicht den genauen Überblick, aber ich weiß das einige Sprachen doch über mehrere Übersetzungen (Sprachebenen) gehen, bis sie schließlich im Maschinencode enden.

Dann kommen wir auch gleich zum Thema Objektorientierung. Die Objektorientierung drückt nochmal unsere Geschwindigkeit runter. Im Prinzip kann man jedes Objekt, wie ein in sich geschlossenes Konstrukt sehen, was eigene Befehle bietet und diese intern auf ihr Fundament runter übersetzt. Auch hier gilt, je mehr ich solche Objekte aufeinander aufbaue, desto länger werden später die (JSR und RTS – Verschachtelung). Aus einem einfachen a=0 wird dann auf einmal megalanger Code. Also kann es auch von Vorteil sein, manchmal auf unnütze Objektorientierung zu verzichten, wenn man Speed braucht.

Ein weiterer wesentlicher Geschwindigkeitsunterschied bei einer Programmiersprache ist dann auch, wie bzw. wann die Sprache übersetzt wird. Ob zeilenweise interpretiert wird oder ob das Ganze im Vorfeld compiliert wird, wirken sich definitiv auch auf die Ausführgeschwindigkeit einer Sprache aus.
verfasst am: 22.06.2015, 21:51 · Edited by: sujin
Spielsatz Alliances

Registrierdatum: 14.07.2004, 14:47

 Beiträge: 1185
Ich spare mir an dieser Stelle eine Punkt-für-Punkt Antwort und fasse zusammen: Du hast keine Ahnung, wie Compiler funktionieren, aber du bist dir sicher, dass sie scheiße sind. Mit Verlaub, das ist dämlich. Und ja, die starke Formulierungen sind bewusst gewählt.

Das ein Methodenaufruf in Java meist einen Funktionsaufruf bedeutet, liegt nicht an der Abstraktion der Objekte, sondern an late binding: Der Compiler (d.h. javac, nicht der JIT Compiler) weiß nicht, welche Klasse das ist und welche Implementierung der Methode aufgerufen wird. Wenn er es wüsste, könnte er es optimieren, und in C++ und Rust weiß der Compiler das alles (sofern der Programmierer es nicht explizit verschweigt, weil das an der Stelle besser ist). Und wenn der Compiler dann optimiert, dann kann er die Definition der Methode inlinen und sieht den Code ohne die lästige Abstraktion dazwischen. Alles ohne Einbußen für den Programmierer. Und wenn da dann ein nutzloses "let i = 0;" steht, dann entfernt er das. Und wenn es nicht nutzlos ist, dann kann das (je nach dem, ob das Register nicht vielleicht dringender für etwas anderes benötigt wird) durchaus darin resultieren, dass im Maschinencode später "movl $0, %eax" steht ohne sonstigen Firlefanz.

Compiler sind kein Hexenwerk. Zugegeben, konkret vorherzusagen, was für ein Assembler-Code diese oder jene Zeile erzeugt, ist oft schwer. Zum Teil auch, weil der Compiler es tatsächlich besser weiß als du, aber manchmal verliert man tatsächlich ein paar Prozent Performance ggü. dem theoretischen Optimum. Aber auch die kann man oft leicht wieder raus holen. Performance ist kein Selbstläufer, man muss von Hand optimieren, aber dabei ist der Compiler unser Verbündeter, kein Hindernis.

Und um das noch einmal klarzustellen: Natürlich gibt es Sprachfeatures (und manchmal sind das auch alle Features einer gegeben Sprache) die unvermeidbare Performance-Kosten haben. Der Umkehrschluss, dass alle netten Features das Programm langsamer machen, ist aber ebenso falsch.

Das traurige ist, dass die letztliche Schlussfolgerung (Python ist langsam weil weit von der Maschine entfernt) nicht einmal so wirklich falsch ist. Nur die Begründung ist sind falsch. Aber eben diese Denkweise lässt dich den Mittelweg übersehen: Abstraktionen, die keine Performance kosten.

Hier, schau dir mal diesen Rust-Code. (Es ist Rust statt C++ weil ich das zur Zeit mehr benutze und deshalb dieses Beispiel schneller schreiben konnte --- etwas sehr ähnliches kann man in C++ schreiben.)

#[derive(Copy, Clone)]
pub struct Point {
    x: f64,
    y: f64,
}

impl Point {
    fn dist_squared(&self, other: Point) -> f64 {
        let dx = self.x - other.x;
        let dy = self.y - other.y;
        dx * dx + dy * dy
    }
}

pub fn closest(p: Point, points: &[Point]) -> Point {
    let mut closest = points[0];
    for &q in points {
        if p.dist_squared(q) < p.dist_squared(closest) {
            closest = q;
        }
    }
    closest
}


Der Code definiert eine Art Objekt mit einer Methode. Und ruft diese Methode in einer Schleife auf. Und die Schleife läuft über einen Iterator, also jeder Schritt der Schleife erzeugt einen Methodenaufruf und das Ergebnis ist eine Datenstruktur namens Option die erst einmal untersucht werden muss, um zu gucken ob die Schleife aufhören soll oder weiter geht.

Nimm dir einen Moment Zeit und stell dir vor, wie furchtbar ineffizient der Maschinencode dafür sein muss.

Genug gefürchtet? Okay, hier ist der Assembler-Code. Sogar interaktiv und farblich hinterlegt damit man sieht welche Maschinenbefehle zu welcher Programmzeile gehören.
verfasst am: 22.06.2015, 23:49
Registrierdatum: 13.03.2009, 16:27

 Beiträge: 13
Really? Wir diskutieren vor der ersten Zeile Code über Geschwindigkeit? (Ja es sind schon viele Zeilen da - ihr wisst was ich meine).

Cache-Misses haben direkt Einfluss auf die Geschwindigkeit. Anzahl der Maschinen-Instruktionen haben direkt Einfluss auf die Geschwindigkeit. Festplattenzugriffe haben direkt Einfluss auf die Geschwindigkeit. BUGS haben Einfluss auf die Geschwindigkeit. Aber am meisten haben geschickte Allgorithmen Einfluss auf die Geschwindigkeit.

Programier-Paradigma haben KEINEN unmittelbaren Einfluss. Programmiersprachen haben KEINEN unmittelbaren Einfluss.

Zusammenfassend: PROGRAMMIERER haben Einfluss auf die Geschwindigkeit.

Kenne deine Programmiersprache. Kenne deinen Compiler. Vorallem kenne deinen Algorithmus und das Programierparadigma.

Und wenn alles zusammenpasst, wird es schnell GENUG. :-)

Also was machen wir da? Wir wählen eine Entwicklungsumgebung und Baukästen und Libs und Tools, die uns ganz viel Arbeit abnehmen können, und bei denen wir aber nach Bedarf die richtig üblen Sachen mit eigenem Code, oder sogar mit einer anderen Programier-Sprache. Und wenn es irgendwer von uns drauf hat, gerne auch in Assember. :p
verfasst am: 23.06.2015, 20:42
Registrierdatum: 20.07.2005, 00:01

 Beiträge: 203
Schade das es kein PM System hier gibt Sujin.

Zitat: sujin
Du hast keine Ahnung, wie Compiler funktionieren, aber du bist dir sicher, dass sie scheiße sind. Mit Verlaub, das ist dämlich.


1. Muss ich Ahnung haben, wie Compiler im Detail funktionieren? Ich bleibe bei meiner Aussage. Sprachen sind unterschiedlich schnell.

https://www.spin.de/forum/145/-/3f3c

2. Ich habe an keiner Stelle hier gesagt, daß ich Compiler scheisse finde. Also bitte sachlich bleiben.

3. Netiquette! Finde hier leider im Forum gerade nicht die Forumsregeln, aber normalerweise steht da irgendwas wie Respekt. Ich zitiere mal aus einem anderen Forum.

Bitte achte in Deinen Beiträgen auf einen fairen und sachlichen Ton und denke stets daran, dass sich in den Foren Menschen mit höchst unterschiedlichen Ansichten, Meinungen und Wertvorstellungen aufhalten. Streit und Zwist sind nie eine Bereicherung für eine Diskussion. Nur durch Toleranz und Offenheit kann sich eine wirklich gute Diskussion entwickeln. Die meisten Leute vergessen, dass ihre Artikel und Beiträge nicht ausschließlich von Computern gelesen werden. Denke also stets daran, dass Dein Gegenüber ein Mensch ist und lasse dich nicht zu verbalen Ausbrüchen hinreißen.

Ansonsten hier noch kurz zur Auflockerung.

http://homepage.ruhr-uni-bochum.de/Frank.Scharf/gdi.html

Zitat: MADetter
Really? Wir diskutieren vor der ersten Zeile Code über Geschwindigkeit? (Ja es sind schon viele Zeilen da - ihr wisst was ich meine).


Es gibt schon eine erste Zeile. Wir haben drei Ansätze hier. Diesbezüglich ist immer noch die Diskussion im Gange, auf welches Fundament ein Rewrite aufgesetzt werden soll. Und in meinem Ansatz geht es derzeit primär um die Optimierung meines Rendering. Und gerade da ist Geschwindigkeit das Thema Nr.1.

Ansonsten wiederhole ich nochmal kurz.

„We are all different“. Tut mir leid, wenn ich nicht das hohe Wissensniveau hier habe, wie es einige von euch meinen zu haben oder vielleicht sogar haben? Ich bin mir aber dafür auch nicht in jeder Zeile sicher, daß ich immer Recht habe und begegne anderen Menschen hier im Forum nicht mit Arroganz.Des weiteren sollten sich einige nochmal bewußt machen, wo das ganze Wissen herkommt. Wissen ist nur das, was andere schon gedacht haben. Wissen entsteht immer auf Basis von Phantasie, wobei die Phantasie in seiner Freiheit durch Wissen begrenzt und zielgelenkt werden kann. Ich persönlich phantasiere (experimentiere) lieber und entdecke die Dinge selber. Andere nehmen halt lieber ein Buch und erweitern damit ihren Wissensstand.

Und ja ich bin naiv, und wenn ich das selber sage, ist das nicht abwertend. Eine gewisse kindliche Naivität hat auch positive Aspekte.
verfasst am: 23.06.2015, 21:15
Spielsatz Alliances

Registrierdatum: 14.07.2004, 14:47

 Beiträge: 1185
Ja, schon schade, dass wir das alles öffentlich regeln müssen. Ich will dich keineswegs persönlich angreifen oder runtermachen. Wir sind alle Freunde hier :) Ich kann mir nur leider nicht verkneifen, fachlich komplett falschen Aussagen entgegenzutreten. Selbstverständlich mit dem Vorbehalt, dass *ich* es sein könnte, der falsch liegt --- aber in wie viel Zurückhaltung ich das umwandle, hängt davon ab wie sicher ich mir bin und wie überzeugend argumentiert wird. Rückblicken hätte ich das aber (selbst mit 0% Zurückhaltung) konstruktiver machen können und sollen. Dafür entschuldige mich.

Gleichzeitig muss ich sagen, ich finde deine Art, wie du mit meiner Opposition umgehst, auch nicht gut. Ich habe den Eindruck, dass du die meisten meiner Stichpunkte ignorierst und einzeln ausgesuchte Sätze mit mehr oder minder passenden Zitaten garnierst. Kurzum, meine Erklärungen und Begründungen scheinen ins Leere zu laufen.

Die Dinge, du von deiner Sichtweise erklärst, sind naiv (da sind wir uns einig), was nicht bedeutet, dass du dumm bist oder so etwas, aber auch nicht, dass du "uneingeschränkt" die Wahrheit suchen kannst. Es bedeutet schlicht, dass deiner Meinung der Feinschliff fehlt. Unser beider Auffassungen von Performance sind Vorhersagen über die Realität (genauer, die tatsächliche Performance von echten Programmen auf echter Hardware). Damit sind sie empirisch testbar abseits von allen theoretischen Überlegungen. Hast du deine Theorien getestet? Ich habe meine getestet. Ich habe Code geschrieben, den Assembler-Code angeschaut, und gemessen wie schnell das Programm ist. Ich habe mit eigenen Augen gesehen, wie diese oder jene Änderung die Performance beeinflusst hat oder nicht beeinflusst hat. Ich hoffe du verstehst, dass ich mir dann nicht einfach so das Gegenteil meiner Erfahrungen erzählen lasse.

(P.S. Passiv-Aggressivität ist IMHO nicht sinnvoll. Entweder wir tun Butter bei die Fische oder vermeiden das Thema. Wenn du mir was vorwerfen willst, dann nenne es ruhig beim Namen.)
verfasst am: 23.06.2015, 23:45
Registrierdatum: 20.07.2005, 00:01

 Beiträge: 203
Es geht einfach darum, daß ich mich nicht die ganze Zeit von dir an den Pranger stellen lassen, da habe ich null Bock drauf. Ich investiere hier im Moment nicht gerade wenig Zeit. Ich verdiene da nichts mit und mache das in meiner Freizeit. Und als Dank bekomme ich hier nur in die Fresse. Das was ich programmiere kann jeder einsehen. Und ja ich überlese deine Themen inzwischen schon teilweise, weil es doch nur die ganze Zeit. „Ne das geht so nicht“. Nein, das mußt du so machen. Oh, so wie du das machst ist das dumm oder naiv oder schlecht oder oder oder … Da kommt nicht einmal konstruktives Feedback, statt dessen sagst du nur andauern, wie schlecht meine Umsetzung ist. Nebenbei bemerkt machen wir das alle, daß wir die Themen anderer gar nicht im Detail durchlesen. Ich bin mir sicher daß du meine Texte gerade zu Anfang der diesjährigen Diskussionsrunde, hier ab Seite 7 vorher nur überflogen hast. Ok und dann Butter bei die Fische, ich habe manchmal das Gefühl, daß ich in deinem Topic [Rewrite] Planung + Organisation, mit meinem Rewrite-Ansatz deiner Ansicht nach nichts zu suchen habe. Das machst du mir immer und immer wieder unmißverständlich mit jeder deiner Aussage deutlich. Nebenbei habe ich kein Bock auf dein ganzes Hochschulblabla, du hast wahrscheinlich studiert und bist Informatiker, ich aber nicht. Mein Abi habe ich abgebrochen und habe es nur bis zum Fachinformatiker Anwendungsentwicklung gebracht. Die haben wieder nochmal eine andere Ansicht zu dem Thema und sehen das alles auch noch kaufmännisch. Ich will mich aber weder mit Informatiker noch mit Anwendungsentwicklergequatsche rumärgern, ich will einfach nur programmieren, weil es mir Spaß macht. Und mir macht es ganz bestimmt nicht Spaß, hier Rede und Antwort zu stehen und zig Themen hier theoretisch auf höchsten Niveau anzureißen, wobei du den Lehrer spielst und ich der Dumme bin. Das bringt mich nicht wirklich weiter. Im Gegenteil das hält mich nur auf, weil sowieso alles schlecht ist was ich mache. Die Diskussion hier lohnt einfach nicht von meiner Sicht.

Ich schließe das dann mal hier logisch ab.

1. es fehlt Manpower
2. man kann sich nicht einigen, auf Sprache oder Sprachumgebung
3. es wird nur geredet
4. wenn einer was macht, schauen es sich die anderen meist sowieso nicht an
5. jeder will sein eigenes Ding irgendwie durchsetzen
6. das Ganze wird dann einmal im Jahr aufs neue angestoßen.

Ich werde mich dann mal mit meiner Engine hier aus diesem Topic zurückziehen, hat ja in dieser Komplexität hier auch nichts zu suchen. Auch scheint mein damit verbundender Rewrite-Ansatz hier auf Null Akzeptanz zu stoßen, aus welchen Gründen auch immer. Ich wünsche noch ein frohes Fest und einen guten Rutsch.
verfasst am: 24.06.2015, 09:24 · Edited by: sujin
Spielsatz Alliances

Registrierdatum: 14.07.2004, 14:47

 Beiträge: 1185
Danke für die Offenheit. Ich wollte ehrlich nur mit gutem Rat helfen (wenn ich schon nicht die Zeit zum Coden habe), aber offensichtlich ist mir das gehörig misslungen. Ich bitte noch einmal um Verzeihung und wünsche dir alles gute und viel Erfolg.
verfasst am: 27.06.2015, 17:00
Registrierdatum: 08.11.2006, 06:23

 Beiträge: 433
Öhm - und Hallo mal wieder...
Hmm, ich habe das Thema nur "überfolgen" und sehe darin viel "streit" und wollte fragen, was nun die Konsequenz ist?

Stirbt X-Force damit nun ganz?


...DX
verfasst am: 28.06.2015, 17:26 · Edited by: Andiana
Registrierdatum: 21.10.2005, 20:08

 Beiträge: 133
Nunja die Hoffnung...

Aber wieviel ich tatsächlich zu X-Force 2 beitragen kann, kann ich auch nicht wirklich sagen.
Vermutlich weit weniger als ich möchte und hoffte, schließlich muss ich mich dann erst in eine neue Sprache einarbeiten und komm jetzt schon nicht dazu hier alles zeitnahe zu kommentieren.
Und falls es ein "Windows only" Projekt wird, werde ich auch erst mal wieder ein sauberes Win installieren müssen und damit auf win 10 warten.

@Kamor
Ja du hast recht. Derzeit bist du hier der einzige der etwas macht und bekommst wenig Feedback. Da muss ich - der ja das Thema wieder angestoßen hat - mich wohl besonders für entschuldigen.
Aber leider hatte ich nun doch nicht so viel Zeit und immer wenn ich was gelesen hatte und dann später etwas zu schreiben wollte gabs schon wieder etwas neues.
Und ich muss zugeben dass ich mich nichtmal dazu motivieren konnte mir deinen Code anzuschauen. Wozu auch ohne C# Kenntnisse?
Mir ist nach wie vor auch nicht wirklich klar welche Erkenntnisse was am Ende deiner "Feldversuche" rauskommen sollen. Bzw ob du bereits "XForce 2" programmierst oder doch nur eine Engine rein für dich selbst.

> Gebt mir "irgendeine Grafik" und stell dir dein Fenster selbst ein, wie es dir am besten gefällt.
Das klingt gut aber Grafik die für eine 3:4 Auflösung erstellt wurde sieht auf einem 16:9 Monitor bescheiden aus. Und eine 1920x1080 Grafig auf einem künftigen 5k+ Monitor sieht sicherlich so schön aus wie die derzeitigen 1280x800 auf deinem 1920x1080.
Eben so ist es von der Bedienbarkeit einen großer unterschied ob die 1920x1080 Pixel auf 28" oder 7" gequetscht werden.
Ich weiß nicht wie du diese Probleme mit wenig aufwand besser lösen willst als es bestehenden Lösungen tun. Im Endeffekt ist es doch einfacher eine Grafik in 5 verschiedenen Auflösungen zu speichern. Oder man setzt gleich auf SVG oder verzichtet ganz auf Grafik*.
Wobei ich dir zustimmen muss, bei sehr einfachen Sachen ist es übertrieben und reinste Ressourcenverschwendung 60 oder 100 mal pro sec alles neu zu rendern.
Aber ich behaupte mal dass eine optimierte Engine vorher prüft ob sich überhaupt etwas geändert hat und ganz so simpel gestrickt wird ja X-Force nicht.
Ich jedenfalls fände es ganz toll wenn sich mehr als nur ein Objekt gleichzeitig auf dem Screen animiert werden kann. Also mal ne Granate werfen -> BUMM -> 5 einstürzende Mauern + 3 sterbende Aliens und ein 4x4 Feld voller Rauch oder gar noch ne explodierende Gasflasche. Schon hat man etwas wo es wohl nicht mehr sinnvoll ist jede Animation einzeln anstoßen zu müssen.
Auch etwas "leben" auf der Karte wie etwa fließendes Wasser wär schon ganz nett. Und dann kommt man um so eine Schleife die x mal pro sec prüft was sich ändert und dieses dann neu rendert einfach nicht mehr drum rum.

Aber ist es auch absolut legitim und ein Stück weit sinnvoll zu sagen "ich programmiere es in der Sprache die ich gut kann und mache dass was ich für richtig halte".
Man muss sich dann allerdings darauf einstellen dass erst dann neue Programmierer kommen wenn man schon was aussichtsreiches hat mit dem man werben kann.
Für mich ist dein bestreben möglichst viel selbst zu machen in Anbetracht der Größe von XForce jedoch nicht aussichtsreich.

Du hast ja selbst auf einem Bericht zu Unknown Horizons verwiesen. Deren Projekt ist ja gut mit XForce vergleichbar und die sind zum Ergebnis gekommen dass die eigene Engine zu viel Zeit kostet und es besser ist alles nur in Englisch anzubieten.
Ich brech mir beim englisch schreiben auch immer einen ab, aber wenn man mehr Programmierer erreichen will muss man da durch.

Dennoch ist es Schade dass du das Handtuch wirfst.
Mein Tipp: Schau mal ob du nicht Git in deiner IDE nutzen kannst und "push" das ganze mal bei GitHub oder so hoch. Jede kleine Änderung wird dann beim "commit" dokumentiert und muss nicht separat in ein Forum. Auch hat man dort mit den "Issues" selbst so eine art Forum in dem man Einzelheiten diskutieren kann, viel besser als hier alles zusammen.

[1] ASCII ist auch Cool: https://youtu.be/IZd7nDW1qYw?t=1m48s, leider closed source.

PS: Auch ich sympathisiere mit Rust. Leider sind dort noch viele interessante Libs selbst noch beta oder mit der stabilen Rust Version inkompatibel.
Auch sieht es mit Docs und Beispielen recht mau aus weil fast alles was man so per Suchmaschine findet inzwischen schon überholt ist. Aber das sind Probleme die in ein paar Monaten wohl schon nicht mehr existieren.
Aber das ist eh irrelevant wenn man auf FIFE setzt.
verfasst am: 28.06.2015, 17:38 · Edited by: Andiana
Registrierdatum: 21.10.2005, 20:08

 Beiträge: 133
x-Force's Problem Nr 1 ist und bleibt die fehlende Manpower.
Von daher sollten wir auf sujin hören und primär zusehen das wir Leute rekrutieren und nicht weiter über Code diskutieren.
Sondern erstmal grundlegendes:

* FIFE Ja/Nein
* Oder Godot?
* Multiplatform/Windows only
* Multilang oder nur Deutsch/Englisch
* Wie und wo werben wir

* Hexagon Tile
* Wo kriegen wir Grafiken und Grafiker her
* Bodeneinsatz sperrt Geoscape

Als schon fest nehme ich an:

* Echtzeit (teilweise wie JA2?): nein
* 3D: nein
* online/Multiplayer: nein
* Raumschiffskampf: per Script simuliert, Scripte "Offensiv", "Defensiv" und "Rückzug" werden bereitgestellt, können aber vom Spielsatzersteller ersetzt werden
* Mehrere (spielbare) Ebenen: nein
* intern mehrere Grafik/Objekt-Ebenen: Ja
verfasst am: 01.07.2015, 03:26 · Edited by: gast2
Registrierdatum: 07.08.2013, 17:14

 Beiträge: 56
Zitat: Andiana
* Wo kriegen wir Grafiken und Grafiker her


Ich arbeite mich seit einiger Zeit für ein anderes Spiel in Gimp ein.
Reicht das für 2D bei Euch?

Einfache Sachen kriege ich aber auch derzeit relativ manierlich hin. :)

edit: Ich würde vermutlich einfach vieles einfach recyclen, was schon da ist. :)

edit2: Ich würde github auch empfehlen.
verfasst am: 02.07.2015, 17:35
Registrierdatum: 21.10.2005, 20:08

 Beiträge: 133
Für den Anfang auf jeden Fall, da reichen ja auch schlichte schnell erstellte Grafiken.
Die meisten Boden Tiles wird man wohl auch gut in 2D erstellen können.
Es macht aber Sinn die Grafiken aus mehreren Blickrichtungen und ggf. auch Auflösungen zu haben bzw erzeugen zu können. Daher ist es wohl besser andere Objekte in 3D zu erstellen, wenn man es denn kann.

Mit dem Erstellen der "richtigen" Grafiken würde ich warten bis die Programmierer sich sicher sind dass sie nichts mehr am Format ändern. Abgesehen von ein paar Tests und Sachen die man leicht neu rendern kann natürlich.

Ich glaube vieles kann man auch schon auf diversen Seiten finden. http://opengameart.org/art-search-advanced?field_art_tags_tid=Isometri c zB.
Aber später muss man auch irgendwie nachvollziehen können welche Grafik woher stammt und welcher Lizenz unterliegt etc.
Können wir bei den jetzigen leider nicht wirklich, daher ist nicht klar ob wir alles aus xForce recyclen dürfen.
verfasst am: 09.07.2015, 05:22 · Edited by: gast2
Registrierdatum: 07.08.2013, 17:14

 Beiträge: 56
@Auflösungen

Ja, hast ja recht. :)
Muss wohl wirklich auf Blender umschulen.

Ansonsten mache ich einfach erstmal nur die Dinge, die so gehen. Wird ja sicher eh nicht so rasend schnell fertis sein.
;)

Nur mal so als Frage - warum nicht gleich bei ufoai.sf.net mitarbeiten?
verfasst am: 11.07.2015, 14:23
Registrierdatum: 21.10.2005, 20:08

 Beiträge: 133
Hab gelesen dass Blender zwar sehr gut aber nicht leicht zu handhaben sein. Manche sollen bis zu ein Jahr gebraucht haben bis sie mit ihren Ergebnissen zufrieden waren. Aber so hohe Anforderungen haben wir ja auch (noch ;)) nicht.

UFO AI wollte ich mir auch mal wieder anschauen, ist schon Ewigkeiten her dass ich es angespielt hatte. Damals war kaum mehr als der Bodenkampf und Basisbau umgesetzt und so wirklich gut fand ich es damals nicht. Aber sie haben da anscheinend kontinuierlich dran weiter gearbeitet. Nur zerstörbare Mauern haben sie wohl immer noch nicht umsetzen können.
Hast du es denn gespielt?
verfasst am: 11.07.2015, 21:49
Registrierdatum: 07.08.2013, 17:14

 Beiträge: 56
@Ufo-AI

Ja, ich hole das immer mal wieder vor, auch wenn es auf Linux ein wenig rumzickt und nicht richtig die Ressourcen des Rechners nutzt. Aber ist vielleicht auch mein Unvermögen... :)

Habe es mir nach meiner Bemerkung auch nochmal richtig angeschaut... Also ich wäre schon froh, wenn Euer Projekt mehr in Richtung xforce gehen würde. Vor allem, was die Forschungsmöglichkeiten angeht.

Am allerschönsten fände ich es, wenn aus xforce, Ufoai und dem Teil aus der Ufo-Reihe, das auf dem Mars spielt (UFOEU?), die jeweils besten Features genommen würden und daraus das xforce2 entstünde.
Aber das wäre wohl krass viel Arbeit...
Und wenn Ihr auch noch eine eigenen Engine bauen wollt, ist ein Jahrzehnt recht schnell die Elbe runter...

Zerstörbare Mauern waren bei der 2014er Version 2.5, die ich grad spiele, nicht dabei. Die Kämpfe waren aber auch so schon schwer genug. :)
Trotzdem: Mein Rundenkampfliebling JA2 ist da wohl echt unschlagbar.
Mittlerweile gibt's eine Entwicklerversion 2.6. Habe ich aber noch nicht.


Die Erdansicht bietet eigentlich alles, was nötig ist.
Die Ufo-Kämpfe sind taktisch schon ein wenig anspruchsvoll.

Großes Manko ist die Forschung und ein leicht verwirrendes Menü.



@Blender

Für unser Spiel bastele ich an comic-stilartigen Gegenständen und Bildern. Da reicht Gimp. Aber es gibt halt immer mal wieder die Diskussion auf 3D rüberzugehen und dann müsste ich mich wohl eh in Blender einarbeiten. Würde da aber sicher geholfen kriegen. Und so schwierig kam es mir bei ersten Versuchen nicht vor. Scheint mir recht intuitiv zu sein. :)
Eigentlich habe ich mich nur an Gimp rangewagt, um zu verhindern, daß das Spiel 3D wird. :)



So, mal noch meine Meinung zu den anderen Fragen:


* Multiplatform/Windows only

Also wir profitieren hinsichtlich der Zuarbeit schon davon, daß das Spiel auf Linux läuft. Die typischen Linuxer sind vermutlich von Hause aus aktiver und code-näher.
Ich spiele fast nur Spiele, die auf Linux laufen. Habe mich so ziemlich aus dem ganzen (wenn auch gewaltigen) Rest ausgeklinkt.


* Multilang oder nur Deutsch/Englisch
Möglichkeit für Spracherweiterungen schaffen

* Wie und wo werben wir
Da könnte ich meine bescheidenen Werbeerfahrungen mit einbringen.

* Hexagon Tile
angenehm

* Bodeneinsatz sperrt Geoscape
Nur, wenn ein Entsperren das Spiel unnötig aufbläht.
Das Sperren wäre vermutlich günstiger, wenn es möglich sein soll auch die Bodeneinsätze zu speichern. Und da bin ich sehr dafür.


@Alien-KI
Gibt es da Ideen? Oder gibt es zu diesem Thema deutsche Literatur?
verfasst am: 14.07.2015, 23:55
Registrierdatum: 14.07.2015, 23:18

 Beiträge: 2
Hallo zusammen,
habe gerade meinen alten "Links"-Ordner auf ner alten HDD geöffnet und siehe da... ein Link zu "X-Force".
Ich liebte das Spiel von Anfang an.
Ich möchte nur einige Gedanken mit euch teilen. Bitte seht mir nach, wenn dadurch jemand sich auf den Schlips getreten fühlt. Es ist wirklich nur ein Feddback eines "alten" Users.

1. Ich bin kein Programmierer. Ich habe davon so wenig Ahnung wie von Teilchenphysik. Ok, etwas mehr schon, aber es dürfte klar sein, was ich meine. Wovon ich mehr Ahnung habe, ist Organisation. Ich bin broterwerbsmäßig Personalmanager (aber ein gaaaanz lieber!).
Das heißt, ich muss in mehreren Bereichen steuern, obgleich ich kein Fachmann in den Metiers bin.
Ich habe mir etliche Forumsbeiträge angesehen. Und wurde erinnert an die Zustände meiner Firma, bevor ich und 2 weitere Kollegen anfingen.
Unheimlich engagierte Menschen mit komplexen und multiblen Fähigkeiten. Aber... planlos. Kein Konzept, keine Vision, kein Progress.

2. Der letzte "Zoff" zwischen sujin und Kamor zeigt eine Grundthematik auf. Beide wollen eigentlich dasselbe. Laufen aber in verschiedene Richtungen, da verschiedene Denkansätze. Dies führt, da nicht gesteuert und optimiert, zu Frustrationen. Diese bedingen Ablehnung und dann kommt die Eskalation und en fin die Abkehr.

3. Wer ist hier überhaupt aktiv. Wer steuert. Ich meine nicht, wer "kümmert" sich mal da oder da. Oder hat dort und hier mal Ideen.
Wer ist Häuptling, wer Indianer. Dabei muss es nicht hierachisch zugehen, wie in der preußisch-kaiserlichen Armee.

4. Wo ist die Vision. Was ist die Strategie (z.B. in 2 Jahren wollen wir einen Relaunch haben. PUNKT)
Taktik: Wir machen in 5 Steps - 1. 2. 3. usw.
Wer betreut was?
Wer ist Aktionshalter oder meinetwegen Bereichsverantwortlicher?
Wer steht obendrüber und hat das große Ganze im Griff und ruft ab, ob die vereinbarten Ziele eingehalten wurden?
Dieser Mischmasch führt zwangsläufig dazu, dass irgendwie einer oder mehrere alles irgendwie machen.

5. Klare Absprachen
User "Programmiergott" kümmert sich um die Skripte in einem Bereich. User "Javaking" macht die anderen Skripte. "Designqueen" macht alles schick. Und die "Karla Kolumna" kümmert sich um die sprachlichen Elemente.
Darüber steht "Kontrollo Maximo" und schaut und fordert die entsprechenden Schritte ab und schreitet bei Konflikten ein und holt alle notfalls wieder runter.
Kleines Team, großen Team; egal.

6. Die Site ist langweilig für jedermann. Die Einträge sind uralt. Geht in die Offensive. Think big.
---- RELAUNCH IN X-Zeit ---- JEWHAW!
Und diese Beiträge á la: "Huhu suche noch Hilfe für neuen Spielsatz" oder "Hab da ne Idee" führen meist leider zu nichts. Neue Spielsätze erst nach neuem Konzept. Erst die Pflicht, dann die Kür.

7. Das wars dann auch. Nochmal, ich liebe das Spiel. Nur bitte... versucht euch zu koordinieren. Lasst diese Kleinschusterei. Macht einen Plan (das dauert und kostet manche schlaflose Nacht). Und bitte nehmt es nicht persönlich. Ich sehe das Ganze von außen und habe vielleicht keine Ahnung. Ich glaube nur, dass all die Mühe und die Kraft, welche man in ein Projekt steckt, völlig für die Katz ist, sofern Struktur fehlt. Es bringt auch nichts Schuldige zu suchen. Hockt euch zusammen; keine Mails oder Posts auf Forenseiten, sondern Skype oder persönlich.
Ich habe nur meine Meinung gepostet, weil ich hoffe, dass es weitergeht.

Greetz
verfasst am: 15.07.2015, 00:12
Registrierdatum: 07.08.2013, 17:14

 Beiträge: 56
Na, prinzipiell hast Du sicher recht... :)

Aber, ich glaube, es gibt hier nicht so recht etwas, was sich strukturieren könnte.

Ich schaue regelmäßig hier vorbei und allszuviel ist nie. Außer diesem Strang hier, werden noch zwei Spielsätze erstellt, die ich gerne unterstütze.
Vielleicht können fertige Spielsätze auch wieder Leute ranlocken.
Aber so richtig Hoffnung habe ich da auch nicht.

Deine Aufgabe als Personalmanager wäre demzufolge erstmal Personal zu besorgen, bevor die sich strukturieren können. :)

Hast Du da Ideen?
verfasst am: 15.07.2015, 00:19
Registrierdatum: 14.07.2015, 23:18

 Beiträge: 2
Hi,

guten Personal ist schwierig zu kriegen. ;)
Nein, ernsthaft. Ich glaube, die Leute, die aktiv sind, zu aktivieren wären, reichen. Man könnte erstmal mit dem Grundkonzept anfangen. Dann sucht man sich die Fachleute für die Bereiche usw.
Das entwickelt oft eine Eigendynamik, die man vorher schwer absehen kann.
Ich liebe gerade solche Projekte, wie X-Force. und diese sterben zu sehen, ist gelide gesagt übel. Aber hinsiechend ist noch schlimmer.
Ich drücke die Daumen, dass es was wird.
Lieber "gast2": Du scheinst mir aktiv zu sein. Und hat ideen. Das ist Klasse. und machnmal reicht schon Enthusiasmus für die ersten Schritte.

Ich verbleibe mit dem Zitat meines Kollegen (unserer Netzwerk-Admin): "Möge der Binärcode mit euch sein!"
verfasst am: 15.07.2015, 01:50
Registrierdatum: 26.04.2014, 20:39

 Beiträge: 39
Zitat: gast2
Vielleicht können fertige Spielsätze auch wieder Leute ranlocken.

Das hoffe ich auch. Kann leider nichts programmieren (bin schon mit X-Script überfordert), aber ein paar neue Spielsätze dürften auf keinen Fall schaden.

Seite: << [1] ... [9] 10 [11] [12] [13] [14] [15] [16] [17] [18] [19] .. [22] [23] >>




Du musst dich registrieren um auf dieses Thema zu antworten.
Login :: » Name » Passwort

Ladezeit (sec.): 0.008 · Powered by miniBB 1.6 with parts of 1.7 © 2001-2003