Gamestudio Links
Zorro Links
Newest Posts
Zorro 2.70
by jcl. 09/29/25 09:24
optimize global parameters SOLVED
by dBc. 09/27/25 17:07
ZorroGPT
by TipmyPip. 09/27/25 10:05
assetHistory one candle shift
by jcl. 09/21/25 11:36
Plugins update
by Grant. 09/17/25 16:28
AUM Magazine
Latest Screens
Rocker`s Revenge
Stug 3 Stormartillery
Iljuschin 2
Galactic Strike X
Who's Online Now
0 registered members (), 18,008 guests, and 5 spiders.
Key: Admin, Global Mod, Mod
Newest Members
krishna, DrissB, James168, Ed_Love, xtns
19168 Registered Users
Previous Thread
Next Thread
Print Thread
Rating: 3
Page 7 of 8 1 2 3 4 5 6 7 8
Re: sehr schlechte engine [Re: zSteam_] #88256
09/04/06 14:29
09/04/06 14:29
Joined: Apr 2005
Posts: 4,506
Germany
F
fogman Offline
Expert
fogman  Offline
Expert
F

Joined: Apr 2005
Posts: 4,506
Germany
Wenn man ein Fahrrad für 99,- gegen eine Rennmaschine für 9999,- antreten läßt, erweist sich das Fahrrad auch als langsamer...
Warte mal den überarbeiteten A6 Renderer ab...


no science involved
Re: sehr schlechte engine [Re: zSteam_] #88257
09/04/06 16:05
09/04/06 16:05
Joined: Jan 2002
Posts: 4,225
Germany / Essen
Uhrwerk Offline
Expert
Uhrwerk  Offline
Expert

Joined: Jan 2002
Posts: 4,225
Germany / Essen
Quote:

aber mit der behauptung, dass 3dgs langsam ist, habe ich trotzdem recht. an sich ist sie ja garnicht so langsam, aber wenn man die a6 gegen die source engine antreten lässt, dann sieht man wie langsam sie wirklich ist. ich nehme die source engine, weil die a6 fast die gleichen funktionen hat wie die source engine.




Wenn Du einen Porsche mit einer Nähmaschine vergleichst, dann ist die Nähmaschine auch blauer in Bezug auf die Weite.

Also ich sehe die Sache so: Du hast diesen Thread in einem ziemlich unsachlichen Ton gestartet. Trotzdem hat diese Community einmal mehr bewiesen, dass sie spitze ist und Dir bei deinem Problem weitergeholfen, so dass Du eine spürbare Verbesserung der Framerate erzielt hast. Was die Langsamkeit der A6 angeht, so brauchst Du dich nicht darüber zu wundern, denn Du scheinst nicht die nötige Erfahrung zu haben (und das meine ich überhaupt nicht böse!), diese Engine effektiv einzusetzen. Wenn Du mit der Source Engine ohne Erfahrung was zusammen bastelst wirst Du genau so die Erfahrung machen, dass Du schnell Probleme bekommst. Ich denke, das wichtigste für einen Entwickler ist -> mit <- der Engine zu arbeiten und nicht gegen sie. Studiere die Dir angebotenen Techniken und setze sie dann effektiv ein.

Die A6 ist eine pfeilschnelle Engine, wenn Du richtig mit ihr umgehst. Und ich bin der Meinung, dass sich das mit dem nächsten Update nochmals drastisch verbessern wird. Und was die geringen Systemvoraussetzungen angeht: Du hast es in der Hand, ob sich die Voraussetzungen weiter erhöhen mit Deinem Spiel oder aber ob sie so niedrig bleiben. Letzten Endes vergrößert jedes bißchen weniger Hardwareanforderungen Deinen potentiellen Kundenkreis.


Always learn from history, to be sure you make the same mistakes again...
Re: sehr schlechte engine [Re: Uhrwerk] #88258
09/06/06 08:02
09/06/06 08:02
Joined: Jul 2002
Posts: 2,002
Europe
ShoreVietam Offline
Expert
ShoreVietam  Offline
Expert

Joined: Jul 2002
Posts: 2,002
Europe
Es ist durchaus moeglich, mit A6.31.4 effektiv mit BSP Geometrie zu arbeiten, wenn man diese richtig einsetzt.

Ich moechte dir im folgenden Ausschnitte aus einem reinen WMB Outdoor-Level zeigen.
Ich habe _kein_ Terrain verwendet und alle insgesamt 12 Gebaeude sind begehbar!
Das Level hat insgesam - 2500 - Portale, WMB Groesse ~19 MB.

Ein Test, die Flache Kollisionsgeometrie druch ein Modell aufpeppen:


Wie zu sehen ist, Gebaeude und Landschaft komplett WMB, Dekoration aus Modellen:


Deutlich sichtbar, die Landschaft ist eher simpel (so sollte WMB eignesetzt werden), dann kann man auch noch zusaetzliche Effekte bedenkenlos einsetzen:


Hier der WMB-Schatten nochmal gut zu sehen:


Zaeune, Tische, Pflanzen ect. aus Modellen:


Wenn man bedacht vorgeht, kann man auch durchaus komplexere Strukturen bauen wie diese Holztraeger:


Landschaftshintergrund einsetzen damit alles nicht so kahl abgeschnitten wirkt (der Fluss endet in einem Wasserfall):


Von einer kleinen Hochebene, recht oben im Eck kann man noch das Dorfzentrum sehen, das Design liegt im Detail, die paar Graeser wirken sehr viel verglichen mit einem platten rein-Textur-Boden:



Allerdings bevorzuge ich in der A6.31.4 eine noch performance-staerkere Kombination.
Unter anderem unter dem Gesichtspunkt, dass WMB bauen sehr angenehm ist.

Wie in folgendem Bild zu sehen, beschraenkt sich die WMB Geometrie auf das Gebaeude so wie unsichtbare Kollisionsbloecke, Terrain, Dekoration oder Holzplanken, alles schnell rendernde Modelle.

In diesem Screen habe ich mit meinem alten Athlon 2.200+ und Radeon 9600 noch gute 50 FPS. Gerendert wurden knapp 7000 Modell-Polygone und nur ~150 WMB Polygone, man bedenke dass hier noch der Programmcode fuer ein ziehmlich weit entwickeltes Spiel im Hintergrund laeuft.


Die Begehbarkeit von Gebaeuden wird ueber extra-Levels fuer das Gebaeude innere Geregelt und spart damit noch weitere Performance:



Alle screens unter A6.31.4 oder weniger!





Last edited by ShoreVietam; 09/06/06 08:24.

My project Schlacht um Kyoto - Das Samurai Browsergame! (sorry, german only)
Re: sehr schlechte engine [Re: ShoreVietam] #88259
09/06/06 11:36
09/06/06 11:36
Joined: Mar 2004
Posts: 202
Germany
zSteam_ Offline OP
Member
zSteam_  Offline OP
Member

Joined: Mar 2004
Posts: 202
Germany
das sieht echt sehr gut aus, aber kannst du noch die fps zeigen, wenn du von einem ende des level zum anderen schaust?

ps.: mit der gleichen sichtweite wie auf den screenshots bitte


A6 Commercial 6.50.6
Re: sehr schlechte engine [Re: zSteam_] #88260
09/06/06 12:14
09/06/06 12:14
Joined: Nov 2004
Posts: 7,121
Potsdam, Brandenburg, Germany
Machinery_Frank Offline
Senior Expert
Machinery_Frank  Offline
Senior Expert

Joined: Nov 2004
Posts: 7,121
Potsdam, Brandenburg, Germany
Quote:

das sieht echt sehr gut aus, aber kannst du noch die fps zeigen, wenn du von einem ende des level zum anderen schaust?

ps.: mit der gleichen sichtweite wie auf den screenshots bitte




Ich musste ein wenig schmunzeln Sorry.

So was kann man doch nicht pauschalisieren. Levelgrenzen sind relativ. In einem extrem detaillieten Level könnten auf dem Marktplatz z.b. schon 100 Tausend Polygone verbraten sein, dann bitte, lasse es als Leveldesigner nie zu, dass er von einem Ende zum anderen schauen kann.

Es geht doch nur darum: Wieviele Polygone sind gleichzeitig sichtbar. Das kann ein Abschnitt des Levels sein, während der Rest im Nebel verschwindet, das könnte auch das ganze Level sein.

Deswegen sollte ja ein Leveldesigner auch etwas Intelligenz mitbringen, um solche Fragen bereits im Design zu klären und ein gutes Level zu bauen. Er sollte seine Tools kennen, die Leistung des Zielrechners und sollte wissen, was Skripte und Effekte kosten werden, um Reserven zu planen.

Im Grunde sollte man Level am Besten dann erst entgültig bauen, wenn die Skripte stehen, die Effekte integriert sind und das Gameplay in dem Level getestet wird, sonst kommen böse Überraschungen und man ändert wie irre.

Aber von einem Ende zum anderen zu schauen - Probier das mal in den anderen Spielen: entweder das ist Nebel oder extremes LOD. In FarCry oder Oblivion verschwindet fast alles in der Fernsicht, da werden ein paar ganz simple Platzhalterbäume angezeigt und das war es am "anderen Ende des Levels".

Leveldesign ist mehr, als ein paar Blöcke zu setzen. Modellieren, LOD, Texturen, Mipmapping, Culling, Nebel, Polygone zählen und Skripten gehört eigentlich dazu.

Ganz nebenbei, ZSteam: Welche Version von Gamestudio nutzt Du eigentlich? Da gibt es große Unterschiede.


Models, Textures and Games from Dexsoft
Re: sehr schlechte engine [Re: Machinery_Frank] #88261
09/06/06 12:39
09/06/06 12:39
Joined: Jul 2002
Posts: 2,002
Europe
ShoreVietam Offline
Expert
ShoreVietam  Offline
Expert

Joined: Jul 2002
Posts: 2,002
Europe
Ueber das ganze Level?

Ich gestehe damals war ich noch nicht so erfahren, man konnte zu viel sehen, eigentlich muss man, wie schone rwaehnt, dafuer sorgen, dass nicht zu viel zu sehen ist.
Aber das kann ich so nicht sagen, es ist sicher 3 Jahre her, dass ich das gebaut habe, inzwischen kann ich das nichtmehr testen weil ich versehentlich mal eine wdl gegrillt habe.
Ausserdem kann man unsere beiden Rechner nicht vergleichen, zumal ich damals eine noch schlechtere Graka hatte.

Wesentlich ist aber, dass es ein Komplettes Dorf mit Gebaeuden und Landschaft ist und 2500 Portale braucht, wohingegen du bei grob einem Haus und etwas blockfoermiger Umgebung bereits bei 8000 warst.

Das Level sollte dir in erster Linie zeigen, wie man Levelgeometrie einsetzen sollte, daher auch der vergleich zum besseren aufbau in den letzten beiden Screens.

Wenn du weisst, wie Protale entstehen und wie du sparsam bauen kannst, dann kannst du Levelgeometrie gezielt einsetzen.

Wichtig ist beobachten von professionellen Spielen, wenn man die genau beobachtet sieht man naehmlich wie eben erwaehnt, dass man eigentlich nichts sieht.
Die Sichtweite ist immer sehr begrenzt und wenn man ganz genau schaut erkennt man wo und wie LOD zum tragen kommt oder wie wenige Polygone/ was fuer kleine Texturen eingesetzt werden an Stellen/ Entfernungen worauf man normal eben nicht achtet.

Es ist zugegeben eine Gratwanderung fuer die man einiges an Erfahrung sammeln muss.
Ich habe die einfachste Loesung gewaehlt, naehmlich die Isometrik.
Ich lasse in den WMBs keine Visibility Berechnung machen und schalte von Hand alles NONE was sowieso nie sichtbar wird.
Das kann man bei Isometrik machen, denn zwischen Kamera und Spielermodell wird sowieso nichts groesseres sein was ausgeblendet werden koennte/ muesste.

Ansonsten hilft nur Nebel und Clipping sowie verschachtelter Aufbau der den Blick schnell blockiert zusammen mit der Visibility Berechnung, weswegen sich der BSP Tree egientlich hervorragend fuer Indoor Bereiche eignet.

Ganz wichtig wie erwaehnt sind letzlich auch die Scripte.
Ein Beispiel, je mehr Objekte sich im Level befinden, je mehr geometrie darin ist, desto laenger braucht jede einzelne Trace oder Move Anweisung.

Sprich ab gewissen Levelgroessen reicht auch LOD nicht aus sondern Objekte muessen wirklich dynamisch geladen und entfernt werden.

Das hat in der Karte bei den letzten beiden Screens 10 bis 40 FPS gebracht, obwohl die geleoschten Objekte alle weit ausserhalb des fuer die Kamera sichtbare Bereiches waren.


Nachtrag:
Setz' in ein beliebiges Level einen breiten Block mit NONE Flag rundherum und lass es mit Visibility Calculation durchrechnen.
Wenn du um den Block herum gehst, wirst du sehen (da er durch NONE ja durchsichtig ist) wie dahinter liegende Levelbereiche verschwinden.

Last edited by ShoreVietam; 09/06/06 12:46.

My project Schlacht um Kyoto - Das Samurai Browsergame! (sorry, german only)
Re: sehr schlechte engine [Re: ShoreVietam] #88262
09/06/06 14:19
09/06/06 14:19
Joined: Sep 2003
Posts: 9,859
F
FBL Offline
Senior Expert
FBL  Offline
Senior Expert
F

Joined: Sep 2003
Posts: 9,859
Noch was zu Levelblocks:

Blöcke, die nur dazu dienen, die Szenerie zu verfeinern und für die Kolission nicht relevant sind, können als Detail Blocks ins Level gebaut werden.

Re: sehr schlechte engine [Re: ShoreVietam] #88263
09/07/06 14:45
09/07/06 14:45
Joined: Mar 2004
Posts: 202
Germany
zSteam_ Offline OP
Member
zSteam_  Offline OP
Member

Joined: Mar 2004
Posts: 202
Germany
- in meiner stadt sind ja jetzt nur noch knapp 2000 portale

- ich würde aber trotzdem gerne erfahren, was der fps durchschnitt ist. bitte poste ihn

- ach meine version ist die 6.4 commercial


A6 Commercial 6.50.6
Re: sehr schlechte engine [Re: zSteam_] #88264
09/07/06 17:09
09/07/06 17:09
Joined: Dec 2002
Posts: 3,375
Vindobona (Ostarichi)
Harry Potter Offline
Expert
Harry Potter  Offline
Expert

Joined: Dec 2002
Posts: 3,375
Vindobona (Ostarichi)
Quote:

ich würde aber trotzdem gerne erfahren, was der fps durchschnitt ist. bitte poste ihn




1.) Zunächst einmal eine Anmerkung zum Thema "FPS":
Hohe Frameraten sind gar nicht so gut für die Grafikkarte. Ich selbst begrenze immer meine Frameraten z.B. auf 60 FPS (je nach Art des Spieles bzw. Levels manchmal auch auf 30 FPS). Und zwar aus folgendem Grund:

Spiele laufen üblicherweise bereits mit 60 FPS flüssig, ohne zu ruckeln. Mehr als 60 FPS macht meiner Meinung nach wenig Sinn, und belastet nur unnötig die Grafikkarte. Ich habe z.B. einen Spielelevel, der auf meinem Rechner mit ca. 120 FPS läuft. Im heißen Sommer hatte ich dann bemerkt, dass bereits nach wenigen Minuten der Kühler-Ventilator von der Grafikkarte zu hören war. Die Grafikkarte hatte sich aufgrund der hohen Framerate erhitzt. Als ich die Framerate von diesem Level auf 60 FPS begrenzt hatte, lief das Spiel genauso flüssig, und zusätzlich wurde die Grafikkarte geschont. Der Kühler-Ventilator war dann nicht mehr zu hören.

Also ein Tipp von mir: beschränkt eure Frameraten. Sehr hohe Frameraten bringen gar nichts. 60 FPS reichen vollkommen aus. Bei manchen Spielen genügen sogar viel weniger FPS, damit das Spiel flüssig läuft.


2.) Hier eine kleine Demo, um zu zeigen, was die Engine so kann. Der Level besteht aus ein paar Models, die ich selbst gemacht habe. Wie ihr sehen könnt, sind die Models sehr detailiert und rund, haben also viele Polygone. Und auch die animierte Schrift ist sehr rechenintensiv (wird mit Pixelbefehlen gezeichnet, und bei jedem Frame werden die Mipmaps vom Papier-Model neu generiert).

Dennoch läuft dieser Level auf meinem Rechner mit ca. 80 bis 100 FPS! Bei dem Demolevel habe ich jedoch aus den oben erwähnten Gründen die Framerate begrenzt (ich glaube auf 30, damit sie auch auf meinem langsamen Laptop nicht ruckelt, und damit die Mipmaps nicht so oft neu erstellt werden müssen). Auf Wunsch kann ich euch aber auch eine Demo schicken, die keine FPS-Begrenzung hat, damit ihr die Framerate messen könnt.

Hier der Link: Download Demo (13 MB)

Hier noch ein Screenshot von dieser kleinen Schrift-Demo:




3.) Und dann habe ich hier noch einen kleinen Demolevel von einer Landschaft. Der Demolevel ist jedoch inzwischen schon 2 Jahre alt ist. Ist nichts besonderes. Erwähnenswert sind dabei jedoch die Zäune. Sie haben relativ viele Polygone, benutzen jedoch LOD. Also wenn man genau hinsieht, bemerkt man, dass sich die Zaun-Models verändern sobald man sich von ihnen entfernt. Aber man muss schon sehr genau hinschauen. Das macht eben gutes LOD aus. Wenn es gut gemacht ist, bemerkt man es fast gar nicht.

Der Level läuft auf meinem PC mit ca. 80 FPS. Aber auch hier habe ich die Framerate begrenzt (ich glaube auf ca. 30 FPS)?!?

Hier der Link: Download (ca. 8 MB)


Was ich mit Punkt 2 und 3 sagen will: Benutzt lieber Models anstatt Blöcke. Vor allem wenn ihr große Städte darstellen wollt. Die Models werden nämlich viel schneller gerendert als die Blöcke, und ihr habt die Polygonanzahl dann besser unter Kontrolle.


Grüße,
Thomas

Re: sehr schlechte engine [Re: Harry Potter] #88265
09/07/06 18:35
09/07/06 18:35
Joined: Jul 2002
Posts: 2,002
Europe
ShoreVietam Offline
Expert
ShoreVietam  Offline
Expert

Joined: Jul 2002
Posts: 2,002
Europe
Stimmt, besonders beim steigenden aufkommen der LCDs die eh nur 60 Herz darstellen, da is jede hoehere Framerate fuer'n A****.

Ich kann keine "Durchschnittliche Framerate" angeben aus diversen Gruenden.

1. Das Script zum Level is verheizt -> laeuft nichtmehr
2. Durchschnittliche Framerate? Was solld as sein? Das waehre im Grunde von jeder einzelnen position in jedem Winkel (Pan/ Tilt) schauen und die Framerate notieren und am Ende eine Durchschnittswert bilden.

Klar hat es eine scheiss Framereate wenn man vom einen ende zum andere schaut.

Aber wieso?

WEIL MAN ES KANN!! (BSP-Tree sinnlos)

-> Schlechter Levelaufbau trotz sparsamem Portaleinsatz.

Zudem kein LOD o_O

Und wenn man fuer den Boden ein Terrain, fuer die Gebaeude Modelle, fuer die Gebaeudekollsition enifache "NONE" WMBs mit normalem ent_move verwendet hat man eine endgeile Framerate, gerantiert!


My project Schlacht um Kyoto - Das Samurai Browsergame! (sorry, german only)
Page 7 of 8 1 2 3 4 5 6 7 8

Moderated by  HeelX, Spirit 

Gamestudio download | Zorro platform | shop | Data Protection Policy

oP group Germany GmbH | Birkenstr. 25-27 | 63549 Ronneburg / Germany | info (at) opgroup.de

Powered by UBB.threads™ PHP Forum Software 7.7.1