PureBoard

Da möchte ich nun aber doch mal nachhaken!
Ich sehe Euren Ansatz, die Sprite3D-Funktionen zu benutzen, ja zunächst ein. Mit den Befehlen ist das Problem zweifellos zu lösen. Aber eines wundert mich doch. Das Super Nintendo (SNES) konnte Grafiken wunderbar rotieren lassen und sogar problemlos zoomen (ohne AA - klar). Wie hat es das gemacht? Damals wurde doch noch nicht mit Vektoren und 3D hantiert, oder? Es muss doch einen schnellen Algorithmus geben, der dies kann? Mich würde auch brennend interessieren, wie das gemacht wird - ohne Sprite3D!
Irgendwie muss das auch mit der 8bit Grafik zusammenhängen. Ich hatte mal eine Sprache (DIV), die konnte das auch - ohne 3D! Diese Sprache hat allerdings nur 8bit-Grafiken dargestellt.

Das geht auch in Software Flott, wenn man sich auf 256 Farben beschränkt. Dazu solltest du dir mal Sinusfunktionen genauer anschauen.

Man kann das ganze gut mit Lookup Tabellen beschleunigen, das kostet aber entweder sehr viel Präzision oder verhältnismäßig viel Speicher.
Die Beschränkung auf 8bit reduziert nur die nötige Datenmenge, hat also nicht direkt mit Optimierung des ganzen zu tun.

Ein sehr gutes Tutorial gibt es hier http://pixwiki.bafsoft.com/mags/5/artic ... sincos.htm

Das SNES hatte sowas natürlich nicht in Software gemacht, dazu war die *quälend* langsame 65816 mit 3,6 MHz getaktete CPU vieeeel zu lahm. Im SNES gab es dafür einen dedizierten Grafikbeschleuniger.

Das bedeutet, dass man mit dieser Technik (link) tatsächlich mit PB eine Bibliothek basteln kann, die ein Mode 7 von SNES simuliert, dass z.B. auf einem Pentium 2 problemlos und flüssig läuft?

Ja, das ist möglich. C-Code ist bei, den brauchst du eigentlich nur zu portieren. Ich hab vor ein paar Jahren sowas in C mit Allegro gemacht und das war trotz meines mangelnden Optimierungswissens auf meinem 800MHz PC rasend schnell. PB bietet dafür alles was notwendig ist und dazu ist sehr wenig notwendig... eigentlich nur zugriff auf den Framebuffer. Da sind wir dann auch schon beim Problematischen Teil: Point und Plot sind dafür zu langsam, du brauchst also einen Zeiger auf den Framebuffer und musst die Zeichenoperationen Manuell machen. Dafür brauchst du DrawingBuffer() und DrawingBufferPitch(). Klingt aber schwerer als es ist.

Alles klar, ich werde mich mal in die 3D-Materie einarbeiten und sehen ob ich das hinbekomme.... Ich danke Euch für die Tipps...

Bis denne,
Michael

STARGÅTE hat geschrieben:ich habe dabei festgestellt das auch kombinationen keine Probleme machen : 64*128 oder 512*32 ...

Fluid Byte hat geschrieben:Die Höhe und Breite einer Textur müssen nicht zwangsläufig identisch sein sondern nur ein Vielfaches von 2 sein.

...du meinst eine potenz von zwei....

CSprengel hat geschrieben:Meines Wissens nach kommt es auf die Grafikkarte an, so kann es passiern das 32 * 64 funktioniert, aber nicht auf allen Rechnern. Zumindest hab ich sowas in Erinnerung.

exactement!
...probier mal auf ner etwas älteren ATI nicht quadratische textures, da geht NIX
auf meiner GF2 hingegen konnte ich sogar ungerade Dimensionen verwenden, also z.b. 187x113

also, wer allgemeine funktionalität haben möchte (und das ist ja wohl allgemein der fall)
sollte sich an die vorgaben halten, dafür sind sie da.

Kaeru Gaman hat geschrieben:exactement!
...probier mal auf ner etwas älteren ATI nicht quadratische textures, da geht NIX

äm ist RADEON 7500 nicht alt genug ? das ding konnte noch nicht mal OpenGL.
Ich musste immer T+L einstellen wo andere Shader stehen hatten -.-
und da funzte diese Rechteckigen sachen

Aber ich stimme dir Zu, lieber auf nummer sichergehen und Quadratische Grafiken der größe 2^n*2^n nehmen

Also eine voll OpenGL1.3 fähige Grafikkarte sollte auch Rechteckige Texturen darstellen können, solange die Dimensionen zweierpotenzen sind und keine Seite länger als 256 Texel groß ist... soviel zur Theorie... wer immer mal wissen wollte, woher ATI ihren schlechten Ruf herhaben was Treiber angeht, der brauch sich darauf nur zu verlassen ^^