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.
:
Bearbeitet durch User
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?
Fan T. schrieb: > Hat der Hardware, die OpenGL unterstütz? oder ist das in der OS? Das weiss ich nicht genau, hab noch nie mit den Dingern gearbeitet. Hat jedenfalls ne GPU: https://jan.newmarch.name/LinuxSound/Diversions/RaspberryPiOpenGL/ Es gibt auch ein LCD, das man direkt anschliessen kann: https://www.raspberrypi.org/documentation/hardware/display/README.md Die Doku auf der Seite ist nicht gerade der Hammer...
> 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)
Fan T. schrieb: > Würdet Ihr mir einen günstigen fertigen controller mit einem screen > empfehlen? der braucht kein HDMI. STM32 Discovery: http://www.ebay.de/itm/STM32F429-Discovery-Kit-32F429IDISCOVERY-1-Stuck-/361623155657?hash=item54326b73c9:g:1CkAAOSw-KFXdRIt Der Bildschirm hat zwar nur 2,4", zum Testen sollte es aber reichen. Dürfte ohnehin die bessere Plattform für das Vorhaben sein. Mehr CPU-Leistung, mehr RAM, bessere Schnittstellen (u.a. speziell für Displayansteuerung).
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
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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)
:
Bearbeitet durch User
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.
ging es nicht, die Animationen per code zu interpolieren? Dass kann doch jede Engine, oder?
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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)
:
Bearbeitet durch User
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).
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.