Hallo.
Tut mir leid für das Delay, aber mein Internetzugang macht zur Zeit Ärger....
Aber als erstes Luftholen.
Ich hatte so eine schöne, lange Antwort parat. Wollte sie abschicken und wurde zwischenzeitlich ausgeloggt.
Natürlich war mein Reply im Nirwana verschwunden.
Wenn man online schreibt und dann kein Ende findet.....
Aber jetzt:
@Nic
Ich glaube du verstehst FlipBuffers nicht.
Ich glaube, ich muss Dich leider enttäuschen...
Wenn du Drawing-Befehle wie 'Plot()', 'Circle()', 'DrawImage()', usw. oder
Sprite-Befehle wie 'DisplaySprite()' und Konsorten verwendest wird alles in
den Backbuffer gemalt, den man nicht sieht.
Und eben dieses will ich verhindern...
Ein Aufruf von 'FlipBuffers()'
"vertauscht" nun den Inhalt von Back- und Frontbuffer, damit das eben
gemalte mit einem mal sichtbar wird und man nicht den Aufbau der
einzelnen Sprites sieht.
Eben. Ich will den Aufbau sehen.
Und zwar aus dem Grund, weil man dann durch Timingroutinen dem Rasterstrahl während dieser den Screen überstreicht, Informationen quasi "anhängen" kann.
Damit sind Effekte möglich, die sich nie und nimmer durch die PB-Befehle (die ich im übrigen grösstenteils recht gut finde...) erreichen lassen.
Erst der spätere Spieler oder Anwender soll den Aufbau, wenn er denn störend ist, nicht sehen.
Ich als Coder will aber schon einen Tick mehr transparenten Biss als den Debug-Command...
Vertauscht wird natürlich nicht wirklich. Die Grafikkarte wechselt lediglich
das anzuzeigende Bild.
Genau diesen "Vorteil" will ich abschalten können.
Na, zum Thema vertauschen und DoubleBuffering:
Gibt es schon seit PET. Seit VC20. Seit C64. Seit Amiga. Seit ewig...
TURRICAN...jedem ein Begriff !?...läuft so wie es läuft einzig nur durch D-Buffering.
Das reine DoubleBuffering war und ist was für langsame Rechner.
(Und freilich auch für schnelle Rechner mit aufwendigen 3D-Routinen!)
Wenn ich beim C64 über $D018 sein Videoram umschalte, zeigt der VIC auch 'ne andere Map.
Natürlich wird die nicht hin und her kopiert.
Das würde ja den Vorteil des DB eventuell nicht nur wieder zunichte machen, sondern die CPU-Effizienz sogar noch
verschlechtern.
DoubleBuffering sollte ursprünglich ja einer leistungsschwachen CPU helfen, Informationen zeitlich so schreiben zu können, dass keine Grafikfehler, Blips oder DropOuts, vor allem aber Ruckler beim Scrollen die makellose Grafik stören.
Indem man ihr Gelegenheit gibt, in einen aktuell gerade nicht sichtbaren RAMbereich schreiben zu können.
So.
Wenn ich mir allerdings die 2D-Games ansehe (mein LieblingsGenre...), die mit 2/3/4 Ebenen ParallaxScrolling, Space Shooter mit 50 Gegnern,
Kollisionsabfrage, Musik usw. aufwarten, so dürfte ab einem 1GHz-Rechner das KOMPLETTE GAME Codemässig in den oberen,
also eh NICHT sichtbaren (!) Rasterzeilen von der CPU abgearbeitet worden sein.
Also inklusive Kollisionsabfrage, Scrolling, Punktezählen, Explosionen hochzählen, Musik/Sound spielen...
Der Prozessor ist also mit der GESAMTEN GameLogik fertig und beginnt wieder von vorne, noch BEVOR der
Rasterstrahl überhaupt den sichtbaren Bildschirmbereich erreicht !
Und dann noch DoubleBuffering ?
Überflüssig und störend.
(Es sei denn, die Betriebssysteme selbst sind dank ihres Vorhandenseins eine CPU-Bremse und müssen die unter ihnen laufenden,
armen Games unter die Obhut des DoubleBufferings stellen, um die eigene verpasste Codeoptimierung zu kaschieren...wie jämmerlich!)
Es gibt auch Möglichkeiten direkt in den Frontbuffer zu schreiben im
"Code, Tipps & Tricks"-Forum. Dazu wird aber nicht geraten, weil gerade
'FlipBuffers()' dazu da ist das Bild sich nicht aufbauen zu sehen.
(Hast Du'n Link, wo ungefähr? Ich suche schon selbst weiter, aber schneller gings mit Tip...)
Bei letzterem gebe ich Dir recht.
Aber die Option, einen SYNC ohne automatischen Screenswitch durchzuführen, müsste integriert werden.
Am besten so : VSYNC (Zeile) und HSYNC (Spalte)....oder gepackter: SYNC (Zeile, Spalte)
Fertig.
OHNE irgendwas anderes zu machen, als auf den Rasterstrahl zu warten.
WANN DoubleGebuffert wird, hat gefälligst der CODER zu entscheiden, NICHT die Sprache !
'Print()' ist ein Befehl für die Konsole. Mit ihm kann man in ihr einen String
ausgeben. Um eine Zahl auszugeben musst du 'Str()', 'StrF()', 'StrD()',
StrQ()', usw. in Verbindung mit 'Print()' verwenden.
Um auf einem Screen, Image oder Sprite eine Zahl oder einen String
auszugeben, musst du 'DrawText()' verwenden.
Beispiele dafür gibt es im Forum und der Hilfe ausreichend.
Ok, danke, werde mich mal durchlesen...
Debug ist nicht dazu gedacht, dem Anwender Informationen zu geben,
sondern nur für den Programmierer zu gebrauchen, der gerade sein
Programm "debugen" will. Der Befehl 'Debug' gehört demensprechende
nicht zur Programmiersprache, sondern zum zugehörigen Debugger und
ist deswegen auch für jeden nativen Typ wie Strings, Longs, Doubles, usw. ausgelegt.
Ein Disassembler ist nicht notwendig, da der Debugger von PureBasic das
ASM-Listing im Debugmodus kennt.
Schade, dass man den nicht einfach an/ausschalten kann in Debugger-Optionen...
'FlipBuffers()' tauscht wie gesagt die Bitmaps nicht wirklich, sondern linkt
nur entweder zu Front- oder Backbuffer. Außerdem macht dies die
Grafikkarte hardwareseitig und somit muss man sich keine Sorgen darum
machen.
Hardwareseitig macht die Karte das nur, weil der FlipBuffers()-Befehl in eine Assembler/Maschienenfolge umgewandelt wird, welche der Karte
den Befehl dazu gibt, dieses zu tun.
Im richtigen Modus muss dazu nur 1 Bit getoggelt werden.
Ich will mir keine Sorgen machen, aber als Programmierer die Kontrolle behalten.
Ich will mich "drum kümmern DÜRFEN".
Als Coder will ich keine Sprüche a la Bill Gates :
"Alles läuft von alleine".
"Sie haben zwar keinen blassen Dunst mehr, was genau Ihr Rechner macht..."
"...aber Hauptsache ist doch, Ihre eigentlich unwichtige und lächerliche E-Mail kommt an".
Alles , um das man sich in der sogenannten "neuen Schule" von heute "nicht mehr zu kümmern braucht",
entlastet das Gehirn des Programmierers, was zum Zellabbau führt.
Die Möglichkeit 'FlipBuffers()' einen Parameter zu übergeben ist
nichts anderes als SYNC oder nicht SYNC.
Leider nicht.
Denn FlipBuffers() mit oder ohne Parameter tauscht trotzdem die Bitmaps.
(Sorry: Lässt den Grafikchip eine andere Map darstellen...
)
Wäre eine weitere Option, z.B.
FlipBuffers (off,1,Zeile,Spalte), bzw. FlipBuffers(on,1)
o.ä. vorhanden, wäre dieser Befehl weitaus flexibler, mächtiger und Codingrelevant einfach binäriger.
Da du scheinbar von der "alten Schule" kommst, musst du jetzt eben
lernen, dass 'FlipBuffers()' besser ist als alles direkt auf den Screen zu
schreiben.
Ok. Hab' ich soeben gelernt. Dazu brauchte mein Gehirn wenige Nanosec.
Aber akzeptieren kann ich es nicht. Dazu müsste ich mich wieder dümmer machen.
Denn das Problem mit der alten Schule ist folgendes :
Wir, (die alten Schüler), haben gelernt, was technisch möglich ist.
Und wissen, wie man Funktionen realisiert, die nahe an der Flackergrenze der Transistoren liegt..
Und wissen daher, was unmöglich GEMACHT wurde.
Und es widerstrebt meinem Coder-Ego aufs verschärfteste, Dinge zu lernen, die vor 20Jahren technisch machbar waren und nach der
Millenium-GHz-Evolution plötzlich einen Rückschritt erleben, weil Funktionen schlicht nicht integriert werden.
Dazu zählt nicht nur das frei wählbare DoubleBuffering, sondern auch die Genialität des selbstmodifizierenden Codes.
Also während das Programm abläuft, Befehle und deren Parameter durch überschreiben in andere Befehle umzuwandeln.
Wird leider durch den Compiler verhindert. Dass heisst, man muss hinterher eh noch am Ass-Code knaupen.
(Damit gibt man seiner EXE nicht nur gewissen Hackerschutz, sondern auch Speed und eine individuelle Note...)
Und wenn ein Coder der Neuzeit auf diesem blockierten Standart sein Wissen aufsetzt, KANN er natürlich nicht wissen, welche
Möglichkeiten und Effekte er mit seinem Nicht-Wissen verpasst.
Und wird weiteren Coder-Generationen ebenso natürlich nichts von dem Wissen der "alten Schule" weitergeben können.
Und dies ist dann ein echter Wegfall von Wissen.
Besser wäre es also zu sagen :
Um die Neuzeit mit dem Wissen der Steinzeit zu veredeln, müsste man die PureBasic-Entwickler kontaktieren, diesen Befehl zu adden.
Ob dieser dann angewendet wird (er würde werden!), ist letztlich egal. Allein auf die Option, dieses tun zu können, kommt es an.
Aber danke für die Antwort, Greetz
@Kaeru Gaman
double buffering ist heutzutage (und schon seit den frühen 90ern) absoluter standard.
sorry, gewöhn dich dran, wenn dus erstmal drinne hast, wird dir die lösung gefallen.
Ich habs drinne.
Das es mir nicht gefällt, habe ich nie gesagt...
Ich will aber die WAHL, ob ichs benutze oder nicht.
Es erschwert definitiv einige Effekte.
(jaja...und vereinfacht einige, schon klar...)
wie Nic schon sagte, Print ist ein Consolen-Befehl.
aufm PC läuft alles über grafix, heutzutage wird nix mehr über Textmode gemacht.
es gibt keinen textspeicher mehr, alles ist grafix.
Naja, so gesehen gab's früher auch keinen Textmode.
Textmode war nur 'ne andere Ausleseart einer Map.
Die es erlaubte, Teile daraus zu codieren und als Zahl zu plotten.
Und somit je nach Verwendung Speicher zu sparen.
Aber ob nun ein "A" in einer Bitmap steht, oder vom Zeichengenarator aus der CharsetMap gelesen wird:
Das "A" hat durch sein Bitmuster genau den gleichen Speicherhunger...
das liegt einfach am OS, es existiert keine textoberfläche mehr seit Win98.
Obwohl jede Grafikkarte auch Text kann...
danke, Greetz
caddy
Der einzig wahre Label ist eine HEXe.
