Erfahrungen mit Speichergrenzen

Übersicht

BlitzBasic

Blitz3D

	okeppelm Betreff: Erfahrungen mit Speichergrenzen	Mi, Dez 17, 2014 9:55 Antworten mit Zitat
hallo leute! ich programmiere seit 3 jahren an einem sehr umfangreichen game! den code zu posten wäre bei ca. 50.000 zeilen nicht zielführend. fakt ist nur dass mir aufgefallen ist dass ab einer gewissen anzahl bzw. größe von geladenen texturen/bildern zum einen im window mode immer mehr texturen schwarz dargestellt werden (im vollbild modus ok!), und im vollbild modus ab einer gewissen grenze an bildern eine memory access violation ausgelöst wird. die geladenen bilder überschreiten jedenfalls wahrscheinlich die 1gb grenze (exakter wert nicht nachvollziehbar da availvidmem nicht korrekt angezeigt wird). mein rechner hat allerdings 12gb ram und 2gb videospeicher - ein überschreiten des verfügbaren rams schließe ich somit trotzdem aus. deshalb wollte ich euch um folgenden erfahrungsaustausch ersuchen: - was passiert in blitz3d bei überschreiten des verfügbaren speichers beim laden von grafiken? kommt memory access violation oder werden grafiken einfach verloren? - kann es sein dass beim laden sehr großer grafiken (>1024x1024) oder asymetrischer grafiken (zb. 8192x4096) eine memory access violation auftritt? gibt es hier unterschiede zwischen images und texturen? - kann durch das laden sehr vieler grafiken eine access violation auftreten da die festplatte noch "hinterher hinkt"? habe versucht mit delay etwas zeit zu geben, hat aber nicht funktioniert. hilft es es mit waittimer zu versuchen? - wird beim zweifachen laden von gleichen grafiken bzw. texturen auch der doppelte speicherplatz benötigt, oder behandelt das blitz3d intern intelligent (lädt zb. nur einmal und weißt gleiche speicheradresse zu)? - wenn einem entity zu große und viele texturen zugewiesen werden kommt auch eine memory access violation -> hilft es hier die texturen in mehrere segmente aufzuteilen und nur diejenigen zuzuweisen die gerade sichtbar sind und die anderen vom mesh zu entfernen? - kann es sein dass blitz3d zuviele grafiken auf einmal vom ram in den grafikspeicher legt (beit auto-management) und somit eine violation erzeugt? hilft es hier das auto-management zu übersteuern? danke für eure antworten!

okeppelm

Betreff: Erfahrungen mit Speichergrenzen

Mi, Dez 17, 2014 9:55
Antworten mit Zitat

hallo leute!

ich programmiere seit 3 jahren an einem sehr umfangreichen game! den code zu posten wäre bei ca. 50.000 zeilen nicht zielführend.

fakt ist nur dass mir aufgefallen ist dass ab einer gewissen anzahl bzw. größe von geladenen texturen/bildern zum einen im window mode immer mehr texturen schwarz dargestellt werden (im vollbild modus ok!), und im vollbild modus ab einer gewissen grenze an bildern eine memory access violation ausgelöst wird.

die geladenen bilder überschreiten jedenfalls wahrscheinlich die 1gb grenze (exakter wert nicht nachvollziehbar da availvidmem nicht korrekt angezeigt wird). mein rechner hat allerdings 12gb ram und 2gb videospeicher - ein überschreiten des verfügbaren rams schließe ich somit trotzdem aus.

deshalb wollte ich euch um folgenden erfahrungsaustausch ersuchen:

- was passiert in blitz3d bei überschreiten des verfügbaren speichers beim laden von grafiken? kommt memory access violation oder werden grafiken einfach verloren?

- kann es sein dass beim laden sehr großer grafiken (>1024x1024) oder asymetrischer grafiken (zb. 8192x4096) eine memory access violation auftritt? gibt es hier unterschiede zwischen images und texturen?

- kann durch das laden sehr vieler grafiken eine access violation auftreten da die festplatte noch "hinterher hinkt"? habe versucht mit delay etwas zeit zu geben, hat aber nicht funktioniert. hilft es es mit waittimer zu versuchen?

- wird beim zweifachen laden von gleichen grafiken bzw. texturen auch der doppelte speicherplatz benötigt, oder behandelt das blitz3d intern intelligent (lädt zb. nur einmal und weißt gleiche speicheradresse zu)?

