PureBoard

Du könntest auch mehrere objekte in einem bitmap speichern, so spart man sich die größe der header des bitmaps.

16 / 3 = 5,3_


5 bit pro farbkanal... hmm
Geht eigentlich (theoretisch)

Speichere die bilder doch in einem anderen dateiformat ab !

16Bit geht mit BMP nicht, aber mit PNG. Und in Speicher sind sie immer in der Bildschirmschirmtiefe. Das ist notwendig, damit man auch schnell mit ihnen arbeiten kann...

macht denn PB das PNG format ?

im speicher in bildschirmtiefe ?

kann ich nicht erst sprites laden und dann den screen öffnen ?

oder im programmverlauf nen zweiten screen mit anderer farbtiefe öffnen und die selben sprites verwenden ?

wenn ich also 24bit BMPs in den Texturespeicher lade, und dann erst nen 16bit screen öffne.... ???

[EDIT] hab grad mal geguckt... anscheinend hab ich doch immer erst den screen geöffnet....
...wenn das zutrifft, wäre mein problem gar keins...

@BPI > PLS CONFIRM THIS <

[/EDIT]


mit gehts nicht um die dateien.. ich habe keine probleme, ne ganze CD .res files zu liefern...

ich will nur nicht den speicher den Grafikkarte zu sehr zubauen... nicht jeden hat 256MB (so wie ich)
... und das ziehen aus dem hauptspeicher dauert nunmal länger, und für Sprite3D muss das quellsprite in der grafikkarte sein, nicht im hauptspeicher...

@Robert
es gibt wirklich 16Bit grafik... siehe Desktopeinstellung HighColor statt TrueColor... ich hab mich früher mit 5bit pro farbkanal rumgeschlagen...

gegenüber 24bit farbe ist das halt ne 33% speicherplatzersparniss...
...bzw. 50% ggü. 32bit, wie's glaubich im Texture-mem steht...

wenns mir um die platte ginge, ich kann ja auch JPGSprite verwenden... aber im Texturenspeicher wird die wieder entpackt, bringt also Null.

also, nochmal zusammengefasst:

ich möchte meine bilder, die ich für einen 16bit Screen verwende, auch als 16bit Textures im Texture-Speicher der Grafikkarte haben.

Wird nicht hinhauen. Du mußt erst einen Screen erstellen und dann laden. Man kann ja auch Grafiken in Hauptspeicher auslagern und man sollte nicht alle Grafiken gleichzeitig laden, sondern nur die, die momentan benutzt werden.

danke.

ich werd sowieso nur die sprites laden, die ich momentan brauche, also die für game erst nach dem hauptmenu, und die vom hauptmenu wieder free'n.

bei mir gehts um forlgendes:

ich will im hauptmenu nen animierten hintergrund haben: einen sich drehenden planeten. damit das flüssig genug und nicht zu schnell ist, kann der sich pro frame nur weniger als 1 grad drehen. bei 1/2 grad drehung macht das zus. 720 frames... wenn der planet den halben screen einnimmt, ist das massig zuviel für 256MB

...ausserdem sollen im spiel selber auch drehende planeten vorkommen, ich hoffe mal, dass ich da mit weniger frames auskomme...

Kaeru Gaman hat geschrieben:ich will im hauptmenu nen animierten hintergrund haben: einen sich drehenden planeten. damit das flüssig genug und nicht zu schnell ist, kann der sich pro frame nur weniger als 1 grad drehen. bei 1/2 grad drehung macht das zus. 720 frames... wenn der planet den halben screen einnimmt, ist das massig zuviel für 256MB

...ausserdem sollen im spiel selber auch drehende planeten vorkommen, ich hoffe mal, dass ich da mit weniger frames auskomme...

Für sowas lädt man doch nicht 720 große Sprites ein.

Das Einfachste wäre hier doch diese Animation als Video
zu rendern und dann einfach das Video (auf einem Sprite)
im Hintergrund abzuspielen.
Ansonsten halt direkt mit 3D ran, wenn in Deinem Game
möglich. 1 Objekt und entsprechende Texture, statt 720
einzelne Sprites.

Die Video-Lösung ist für Dich aber bestimmt das Einfachste
und am schnellsten umzusetzen, wenn Du nur PB/2D benutzt.
Das (komprimierte) Video mit den 720 Frames ist doch auch
nicht größer als 720 Sprites einzeln gespeichert.

Wenn Du die Animation als einzelne Bilder hast (z.B. BMP),
dann kannst Du auch mal nach BMP2AVI oder so suchen -
damit kann man die Bilder ganz einfach zu einem Video
zusammenfügen.


