Optimales Bild-Dateiformat...

[hackball]

für nachladbares horizontales Scrolling suche ich. Eventuell könnte man auch supergroße Bilder auf der Grafikkarte direkt in den Speicher laden? Wäre das zu empfehlen? Oder lieber alles in Tiles aufteilen....

[Blackbird]

Ich würde Tiles bevorzugen, da hast du mehr Möglichkeiten

[Der Wanderer]

Was die beste Methode ist hängt ganz stark von deinen Rahmenbedingungen ab.

- Ziel Platform, System Vorraussetzngen?
- Beschaffenheit des Levels (stark Tile orientiert oder eher eine individuelle Grafik, wie werden die Level Grafiken erstellt?)

Grundsätzlich eignet sich KEIN bestehendes Grafikformat für horizontales Scrolling, da alle mir bekannten Formate die Bitmaps Zeilenweise ablegen, du bräuchtest aber Spaltenweise. Du kannst das hächstens in viele kleine Steifen aufteilen.

Unterm Strich kann deine Frage aber nut beantwortet werden, wenn du mehr Information bereitstellst.

[hackball]

Das Level ist ein riesiges langes Bild, die Objekte darauf sind animiert, aber es ist nicht aus wiederholbaren Tiles zusammengesetzt, d.h. wenn ich das Level nachladen würde, müßte ich das gesamte Bild in Tiles zerlegen, wovon keine doppelt sind. Also wäre es dahingehend keine Ersparnis. Gäbe es ein Bildformat, das Spaltenweise einlesbar ist, könnte man das Level Streamen, dachte ich mir so.
Tiles schneiden ist ja auch nicht sooo aufwändig, aber erfordert eben wieder ein paar Schritte mehr.

[Der Wanderer]

Wieviel Rechenleistung hast du denn zur Verfügung? Je weniger, desto härter muss optimiert werden, und je schlimmer wird der Code aussehen.

Ist das RTG only, oder auch Chipset? Sind die Grafiken Farb indiziert oder True Color?

Grundstäzlich musst du das Nachladen ja sowieso selbst implementieren. D.h ob das nun Tiles oder Stream etc. ist kommt für dich auf das gleiche raus. Tiles sind in dem Fall ja nur eine Art Streaming in Blöcken.
Disk Zugriff kostet viel Zeit. D.h. du kannst da snur für Systeme mit DMA machen. Ohne DMA wird es ruckeln.

Mein Vorschlag wäre, das Bild als RAW Daten spaltenweise abzulegen, und dann eben spaltenweise einzuladen. Das ist sehr simpel. Dann kann man weiter sehen wo optimierungsbedarf ist. (Make it work => make it right => make it fast)

[hackball]

Also Tiles kann ich wohl vergessen, da es sich ja nicht wiederholt. Außer, ich definiere Tiles einfach als "Scene". :-)
Das Nachladen/Streamen müßte ja auch mit dem Schreiben in den Bildspeicher (via OS) harmonieren müssen, ansonsten wäre das ja sinnlos. Das Laden an sich ist ja egal; allerdings wäre ein (offenes) Bildformat mit vertikaler Anordnung wünschenswert.

[Der Wanderer]

Wieviel Rechenleistung hast du denn zur Verfügung? Je weniger, desto härter muss optimiert werden, und je schlimmer wird der Code aussehen.

Ist das RTG only, oder auch Chipset? Sind die Grafiken Farb indiziert oder True Color?

Grundstäzlich musst du das Nachladen ja sowieso selbst implementieren. D.h ob das nun Tiles oder Stream etc. ist kommt für dich auf das gleiche raus. Tiles sind in dem Fall ja nur eine Art Streaming in Blöcken.
Disk Zugriff kostet viel Zeit. D.h. du kannst da snur für Systeme mit DMA machen. Ohne DMA wird es ruckeln.

Mein Vorschlag wäre, das Bild als RAW Daten spaltenweise abzulegen, und dann eben spaltenweise einzuladen. Das ist sehr simpel. Dann kann man weiter sehen wo optimierungsbedarf ist. (Make it work => make it right => make it fast)

[hackball]

Yeah, wie der Wanderer schon meinte: Als RAW ablegen. Also kein bestehendes Format, sondern etwas proprietäres. Wie immer. ;-)

Imageconverter muß ich dann selbst machen; kein Problem außer Zeit.

[Blackbird]

PerfectPaint kann RAW...

[hackball]

Schön :-)
Muß aber die Daten spaltenweise ablegen, kann PP das auch?