- wenn einem entity zu große und viele texturen zugewiesen werden kommt auch eine memory access violation -> hilft es hier die texturen in mehrere segmente aufzuteilen und nur diejenigen zuzuweisen die gerade sichtbar sind und die anderen vom mesh zu entfernen?

- kann es sein dass blitz3d zuviele grafiken auf einmal vom ram in den grafikspeicher legt (beit auto-management) und somit eine violation erzeugt? hilft es hier das auto-management zu übersteuern?

danke für eure antworten!

	BladeRunner Moderator	Mi, Dez 17, 2014 10:08 Antworten mit Zitat
B3D benutzt DX7, daher hast Du da einiges an Einschränkungen. Maximale Texturgröße (iirc) ist 4096². Es kann auch sein dass der Texturspeicher in der Tat auf 1 GB begrenzt ist, wobei ich das nicht mit Sicherheit weiß. Erneutes Laden weisst (auch hier iirc) auch erneut Speicher zu. Es ist also sinniger die Grafik durch eine interne Variablenzuweisungzu Kopieren, denn ein Handle kostet nur 4 Byte. Ansonsten empfehle ich gründlich zu prüfen wo Du Grafikkartenspeicher einsparen kannst, mit einem selbstgeschriebenen Dateimanagement vielleicht, welches nicht benötigte Grafiken aus dem Speicher entfernt (freeimage, FreeTexture). Was für ein Spiel wird es denn?
Zu Diensten, Bürger. Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3 Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64 B3D BMax MaxGUI Stolzer Gewinner des BAC#48, #52 & #92

BladeRunner

Moderator

Mi, Dez 17, 2014 10:08
Antworten mit Zitat

B3D benutzt DX7, daher hast Du da einiges an Einschränkungen. Maximale Texturgröße (iirc) ist 4096².
Es kann auch sein dass der Texturspeicher in der Tat auf 1 GB begrenzt ist, wobei ich das nicht mit Sicherheit weiß.
Erneutes Laden weisst (auch hier iirc) auch erneut Speicher zu. Es ist also sinniger die Grafik durch eine interne Variablenzuweisungzu Kopieren, denn ein Handle kostet nur 4 Byte.

Ansonsten empfehle ich gründlich zu prüfen wo Du Grafikkartenspeicher einsparen kannst, mit einem selbstgeschriebenen Dateimanagement vielleicht, welches nicht benötigte Grafiken aus dem Speicher entfernt (freeimage

, FreeTexture

).

Was für ein Spiel wird es denn?

Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3
Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64
B3D BMax MaxGUI
Stolzer Gewinner des BAC#48, #52 & #92

	DAK	Mi, Dez 17, 2014 12:02 Antworten mit Zitat
Hey, Mal zuerst zu den Speichergrenzen: B3D ist 32-Bit, das heißt, über mehr als 2 GB normalen RAM bekommt dein Programm nicht, egal wie viel RAM du eingebaut hast. Was genau das Grafiklimit ist, das weiß ich nicht, wird aber ziemlich sicher auch nicht höher sein, eventuell sogar weniger. Was genau passiert wenn du zu viel lädst, das weiß ich nicht, gefühlt sollte dort aber ein MAV kommen. Kannst du aber auch leicht ausprobieren. Einfach in einer Schleife ein Bild laden. Ja, große Bilder, und Bilder die nicht Zweierpotenzen als Kantenlänge haben können auf vielen Grafikkarten Probleme machen. Ist aber Grafikkarten-/Treiber-abhängig. 1024x1024 sollte aber noch ohne Weiteres gehen. Erst ab 2k oder 4k könnte es eventuell Probleme geben. Wenn du Grafiken mehrfach lädst, dann liegen sie mehrfach im Speicher. Jede der Grafiken könnte ja manuell von dir bearbeitet werden, deswegen macht B3D hier genau das was du sagst: die Grafik mehrfach laden. LoadImage ist blocking, das heißt, es hält das Programm beim Laden an, bis die Grafik fertig im RAM liegt. Festplattenlag macht hier also keine Probleme. @Zu viele Texturen pro Objekt: Meinst du, dass du zu viele Texturen als Layer auf das gleiche Surface packst, oder dass mehrere Surfaces unterschiedliche Texturen haben? Beim ersten Fall hast du einfach Pech gehabt, da kannst du direkt nicht so viel tun. Was man hier am Besten macht ist die Texturen soweit möglich im Vorhinein (z.B. mit GIMP) zu vereinigen, dann brauchst du nur mehr eine Textur. Beim zweiten Fall kannst du das Objekt in mehrere kleinere Objekte aufteilen. @Auto-Management: Ja, eventuell hilft es, dass du Grafiken explizit als Dynamic oder Scratch lädst.
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

