Ist die Ausrichtung des GP2X-Displays wie beim GP32?


d4rkm4r3

Still Fresh
Joined
Mar 18, 2003
Messages
98
Age
46
Das erste Byte bzw. Word im Grafikspeicher hat beim GP32 den Pixel unten links beeinflusst:
Ausrichtung GP32:

X
| Display
|
0---Y


Ist das Display vom GP2X genauso ausgerichtet?
 
The major problem is that my rendering routines are optimised for the GP32's weird frame buffer layout (bottom-left to top-right) so I'm going to have to re-write them for the GP2X as it has a normal frame buffer ( top-left to bottom-right).

hm..
 
Ich nehme an das war damals der Grund warum viele das gp32 hochkant gehalten haben?
Wenn jemand "zu faul" war oder es nicht geschafft hat das Bild zu drehen?
 
dedeibel said:
Ich nehme an das war damals der Grund warum viele das gp32 hochkant gehalten haben?
Wenn jemand "zu faul" war oder es nicht geschafft hat das Bild zu drehen?

und ich hab mich gewundert warum man beim GP32 Linux den GP32 hochkant halten muss :D

gp32linux.jpg
 
Wäre echt hilfreich zu wissen...

<r>Ich will, sobald ich mein gp2x in den händen halte, meine 3DEngine von GP32 zum GP2X portieren.<br/>
Zur Zeit schreibe ich die Grafikfunktion von C nach Assembler um. Da die Routinen alle "hard coded" sind wäre es echt hilfreich zu wissen wie die Ausrichung vom Display ist.<br/>
<br/>
Da die Assembler Version noch nicht fertig ist, gibt es auch noch keine Vorschau. <E>:)</E><br/>
<br/>
Aber für die alte Version: <URL url="http://d4rkm4r3.de/GPMM.zip"><s></s>d4rkm4r3.de/GPMM.zip<e></e></URL><br/>
Die alte Version hat noch einen ganz übelen "Function Overheat" durch den "Free Span Buffer" und den Object renderer.<br/>
In der FXE mit dem 3D-Gleiter kann man mit dem A-Button zwischen zwei Renderingarten wechseln. (NoLight und VertexLighting)</r>
 
hab gehört auf gp32x das man jetzt bei x/y (1/1) anfängt also oben links.
soll sogar einfacher und schneller zu programieren sein.
 
Also die neusten Aussagen von Squidge usw auf gp32x sagen das der Bildschirm diesmal richtigherum ist, und sich daher deutlich schneller ansteuern lässt.

Edit: Soll aus der 3dEngine auch ein Spiel werden? Noch Hilfe benötigt was 3d modelle angeht?
 
Julius said:
Also die neusten Aussagen von Squidge usw auf gp32x sagen das der Bildschirm diesmal richtigherum ist, und sich daher deutlich schneller ansteuern lässt.

Edit: Soll aus der 3dEngine auch ein Spiel werden? Noch Hilfe benötigt was 3d modelle angeht?

das mit dem "schneller ansteuern" ist so eine Sache :) , wenn es sich um einen Portierung handelt sicher, aber die Zeichenroutinen von mir sind extra auf das Display vom GP32 angepasst.

Aus der Engine soll eine art SDK/Library werden, also frei für alle. :)
Eine ganzes Spiel ist nicht in Planung, aber an ein paar einfache Vorlagen für eigene Spiele habe ich gedacht. Aber erst wenn die Engine steht.

modelle? Noch nicht, aber später sicher. :)
 
3D Engine ist ja mal sehr interessant. Auf dem PC programmiere ich im Moment mit der Beta von Coldsteel. 3D auf dem GP2x wäre sehr geil, was für Textur- und Modellformate werden denn unterstützt?
 
@Sebe:
Die Texturen sind noch RAW-Dateien, also nur die reinen Grafikdaten, ohne Header. Ich werde aber noch ein eigenes Grafikformat schreiben (wegen Mipmapping) und einen Konverter.
Das Modellformate ist auch ein eigenes Format. Modell einfach in Blender3D erstellen, als Wavefront-Object abspeichern und durch den Konverter jagen. Fertig! Animation werden noch nicht unterstützt.
 
Die Texturen sind noch RAW-Dateien, also nur die reinen Grafikdaten, ohne Header. Ich werde aber noch ein eigenes Grafikformat schreiben (wegen Mipmapping) und einen Konverter.
Das ist ja dann kein Problem, Gimp kann sehr viele Formate lesen und schreiben. Was mir erstmal eher Sorgen gemacht hat, war
Das Modellformate ist auch ein eigenes Format. Modell einfach in Blender3D erstellen, als Wavefront-Object abspeichern und durch den Konverter jagen. Fertig!
Als ich aber festgestellt habe, dass mein Nendo auch Wavefront .obj speichern kann war die Welt wieder in Ordnung :roll:
Animation werden noch nicht unterstützt.
Das ist kein Beinbruch (wir das noch eingebaut?). Es gibt ne Menge Spielideen, für die ein Animieren des Objekts nicht nötig ist (Stichwort: Lylat Wars) :wink:
 
@d4rkm4r3:

Ist es so schlau jetze aus C zu ASM zu optimieren, wenn der Port zum GP2X noch nicht mal begonnen wurde? Hast du ein paar mehr Detaisl zu deiner enigine? Ich habe erst vor ein paar Tagen den Dreamcast-port der Yeti 3d enigine für den GP2X fit gemacht. DIe läuft schon verdammt gut, leider ist es die üblich in-door cell-based engine. Leider sind die formate für texturen, models, etc. nicht sehr gutdokumentiert. Hast du vor den Source deiner engine bald frei zugeben? (GPL?) (http://gp2x.sector808.org/yeti2x.jpg danke an Woogal)
 
@synkro:
Ist es so schlau jetze aus C zu ASM zu optimieren, wenn der Port zum GP2X noch nicht mal begonnen wurde?
In erster Linie will ich erst einaml die Grafikroutien optimieren. Besonders wichtig sind mir da das Clipping und die Rotation.

Details:
8-Bit Rendering (Noch, 16-Bit Kommt)
Blending: Add, Sub, Mul, Mul*2, Transparenz 33% & 66% (über LUTs)
No-Lighting, Vertex-Lighting & Lightmaps
Free Span Buffer (vielleicht später noch Z-Buffer)
Frustum/Object Culling
...

ToDo:
Perspective Correction
Speed Up
etc...

Für die Statistik: :lol:
ca. 6900 Zeilen Code, davon ca. 660 in Assembler. :wacko:
davon (ca. 10% für debugging und testing)

Den Source Code werde ich vorerst nicht frei gegeben. Da einige GPL für PD halten.
 
Back
Top