Hinweis für Allergiker: Kann Spuren von Esotherik und fehlenden Fakten enthalten. Mathematisch habe ich mich leider verskillt, daher kann ich die Formel nicht auf Plausibilität prüfen. Ich bedanke mich aber an math.stackexchange.com für das Bereitstellen der Formel. Ich kann zumindest bestätigen, dass die Rückrechnung jedes Mal erfolgreich war. Es ist komplett fraglich, ob das ganze effizienter als der gewöhnliche RAM ist. Ich habe aber ein paar Tage lang recherchiert und zumindest ein Proof of Concept.
Hintergrund
Für gewöhnlich landen die meisten Daten des Game Makers im RAM. Der Game Maker speichert jedoch scheinbar Surfaces aus Geschwindigkeitsgründen im VRAM der Grafikkarte. Leider sind jegliche Interaktionen im VRAM dem User entweder verwehrt, oder gar nicht erst dokumentiert. Aufgrund der Umrechnung, bin ich mir nicht sicher, ob die schnelleren Zugriffsgeschwindigkeiten sich überhaupt lohnen.
Funktionsweise
Um eigene Informationen (bevorzugt Integer) im VRAM ablegen zu können, greife ich auf folgenden Trick zurück:
Der Integer wird als Pixel dargestellt. Der Game Maker kann Pixel in einem Surface speichern. Ein Surface liegt im VRAM -> Jackpot!
An dieser stelle ist mal dahingestellt, ob die Umrechnung nun die tatsächliche Zeitersparnis des Zugriffs wieder gutmacht.
Theoretische Anwendungsmöglichkeiten sind: Poligone/Vertexe (3D Modelle) o.Ä.
Da RGB nur 256^3 Farben darstellen kann, darf der Integer auch nicht 256^3 überschreiten! Floats werden nach meinen Kenntnissen im GM gerundet.
Zuerst wird der Integer in einen rgb-Wert umgewandelt:
GML-Quellcode
- /*int2rgb
- Script converts any integer below 256^3 into an three values: r, g, b
- by domis4, thanks to math.stackexchange.com for the formular.
- */
- var integer, color;
- integer = argument0;
- r = integer div (256*256);
- g = integer div 256 mod (256*256);
- b = integer mod 256;
- color = ds_list_create();
- ds_list_add(color, r);
- ds_list_add(color, g);
- ds_list_add(color, b);
- return color;
die Rückrechnung von rgb zu integer:
GML-Quellcode
Beispiel eines Speicher und Ladevorganges:
GML-Quellcode
- integer = 1958; //integer to store in surface
- show_message("integer: "+string(integer)) //output integer
- color = int2rgb(integer); //create rgb color from integer
- w = 1; //width of surface
- h = 1; //height of surface
- r = ds_list_find_value(color, 0); //save red from integer
- g = ds_list_find_value(color, 1); //save green from integer
- b = ds_list_find_value(color, 2); //save blue from integer
- show_message("red: "+string(r)+string(" green: ")+string(g)+string(" blue: ")+string(b));
- pixel = make_color_rgb(r, g, b); //create pixel from integer colors
- surface = surface_create(w, h); //create surface
- surface_set_target(surface); //target surface
- draw_point_color(0, 0, pixel); //draw pixel to surface
- surface_reset_target(); //reset target
- getpixel = surface_getpixel(surface,0,0); //get pixel from surface
- r_new = color_get_red(getpixel); //get red from pixel
- g_new = color_get_green(getpixel); //get green from pixel
- b_new = color_get_blue(getpixel); //get blue from pixel
- show_message("surface red: "+string(r_new)+string(" green: ")+string(g)+string(" blue: ")+string(b));
- newinteger = rgb2int(r_new, g_new, b_new);
- show_message("integer from surface: "+string(newinteger));
Ein Beispielprojekt (GM8):
vramtest.zip
speichert einen Integer in den VRAM und lädt ihn wieder heraus.
Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von domis4 ()