|
Anzeige
|
getPixel in Codeblocks
Gast
#3350176
Weiß jemand wie ich getPixel() in C in Codeblocks mit dem GCC Compiler verwenden kann? Wenn ich versuche den Code zu kompilieren bekomme ich diese Fehlermeldung: fatal error: graphics.h: No such file or directory| Mein Code:
Gast
#3350221
http://stackoverflow.com/questions/7860569/how-i-can-get-and-use-the-header-file-graphics-h-in-my-c-program ...sieht aus als wäre das veraltet und sollte durch neuere APIs ersetzt werden. graphics.h dürfte noch DOS-BGI-Kram sein. Wenns um Windows geht dann eher windows.h und http://msdn.microsoft.com/en-us/library/windows/desktop/dd144909%28v=vs.85%29.aspx Wenn die Frage besteht, wie Windows-GDI funktioniert, einfach fragen.
Gast
#3350304
Hat jemand zufällig einen kurzen Beispielcode in dem mit der Windows-GDI die Farbe eines Pixels auf dem Bildschirm eingelesen wird. Danke für euere Hilfe :-)
Gast
#3350307
Schau dir das mal an: http://msdn.microsoft.com/en-us/library/windows/desktop/dd144909%28v=vs.85%29.aspx viel Erfolg Welcher Fehler wurde denn erwartet? Was machen TPascal-Befehle im Code? Und dann BGI-Treiber mit InitGraph laden, gibt es die überhaupt noch? Header graphics.h in C/Cpp unter CodeBlocks wäre mir neu. Falls dieser Header funktioniert und im Verzeichnis des Quellcode vorliegt, dann sollte er mit #include "graphics.h" eingebunden werden. Zudem ist der Code wohl für ein Konsolenprogramm. Das hat kein eigenes Fenster und macht Ein-/Ausgaben von Text, nichts mit GetPixel(), SetPixel() usw. Man kann unter CodeBlocks in C/Cpp ein WinGUI-Projekt mit eigenem Fenster erstellen, Verwendung Win32API mit #include <windows.h>. Anwendung von Funktion GetPixel() in geeigneter Weise, siehe z.B.: http://www.coding-board.de/showthread.php/28267-C-GetPixel-viel-zu-langsam-auf-1280x1024. Syntax: COLORREF GetPixel(HDC hdc, int nXPos, int nYPos); hdc = device context handle, nXPos und nYPos = Koordinaten x und y in logischen Einheiten. Funktionsrückgabe COLORREF ist ein RGB-Wert, der Typ Long entspricht (4 Bytes, longint bei TPascal oder FPC). Beachten, wie man das Handle hdc ermittelt und nach Gebrauch wieder freigibt! Zur Erstellung von Fenstern gibt es im Web einige Win32API-Tutorials, z.B. auf pronix.de. Wärst Du angemeldet, könnte ich Dir einen C/Cpp-Code für main.c schicken (erstmal für die Maus unter WinAPI).
Gast
#3350322
@ leo Man muss nicht unbedingt mit Fenstern arbeiten über die Win - Api kann man auch auf der Konsole pixeln wenn du das willst. Einfach ein Handle auf die Konsole holen. Siehe hier: http://stackoverflow.com/questions/12378642/c-pixels-in-console-window Lese dir vielleicht auch mal dieses win32 - Api Tutorial. http://www.winprog.org/tutorial/bitmaps.html
Gast
#3350323
Muss nicht unbedingt TP sein könnte auch Turbo C sein, BGI heißt Borland Graphics Interface das gabs sowohl für Turbo Pascal als auch für Turbo C.
Gast
#3350589
Hat jemand einen Beispielcode?
Gast
#3350680
Ich habs jetzt doch noch geschaft. Hier ein Beispielcoden, falls in jemand irgendwann brauch...
Da kommt bei mir nur Error: undefined reference to '_GetPixel@12' Ebenso mit SetPixel(), nur GetDC u. ReleaseDC scheinen zu funktionieren. In einem richtigen WinAPI-Fenster mit Botschaftverarbeitung läuft es sowieso, allerdings erhalte ich für eine windowsgraue Fensterfläche immer den Farbwert 0xFFFFFF. Wie das? Korrektur: Der Farbwert ist 0xc8d0d4. Fehler meinerseits, sorry! Rainer V. schrieb: > Da kommt bei mir nur Error: undefined reference to '_GetPixel@12' -lgdi32 bzw. in Codeblocks in den Build Linker-Options => Linker settings => Link Libraries "gdi32" einfügen Supi! Jedoch erhalte ich im Konsolenprogramm jetzt tatsächlich immer den Farbwert 0xffffff, auch bei Abtasten größerer Flächen kein Unterschied. Es hätte mal eine andere Farbe kommen sollen, dabei waren die Handles für Fenster/Desktop und Bildschirmkontext nicht Zero oder NULL. Na ja, das Programm hat für mich keinen Nutzen, es war nur interessant. Zu "graphics.h von Borland": http://www.cplusplus.com/reference/ FAQs gibt es bei Sucheingaben wie "CodeBlocks Borland graphics.h" Zum Thema "Ersatz für graphics.h" gibt es Artikel und Downloads, mit der praktischen Anwendung bin ich aber nicht zurechtgekommen. http://openbgi.sourceforge.net/ , Download: openbgi-sources-1.5.zip http://winbgim.codecutter.org/ , Download WinBGIm 6.0 Libray für MinGW 5.x.x (Library build with MingW 5.0.3 and GCC 3.4.5). In Forenbeiträgen (EN) war oft zu lesen, daß Datei graphics.h von Borland nur mit spez. Borland-Produkten nutzbar und das alles schon obsolet sei, es habe schon Probleme beim Übergang von DOS nach OOP in Windows gegeben. @Leo Möchtest Du unbedingt die Konsole benutzen ? Die Möglichkeiten ein Fenster unter Windows zu nutzen, mit oder ohne Framework, sind auch nicht zu verachten. So Interaktive Möglichkeiten sind ja von der Konsole her nicht so üppig. Paar Schlagwörter :) -Dialoge aus Resourcen oder Direkt per CreateWindow mit Radio/Check/Bitmap-Buttons, Listboxen, List-/Treeview, Scrollbars, Progressbar, Labels und das alles variabel. -entweder mit einem Framework oder direkt als reine Api-Anwendung mit Nachrichtenschleife. -selbst definierte Windowklassen die sich nach deinem Geschmack verhalten Dialoge/Fenster mit Codeblocks gehen besonders einfach. Einfach Resedit runterladen und als Standard Reseditor eintragen. Da hat man ratz fatz ne nette GUI fertig. Und reines Winapi ohne den Visual Studio Firlefanz. Die GDI-Api von Windows hat auch einiges zu Bieten. Zeichenbefehle und Bitmapbefehle. Ein kleines Programm im Anhang. Schönes Programm! Habe BALL_MOVE_DELTA leicht erhöht, da hüpfen die Bälle etwas zackiger. Blauer und grüner Ball springen immer synchron. Ist das beabsichtigt? Womit Ressourcen compiliert? Dazu hatte ich mal RC.exe für Win-16-Bit. Läuft nicht in Win7, auch im Win-XP-Modus nicht. Das MINGW welches üblicherweise bei Codeblocks inklusive ist hat WINDRES dabei. Das Resourcenskript ist Resource.RC und im Projektbaum eingebunden. Passende Header-Files genierieren die Resourceneditoren normal mit. Für eventuelles Editieren von dem RC-File gibt es ja RESEDIT oder ResEd. Das Programm war "Damals[tm]" dafür angedacht um rauszufinden wie flüssig man das animieren kann ohne DX oder OpenGl. Bewegungen sind da eher zufällig reinprogrammiert. Kann sogar sein, daß ein Teil ein ehemaliges MASM32-Projekt war. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
