ZFX + Developia

Verfasst: **27.03.2018, 15:41**

Sobald ich den Schaltplan habe, werd ich ne Projektvorstellung hier machen. Aber grundlegend einen sehr aufgebohrten GameBoy Advance

Verfasst: **27.03.2018, 15:57**

Klingt nach einem guten Standardprojekt. Cool! Ich kann mein Projekt auch bald mal hier vorstellen. Sollte in 2 Wochen hardware-komplett sein (Gehäuse; mein 3D-Drucker läuft heiß) und in 6-8 Wochen auch firmware-fertig.

Wenn du eh einen FPGA hast... wozu dann noch der Mikrocontroller? Eine Singlechiplösung mit größerem FPGA und Softcore scheint attraktiver :-O

Verfasst: **27.03.2018, 16:06**

Wenn du eh einen FPGA hast... wozu dann noch der Mikrocontroller? Eine
Singlechiplösung mit größerem FPGA und Softcore scheint attraktiver :-O

Der FPGA soll anwendungsabhängig konfigurierbar sein (also andere cartridge -> andere FPGA-Config). Das geht aber so recht schlecht, wenn der FPGA der ist, der den Code ausführt. Zudem möchte ich keine Zwangsnutzung des FPGAs haben, der ist im Standardmodus des Systems gar nicht "sichtbar"

Verfasst: **27.03.2018, 16:42**

Verstehe :-)
Brainfart: Kann man eigentlich einen FPGA in einem FPGA implementieren? :-D

Verfasst: **27.03.2018, 17:19**

Brainfart: Kann man eigentlich einen FPGA in einem FPGA implementieren? :-D

Soweit ich weiß ja, ein FPGA ist ja nix anderes als ein rießiger SRAM mit Ein- und Ausgängen anstatt Adressen

Verfasst: **29.03.2018, 00:06**

Hups. Ich hab grade mal noch polygon culling mit Frustum eingebaut...

Die Glitches sind massiv weniger geworden (die kommen aber auch nur davon, dass ich fast durch 0 teile....) und plötzlich rendert das ganze mit 2907 µs pro Frame. Nice!

Verfasst: **29.03.2018, 01:29**

Also bist du rund x10 schneller geworden? DurchCulling? Sollte nur 50% geben ^_^

Ich finde es zZ noch komisch, dass du zwischen den 3ecken Lücken hast. Die Vertices aneinanderliegender 3ecke sollten gleich sein, damit sollte auch die Seitenlinie der 3ecke identisch sein. Mit anderen Worten: man hat da eher Overdraw, aber keine Lücken. Hmmh.

Verfasst: **29.03.2018, 07:09**

DerAlbi hat geschrieben:Also bist du rund x10 schneller geworden? DurchCulling? Sollte nur 50% geben ^_^

Du meinst sicher durch Backface-Culling 50%, oder? Frustum-Culling kann ja je nach Szene mehr skippen.

Die Glitches sind massiv weniger geworden (die kommen aber auch nur davon, dass ich fast durch 0 teile....)

Clippst du nach der Projektion im Screen-Space? Denn im World-Space gegen das "echte" Frustum gibt's die nahe-0-Teiler ja eigentlich nicht. Das Problem kenne ich gut vom Line-Clipping in meinen Projekten, falls wir dasselbe meinen. Für Lines ist das natürlich noch trivial zu lösen. Aber ein Dreieck wäre im Rasterizer dann ja kein Dreieck mehr? Hm, wie macht man das denn eigentlich "richtig"?

Verfasst: **29.03.2018, 08:48**

joeydee hat geschrieben:Clippst du nach der Projektion im Screen-Space? Denn im World-Space gegen das "echte" Frustum gibt's die nahe-0-Teiler ja eigentlich nicht. Das Problem kenne ich gut vom Line-Clipping in meinen Projekten, falls wir dasselbe meinen. Für Lines ist das natürlich noch trivial zu lösen. Aber ein Dreieck wäre im Rasterizer dann ja kein Dreieck mehr? Hm, wie macht man das denn eigentlich "richtig"?

