Hallo,
mich interessiert, welche Bauteile ich brauche um einen Handheld für 3d
Spiele zu bauen.
Was er können soll:
auf einem ca 4" Display(ca.600x480px), texturierte(512px) 3d Grafik
darstellen, mit ca 3000polygonen/model und 1000 objekten.
Gesteuert werden sollte er mit 12 knöpfen. und max 4xaaa Baterien haben.
zur Software Seite: Ich vermute, dass man einen eigennen Bootloader/
Kernel oder OS programmieren muß um die Spiele zu verwalten, als 3d
bibliothek frage ich mich ob assimp funktionieren würde.
ich habe mir bisher, Atmega angeschaut, sie sind günstig und haben fast
soviel mhz wie eine nintendo 64 GameKonsole, aber was ist mit der GPU?
ist nimmt man dafür einen zweiten microcontroller und schliesst an
diesen speicher an, der als grafikspeicher reserviert wird? oder gibt es
extra microcontroller für 3d grafik, die nur ein paar euros kosten?
Ich finde das Thema sehr Interessant und freuhe mich über Antworten.
Hast du schon jemals etwas programmiert oder eine Elektronik aufgebaut?
Wenn nicht, empfehle ich dir klein anzufangen und das Tutorial dieser
Seite durchzuackern. Selbst als Profi klatscht man dein Vorhaben nicht
einfach so mal hin. Ich würde mir dein Projekt im Alleingang jedenfalls
nicht zutrauen, jedenfalls nicht, wenn es in einem vernünftigen
Zeitrahmen (< 2 Jahre) fertiggestellt werden soll.
Ich glaube dass man ohne eine 3D-fähige GPU keine Chance hat, denn diese
sind spezialisiert auf Polygone, Texturen etc.
Die Nintendo Konsolen haben bestimmt die optimale GPU zu ihren (ARM
?)Chips verbaut.
So ein Polygon in Software zu rendern halte ich für unrealistisch, aber
vielleicht gehts mit GHz-getakteten Controllern/CPUs.
Ich programmiere Spiele und beschäftige mich abund an mit dem Ardurino
nano, aber ich habe noch kein Display um selber tests zu machen.
Ich denke der nano schafft auch kein Farbdisplay wie ich das möchte.
Ich habe ein Video gesehen, in dem "AterLux" einen 3d Würfel mit hilfe
eines ATmega8A darstellet,
www.youtube.com/watch?v=VWVvKVIVqeg
aber ich vermute, das dieser Test für mich negativ ausfallen würde, da
das Bild des würfels flackert.
Auch denke ich, für jemanden, der nicht Spiele programmiert meine
Angaben zu groß sind, da es eigentlich angaben an die Engine sind.
Also wenn bis zu 20 modelle auf dem Bildschirm gezeigt werden könnten,
wäre ich zufrieden.
Es gibt auch videos mit 2d Dos- Games, könnten solche controller auch 3d
Grafik darstellen? und was sind das für controller?
zusatz: ein Spiel wie Stunts von Amiga500,
www.youtube.com/watch?v=7hpdj4mAxxM
Währe horror, da sind die Texturen viel zu klein und wenn die Bausteine
für die Hardware mehr als 10€ kosten, dann bin ich entteuscht, weil
meine Hardware bestimtt sehr viel teuerer wäre
H-G S. schrieb:> Ich glaube dass man ohne eine 3D-fähige GPU keine Chance hat, denn diese> sind spezialisiert auf Polygone, Texturen etc.>> Die Nintendo Konsolen haben bestimmt die optimale GPU zu ihren (ARM> ?)Chips verbaut.>> So ein Polygon in Software zu rendern halte ich für unrealistisch, aber> vielleicht gehts mit GHz-getakteten Controllern/CPUs.
Nakla hat die N64 die passende GPU, einge 3d Konsolen habe ihre GPUs
sogar koop mit Elektronik firmen selber entwickelt.
Ich finde das so Spannend, dass die für Bestimmte GameLocks(Styles) eine
perfekt angepasste Hardware entwickelt haben(also nicht nur Nintendo).
Besonders bei der Dreamcast, die angeblich ein flop war, kann ich mir
vorstellen, dass der jenige, der die Idee hatte, überglücklich war, dass
seine Konsole gebaut wurde. vielleicht hat er die immer noch und Spielt
genau die Games, die er immer haben wollte, angeblich werden ja immer
noch games dafür produziert.
Fan T. schrieb:> Ich programmiere Spiele und beschäftige mich abund an mit dem Ardurino> nano, aber ich habe noch kein Display um selber tests zu machen.
Sehr gut. Aus deinem Eingangspost war das nicht ersichtlich, deswegen
die Nachfrage.
Fan T. schrieb:> Ich denke der nano schafft auch kein Farbdisplay wie ich das möchte.> Ich habe ein Video gesehen, in dem "AterLux" einen 3d Würfel mit hilfe> eines ATmega8A darstellet,> www.youtube.com/watch?v=VWVvKVIVqeg> aber ich vermute, das dieser Test für mich negativ ausfallen würde, da> das Bild des würfels flackert.
Könnte schwer werden, das mit einem ATmega hinzugekommen, wäre aber eine
schöne Herausforderung. An deiner Stelle würde ich auf einen
Einplatinencomputer (z.B. RasPi) zurückgreifen, dann hast du schon mal
eine funktionierende Hardware für einen durchaus guten Preis. Ich denke,
die Dinger haben auch genug Leistung für dein Vorhaben. Unterstützen
auch OpenGL und können Filme in Full-HD rendern, HDMI und FBAS Anschluss
inklusive.
Einfarbige Polygone ohne Texturen sollten auch ohne GPU machbar sein.
Es gibt Formeln/Prozeduren wie man Linien zwischen 2 Koordinaten
berechnet/zeichnet. Für die einfarbige Fläche gibt es soetwas bestimmt
auch.
Ich hatte mal so ein Buch in der Hand, habe es aber verkauft.
Schwierig wirds mit Texturen, also diese zu drehen/verzerren etc. damit
sie auf die Ausrichtung des Polygons angepasst werden.
Also wenn der Amiga so ein flottes untexturiertes 3D-Spiel schafft dann
müsste ein krasser Controller da ziemlich was machen können :-)
Auf dem PC werden 3d Darstllungen meist mit HLSL(DirectX), oder HLSL
programmiert, diese Sprachen sind Grafiknahe Sprachen zum Rendern usw.
Ich muß mich mal informieren, wie sowas ohne diese Programmiert wird.
ein Krasser Microcontroller währe Banana Pi und Odroid, die haben eine
400-MP2-GPU von Mali(was auch immer das heisst X)
quelle:
http://www.pcwelt.de/ratgeber/Die-besten-Raspberry-Pi-Alternativen-im-Ueberblick-Ein-Platinen-PCs-9634864.html
ich denke auf den Raspberrys könnte man das alle laufen lassen, indem
man linux drauf macht.
Jetzt wird es peinlich: kann jeder raspberry pi ein Display ansteuern
oder brauche ich das extra bauelemente?
Da gibt es noch das Problem mit dem LCD-Speicher bzw. dann dem
Bildpuffer.
So ein 640x480 LCD hat etwa 300kB Bildspeicher, und du brauchst den
doppelt damit du in einem zeichnen kannst während das LCD den anderen
Puffer anzeigt.
Wo soll dieser Speicher sein, extern oder im Controller ?
Wenn es 16-Bit Farben sein sollen (5R5G5B) dann sind es 300kB mal 16
Bit.
Dann ist da noch die Sache mit der Bildwiederholfrequenz, es müssten
wohl über 25/30 Bilder pro Sekunde sein damit es flüssig läuft.
Das heisst es müssten alle etwa. 30ms das neue Bild gezeichnet und der
Bildpuffer kopiert/gefüllt werden bevor man den aktuellen LCD-Puffer
wechselt bzw. beschreibt.
ich habe mir mal die vorund nachteile von externen und internen
Bildpuffer Spicher überlegt.
o Wird der Chip zu heiß im kleinem Gehäuse?
o muß man Mehanismen zum sofortigem löschen des externen speichers
einbauen?
o wie lange reicht der akku?
o ist externer Speicher billiger als ein microkontroller mit viel
internem(weil mein 640x480.bmp bild 1.3MB Groß ist und ich dann mal von
3MB Pufferspeicher aussgehe im controller für <2€, ist bestimmt nicht
soviel).
ist externer Speicher zu langsam?
Würdet Ihr mir einen günstigen fertigen controller mit einem screen
empfehlen? der braucht kein HDMI.
den ich studieren könnte.
ps.
Be S. schrieb:
An deiner Stelle würde ich auf einen
> Einplatinencomputer (z.B. RasPi) zurückgreifen, dann hast du schon mal> eine funktionierende Hardware für einen durchaus guten Preis. Ich denke,> die Dinger haben auch genug Leistung für dein Vorhaben. Unterstützen> auch OpenGL und können Filme in Full-HD rendern, HDMI und FBAS Anschluss> inklusive.
Hat der Hardware, die OpenGL unterstütz? oder ist das in der OS?
> ich habe mir bisher, Atmega angeschaut, sie sind günstig und haben fast> soviel mhz wie eine nintendo 64 GameKonsole
Das N64 hat einen NEC-VR4300 (93.75MHz) CPU -> 64Bit MIPS, 5 stufige
Pipeline (in-order Execution) mit FPU + L1 I/D Cache, ...)
Nimm einen Raspberry Pi und schau dir OpenGL ES an (google).
Bei deinen restlichen Ideen mangelts (IMHO) an einigen
Grundlagen/Wissen, es ist möglich aber da brauchts mehr als Fantasy :-)
(aber konkreteren Fragen, wird dir bestimmt geholfen)
lustig Marten W.:D
...OK ich schaue mir das mal an und zwischen durch auch wie man ohne
opengl renderd und danke für euere tollen infos und den schnellen
überblick.
noch eine schöne Woche euch allen. tschüüüs
edit: Marten W.,den Nintendo werde ich mir noch mal nur so zum Spass
genuer angucken und einbishen von einer os träumen :D
Fan T. schrieb:> auf einem ca 4" Display(ca.600x480px), texturierte(512px) 3d Grafik> darstellen, mit ca 3000polygonen/model und 1000 objekten.
Ich habe ein paar Dinge auf dem Nintendo DS in der Richtung gemacht
(Sowas wie Wolf3D) und irgendein geniales Köpfchen hat eine recht
beeindruckende 'Proof of Concept' auf dem DS gemacht (heisst 'Sonic').
Aber auf dem DS läuft auch OpenGL mit Hardware Unterstützung.
Aus meiner Erfahrung mit PC Engines (Battlefield 2 und Torque 3D) weiss
ich, das man für 1000 Objekte mit je etwa 3000 Tris schon ganz schön
Power braucht. Unsere Mod für BF2 hatte Objekte (Vehikel wie Panzer,
Schiffe und Autos) mit um die 3000-6000 Tris und bei hundert davon ist
BF2 einfach zusammengebrochen auf den damaligen Dualcore Maschinen. Eine
heutiger Quadcore mit guter GPU Unterstützung schafft evtl. 500 solche
Objekte.
Die im Moment hochgehandelste Engine ist vermutlich die Unreal 4 und
selbst die wird bei solchen Anforderungen ihre Probleme haben.
Ich habe von den Valve Games gelesen, dass man die mit der sdk verändern
darf, aber ich vermute, dass die modelle alle viele Werte haben, flags
und so.
Ich habe mal mit meinem Laptop(14-r103ng) 4GB Ram, in einem particle
effekt, die particle durch 2k poly modele ersetzt. die 700 modelle sieht
man gleichzeitig, bei 27 fps.
hier das Bild:
http://www.bilder-upload.eu/upload/1c590d-1467954849.jpg
zusatz:die modelle sind weiß, weil die ohne textur sind
edit:
Matthias Sch., wenn deine Level etwas mehr an plastität hätten, könnte
das Level schon 3k polygone habe, ich habe nicht damit gemeint, dass
alle objekte soaufwändig wären.
Ich wollte aber nicht für eine Konsole coden, weil das Teilen der
Gamesich mir schwierig vorstelle, ich werde mir das STM32F429 Discovery
Kit, welches Icke ® vorgeschlagen hat, kaufen, obwohl die Form mir nicht
zusagt, bin ich damit doch für Monate/ Jahre bedient und wenn ich es auf
dem schaffe, kann ich es mit anderen Mikrocontrollern versuchen.
Fan T. schrieb:> hier das Bild:> http://www.bilder-upload.eu/upload/1c590d-1467954849.jpg> zusatz:die modelle sind weiß, weil die ohne textur sind
Naja, wenns nur um sowas geht, kannst du ja mit dem F429 rumspielen. Ich
hatte mehr an texturierte Modelle, evtl. sogar mit Bump/Normal Maps
gedacht, was wir für Torque 3D und BF2 natürlich gemacht haben, damits
gut aussieht.
Fan T. schrieb:> ich habe nicht damit gemeint, dass> alle objekte soaufwändig wären.
Ahso, das klang eingangs aber so - 1000 Objekte mit je 3000 Polies/Tris
macht das denn sinn bei bei einem kleinem display wie bem DS, normal
maps einzusetzen?
sogar das licht würde ich mit einer licht textur im level und dacals bei
charaktern nehmen
zu der Texturgröße:
das sind Bilder aus meinen Games
http://www.bilder-upload.eu/upload/fe8b93-1467971186.jpg
Und bis auf den helicopter sind das alles 16px;32px und 64px texturen,
bis auf das Wasser sind auch keine Shader aktivier, ich habe sie auf
280x370 runterskalliert.
damit komme ich aus aber an einigen Stellen brauche ich doch 1-bis 2
große Texturen
Die Displays, die zum Anschluß an µC gedacht sind, haben ihren eigenen
Speicher (klar, denn der Speicher des µC ist ja meist nicht auf einem
Bus herausgeführt). Sie sind per parallelem 8-Bit Interface, I2C oder
SPI angebunden. Diese Anbindung bestimmt die mögliche Bildwiederholrate.
Falls bei der Demo eines solchen Displays irgendetwas schnell geht, dann
ist es recht wahrscheinlich, daß vorher in das Display geladene Bitmaps
angezeigt werden.
Die kleinen (Touch-)Displays für den Raspberry Pi, die z.B. bei
Watterott oder Adafruit angeboten werden, funktionieren m.W. ähnlich.
Ich würde an Deiner Stelle mit dem Raspberry Pi und Raspian mal
herumspielen. Der schnelle Closed-Source-Treiber von Broadcom für OpenGL
ES (also die abgespeckte Mobilversion) ist im Moment noch erste Wahl,
aber es wird an einem Open-Source-Treiber für volles OpenGL gearbeitet.
Beide benutzen die sogenannte VPU (==GPU).
Da kann mann dann jedes HDMI-Display anschließen und Input-Pins für
Knöpfe gibt es auch genug.
Beim Stromverbrauch bin ich mir aber nicht so sicher. Man kann sicher
auf einen Raspberry Pi Zero mit einem Core heruntergehen, aber ein
HDMI-Display dürfte 4 AA(A) Zellen schnell leersaugen, oder? Mußt Du mal
ein bißchen mit den Displays, die in Deinem Budget liegen, herumrechnen.
Oder gleich auf das offizielle 7"-Display und einen fetten Akkupack
setzen...
Du solltest auf jeden Fall einkalkulieren, daß Du manche Entscheidung
für Hard- oder Software u.U. mehr als einmal revidieren mußt. Aber das
ist ja nichts Neues für Dich: die Bilder die Du hochgeladen hast, sehen
auf jeden Fall nicht nach dem ersten Programmierversuch aus.
Vielleicht fängst Du einfach erstmal damit an, auf (D)einem PC Linux zu
installieren und OpenGL zu programmieren, wenn Du das nicht schon längst
getan hast. Dieses Wissen ist auf dem Raspberry Pi dann direkt
wiederverwertbar.
Danke für die Antwort,
Bei hdmi/TMDS habe ich gelesen, dass da eine übertragung von 1,65 Gbit/s
möglich sind, ich nehme an, dass das ein guter Orientierungskrise zum
suchen meiner Platine ist.
ich gucke mir mal später an, wieviel speichen nun ein voller bildaufbau
hat, Dein Hinweis mit dem darstellen von bildern aus dem display
speicher, finde ich super. Du hast recht, es ist nicht mein erster code
und ichnehme an solche tricks kann man für das grafische interface ode
menue, nutzen. vielleicht passt auch ein font darein.
OpenGL bzw WebGL habe ich auch schon offt daran gedacht mich endlich
richtig damit zu befassen.
Trotztdem hätte ich auch gerne ein Gerät, auf dem ich das testen kann,
am desten wäre ein emulator und ein Gerät, jenachdem.
Fan T. schrieb:> macht das denn sinn bei bei einem kleinem display wie bem DS, normal> maps einzusetzen?
Nö. Das bezog sich auf BF2 und Torque3D. Bei Smartphones und DS(i) würde
ich das nicht machen wollen.
Matthias S. schrieb:> Fan T. schrieb:>> macht das denn sinn bei bei einem kleinem display wie bem DS, normal>> maps einzusetzen?>> Nö. Das bezog sich auf BF2 und Torque3D. Bei Smartphones und DS(i) würde> ich das nicht machen wollen.
Ich habe nicht gesehen, was Ihr gemacht habt, würdest Du bitte einen
Link posten.
Für Modelle mit Spitzenqualität braucht man viel Übung und gekaufte
Assets, passen oft nicht zusammen und sogar mit allen shadern(normalmap,
beleuchtung, blur,ssoa,foc unschärfe usw.) gehen sie einfach in der
Menge unter.
Fan T. schrieb:> OpenGL bzw WebGL habe ich auch schon offt daran gedacht mich endlich> richtig damit zu befassen.
Finde ich gut. Aber nicht das veraltete OpenGL 1.0 mit den glBegin und
glEnd blöcken, sondern mindestens 2.0 oder GLES.
Das grundkonzept ist recht simpel. Das Hauptprogramm erstellt Buffer und
Texturen, compiliert Shader und reicht diese an die Grafigkarte
durchreicht. Die Grafigkarte führt die Shader aus u d zeichnet damit ein
Bild in einen Buffer.
Der Ablauf ist dann normalerweise, dass 3D objekte als Ansammlung von
Dreiecken betrachtet werden. Von diesen nimmt man die Eckpunkte, die
werden dann Verteces genannt. Wenn viele 3ecke sich eckpunkte teilen,
speichert man alle nir einmal, und macht noch eine Liste mit Indizies,
also eine Liste der Positionen wo sich die Verteces der Dreiecke in der
Vertex liste befinden. Die beiden Listen sind dann der Vertex und der
Index Buffer. Beispiel:
1
0 1
2
+---+
3
|a /|
4
| / |
5
|/ b|
6
+---+
7
2 3
8
Verteces:
9
0 1
10
1 1
11
0 0
12
0 1
13
Indeces:
14
0 1 2 <- Dreieck a
15
1 3 2 <- Dreieck b
Die Daten übergibt man dann der Grafigkarte.
Die wichtigsten Shader sind Vertex und Fragment shader. Der Vertex
shader bekommt die Verteces der gegebenen Buffer, er wird für jedes auf
der GPU neu ausgeführt. Er berechnet & gibt den Positionsvertex zurück,
mit welcher die Grafikpipeline die Fragmente (=pixel) auf dem Bildschirm
berechnet, die im Dreieck liegen. Der Fragment shader wird für jedes
dieser Fragmente aufgerufen. Dieser gibt entweder die Farbe des
Fragments zurück, oder verwirft dieses. So wie zu den Positions Verteces
noch weitere Werte wie Farben gehören können, kann der Vertex Shader
diese auch Verarbeiten, und derartige Werte dem Fragment Shader
weitergeben. Die Zusammengehörenden Werte der Verteces, die das Dreieck
bilden, zudem das Fragment gehört, werden dann so Interpoliert, das der
wert eines Fragments stärker gewichtet wird, je näher das Fragment dem
Vertex relativ zu den anderen ist.
Beispiel:
1
1 2
2
+-----+
3
a b c
4
1 und 2 sind die Verteces, a, b und c stellen Fragmente dar. Fragment a bekomt die Werte von Vertex 1. Fragment c die von Vertex 2, und Fragment b bekommt von beiden den Durchschnitt.
Das sind die Basics, wie OpenGL und Direct3D arbeiten. Der witz ist,
dass theoretisch die berechnungen für alle Verteces und alle Fragmente
gleichzeitig gemacht werden können.
Also erstmal nochmal zur Hardware: Ich könnte den Raspberry,
(vielleicht wird es ein Zero, muß aber noch wegen der VPU gucken)
vielleicht auch ohne Baterie testen, wenn ich sowieso mehrmals die
Hardware wechseln werde.
wenn ich ein Handy LCD Display nehme, mu ich das bestimmt auch nicht
löten, weil es meist die passenden fpc stecker erhältlich sind, zum
löten müsste ich die Dräte erst auseinander schneiden, aber das ist bei
den gebogennen total schwierig.
Ich habe mal rumexperementiert und auchnebenbei defekte Gamecube
Gamepads gekauft, von denen ich ein paar wieder verkauft habe, wenn ich
nach diesen geldern gehen würde wäre mein Budget ehr klein, aber ich
habe auch ein 4-Draht SPI raspbarry display für 5€ gesehen
http://www.ebay.de/itm/2-2-Seriel-SPI-TFT-LCD-Modul-Display-Anzeige-m-SD-Slot-f-Arduino-Raspberry-/162085314458?hash=item25bd099f9a:g:3PMAAOSwUfNXSV~u
zu OpenGL:
Daniel A. schrieb:
on Vertex 2, und Fragment
> Der witz ist,> dass theoretisch die berechnungen für alle Verteces und alle Fragmente> gleichzeitig gemacht werden können.
sehr interessant, werden dann einfach alle farbwerte zwischen 2 Farben
berechnet und dann durch die anzahl der Pixel, die zwischen 2 verticies
liegt dividiert? hehe
hey Jungs ich wünsche euch schonmal ein schönes wochenende, werde bei
meiner Familie sein, es ist zu spannden aber sonst sehe ich überall
nichts mehr als computer. zzG1)
Fan T. schrieb:> Ich habe nicht gesehen, was Ihr gemacht habt, würdest Du bitte einen> Link posten.
Ich war bei XWW2:
http://www.moddb.com/mods/experience-ww2
eine WW2 Mod für (ursprünglich) BF1942 und dann für BF2.
Wir haben dann umgesattelt auf Torque3D, haben aber nie jemanden
gefunden, der Animationen für diese Engine machen konnte.
http://www.garagegames.com/
Seltsam, dass ihr das nicht geschafft habt,... braucht es ein
spezieelles callada format? Ich frage, weil in blender callada(Default)
steht, oder werden die Animationen als extradatei geladen?
Guten Morgen,
ich wollte am Wochenende eigentlich nichts mit Computern machen, aber
ich denke Spät abends kann ich mich zurückziehen, und online gehen um
einwenig was zu lernen :)
Und nachdem ich in meinem ersten thread:
Beitrag "Re: eigennen 3d Handheld bauen"
so viele hilfreich Tips bekommen habe, dachte ich mir, dass ich noch ein
thema aufmache.
Ich würde gerne besser erkennen welche Microcontroller für meine Wahl am
geeignet sind( es soll ein handheld für 3d Grafik werden)
Bisher weiss ich soviel. die Chips haben Power + - Ground, manche haben
integrierte USB schnittstellen.
Es gibt Daten in und out, die werden vermutlich mit Dioden nur in eine
Richtung funktionieren.
Dann haben die eine Takt frequenc und manche internen buffer.
die Controller gehören einer übergeordneten Familie an, wie arm und für
manch gibt es schon fertige Compiler, andere brauchen eine extra lib - c
, die Software bekomme ich beim Hersteller wenn es sich um im
Fachgeschäft erhältliche chips handelt und nicht um etwa um einen Chip
aus einer PSP oder einem Gameboy.
Aber es gibt auch Menschen, die Ihre eigene Bibliothek zum kompelieren
für die Architektur schreiben, dafür braucht man aber eine Lizenz vom
Hersteller.
Microcontroller wie Raspberry Pi Zero haben SPI Anschlüsse für ein LCD
Display.
Es gibt aber soviele Chips im handel und ich nicht meine Zeit mit
bildhen laden verschwendem möchte, weürde ich gerne Wissen, welche Daten
noch interessant sind und ob die oben beschriebennen Annahmen richtig
sind.
Fan T. schrieb:> Seltsam, dass ihr das nicht geschafft habt,... braucht es ein> spezieelles callada format? Ich frage, weil in blender callada(Default)> steht, oder werden die Animationen als extradatei geladen?
Nee, da ist schon Collada, aber Torque3D geht z.B. von einer recht
ungewöhnlichen Avatar Grundposition aus. In so gut wie allen Engines ist
das der 'Jesus am Kreuz', während Torque da eine Position a là
'schussbereiter GI' benutzt. Dann muss bei allen Waffenanimationen der
komplette Player mit geriggt werden und ergibt eine schier endlose Zahl
von Animationen - immerhin sinds in unserer Mod etwa 20 Waffen gewesen.
Ich bin kein grosser Animator und habe mich deswegen erstmal nur mit den
Avataren beschäftigt, was auch ganz gut geklappt hat, aber bei den
Waffen habe ich dann das Handtuch geschmissen. Ich bin eher Modeller,
Coder, AI Fuzzy und Texturentyp und bei Animationen nur rudimentär
begabt. Das C++ allerdings von Torque war sehr brauchbar und Schiffe in
die Engine zu bringen (gibts sonst in T3D nicht) habe ich in einer Woche
gemacht, plus grundlegende AI und unserem 'Conquest' Gamemode.
Fan T. schrieb:> ging es nicht, die Animationen per code zu interpolieren? Dass kann doch> jede Engine, oder?
Nee, das geht nicht. Bei T3D sind das Sequenzen mit 1/30 Sekunde pro
Frame und man blickt auch nicht durch. Du kannst nämlich nicht etwa die
Waffe mit in die Szene importieren, sondern bewegst nur einen Haufen von
Dummies durch die Gegend. Das ist etwas ungeschickt und z.B. bei BF2
viel einfacher und übersichtlicher, aber auch da wird nicht per Code
interpoliert, sondern in 3DSMax Framesequenzen gemacht. Max selber kann
dann allerdings zwischen Keyframes interpolieren.
Merkwürdig ist bei T3D auch, das selbst die Lenkung von Rädern (Autos)
und die Federung derselben Animationen sind - da muss man sich erstmal
dran gewöhnen und ist gar nicht zu vergleichen mit z.B. FarCry oder BF2,
wo sowas per Skript/Code gemacht wird.
Also ich würde ein Multiplayerparkur machen, bei dem das Level die die
"waffe" ist.
Der erste Am ziel hat gewonnen und im level könnte man objekte
verschieben und aktivieren um den anderen den perkur zu erschweren. man
kann da auch reaktions zeit brauchen um erfolgreich zu werden und eine
vorahnung haben, welches podest unter den füssen verschwindet oder
welche wege sich, durch das verändern des Level, durch die spieler,
kreuzen werden.
Fan T. schrieb:> Der erste Am ziel hat gewonnen und im level könnte man objekte> verschieben und aktivieren um den anderen den perkur zu erschweren.
Für sowas schau dir mal die RAPID Collision Library an.
http://gamma.cs.unc.edu/OBB/
Die habe ich mal auf den Nintendo portiert und läuft prima zur
Kollisionserkennung, sowohl damit man nicht durchs Terrain fällt als
auch für Wände usw.
Du fütterst die Library mit den Tris deiner Welt und einem vereinfachten
Kollisionsmodell des Players. Anfragen an RAPID beantwortet die Library
dann entweder sehr schnell mit 'no Collision' oder mit der Anzahl der
Kollisionen. Denkbar wäre auch eine Erweiterung, um Kollisionen mit
verschiedenen Materialien zu erkennen.
Bei mir war das einfach, da ich praktisch nur Boden und Wände hatte.
Meine Player Kollision hatte immer die gleiche Orientierung und ich habe
(war einfacher) beim Umdrehen die Welt gedreht. So wusste ich immer, wo
der Player kollidiert (vorne hinten rechts links unten) und habe dann
einen kleinen Gegenimpuls auf die Bewegung des Spielers gegeben. So
konnte man auch Abhänge hoch und runterlaufen. Sogar ducken hatte ich
mit drin.
Kollision erledigt. Die Level habe ich damals mit 3DSMax und einem
kleinen selbstgeschriebenen Exporter gemacht. Die Material ID habe ich
für die Art der Textur genommen (Wände/Boden)
hm, ich wollte eigentlich gerne in c oder java programmieren, aber die
haben den c support eingestellt
und kann sein, obwohl das system sogar mit 90 MHz R8000 CPU, 512 MB
läuft, dass es zu genau ist?
aber habe das nicht verstanden, weil da steht
"... RAPID is a OBB tree...
und ich habe gelesen:
OBB-Kollisionserkennung. OBB bedeutet 'oriented bounding box'
(ausgerichtete Begrenzungsbox) und stellt eine rechteckige Box
also doch nicht für polygonale erkennung?
Ausserdem konnte ich dann die cov.ps Datei nicht lesen.
die gab es hier zu:
ERRATA: The equations for the "infinitely densely" sampled triangles in
the second column of page 173 (of the SIGGRAPH '96 publication) are
incorrect. Here are the correct equations, but notice that we are using
the variable A for the area of a triangle, and the variable m denotes
the centroid of a triangle (which are different usages from those in the
paper).
Fan T. schrieb:> hm, ich wollte eigentlich gerne in c oder java programmieren, aber die> haben den c support eingestellt
Nee, da verwechselst du irgendwas - den Code in C gibts gegen eine
Anfrage per Mail an die Jungs, aber notfalls habe ich auch das Original
hier für MSVC und auch die an den Nintendo angepasste Version. (Version
2.0.1)
Für den DS habe ich die Endungen auf *.cpp umgestellt und den ganzen
Code für RAPID in eine Datei gepackt. Ausserdem alle 'double' auf
'float', damits schneller geht. Ich habe RAPID nur ein wenig erweitert,
damit es nach X Kollisionen zurückkehrt, denn mir reichte meistens schon
eine Kollision für meinen 'Wolf3D' Tester.
Als Projekt Grundlage habe ich damals Code von den
http://drunkencoders.com
benutzt, die schon OpenGL und z.B. Tastenabfragen gut gelöst hatten.
Dazu brauchte man allerdings eine Karte für DS Slot 2 und Homebrew
Software, das war bei mir die R4. Bei mir hat man den Spieler nie
gesehen, deswegen gabs auch keinen Avatar.
Das sind Dinge, die du für den STM32 noch brauchst. Als Grundlage für
eigene Projekte auf dem F429 ist Uwe B. immer eine gute Anlaufstelle:
http://mikrocontroller.bplaced.net/wordpress/?page_id=2736
der für alle möglichen Dinge auf dem F429 Disco schon nette Libraries
gemacht hat. OpenGL ist da allerdings nicht bei.