Mi, Dez 17, 2014 12:02
Antworten mit Zitat

Hey,

Mal zuerst zu den Speichergrenzen:

B3D ist 32-Bit, das heißt, über mehr als 2 GB normalen RAM bekommt dein Programm nicht, egal wie viel RAM du eingebaut hast. Was genau das Grafiklimit ist, das weiß ich nicht, wird aber ziemlich sicher auch nicht höher sein, eventuell sogar weniger.

Was genau passiert wenn du zu viel lädst, das weiß ich nicht, gefühlt sollte dort aber ein MAV kommen. Kannst du aber auch leicht ausprobieren. Einfach in einer Schleife ein Bild laden.

Ja, große Bilder, und Bilder die nicht Zweierpotenzen als Kantenlänge haben können auf vielen Grafikkarten Probleme machen. Ist aber Grafikkarten-/Treiber-abhängig. 1024x1024 sollte aber noch ohne Weiteres gehen. Erst ab 2k oder 4k könnte es eventuell Probleme geben.

Wenn du Grafiken mehrfach lädst, dann liegen sie mehrfach im Speicher. Jede der Grafiken könnte ja manuell von dir bearbeitet werden, deswegen macht B3D hier genau das was du sagst: die Grafik mehrfach laden.

LoadImage ist blocking, das heißt, es hält das Programm beim Laden an, bis die Grafik fertig im RAM liegt. Festplattenlag macht hier also keine Probleme.

@Zu viele Texturen pro Objekt:
Meinst du, dass du zu viele Texturen als Layer auf das gleiche Surface packst, oder dass mehrere Surfaces unterschiedliche Texturen haben?
Beim ersten Fall hast du einfach Pech gehabt, da kannst du direkt nicht so viel tun. Was man hier am Besten macht ist die Texturen soweit möglich im Vorhinein (z.B. mit GIMP) zu vereinigen, dann brauchst du nur mehr eine Textur.
Beim zweiten Fall kannst du das Objekt in mehrere kleinere Objekte aufteilen.

@Auto-Management:
Ja, eventuell hilft es, dass du Grafiken explizit als Dynamic oder Scratch lädst.

Gewinner der 6. und der 68. BlitzCodeCompo

	okeppelm	Mi, Dez 17, 2014 13:19 Antworten mit Zitat
hallo leute, vielen dank für eure rasche und kompetente rückmeldung! dh also ich hab einiges an optimierungsbedarf beim grafik- bzw. speichermanagement! das mit dem <bilder über loop laden bis speichergrenze erreicht> habe ich probiert: es scheint so dass eben hier (voererst) keine mav kommt aber offensichtlich grafiken verloren gehen da bei späteren operationen die grafik nicht mehr gefunden werden konnte. @bladerunner: es wird ein strategiespiel über den siebenjährigen krieg in europa und nordamerika (mix aus empire, siedler und hearts of iron). release sollte mitte 2015 sein. je nachdem wie ich die speicherthematik hinkriege wird die grafik halt besser oder schlechter werden @DAK: das hauptproblem ist der grafikload der kampagnenkarte (1024 x 512 vertices mit texturengröße gesamt 4096x2048 -> aufgeteilt in meshes 32 x 16 mit jeweils texturen von 128x128). hier hatte ich noch die idee nur diejenigen texturen den meshes zuzuweisen die gerade am schirm sichtbar sind und die restlichen über freetexture zu entfernen, so könnte ich größere detailtexturen auf dem gerade sichtbaren schirm anzeigen. müsste halt hier nach jedem scrollvorgang die grafiken entfernen und neue laden -> habt ihr hier erfahrung ob das sinn macht ständig freetexture und loadtexture im lfd. spielbetrieb zu verwenden?

okeppelm

Mi, Dez 17, 2014 13:19
Antworten mit Zitat

hallo leute,

vielen dank für eure rasche und kompetente rückmeldung! dh also ich hab einiges an optimierungsbedarf beim grafik- bzw. speichermanagement!

das mit dem <bilder über loop laden bis speichergrenze erreicht> habe ich probiert: es scheint so dass eben hier (voererst) keine mav kommt aber offensichtlich grafiken verloren gehen da bei späteren operationen die grafik nicht mehr gefunden werden konnte.

