 |
Das deutsche QBasic- und FreeBASIC-Forum
Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
|
| Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
| Autor |
Nachricht |
mkfezzo
Anmeldungsdatum: 16.08.2007
Beiträge: 25
|
 Verfasst am: 17.12.2007, 13:04 Titel: point(x,y) in rgb-werte aufsplitten? |
 |
|
Hallo zusammen,
ich versuche meine Urlaubszeit mal ein wenig dazu zu nutzen um ein bisschen zu proggen.
Mein aktuelles Problem:
Wenn ich ein Farbwert per point(x,y) abfrage, wie kann ich diesen Farbwert (Grafikscreen: screen 19,32,,) wieder in rgb-form aufsplitten?
z.B.:
screen 19,32,,
pset(100,100),rgb(200,200,200)
c=point(100,100)
nun möchte ich den in c gelesenen wert z.B. dunkler machen,
was ja nu nicht funktioniert:
pset(100,100),rgb(c-20,c-20,c-20)
Wie macht Ihr soetwas? |
|
| Nach oben |
|
 |
AndT
Anmeldungsdatum: 02.04.2007
Beiträge: 481
|
| Verfasst am: 17.12.2007, 14:51 Titel: |
|
|
RGB Würde ich so Splitten
Erkennt aber manchmal fehlerhaft..
| Code: | type pixel
r as ubyte ' rot
g as ubyte ' grün
b as ubyte ' blau
a as ubyte ' alpha (nicht notwendig)
end type
function hexrgb (byval x as integer,byval y as integer) as string
dim as integer mycol = point(x,y)
dim as string rgbhexcode = HEX(mycol)
function = "&h" & rgbhexcode
end function
dim shared as pixel dieserpixel
sub scanpixel (byval x as integer ,byval as integer)
dim as string pix = hexrgb(x,y)
dim as ubyte r,g,b
dieserpixel.r = val ("&H" & miD(pix,3,2))
dieserpixel.g = val ("&H" & miD(pix,5,2))
dieserpixel.b = val ("&H" & miD(pix,7,2))
end sub
screen 18,32
pset(100,100)
scanpixel(100,100) ' Pixel Scannen
print "r=";dieserpixel.r
print "g=";dieserpixel.g
print "b=";dieserpixel.b
sleep
|
_________________
Bis irgendwann...  |
|
| Nach oben |
|
|
mkfezzo
Anmeldungsdatum: 16.08.2007
Beiträge: 25
|
| Verfasst am: 17.12.2007, 17:20 Titel: |
|
|
Hi AndT!
Super, dieser Hinweis hat gefunzt! Habe Deine Code mal angepasst, da ne kleine Macke drinwar...aber nu läuft's! (und nach meinen Tests sogar zu 100%)
Danke für das KnowHow! Ich hab mir dabei vorher den finger im ohr abgebrochen - nix lief.
| Code: |
TYPE pixel
r AS UBYTE ' rot
g AS UBYTE ' grün
b AS UBYTE ' blau
a AS UBYTE ' ALPHA (nicht notwendig)
END TYPE
FUNCTION hexrgb (BYVAL x AS INTEGER,BYVAL y AS INTEGER) AS STRING
DIM AS INTEGER mycol = POINT(x,y)
DIM AS STRING rgbhexcode = HEX(mycol)
FUNCTION = "&h" & rgbhexcode
END FUNCTION
DIM SHARED AS pixel dieserpixel
SUB scanpixel (BYVAL x AS INTEGER ,BYVAL y AS INTEGER)
DIM AS STRING pix = hexrgb(x,y)
DIM AS UBYTE r,g,b
dieserpixel.r = VAL ("&H" & MID(pix,5,2))
dieserpixel.g = VAL ("&H" & MID(pix,7,2))
dieserpixel.b = VAL ("&H" & MID(pix,9,2))
END SUB |
|
|
| Nach oben |
|
|
AndT
Anmeldungsdatum: 02.04.2007
Beiträge: 481
|
| Verfasst am: 17.12.2007, 18:12 Titel: |
|
|
Einfach mal die Maus im Fenster von Links nach rechts bewegen oder von oben nach unten bewegen..
Alle anderen Richtungen bleiben einfach Weiss 
| Code: | TYPE pixel
r AS UBYTE ' rot
g AS UBYTE ' grün
b AS UBYTE ' blau
a AS UBYTE ' ALPHA (nicht notwendig)
END TYPE
DIM SHARED AS pixel thispixel
FUNCTION hexrgb (BYVAL x AS INTEGER,BYVAL y AS INTEGER) AS STRING
DIM AS INTEGER mycol = POINT(x,y)
DIM AS STRING rgbhexcode = HEX(mycol)
FUNCTION = "&h" & rgbhexcode
END FUNCTION
SUB scanpixel (BYVAL x AS INTEGER ,BYVAL y AS INTEGER)
DIM AS STRING pix = hexrgb(x,y)
DIM AS UBYTE r,g,b
thispixel.r = VAL ("&H" & MID(pix,5,2))
thispixel.g = VAL ("&H" & MID(pix,7,2))
thispixel.b = VAL ("&H" & MID(pix,9,2))
END SUB
screen 18,32
dim as integer mx,my
Print "Verlassen mit ESC"
getmouse mx,my
do
getmouse mx,my
sleep 10
locate 15,1
scanpixel(mx,my)
thispixel.r-=1
thispixel.g-=2
thispixel.b-=3
line(mx,my)-(mx+15,my+15),rgb(thispixel.r,thispixel.g,thispixel.b),bf
loop until multikey (&h01)
|
_________________
Bis irgendwann... |
|
| Nach oben |
|
|
mkfezzo
Anmeldungsdatum: 16.08.2007
Beiträge: 25
|
| Verfasst am: 17.12.2007, 19:06 Titel: |
|
|
hehe, genau für solche Spielereien kann man diese Funktion gut gebrauchen. Werde mal ne menge damit rumspielen (kann ich gut für mein laufendes Projekt gebrauchen).
|
|
| Nach oben |
|
|
Jojo
alter Rang
Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte
|
| Verfasst am: 17.12.2007, 19:23 Titel: |
|
|
oh mein gott, wie umständlihc, rechenintensiv und falsch!
AndT, echt, das muss ich endlich mal sagen, dein code ist einfach zum 
Sowas geht nicht per langasmer string-manipulation, sondern per berechnung:
| Code: | SUB int_to_rgb(col AS UINTEGER, BYREF r AS UBYTE, BYREF g AS UBYTE, BYREF b AS UBYTE)
r = col SHR 16
g = col SHR 8
b = col
END SUB |
bitte diesen code verwenden, ist extrem effizient und auch fehlerfrei
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
 |