Ja, ich clippe grade im Screen Space (da ich das so oder so machen muss, um out-of-bounds-access zu vermeiden. Eigentlich wäre es sinnvoll, die Dreiecke gegen das "echte" Frustum zu clippen und wenn es ein dreieck eine der frustum planes schneidet, das dreieck daran "abschneiden" und in zwei dreiecke zu unterteilen (das hat DerAlbi ja auch schon vorgeschlagen)

DerAlbi hat geschrieben:Ich finde es zZ noch komisch, dass du zwischen den 3ecken Lücken hast. Die Vertices aneinanderliegender 3ecke sollten gleich sein, damit sollte auch die Seitenlinie der 3ecke identisch sein. Mit anderen Worten: man hat da eher Overdraw, aber keine Lücken. Hmmh.

Ich mach grade noch sehr viel Integer-Arithmetik ohne ordentliches runden. theoretisch müsste ich für den rechten vertices nach ceiling runden, für den linken nach floor und das gleiche nochmal für oben/unten, damit die dreiecke auf jeden fall deckungsgleich werden. bin mir aber ehrlich gesagt noch nicht ganz sicher, wo diese dünnen pixelglitches herkommen (könnte auch an der schnellere scanline-bestimmung liegen!)

Zum Thema Backface-Culling: Das sollte ich natürlich auch noch irgendwie mal implementieren, aber das wäre die letzte Sache, die ich machen würde (da ich ja so weniger impact habe, da ich weniger dreiecke zeichne)

Mal gucken, ob ich während der Action auch den Rasterizer verwende, das Spiel wird aber auf jeden Fall hauptsächlich mit dem Raycaster gebaut werden.

Grüße
Felix

Scheisse, ich hab meinen Zug verpasst :~

Verfasst: **29.03.2018, 14:36**

Eigentlich wäre es sinnvoll, die Dreiecke gegen das "echte" Frustum zu clippen und wenn es ein dreieck eine der frustum planes schneidet, das dreieck daran "abschneiden" und in zwei dreiecke zu unterteilen (das hat DerAlbi ja auch schon vorgeschlagen)

Wobei ich da nochmal in Erinnerung rufen möchte, dass ich mir hier nicht mehr komplett sicher bin, was schneller ist.
Da das Aufsetzen eines 3ecks zum Rendern recht rechenintensiv ist (die ganzen Ableitungen entlang des 3ecks benötigen Division) meinte ich auch, dass ein min/max pro Scanline, im Vergleich dazu dass man 1-3 weitere 3ecke prozessieren muss, recht gut sein könnte. Natürlich sollte man immer noch gegen Front- und Backplane schneiden (zwecks Korrektheit) und auch 3ecke aussortieren, die komplett außerhalb sind.
Das Schneiden gegen das Frustum hat auf jeden Fall auch keinen Spaß gemacht... das ist in meinem Code bei in VertrexPipeline.cpp bei CVertexPipeline::ClippTri. Die Funktion returnt false, wenn das 3eck komplett außerhalb ist (oder bei Culling), oder true, wenn was gezeichnet werden soll. In Fall eines Schnitts mit
dem Frustrum wird die retriangulierte Fläche den zu Zeichnenden VertexBuffer geschrieben. Vollständig geklappt hat das damals auch noch nicht.

Verfasst: **13.09.2018, 13:57**

Lang, lang ists her, aber das Projekt lebt noch:

LPC1768 mit 320x240x16bpp Display via SPI:

Verfasst: **13.09.2018, 15:00**

Huui, was ist denn da der Flaschenhals?
Ein 120MHz Cortex M3 sollte sowas fast flüssig rendern können; 24FPS bedeutet immer hin 65 takte pro Pixel.
Eine SPI mit ~30MHZ und DMA haut das auch mit 24FPS raus.
Der Backbuffer passt auch 2x in den Ram, also kann man SPI & DMA tatsächlich nutzen. Mit Texturen wird es zugegebener Maßen recht eng ^_^

Bekommst du Artefakte, wenn du die SPI hochdrehst?

Verfasst: **13.09.2018, 15:16**

Huui, was ist denn da der Flaschenhals?

Softfloat-Implementierung :P

Der Backbuffer passt auch 2x in den Ram, also kann man SPI & DMA tatsächlich nutzen. Mit Texturen wird es zugegebener Maßen recht eng ^_^

Nein, passt er nicht, da das Display ein 9-Bit-SPI fährt und damit benötige ich für DMA 16 bit pro symbol und zwei bis drei symbole pro pixel (damit sind wir bei max. 460800 Byte pro Framebuffer, was unsere verfügbaren RAM um das 5,625-fache für einen einzelnen Framebuffer übersteigt).

Mit 15 Megahertz SPI bekomm ich maximal 10 FPS hin, wären also 120 Cycles per Pixel @ 100 MHz, damit also 60-120 Befehle.

Ich werd am Wochenende ein bisschen tunen, fixed point arithmetik verwenden, wo es nur geht und n bisschen Prekalking machen, damit dürfte der Raycaster massiv schneller werden

Verfasst: **13.09.2018, 15:27**

Oha, das in Fixpunkt umzuarbeiten wird ein murx, aber das ist schon ok. Ich habe hier eine FP-Biliothek mit Lazy-Eval und multiply-add optimierung und so (C++14 oder so)
Falls du sowas nutzen magst, einfach sagen ^_^ ich update dann

Verfasst: **13.09.2018, 15:56**

Oha, das in Fixpunkt umzuarbeiten wird ein murx,

Das wird ca. so viel murx:

Code: Alles auswählen

// using real_t = float;
using real_t = fixed<16,16>;

Verfasst: **13.09.2018, 16:47**

Bis zur ersten Multiplikation. Hallo, Überlauf :-) Aber trotzdem ein cooles Projekt!