@bladerunner: es wird ein strategiespiel über den siebenjährigen krieg in europa und nordamerika (mix aus empire, siedler und hearts of iron). release sollte mitte 2015 sein. je nachdem wie ich die speicherthematik hinkriege wird die grafik halt besser oder schlechter werden Confused

@DAK: das hauptproblem ist der grafikload der kampagnenkarte (1024 x 512 vertices mit texturengröße gesamt 4096x2048 -> aufgeteilt in meshes 32 x 16 mit jeweils texturen von 128x128). hier hatte ich noch die idee nur diejenigen texturen den meshes zuzuweisen die gerade am schirm sichtbar sind und die restlichen über freetexture zu entfernen, so könnte ich größere detailtexturen auf dem gerade sichtbaren schirm anzeigen. müsste halt hier nach jedem scrollvorgang die grafiken entfernen und neue laden -> habt ihr hier erfahrung ob das sinn macht ständig freetexture und loadtexture im lfd. spielbetrieb zu verwenden?

	DAK	Mi, Dez 17, 2014 14:04 Antworten mit Zitat
Hab noch mal nachgeschaut, in der Dokumentation steht Folgendes: Zitat: Die Grafikkarte kann nur Texturen mit folgender Breite/Höhe verarbeiten: 1,2,4,8,16,32,64,128,256,512,1024. Wenn ein Bild eine andere Größe hat, dann wird es von BlitzBasic automatisch gestreckt. Dies bedeutet dann: -Geschwindigkeitsverlust -Unnötiger Speicherverbrauch -Qualitätsverlust Bei den Texturen die du da lädst hast du einen theoretischen Speicherbedarf von 1 GB (128x128 Meshes mit je 128x128 Texel zu je 4 Byte). Das ist eine ganze Menge. Mit FreeTexture/LoadTexture die Texturen verwalten wäre sinnvoll, allerdings langsam, da er haufenweise Texturen über die Festplatte laden muss. Eventuell kannst du die Texturen als Images im RAM halten (mittels Scratch-Modus). Immer wenn die Textur dann gebraucht wird, erstell mit CreateTexture eine neue leere Textur mit dem Modus 256 (im VRAM halten) und schreib dort die Textur aus dem Image rein. Somit kannst du den größeren Hauptspeicher nutzen und brauchst trotzdem nicht auf die Festplatte zugreifen. Bleibt dir haber hald nur mehr 1 GB für alles andere im RAM übrig.
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

Mi, Dez 17, 2014 14:04
Antworten mit Zitat

Hab noch mal nachgeschaut, in der Dokumentation steht Folgendes:

Zitat:

Die Grafikkarte kann nur Texturen mit folgender Breite/Höhe verarbeiten: 1,2,4,8,16,32,64,128,256,512,1024. Wenn ein Bild eine andere Größe hat, dann wird es von BlitzBasic automatisch gestreckt. Dies bedeutet dann:
-Geschwindigkeitsverlust
-Unnötiger Speicherverbrauch
-Qualitätsverlust

Bei den Texturen die du da lädst hast du einen theoretischen Speicherbedarf von 1 GB (128x128 Meshes mit je 128x128 Texel zu je 4 Byte).
Das ist eine ganze Menge.

Mit FreeTexture/LoadTexture die Texturen verwalten wäre sinnvoll, allerdings langsam, da er haufenweise Texturen über die Festplatte laden muss.

Eventuell kannst du die Texturen als Images im RAM halten (mittels Scratch-Modus). Immer wenn die Textur dann gebraucht wird, erstell mit CreateTexture eine neue leere Textur mit dem Modus 256 (im VRAM halten) und schreib dort die Textur aus dem Image rein. Somit kannst du den größeren Hauptspeicher nutzen und brauchst trotzdem nicht auf die Festplatte zugreifen. Bleibt dir haber hald nur mehr 1 GB für alles andere im RAM übrig.

Gewinner der 6. und der 68. BlitzCodeCompo

	okeppelm	Mi, Dez 17, 2014 15:16 Antworten mit Zitat
ok interessanter tipp. bis jetzt hatte ich die gesamten texturen den meshes am schirm zugewiesen. weißt du ob blitz3d hier bei auto-management nur die sichtbaren grafiken im vram hält und die nicht sichtbaren in ram verfrachtet? oder muss man das wirklich manuell machen wie von dir beschrieben?

okeppelm

Mi, Dez 17, 2014 15:16
Antworten mit Zitat