|
| Nach oben |
|
|
jensma
Anmeldungsdatum: 16.05.2005
Beiträge: 85
Wohnort: Gleich neben Frankfurt, zwei Zimmer neben Lloyd!
|
| Verfasst am: 18.12.2007, 08:32 Titel: |
|
|
| Jojo hat Folgendes geschrieben: | oh mein gott, wie umständlihc, rechenintensiv und falsch!
AndT, echt, das muss ich endlich mal sagen, dein code ist einfach zum
...
bitte diesen code verwenden, ist extrem effizient und auch fehlerfrei |
Ja, genau, mit dem Code war mir letztens auch bestens geholfen 
Und bei AndTs Lösung habe ich mich grade bis in die hinterste Ecke meiner Wohner gelacht xD |
|
| Nach oben |
|
|
mkfezzo
Anmeldungsdatum: 16.08.2007
Beiträge: 25
|
| Verfasst am: 18.12.2007, 12:38 Titel: |
|
|
Hmmm. OK - @JoJo:
Deine Funktion sieht natürlich kurz und effektiv aus, werde diese auch gleich mal antesten. Mir ging es auch in erster Linie darum, überhaupt einen Lösungsansatz zu bekommen. Ich hatte ja nicht nach der perfekten Lösung gefragt. Und wenn man überhaupt so gar nicht weiterkommt ist es echt klasse überhaupt einen Lösungsansatz zu bekommen. Daher finde ich es etwas schade jemandem zu sagen sein Hilfsangebot sei "zum kotzen". Irgendwie muss ich sogar sagen AndT's Methode ist verdammt kreativ - ich konnte die Schritte nachvollziehen und habe dadurch begriffen wie ich das Ding hinkriegen kann (sonst hätte ich die kleinen Fehler in der Funktion nicht verbessern können). Das das besser geht steht gar nicht zur Debatte. Aber erst musst Du das Vorgehen mal kapieren um etwas zu verbessern.
Also Danke an AndT (für die logik) und Jojo (für die optimierte Fassung)!  |
|
| Nach oben |
|
|
croco97
Anmeldungsdatum: 04.11.2005
Beiträge: 260
|
| Verfasst am: 18.12.2007, 14:00 Titel: |
|
|
@mkfezzo:
Jojo's Reaktion klingt für jemanden, der AndT so noch nicht kennt, ziemlich arrogant. Aber ich kann Jojo verstehen, wenn man sich das da mal durchliest:
http://forum.qbasic.at/viewtopic.php?t=4470
AndT begegnet hier nur den Maßstäben, die er sich selbst gesetzt hat. Für einen Anfänger ist der Code oben OK. Für jemandem, der sich selbst als der grosse Interpreter-/IDE-/Betriebssystembauer einschätzt, ist der Code einfach nur peinlich.
Grüsse!
Croco |
|
| Nach oben |
|
|
ThePuppetMaster
Anmeldungsdatum: 18.02.2007
Beiträge: 1839
Wohnort: [JN58JR]
|
| Verfasst am: 18.12.2007, 15:39 Titel: |
|
|
| Jojo hat Folgendes geschrieben: | oh mein gott, wie umständlihc, rechenintensiv und falsch!
AndT, echt, das muss ich endlich mal sagen, dein code ist einfach zum
Sowas geht nicht per langasmer string-manipulation, sondern per berechnung:
| Code: | SUB int_to_rgb(col AS UINTEGER, BYREF r AS UBYTE, BYREF g AS UBYTE, BYREF b AS UBYTE)
r = col SHR 16
g = col SHR 8
b = col
END SUB |
bitte diesen code verwenden, ist extrem effizient und auch fehlerfrei |
stimm ich dir zu ... is ja grausam,. so viel code, für so eine kleine aufgabe ...
naja...soweit ich das noch weis, is BitShifting nicht besonders effektiv ganz im gegenteil .. bei solch einer aufgabe ist es eher unsinnig (wenn man von optimierung redet) .. da is Logische Operation schneller z.B. mit Bitmaske und Division... SHR braucht (wenn ich mich richtig erinnere) bei 16 Bits 16 Instruktionen oder noch mehr ... 32 Instruktionen (müsst ich nochmal nachlesen)
BitShifting is eigentlich nur dann effektiv, wenn mit den Bits ansich gearbeitet wird, und das verschieben zeit spart, im gegensatz zur Bitmasken nutzung
MfG
TPM
_________________
[ WebFBC ][ OPS ][ ToOFlo ][ Wiemann.TV ] |
|
| Nach oben |
|
|
Mao
Anmeldungsdatum: 25.09.2005
Beiträge: 4409
Wohnort: /dev/hda1
|
| Verfasst am: 18.12.2007, 17:27 Titel: |
|
|
Ist aber, wenn man sich mal Bits & Bytes auseinander setzt, einfacher zu erkennen, als irgendwelche String-Hampeleien.
_________________
Eine handvoll Glück reicht nie für zwei.
--
 |
