Über den hDC die Breite und Höhe des Ausgabekanals ermitteln

[PureLust]

Nee, *shi** ... klappt ja doch noch nicht mit der Nachbarin.

An das Ergebnis von xyOutput() komme ich in meiner Prozedur ja garnicht heran - den Output hat der User ja schon lange vorher festgelegt.
Ich komme zwar an den DC (durch die Assembler-Routine: "DrawingDC()"), aber eben nicht an den Output (laut PB-Hilfe halt "Ausgabekanal" - also den Pointer zu der DIS).

*grrrrrrrr*

[Nachtrag:]
Gibt's nicht auch zum DC irgendeine Struktur in der man dann den OutputChannel ablesen kann?

[Fluid Byte]

Also die Infos über die Nutzung der internen PB Objects ist recht dünn gesäht. Ich hab jetzt mal was zusammen geschraubt aber will dich gleich warnen. Auf Korrektheit und Funktionalität gibts keine Garantie:

Code: Alles auswählen

Structure PB_2DDrawingInfo
	Type.l				; Type of the DC
	Window.l			; Window associated to the DC (if any)
	hDC.l				; DC (Display Device Context)
	ReleaseProcedure.l	; Address to a procedure to release the DC when StopDrawing() is called
	PixelBuffer.l		; Address of the memory pixel buffer (DirectX)
	Pitch.l				; Bytes per line (DirectX)
	Width.l
	Height.l
	Depth.l
	PixelFormat.l
	StopDirectAccess.l
	StartDirectAccess.l 	
EndStructure

Import "kernel32.lib" 								; Not in the kernel32.lib, but always linked
	PB_2DDrawing_GlobalStructure.PB_2DDrawingInfo	; non-threaded
	PB_2DDrawing_Globals           					; threadedsafe mode
	PB_Object_GetThreadMemory(*Globals)
EndImport 

InitSprite()