ok interessanter tipp. bis jetzt hatte ich die gesamten texturen den meshes am schirm zugewiesen. weißt du ob blitz3d hier bei auto-management nur die sichtbaren grafiken im vram hält und die nicht sichtbaren in ram verfrachtet? oder muss man das wirklich manuell machen wie von dir beschrieben?

	Silver_Knee	Mi, Dez 17, 2014 17:27 Antworten mit Zitat
Werden die Grafiken gemipmapt? Das kostest auch noch mal Speicher

Silver_Knee

Mi, Dez 17, 2014 17:27
Antworten mit Zitat

Werden die Grafiken gemipmapt? Das kostest auch noch mal Speicher

	okeppelm	Mi, Dez 17, 2014 20:01 Antworten mit Zitat
ich nutze hier eher den Alpha Kanal (bei Texturen). benötigt das wirklich mehr speicher? ich dachte die argb (ein integer wert je Pixel) enthält bereits 4 kanäle 256^4?

okeppelm

Mi, Dez 17, 2014 20:01
Antworten mit Zitat

ich nutze hier eher den Alpha Kanal (bei Texturen). benötigt das wirklich mehr speicher? ich dachte die argb (ein integer wert je Pixel) enthält bereits 4 kanäle 256^4?

	BladeRunner Moderator	Mi, Dez 17, 2014 20:13 Antworten mit Zitat
alpha <> mipmapping! Der Alphawert ist in der Tat in den Texels mit drin, eine MipMap hingegen verschlingt Extra RAM, da ja mehrere Texturen für das selbe Vertice im Speicher gehalten werden.
Zu Diensten, Bürger. Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3 Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64 B3D BMax MaxGUI Stolzer Gewinner des BAC#48, #52 & #92

BladeRunner

Moderator

Mi, Dez 17, 2014 20:13
Antworten mit Zitat

alpha <> mipmapping!
Der Alphawert ist in der Tat in den Texels mit drin, eine MipMap hingegen verschlingt Extra RAM, da ja mehrere Texturen für das selbe Vertice im Speicher gehalten werden.

Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3
Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64
B3D BMax MaxGUI
Stolzer Gewinner des BAC#48, #52 & #92

	DAK	Do, Dez 18, 2014 23:42 Antworten mit Zitat
Noch mal zur Erklärung, eine Mipmap ist eine Bildpyramide, wo die Texturen mit einem schönen Filter vorskaliert werden, womit sie auf größere Distanzen schöner ausschauen. Das macht das Bild um Einiges schöner. Alpha kostet dich nur was, wenn du zwischen rgb- und argb-Texturen wählen kannst. Ich bin mir nicht sicher, ob B3D rgb-Texturen kann, oder nur argb-Texturen. Solltest du auf reine rgb-Texturen gehen könntest, dann könntest du dir 1/4 des Speichers sparen. Ich weiß nicht, was B3D mit Managed Texturen macht, also wo die gespeichert werden. Ich würde allerdings nicht mit zu viel Intelligenz rechnen. Wahrscheinlich ist, dass Texturen, die gerade an kein Objekt gebunden sind in den RAM gezogen werden (und somit aus dem VRAM raus). Ich bin mir allerdings fast sicher, dass Texturen, die zwar gebunden sind, aber aber außerhalb des Bildschirms sind, nicht aus dem VRAM raus gezogen werden. In den meisten Fällen würde das nämlich keinen Sinn machen. In den meisten Szenen wandern Objekte oft schnell aus dem Bild und wieder rein. Jedes Mal die ganzen Texturen zwischen RAM und VRAM hin und her zu schupfen wäre hier viel zu Zeitintensiv. Wenn du ein speziell getrimmtes Speichermanagement haben willst, dann musst du es wohl selber machen.
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

Do, Dez 18, 2014 23:42
Antworten mit Zitat

Noch mal zur Erklärung, eine Mipmap ist eine Bildpyramide, wo die Texturen mit einem schönen Filter vorskaliert werden, womit sie auf größere Distanzen schöner ausschauen. Das macht das Bild um Einiges schöner.

Alpha kostet dich nur was, wenn du zwischen rgb- und argb-Texturen wählen kannst. Ich bin mir nicht sicher, ob B3D rgb-Texturen kann, oder nur argb-Texturen. Solltest du auf reine rgb-Texturen gehen könntest, dann könntest du dir 1/4 des Speichers sparen.

