PureBoard

Hallo.
Vorneweg : Bin Frischling in PureBasic.
Kann C64/Intel-Assembler und Basic.(...anscheinend nicht...)

Und mach' momentan Fehler über Fehler.


Direkt zur Frage :

1.

FlipBuffers() soll ja 2 Screens verwalten. Hauptbegründung: Spiele.
Wenn man aber keine 2 Screens braucht ?

Also wenn man gar keine andere Möglichkeit hat als diesen Befehl, dann ist das aber schlecht implementiert in PB.

Bin zu Lernzwecken am dem Vertikalshooter dran, der bei der Testversion von PB unter Code-Examples liegt.
Weaponex oder so heisst er.
Bei dem der Screen ohne den Flipbuffers() dunkel bleibt. Was aber Programmtechnisch unlogisch ist.
Gibt es denn echt keine andere Möglichkeit, auf die Austastlücke zu warten, um die Spielabläufe frametechnisch zu synchronisieren ?

Die 2d-Sprite Gegenerroutinen, Schussroutinen dürften auf meinem zwar alten, aber dennoch 2GHz-Rechner schnell genug ablaufen, so dass zeitlich garantiert keine Bufferung notwendig ist, sondern ein fehlendes
FlipBuffers() in diesem Fall ja sogar zur Funktionstörung führt.

Wenn FlipBuffers bei jedem Aufruf die Bitmap wechselt, dann müsste man den Befehl zu Beginn doch sooft aufrufen können, bis ein Bild zu sehen ist und dann die weitere Synchronisierung anderweitig durchführen können.
...es sei denn FlipBuffers macht intern einiges mehr als beschrieben....was gar nicht gut wäre.



2.
Kann man mit Print tatsächlich keine normale Zahl drucken wie in jedem anderen Basic-Dialekt auch ?
"PRINT C" um den Inhalt von C zu plotten geht nicht. Kann nicht wahr sein ?!
Wer kommt auf die Idee, DEBUG zu benutzen, um eine Zahl zu PRINTen?