Wenn ich mal davon ausgehe das Du die 720 Frames bei
72Hz darstellst, dann läuft die Anim 10 Sekunden.
Eigentlich sollte das aber auch bei 30 bis max. 50 FPS noch
flüssig genug sein. Damit hättest Du bei 10 Sekunden nur
300 - 500 Frames im Video, also im Durchschnitt halbiert.
Mußt mal probieren das Video mit 30 FPS zu rendern,
vielleicht reicht das ja schon. Wenn nicht, dann die FPS langsam
erhöhen, aber nicht gleich zu Beginn mit 72 FPS testen.

Solltest Du im Spiel wirklich auch so viele große 3D-Anims
haben, dann ist es ernsthaft an der Zeit mal zu überlegen
auch auf 3D umzusteigen. 2D ist nicht für alles geeignet, und
Du willst ja sehr viel 3D durch die Anims darstellen.

das mit dem video im sprite is ne gute idee.. BMP2AVI muss ich mir mal raussuchen, brauch ich schon lange...
generell wollte ich mit 30fps arbeiten, weil ich genügend zeit zum rechnen haben will, und das ist mir auch flüssig genug...

das mit der texture is mir schon klar... vergiss nicht, ich hab PB3.30...
und für 'ne texture auf nem Sprite3D muss es im kartenspeicher stehen...

...am liebsten wär mir DX9... das kann direkt sphären betexturen.. dann wäre ich diese sorge los...

die einfachste lösung jetzt scheint mir AVI im sprite zu sein... mal nachlesen ob 3.30 das schon kann...

(werde mir wohl ende der woche das PB mal updaten... kost mich halt...)
(vielleicht kauf ich auch ganz neu und verscheuer die 3.30...)

btw: ich brauche min 720 frames, weil sich sonst das ganze zu schnell oder zu ruckartig dreht... 1/2 winkelgrad drehung pro frame ist das absolute maximum... eigentlich wären mir 1440 frames lieber... aber mit avi ja kein problem...

so.... hab mir BMP2AVI runtergeladen...

klappt ganz gut, die 720 frames, die zusammen 540MB haben, haben als AVI gerade noch 3097KB (bzw. 21404 bei anderer codierung)
[ allerdings dreht sich der planet bei 30FpS noch etwas zu schnell... ich werd wohl doch auf 1440 Frames gehen]

...damit kann ich leben denk ich.... jetzt muss ich nurnoch den AVI in ein sprite bekommen, das wird noch mal spannend...

... hast du da nicht nähere tipps dazu, danilo ?

oh mein got !
Was soll das denn nur für ein spiel werden ?
Render adventure FX ?

Also:
Du basust deine erde aus einzelnen sprite 3d zusammen (europa 1 & 2 sprite .....)
Eben so wie eine 3d kugel, danach muss du etwas progen:

Die xy Position der einzelnen sprite3d punkte kann man sich mit der sin-cos ausrechnen !
Danach sollte man mit der sin oder der cosinus funktion die tiefe der einzelnen sprites bestimmen !
Und dann: z-sortierung !
Mit etwas hirnschmalz im schädel währe man auch selbst drauf gekommen !
Mann muss nur die einzelnen "texturen" der sprites laden, das wähen dann einig MB, stat ne halbe triliarde !

Danke !

Robert Wünsche hat geschrieben:Mit etwas hirnschmalz im schädel währe man auch selbst drauf gekommen !

danke, schatz, aber darauf bin ich auch schon selbst gekommen...
kannst du dir vorstellen, wie viele flächen so eine kugel haben muss, um meine ansprüche zu befriedigen ?
Ich habe im 3DGameStudio Weltraumspiel-Tutorial eine Kugel aus 600 Dreiecken... damit bin ich gerade so zufrieden...
...ausserdem hiesse deine methode nichts anderes, als eine 3D-Engine für PB zu basteln.. oder ?

der riesige, drehende planet ist nur für den Hintergrund des Hauptmenus

Danilo hat geschrieben:Das Einfachste wäre hier doch diese Animation als Video
zu rendern und dann einfach das Video (auf einem Sprite)
im Hintergrund abzuspielen.

sollte also eine lösung für AVI-on-Sprite geben....

den planeten als POVRay-Anim zu erzeugen ist für mich das einfachste... da kann ich mich richtig austoben, den Planeten wirklich **SCHÖÖÖÖN** zu machen. Die drehung ist dann nurnoch 'ne rotate-variable, und dann rechnet er eben mal 6 stunden für die 1440 BMPs (trotz Athlon XP3000+ mit 512MB RAM)

für die planeten im spiel hab ich ne easy lösung gefunden... da man hier die planeten von oben sieht, render ich jeden planeten-typ nur einmal, voll angeleuchtet, den Schatten lege ich als zweites sprite darüber...dann kann ich beide unabhängig von einander rotieren...(planet: tages-rotation ; Schatten: Jahres-rotation)

PS:

Robert Wünsche hat geschrieben:oh mein got !
Was soll das denn nur für ein spiel werden ?

so 'ne art 2D-Frontier (Elite)