Ich weiß nicht, was B3D mit Managed Texturen macht, also wo die gespeichert werden. Ich würde allerdings nicht mit zu viel Intelligenz rechnen. Wahrscheinlich ist, dass Texturen, die gerade an kein Objekt gebunden sind in den RAM gezogen werden (und somit aus dem VRAM raus). Ich bin mir allerdings fast sicher, dass Texturen, die zwar gebunden sind, aber aber außerhalb des Bildschirms sind, nicht aus dem VRAM raus gezogen werden. In den meisten Fällen würde das nämlich keinen Sinn machen. In den meisten Szenen wandern Objekte oft schnell aus dem Bild und wieder rein. Jedes Mal die ganzen Texturen zwischen RAM und VRAM hin und her zu schupfen wäre hier viel zu Zeitintensiv.

Wenn du ein speziell getrimmtes Speichermanagement haben willst, dann musst du es wohl selber machen.

Gewinner der 6. und der 68. BlitzCodeCompo

	okeppelm	Mi, Dez 31, 2014 10:58 Antworten mit Zitat
hallo leute, danke für eure umfangreichen rückmeldungen. ich habe mal einige forschungsarbeiten mit ram ausnützung im task manager angestellt: aufgefallen ist mir dass geladenen texturen jedenfalls in den ram geladen werden und dort auch verbleiben (unabhängig davon ob sie dann später in den vram wandern oder nicht -> die vram nutzung konnte ich leider nicht eruieren -> siehe mutmaßungen dazu weiter unten). interessanter side-aspect dabei: lade ich ein image (beispiel 2048x2048 bmp) so benötigt das image fast den doppelten ram als durch laden des gleichen bmps mittels einer textur (33mb statt 16mb). gefühlsmäßig dürfte jede textur standardmäßig sowohl im ram als auch in den vram geladen werden, denn eine überschreitung des rams von 1gb war problemlos möglich, erst ab 1,3 gb gingen texturen bzw. grafiken verloren. wenn ich ermittelte 0,3 gb ram für variablen abziehe komme ich dann ziemlich genau auf die 1 gb vram grenze. dh. ein manuelles speichermanagement zwischen ram und vram dürfte sinn machen, so kann man zumindest noch die ram differenz zwischen 1gb und 2gb (abzgl. platz für variablen) nutzen...

okeppelm

Mi, Dez 31, 2014 10:58
Antworten mit Zitat

hallo leute,

danke für eure umfangreichen rückmeldungen. ich habe mal einige forschungsarbeiten mit ram ausnützung im task manager angestellt:

aufgefallen ist mir dass geladenen texturen jedenfalls in den ram geladen werden und dort auch verbleiben (unabhängig davon ob sie dann später in den vram wandern oder nicht -> die vram nutzung konnte ich leider nicht eruieren -> siehe mutmaßungen dazu weiter unten). interessanter side-aspect dabei: lade ich ein image (beispiel 2048x2048 bmp) so benötigt das image fast den doppelten ram als durch laden des gleichen bmps mittels einer textur (33mb statt 16mb).

gefühlsmäßig dürfte jede textur standardmäßig sowohl im ram als auch in den vram geladen werden, denn eine überschreitung des rams von 1gb war problemlos möglich, erst ab 1,3 gb gingen texturen bzw. grafiken verloren. wenn ich ermittelte 0,3 gb ram für variablen abziehe komme ich dann ziemlich genau auf die 1 gb vram grenze. dh. ein manuelles speichermanagement zwischen ram und vram dürfte sinn machen, so kann man zumindest noch die ram differenz zwischen 1gb und 2gb (abzgl. platz für variablen) nutzen...

	Eisbaer Betreff: re	Sa, Jan 03, 2015 16:17 Antworten mit Zitat
Inzwischen ist es auch Möglich den Quellcode von B3D einzusehen, somit sollte es möglich sein die Grenzen der Engine zu ermitteln.
Eigene Webseite: http://www.eisbaer-studios.de

Eisbaer

Betreff: re

Sa, Jan 03, 2015 16:17
Antworten mit Zitat

Inzwischen ist es auch Möglich den Quellcode von B3D einzusehen,
somit sollte es möglich sein die Grenzen der Engine zu ermitteln.

Eigene Webseite:

http://www.eisbaer-studios.de

Übersicht

BlitzBasic

Blitz3D

Nach Oben

BlitzBasic Portal

Erfahrungen mit Speichergrenzen

Betreff: Erfahrungen mit Speichergrenzen

Betreff: re