3.
Wie kann ich mir nach einem Compiliervorgang mein Compilat, also
das aus meinem PB-Code resultierende Assemblerlisting ansehen ?
(Bitte jetzt keine Antwort wie "ei mit 'nem Disassembler.....).

Ich meine, ist in den Debuggeroptionen kein "echter Debugger", also ein Intel-Disassembler, zuschaltbar ?
Oder gibt es den nur in der Vollversion ?


Ich bin eigentlich sehr begeistert von PB, aber als Ass-Coder sind mir einige Funktionen doch sehr traurig implementiert.
(Warum kein SYNC-Befehl um auf den Rasterstrahl zu warten ohne jegliche Abhängigkeiten wie dämliches Bitmaptauschen...)


Ps: Mann möge mir Rechtschreibfehler verzeihen, jedoch sitze ich gerade im Internetcafe, welches mir am Geldbeutel hängt.

Grüsse an alle Codemacher.

Caddy

caddy6510 hat geschrieben:1. FlipBuffers

Ich glaube du verstehst FlipBuffers nicht.
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. Ein Aufruf von 'FlipBuffers()'
"vertauscht" nun den Inhalt von Back- und Frontbuffer, damit das eben
gemalt mit einem mal sichtbar wird und man nicht den Aufbau der
einzelnen Sprites sieht.
Vertauscht wird natürlich nicht wirklich. Die Grafikkarte wechselt lediglich
das anzuzeigende Bild.
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.

2. Print

'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.

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.

3. Assemblerlisting

Siehe unter Hilfe -> Benutzung des SHELL-Compilers
Oder schau mal bei PureArea vorbei. Dort sollten unter Tools für die IDE
schon komfortablere Programme zu finden sein.

Ich meine, ist in den Debuggeroptionen kein "echter Debugger", also ein Intel-Disassembler, zuschaltbar?

Ein Disassembler ist nicht notwendig, da der Debugger von PureBasic das
ASM-Listing im Debugmodus kennt.

(Warum kein SYNC-Befehl um auf den Rasterstrahl zu warten ohne jegliche Abhängigkeiten wie dämliches Bitmaptauschen...)

'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. Die Möglichkeit 'FlipBuffers()' einen Parameter zu übergeben ist
nichts anderes als SYNC oder nicht SYNC.


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. Natürlich gibt es sicherlich Probleme, bei denen man direkt auf
den Screen schreiben möchte, aber dazu gibt es wie gesagt Abhilfe.

Ich glaube ich habe 2. falsch verstanden, aber vielleicht doch nicht?
wie wäre es mit Print c statt Print "c" ^^

Print ist in PB kein Schlüsselwort sondern eine Procedure:

Was in QBASIC war

ist in PB

Hi Caddy!

ich progge seit 25 jahren, hab damals aufm C64 angefangen, nannte mich TGR6502.

zu 1.
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.

zu 2.
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.

ausgabe von einfachen strings beim erstellen machst du über DEBUG

ausgaben innerhalb deiner oberfläche musst du in deine grafikumgebung Drawen,
oder in ein extra textelement anzeigen (TextGadget-> SetGadgetText)

das liegt einfach am OS, es existiert keine textoberfläche mehr seit Win98.

zu 3.
irgendwo wird ein assemblercode rückgespeichert... weiß jetz nich wo.

Kaeru Gaman hat geschrieben: zu 3.
irgendwo wird ein assemblercode rückgespeichert... weiß jetz nich wo.

Man muss dem Compiler den Parameter /COMMENTED übergeben. Dann bekommt man einen kommentieren Assemblercode ausgespuckt, der nach dem assemblieren auch nicht gelöscht wird. Leider gibts dafür in der IDE keine Einstellungsmöglichkeit. Etwas ärgerlich aber den Compiler zu Fuß zu starten ist ja auch nicht weiter schwierig.

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

wen du unbedingt ohne buffer "Zeichnen" willst, dann male doch direkt auf dem Desktop rum:

Dieser Code bemalt den Bildschirm mit farbigen Linien,
beendet werden kann der Code mit Escape, jedoch wird der Desktop daduch nicht "bereinigt", danach einfach n Fenster durch die Gegend schieben

@caddy

sehr langes posting...

das ist ja alles schön und gut, und größtenteils auch nachvollziehbar,
aber du vergisst zwei grundlegende punkte:

1) die taktfrequenz unterschiedlicher monitore kann sehr stark variieren.
angefangen von 60/65Hz bis zu 240Hz.

2) TFTs haben zwar eine taktfrequenz, aber keinen Elektronenstrahl.
da gibts also nix, wo du hinterhermalen könntest.

letztendlich scheitert dein vorhaben also an so kleinen aber unbeeinflußbaren faktoren.
du kannst dem spieler deines games schließlich nicht sagen:
kauf dir nen röhrenmonitor und stell ihn auf 120Hz, damit mein game richtig läuft.

Es gibt unter PB keine möglichkeit, direkt auf den Frontbuffer zu malen
mittels der PB-Befehle. Fals dir das so wichtig ist, solltest du dich mal mit
Fred in verbindung setzten. Am besten wäre im englischen Forum nen
Feature-Request.

NicTheQuick benötigte ebenfalls mal so eine möglichkeit, weil er asyncron
auf den Screen malen wollte und es somit nie ein "fertiges" Bild an sich
geben sollte. Da es unnötige Leistung fressen würde, wenn sich die
Speicherbereche ändert, hab ich mal geschaut, wie sich da PB verhällt.
Hab den Link aber jetzt nicht, vielleicht ist Nic aber da auch schon etwas
weiter.

Den Zeiger auf den aktuellen Screen bekommt man aber mittels der PB-
Befehle, also nix schwiriges. Äh das war ... Damit kann man den Speicher direkt manipulieren oder auslesen, aber
die ganzen Befehle arbeiten immer mit dem aktuellen BackBuffer.

MFG PMV