OpenWindow(0,0,0,640,480,"void",#PB_Window_SystemMenu | #PB_Window_ScreenCentered)
CreateGadgetList(WindowID(0))
OpenWindowedScreen(WindowID(0),0,0,640,480,0,0,0)

LoadFont(0,"Arial",9,256)

Repeat
	EventID = WindowEvent()
	
	ClearScreen(RGB(40,90,140))

	hdc = StartDrawing(ScreenOutput())
	
	*pbdis.PB_2DDrawingInfo = PB_Object_GetThreadMemory(PB_2DDrawing_Globals) + 48

	DrawingMode(1)
	DrawingFont(FontID(0))
	FrontColor(#White)
 	DrawText(10,10,"Type = " + Str(*pbdis\Type))
 	DrawText(10,25,"Window = " + Str(*pbdis\Window))
 	DrawText(10,40,"Device Context = " + Str(*pbdis\hDC))
 	DrawText(10,55,"ReleaseProcedure = " + Str(*pbdis\ReleaseProcedure))
 	DrawText(10,70,"PixelBuffer = " + Str(*pbdis\PixelBuffer))
 	DrawText(10,85,"Pitch = " + Str(*pbdis\Pitch))
 	DrawText(10,100,"Width = " + Str(*pbdis\Width))
 	DrawText(10,115,"Height = " + Str(*pbdis\Height))
 	DrawText(10,130,"Depth = " + Str(*pbdis\Depth))
 	DrawText(10,145,"PixelFormat = " + Str(*pbdis\PixelFormat))
 	DrawText(10,160,"StopDirectAccess = " + Str(*pbdis\StopDirectAccess))
 	DrawText(10,175,"StartDirectAccess = " + Str(*pbdis\StartDirectAccess))
	StopDrawing()
		
	FlipBuffers()
Until EventID = #PB_Event_CloseWindow

[PureLust]

Super, damit scheint's zu klappen. ... zumindest unter Windows.

Was ich bezüglich Linux und OSX jedoch noch nicht so ganz verstehe ist das hier:

Code: Alles auswählen

Import "kernel32.lib"                         ; Not in the kernel32.lib, but always linked 
   PB_2DDrawing_GlobalStructure.PB_2DDrawingInfo   ; non-threaded 
   PB_2DDrawing_Globals                          ; threadedsafe mode 
   PB_Object_GetThreadMemory(*Globals) 
EndImport

Bedeutet das nun, dass die Kernel32.lib benötigt wird oder doch nicht?
Denn falls sie benötigt wird, wäre es ja dann leider doch wieder nur eine reine Windows-Lösung.

Ich hab Dein Beispiel in dieser Form einfach mal unter Linux ausprobiert und bekomme natürlich einen Linker-Error, da er die Kernel32.lib unter Linux nicht finden kann.

So ganz hab ich den Kommentar "Not in the kernel32.lib, but always linked" nämlich nicht verstanden.
Den Kommentar könnte man ja u.U. so interpretieren dass die Kernel32.lib doch nicht benötigt würde - aber warum sollte man die linken, wenn das benötigte nicht drin ist?
Wie gesagt - so ganz schlau draus geworden bin ich nicht und wüsste jetzt nicht, wie ich and die entsprechenden Strukturen und das Interface (hab ich das so einigermaßen richtig erkannt auf was Du da zugreifst? ) unter Linux oder OSX rankommen sollte.

Oder gibt es u.U. für Linux und OSX ein Äquivalent zur Kernel32.lib, das ich dann per CompilerIF einfach entsprechend Importieren müsste?

Ohh je ... Fragen über Fragen ... und das auch noch soooo früh am Morgen.

[edel]

Kernel32.lib wird nur unter Windows benoetigt, und dient hier nur als Platzhalter.

Code: Alles auswählen

CompilerSelect #PB_Compiler_OS 
  CompilerCase #PB_OS_Linux,#PB_OS_MacOS
    Import "2ddrawing.a"
  CompilerCase #PB_OS_Windows
    Import "2ddrawing.lib"
CompilerEndSelect

   PB_2DDrawing_GlobalStructure.PB_2DDrawingInfo   ; non-threaded
   PB_2DDrawing_Globals                            ; threadedsafe mode 
   PB_Object_GetThreadMemory(*Globals)
EndImport 

So muesste es unter den anderen 2 System laufen.

[PureLust]

Jo, ... mit der 2ddrawing.lib klappts auch - zumindest unter Windows.

Unter Linux bekomme ich allerdings einen Fehler:

gcc: 2ddrawing.a: No such file or directory
Error: Linker

Das wird ja aber vermutlich irgendwie an meine PB-Installation unter Linux liegen, da es die 2ddrawing-Library ja unter Linux gibt.
(Ich dachte eigentlich, ich hätte PB unter Linux soweit sauber installiert. Sonst läuft nämlich alles und ich kann auch Programme kompilieren - aber hab vorher ja auch noch nie IMPORT benutzt. )

[Fluid Byte]

Hat die Neuinstallation was gebracht bzw. existiert die Datei "2ddrawing.a"?

[PureLust]

Hat die Neuinstallation was gebracht bzw. existiert die Datei "2ddrawing.a"?

Mit Neuinstallation meinst Du eine Neuinstallation von PB unter Linux?
Hatte ich jetzt noch nicht gemacht bzw. nicht dran gedacht, da mein PB unter Linux ja bisher lief (seit etwa 2 Monaten)

Und ja, es gibt eine "~/purebasic/purelibraries/2ddrawing". Die Extension ".a" bekomme ich jedoch nicht angezeigt.

[edel]

Das ist einer der grossen Nachteile von PB. Die eigentlichte Library
(also .a oder .lib) sind in diesen Dateien ohne Endungen. Sie werden
erst dann entschluesselt und entpackt, wenn der Compiler einen Befehl
fuer diese Lib findet. Die .lib oder .a existiert also nur beim kompilieren
und linken, danach wird sie wieder geloescht.
Welche Sinn das hat, kann ich nur vermuten, es ist wohl nur dafuer
gedacht um Missbrauch vorzubeugen. Allerdings lassen sich alle Libs
sehr einfach entschluesseln, was das wieder in Frage stellt.

Einen anderen Weg hat Fluid Byte ja bereits gepostet, eine Library
angeben die immer hinzu gelinkt wird. Unter Windows ist das eben Kernel32.
Welche das unter Linux oder gar Mac sind, kann ich aber nicht sagen.
Allerdings muss sich auch hier im Code mindestens ein Befehl aus der
Lib befinden, um an die Internen Variabeln oder Funktionen zu kommen.

[PureLust]

..., eine Library angeben die immer hinzu gelinkt wird. Unter Windows ist das eben Kernel32.
Welche das unter Linux oder gar Mac sind, kann ich aber nicht sagen.
Allerdings muss sich auch hier im Code mindestens ein Befehl aus der
Lib befinden, um an die Internen Variabeln oder Funktionen zu kommen.

Naja ... da es sich bei der Geschichte ja um 2D-Drawing Dinge dreht wird also mit Sicherheit immer ein StartDrawing() im Code vorkommen.
Somit würde sich also die von Dir bereits favorisierte 2ddrawing.lib anbieten.

Aber vielleicht eine Idee, warum ich dann den Linker-Error bekomme wenn ich diese wie von Dir beschrieben Importen will?

Die PBHome- und Compilerpfade müssten eigentlich soweit richtig gesetzt sein, da ja PB ansonsten nicht so sauber laufen würde.

[Shardik]

Hintergrund für die Frage nach einer API-freien Lösung ist, dass ich meinen Code weitestgehend plattformübergreifend halten möchte - was ja durch den oben gezeigten Assemblercode eigentlich gewärleistet sein müsste.

Assemblercode gewährleistet keine Plattform-Kompatibilität. Er läuft nur auf Betriebssystemen mit x86-Prozessoren (Intel, AMD, Via). Die PureBASIC Mac-Version ist aber nach meinem Kenntnisstand für den PowerPC-Prozessor entwickelt und noch nicht auf die Intel x86-Prozessorplattform portiert. Und die für Linux kompilierten PureBASIC-Programme laufen ebenfalls nur unter Linux-Systemen mit x86-Prozessor...