|
| Nach oben |
|
|
Jojo
alter Rang
Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte
|
| Verfasst am: 18.12.2007, 19:32 Titel: |
|
|
bitshifting sollte schneller als die division sein...
mkfezzo, um dir meine version zu verdeutlichen (ja, ich habe die QB-Hilfe noch komplett gelesen und weiß deswegen ein bisschen mehr über Paletten und co.):
Ein RGB-Wert setzt sich aus den Rot-, Grün und Blauanteilen zusammen, ist ja logisch.
Dabei wird er wie folgt berechnet:
RGB = R + 256 * G + 65536 * B
Auf die 256 bei Grün kommt man, da ja 256 graustufen möglich sind. die 65536 sind eben 256*256... Somit wird die Zahl bis aufs letzte Bit mit Farbwerten "gefüllt".
Logischerweise kommt man auf die original-Werte zurück, indem man nun wieder durch diese Zahlen teilt:
R = RGB MOD 256
G = RGB \ 256 MOD 256
B = RGB \ 65536 (MOD 256)
Mit bitshifting geht's noch eine ecke schneller
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
|
|
| Nach oben |
|
|
ThePuppetMaster
Anmeldungsdatum: 18.02.2007
Beiträge: 1839
Wohnort: [JN58JR]
|
| Verfasst am: 19.12.2007, 02:58 Titel: |
|
|
@jojo .. meinst du? ... hmm .. naja.. wie gesagt, hab mich lange nicht mit Bit operation beschäftigt, aber ich glaube, das ein Bitshift ziemlich viele zyklen braucht. im gegensatz zu einer division.
Soweit ich das weis wird bei einer "geraden" divisionen ein anderes verfahren angewenden,um die zahl zu teilen.
z.B.
Wenn ich 16 / 2 teile, wäre das ergebniss 8 ... Das kann man ähnlich wie dem Bitshift miteiner verschiebung erreichen. Aber, im Prozessor gibt es, wenn ich mich richtig erinnere, "vorlagen", die solche operationen extrem beschleunigen, udn auf 2 Instruktiionen beschränken.
Natürlich geht das nicht mit / 3 oder /5 .. es geht eben nur mit "geraden" teilungsfaktoren im bezug auf das Bit-system ... /1 / 2 /4 /8 /16 /32 ...
Darum wär es idealer, bei grösseren Werten, keine verschiebung um 8 oder 16 Bits zu nutzen, sondern eher der "umweg" über die BitMaske
(X AND 65281) / 256
(65281 = 1111111100000000)
Wier wird die Bitmaske auf ein Wert angesetzt. Das ist eine Logische operation, die der Prozessor mit einer Instruktion ausführen kann. Anschliessend die "gerade" teilung, welche wiederum in 1 oder 2 Instruktionen ausgeführt wird. Das ergebnis wäre eine beschleunigung von BitAnzahl - 3
MfG
TPM
_________________
[ WebFBC ][ OPS ][ ToOFlo ][ Wiemann.TV ] |
|
| Nach oben |
|
|
AndT
Anmeldungsdatum: 02.04.2007
Beiträge: 481
|
| Verfasst am: 19.12.2007, 11:28 Titel: |
|
|
SHR VS DIVISION:
| Code: | DIM AS DOUBLE t1,t2,t3,t4
DIM AS INTEGER a
CONST runden = 300000000
' Leerlauf
t1= TIMER
FOR i AS INTEGER = 1 TO runden
NEXT
t4 = TIMER - t1
' Division
t1=TIMER
FOR i AS INTEGER = 1 TO runden
a = 8 / 2
NEXT
t2=TIMER - t1
' SHR
t1=TIMER
FOR i AS INTEGER = 1 TO runden
a = 100000 SHR 16 ' Zahl egal..
NEXT
t3=TIMER - t1
? "LEERLAUF : ";
? USING "###.##";t4
? "DIVISION : ";
? USING "###.##";t2
? "SHR : ";
? USING "###.##";t3
? "SHR IST UM CA.";
? USING "###.##";t2-t3;
? " SEC. SCHNELLER ALS DIVISION"
SLEEP |
_________________
Bis irgendwann...
Zuletzt bearbeitet von AndT am 19.12.2007, 11:43, insgesamt 3-mal bearbeitet |
|
| Nach oben |
|
|
Bimi
Anmeldungsdatum: 03.12.2007
Beiträge: 66
|
| Verfasst am: 19.12.2007, 11:34 Titel: |
|
|
| ThePuppetMaster hat Folgendes geschrieben: |
naja...soweit ich das noch weis, is BitShifting nicht besonders effektiv ganz im gegenteil .. bei solch einer aufgabe ist es eher unsinnig (wenn man von optimierung redet) .. da is Logische Operation schneller z.B. mit Bitmaske und Division... SHR braucht (wenn ich mich richtig erinnere) bei 16 Bits 16 Instruktionen oder noch mehr ... 32 Instruktionen (müsst ich nochmal nachlesen)
BitShifting is eigentlich nur dann effektiv, wenn mit den Bits ansich gearbeitet wird, und das verschieben zeit spart, im gegensatz zur Bitmasken nutzung
MfG
TPM |
Äh...wie bitte?
Bit-Shifting ist neben logischen Operationen die schnellste die eine CPU ausführen kann und die Rechnung bei 16 Bit=16 Operationen - ich weiß nicht wo du die her hast.
SHL wird von Intel mit einem Latency von eins und einem Throughput von 0,33 angeben, sprich max 1 Taktzyklus atomare Ausführung und in drei EU gleichzeitig ausführbar - theoretisch als 3 SHL pro Takzyklus auf PP oder höher.
SHL und SHR zählen zu den schnellsten Befehlen und das seit jeher. Seit dem i486 ist die Ausführungszeit unabhängig der anzahl Bitverschiebung.
Das Ganze ist auch nachzulesen im
"Intel 64 and IA-32 Architectures Optimization Reference Manual", Dokumentnummer 248966
Ich habe ein Bitte an euch:
In Bezug auf Performance vergesst alle Dokumentationen die sich auf Pentium 1 oder früher beziehen. Seit der P6 Architektur im Pentium Pro und folgenden ist alles anders.
Die meisten Assemblerdokus und Tutorials sind irgendwo auf diesem Stand stehen geblieben.
| Code: |
DIM pixel AS UINTEGER
DIM r,g,b AS UBYTE
ASM
mov eax,[pixel] ; Pixel in EAX
mov [b],ah ; blau steht dann in highbyte, das lowbyte enthält den alpha
shr eax,16 ; oberes Wort runterziehen
mov [g],al ; gruen im lowbyte
mov [r],ah ; rot im highbyte
|
Stichwort effektiver Code:
...man käme nie auf die Idee die Werte zu Splitten und in Bytes abzulegen. Man bearbeitet immer das gesamte Langwort, weil man dann mehrere Komponenten auf einmal bearbeiten kann und ein Bytezugriff langsamer als ein Langwortzugriff ist!
Um nun auf das von mkfezzo gepostete Beispiel zurückzukommen - alle RGB-Werte um 20 dunkler machen:
20 = 0x14
Maske = 0x14141400 = 336860160
| Code: |
DIM pixel1 AS UINTEGER
ASM
mov eax,[pixel]
sub eax,336860160
mov [pixel],eax
END ASM
|
...gibt schöne Effekte wenn ein Farbwert < 20 ist....
Entweder also dafür sorgen das es keine Farbwerte unter 20 gibt...oder mmx verwenden, damit kann man auch gleich zwei Pixel auf einmal bearbeiten
| Code: |
DIM pixelarray AS INTEGER PTR
DIM pixelanzahl AS INTEGER
DIM maske(0 to 1) AS UINTEGER
ASM
mov eax,336860160 ' subtraktionsmaske laden
mov [maske[0]],eax ' und durch duplikation
mov [maske[1]],eax ' eine 64 Bit MAske bauen
movq mm1,[maske] ' in mmx register laden
mov ecx,[pixelanzahl] ' Anzahl Bildpunkte laden
shr ecx,1 ' durch zwei dividieren (weil immer zwei Bildpunkte pro durchlauf)
mov ebx,[pixelarray] ' Adresse pixelarray holen
L1:
movq mm2,[ebx] ' Daten laden ins mmx Register
psubq mm2,mm1 ' SIMD Operation - 64 Bit als 8 Bytes betrachten
movq [ebx],mm2 ' zurückschreiben
add ebx,8 'acht Byte weiter
loop L1 ' ecx decrementieren, zurück zu Label wenn ungleich 0
END ASM
|
Laufzeiten: movq 1, psub 2, add 1, loop 3
...macht in der Summe 8 Takte pro Durchlauf...oder bei einem 1 Ghz Rechner rund 500 Mio. bearbeiteter Bildpunkte/Sekunde.
Bei 1024*768 sind das über 600 Frames pro Sekunde...und das ohne Graphikhardware...
In der Praxis jedoch langsamer - da kommt kein Speicherbus mit...
Ps. Sourcecode aus der hohlen hand, nicht getestet, so oder so ähnlich halt...
_________________
Rechtbehelf:
Rechschreibverfehlungen, Vergehen an der Deutschen Sprache sowie Stabwechselverbuchselungen unterliegen dem Urheberrecht, sind voll beabsichtigt und fördern das aufmerksame Lesen. |
|
| Nach oben |
|
|
ThePuppetMaster
Anmeldungsdatum: 18.02.2007
Beiträge: 1839
Wohnort: [JN58JR]
|
| Verfasst am: 19.12.2007, 11:43 Titel: |
|
|
ok .. kann auch sein, das ich das mit der AVR Architektur verwechselt habe .. wie gesagt, bin mir nicht sicher, aber irgend wie hab ich das ziemlich fest im kopf, das in irgen deinem meiner verwendeten Prozessoren das Shifting ziemlich lahm is, im vergleich zur masken variante.
Hab ich wohl verwechselt ...
MfG
TPM
_________________
[ WebFBC ][ OPS ][ ToOFlo ][ Wiemann.TV ] |
|
| Nach oben |
|
|
AndT
Anmeldungsdatum: 02.04.2007
Beiträge: 481
|
| Verfasst am: 19.12.2007, 12:09 Titel: |
|
|
Wennman das Teil mal Startet, kann mann gesichter erkennen und zwar jedesmal beim Wechsel von hell nach dunkel. Allerdings schwächt sich der Effekt mit der Zeit ab..
| Code: | function pixelcalc (byval x as integer,byval y as integer,pixel1 as uinteger) as uinteger ' Berechnung
pixel1 -= rgba(1,1,1,1)
function = pixel1
end function
sub pixeleffect (byval x as integer,byval y as integer)
dim as uinteger col = point (x,y)' Farbe
dim as uinteger newcol
newcol = pixelcalc (x+1,y+1,col)
pset (x,y),newcol
end sub
const pixelsize = 120
screenres pixelsize,pixelsize
setmouse ,,0
RANDOMIZE 458415 ' FaceCode
' Mainloop
do
pixeleffect (int(rnd*pixelsize),int(rnd*pixelsize))
loop until multikey(&h01) |
_________________
Bis irgendwann... |
|
| Nach oben |
|
|
mkfezzo
Anmeldungsdatum: 16.08.2007
Beiträge: 25
|
| Verfasst am: 19.12.2007, 13:57 Titel: |
|
|
Diese Antworten haben doch glatt mal ein kleines Tutorial zu dem Thema ersetzt. Das letzte mal, das ich mich mit Bit-Operationen ernsthaft befasst habe war bei der Umstellung vom C116 auf den C64 (Was hat mich diese Kiste erst angekotzt (wo sind die Grafikbefehle geblieben?) und dann gefordert). Ich glaub damals gings um Sprites und Ansteuerung des Soundchips. Bin erst dieses Jahr von QB auf FB umgestiegen und komme echt nicht mehr aus dem Staunen heraus. Echt super leistungsfähig, dieses FB. Und ich arbeite mich erstmal wieder ein.
Danke für die ausführliche Hilfe! |
|
| Nach oben |
|
|
Mao
Anmeldungsdatum: 25.09.2005
Beiträge: 4409
Wohnort: /dev/hda1
|
| Verfasst am: 19.12.2007, 15:28 Titel: |
|
|
@AndT:
Bei solchen Dingen sollte man lieber nicht die Zeit messen, da du ja wahrscheinlich auf einem Multitasking-Betriebssystem arbeitest.
Funktioniert da schon genauer: http://www.freebasic-portal.de/index.php?s=tutorials&id=26&seite=1
_________________
Eine handvoll Glück reicht nie für zwei.
--
|
|
| Nach oben |
|
|
dreael
Administrator
Anmeldungsdatum: 10.09.2004
Beiträge: 2529
Wohnort: Hofen SH (Schweiz)
|
| Verfasst am: 19.12.2007, 16:20 Titel: |
|
|
Aus gutem Grund sollte man, wenn man zwischen 24 bpp und 32 bpp in Windows unter "Systemsteuerung"/"Anzeige", "Einstellungen" wählen kann, der Variante 32 bpp den Vorzug geben, weil dort ein Pixel in einem Rutsch und Speicheradresse verarbeitet werden kann. Ebenso sind auch aus gutem Grund Speicherstrukturen wie sog. Bitplanes wie in den 80er-Jahren noch bei den Videochips üblich heute praktisch ausgestorben, d.h. werden im PC-Bereich nur noch für DOS-Rückwärtskompatibilität bei VGA-Grafikkarten in den 16-Farben-Videomodi zur Verfügung gestellt.
Sonst zum Titelthema und Performance: An und für sich wäre dies ein Stück weit auch ein Fall für Typ-Casting (in C/C++ mit dem bekannten Cast-Operator "(typ *)Ausdruck" abgedeckt, in QB die gesamte MKx$()/CVx()-Funktionenfamilie), d.h. man bildet den RGB-TYPE-Record genau so ab, dass die Byte-Farbkomponenten korrekt im Speicher liegen. Falls FreeBasic über C/C++-ähnliche Pointer verfügt, müsste Typen-Casting problemlos möglich sein.
Typencasting ist aber generell kein schöner Programmierstil, wenn das Ganze möglich portierbar auf unterschiedlichen Plattformen sein soll, weil man dort doch sehr stark plattformspezifische Implementationseigenschaften ausnutzt. An dieser Stelle sind die FreeBasic-Gurus sämtlicher Plattformen nun gefragt, ob sich POINT() 100% identisch auf jeder Plattform (Winodws, Linux, UNIX, Mac usw.) verhält und nicht etwa, dass auf der einen der Rot-Anteil das niederwertigste Byte belegt, während auf einer anderen Plattform der Blauanteil oder gar Alpha-Kanal dort liegt.
_________________
Teste die PC-Sicherheit mit www.sec-check.net |
|
| Nach oben |
|
|
|
|
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
|
|
FAQ
Suchen
Mitgliederliste
Benutzergruppen
Registrieren
Profil
Einloggen, um private Nachrichten zu lesen
Login