Verfasst: **13.09.2018, 18:31**

Ja, das finde ich auch nicht sonderlich durchdacht, da einfach ein FP16-Typ hinzusetzen.
Generell wird dir auch der Cortex M3 dankbar dafür sein, wenn du ein 16x16+32 machst, anstatt ein 32x32+64. Es ist also schon sinnvoll zu wählen, wo man wie viel fractional bits investiert. Texturkoordinaten z.B. brauchen z.B. eher mehr kommastellen als ganzzahlstellen und eventuell würde sogar unsigned short aussreichen. Vertices, könnten FP16 bleiben; die fertig transformierten screen-koordinaten allerdings brauchen ganz wenig kommastellen, da Pixel anzzahlich gemappt werden können (je nach dem wo du die umrechnung machst), Die zeilen-Interpolation um rauszufinden wo man gerade im 3eck ist, braucht wiederum nur die 1.0 als Maximalwert usw. Es ist überall im Code eine gesonderte Abwägung zu treffen wie der Datentyp dort einzusetzen ist.
Das Mixen von Präzisionen ist vor allem wichtig - ich hoffe, dass das dein Datentyp kann. Auch multiply-add optimierungen sind kritisch z.B. bei der Koordinatentransformation und allem wo man interpoliert.

Aber der Ansatz war bei mir nicht anders: ich hatte mir die verschiedenen Fixkommatypen hingebaut und konnte über ein #define einfach alles auf float setzen. Das lief dann äquivalent auf dem PC.

Nutzt du für Fixkomma auch etwas eigenes, oder irgendwas fertiges?

Verfasst: **14.09.2018, 15:36**

Fixed<16,16> und ein paar branches weniger:

Für Fixkomma nutz ich was eigenes, und mappe alle "teuren" ops auf float (sin, cos, atan)

Verfasst: **16.09.2018, 11:41**

Interessant, dass das so problemlos geht ^_^
Ich wollte schon auf die Wobbel in der Textur (Steinwand) hinweisen, aber die Float-Variante hat das irgendwie auch.
Weißt du, warum das so komisch ist?

ZFX + Developia

[Projekt] Basic3D / Irwin3D / Violent3D

Re: [Projekt] Basic3D / Irwin3D / Violent3D

Re: [Projekt] Basic3D / Irwin3D / Violent3D

Re: [Projekt] Basic3D / Irwin3D / Violent3D

Re: [Projekt] Basic3D / Irwin3D / Violent3D

Re: [Projekt] Basic3D / Irwin3D / Violent3D

Re: [Projekt] Basic3D / Irwin3D / Violent3D

Re: [Projekt] Basic3D / Irwin3D / Violent3D

Re: [Projekt] Basic3D / Irwin3D / Violent3D

Re: [Projekt] Basic3D / Irwin3D / Violent3D

Re: [Projekt] Basic3D / Irwin3D / Violent3D

Re: [Projekt] Basic3D / Irwin3D / Violent3D

Re: [Projekt] Basic3D / Irwin3D / Violent3D

Re: [Projekt] Basic3D / Irwin3D / Violent3D

Re: [Projekt] Basic3D / Irwin3D / Violent3D

Re: [Projekt] Basic3D / Irwin3D / Violent3D

Re: [Projekt] Basic3D / Irwin3D / Violent3D

Re: [Projekt] Basic3D / Irwin3D / Violent3D

Re: [Projekt] Basic3D / Irwin3D / Violent3D

Re: [Projekt] Basic3D / Irwin3D / Violent3D