*DC direkt ansprechen

[super_castle]

Ich habe hier :
OpenWindowedScreen(WindowID(0),10,10,660,300,0,0,0)

Das oben möchte ich dann als DC ansprechen:
SetPixel_(*DC,xd+xs,yd+ys,RGB(farbe,farbe,farbe))

Wie kann ich OpenWindowedScreen in ein DC übergeben ?

Gruss

[STARGÅTE]

Ich frage mich echt, wie lange du noch die Funktionen, die PureBasic bietet, ignorieren willst.

Warum willst du die nicht nutzen ?
Ist ja nicht das erste mal, dass du wiedermal n Weg außenrum suchst, obwohl es einen direkten gibt:

Code: Alles auswählen

StartDrawing(ScreenOutput())
  Plot(xd+xs,yd+ys,RGB(farbe,farbe,farbe))
StopDrawing()

[c4s]

@STARGÅTE
Antworte ihm doch am Besten gar nicht, dann musst du dich auch nicht über seinen Schwachfug ärgern.

@super_castle
Du hast die Code-Tags vergessen - sie erhöhen die Leserlichkeit deines Beitrags.
Außerdem hat Stargate schon recht. Es spricht nichts gegen die Benutzung der PureBasic-Funktionen. Soweit ich weiß sind diese sogar um einiges schneller als SetPixel_().

[Fluid Byte]

Antworte ihm doch am Besten gar nicht, dann musst du dich auch nicht über seinen Schwachfug ärgern

Wie oft hab' ich mich das schon gefragt ...

Das gesamte Forum ist von ihm so oft mit Scheiße beschissen worden und trotzdem gibt es immer noch ein paar Volltrottel die ihm helfen. Muss wohl eine Art Paradoxon sein, wie die Ehefrau die immer wieder zu ihrem Mann zurückkehrt der sie ständig krankenhausreif prügelt.

super_spacken einfach nicht füttern, dann verschwindet er irgendwann

[super_castle]

Code: Alles auswählen

StartDrawing(ScreenOutput())
  Plot(xd+xs,yd+ys,RGB(farbe,farbe,farbe))
StopDrawing()

Das kann ich nicht gebrauchen, weil die Bildhöhe(80-Y-Pixel) syncronisiert wird durch die Zeit einer Wav-Datei mit 32000hz , das heisst, jeder Bildpunkt muss sofort sichtbar sein, es darf nicht erst gesammelt werden und dann das Bild anzeigen.
Mit Startdrawing werden da zwischen 75- 90 Pixel erzeugt, das ist zu ungenau, das Bild ist nicht erkennbar.

[STARGÅTE]

Gut, dann nimmst du halt (wie ich im übrigen schon mal geschreiben hab) DrawingBuffer()

Dieser ist für den Screen dauerhaft gültig, du musst also nicht StartDrawing() während der laufzeit ausführen, sonden nur am Start.

Weitere Details dazu findest du in der Suche

[mk-soft]

@super_castle

ich glaube nicht das ein Mensch 32000 Bilder in der Sekunde sehen kann.
Es reichen 25 Bilder in der Sekunde die du aus der laufenden Wave anzeigen willst.
...
Nicht einfach los dappeln, sondern vorher ein Kopf machen was man erreichen möchte...
... mal einige Grundlagen selber beibringen. Damit ersparst du dir und uns einige sehr unnötige fragen hier.

[Thorium]

@super_castle

ich glaube nicht das ein Mensch 32000 Bilder in der Sekunde sehen kann.
Es reichen 25 Bilder in der Sekunde die du aus der laufenden Wave anzeigen willst.
...
Nicht einfach los dappeln, sondern vorher ein Kopf machen was man erreichen möchte...
... mal einige Grundlagen selber beibringen. Damit ersparst du dir und uns einige sehr unnötige fragen hier.

Lasst den kerl doch einfach brabeln, der rafft sowieso nicht das sein Bildschirm nur X Bilder die Sekunde anzeigt egal wieviele wer auch immer wahrnehmen kann.

[Fluid Byte]

[super_castle]

ich glaube nicht das ein Mensch 32000 Bilder in der Sekunde sehen kann.

Du sollst mal richtig lesen!!!!

Es geht hier um eine Pixelzeit pro Pixel von 1/32000, weil die Wav-Datei 32000Hz hat.
Es werden 12,5 Bilder a 32 Zeilen geschrieben pro Sekunde.
Es steht die Anzahl der Bilder pro Sekunde fest und die Zeilenanzahl-X.
Die Höhe Y pro Zeile wird durch die Zeit festgelegt!!!

Also:
12,5* 32 = 400 > 1/400=0,0025 sec pro Zeile.

Wav-Datei mit 32000Hz > 1/32000 = 0,00003125 sec Zeit pro Pixel

Da eine Zeilenhöhe eine Zeit von 0,0025 sec hat entspricht das 0,0025/0,00003125 =80
Also wenn die Zeit genau eingehalten wird kommt eine Höhe von 80 Pixel raus.

Mit diesem Befehl "QueryPerformanceCounter_(@Time_1) " bekomme ich +- 1 YPixel zur Darstellung mit dem *Dc. Das Bild was ich jetzt damit aus der Wavdatei Anzeige , ist sehr stabil.
Dieses Wavdatei-Format ist fest vorgegeben, weil diese auch auf meiner echten Nipkowscheibe, umgesetzt wird als Bild.
http://www.sptv.demon.co.uk/nbtv/
Es geht um eine reale Darstellung. Die Nipkowscheibe sammelt auch keine Pixel.
Auch die Nipkowscheibe muss ich ab und zu während der Film abläuft nachjustieren, das Bild wandert dann wenn die Justierung nicht stimmt.

Diese feine Nachjustierung mache ich auch auf meinem *dc auf dem PC. Daran sieht, wie genau mein Programm doch als Real arbeitet.

So sieht das bild aus, wenn es günstig steht :
http://www.roboternetz.de/phpBB2/album_ ... ic_id=2549
Nach ca 5sec wandert es wieder und ich muss es auch in Purebsic wieder justieren.

Diesen Bausatz habe ich mir schicken lassen : http://www.zarkovision.de/mutr.html.