Bild anzeigen

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Bild anzeigen

    Hallo!

    Ich programmiere zur Zeit einfach vor mich hin und da ich nicht VC(++) verwende (n möchte) habe ich mich gefragt wie ich mittels einer einfachen IDE (wie bsp DEV C++) oder nur mit einem Compiller ein Bild darstellen kann. Funktioniert das mit der CMD\Eingabeaufforderung? -> also mit einem Code der dann dort ausgeführt wird.

    ich würde mich über Antworten segr freuen! Danke Johannes

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Johannes ()

  • Die aktuelle Betriebssystem lassen ja nur noch eingeschränkt hardwarenahe Zugriffe zu.

    Hab das aktuell nicht getestet.
    Und dem Videomodus 13 und unter 16bit könnte die Graphikdarstellung noch möglich sein.
    Unter 32bit wird der Speicher schon anders verwaltet. Ob da heute eine 16bit Emulation noch immer funktioniert?

    Der aktuelle Compiler, Version Watcom 1.9, kann 16bit als Zielsystem nicht mehr - vielleicht kommt ihr ja noch an einen 1.4.

    Hab noch ein paar Graphikspielereien gefunden, die liefen noch unter W2k. Keine Ahnung womit ich die damals kompiliert habe. C oder C++ klar; aber welcher?

    Quellcode

    1. /*
    2. * File: MANDEL.C
    3. *
    4. * Mandelbrot set generator.
    5. * Uses iterative algorithm z(i) = z(i-1) * z(i-1) + c,
    6. * to determine the color of current (x,y).
    7. *
    8. * DO NOT try to compile this using WCL386 !
    9. * Use "WCL -3" or Borland/C++ instead.
    10. *
    11. * (c) Lenik Terenin, 1995
    12. */
    13. #include <stdio.h>
    14. #include <conio.h>
    15. // #include
    17. #define LIMIT 100 // Increase LIMIT to get more exact picture
    19. #ifdef __BORLANDC__
    20. void SetVmode( short mode )
    21. {
    22. asm {
    23. mov ax, [mode]
    24. push bp
    25. int 10h
    26. pop bp
    27. }
    28. }
    30. #define PutPixel13(x,y,c) pokeb( 0xA000, (x) + (y) * 320, (c))
    31. #else
    32. #ifdef __386__
    33. #error Can't run in 32-bit mode, sorry...
    34. #endif
    36. void SetVmode(short);
    37. #pragma aux SetVmode = \
    38. "push bp" \
    39. "int 10h" \
    40. "pop bp" \
    41. parm [ax]
    43. void PutPixel13( short x, short y, short c);
    44. #pragma aux PutPixel13 = \
    45. "push ax" \
    46. "mov ax, 0a000h" \
    47. "mov es, ax"\
    48. "pop ax" \
    49. "shl bx,6" \
    50. "add di,bx" \
    51. "shl bx,2" \
    52. "add di,bx" \
    53. "stosb" \
    54. parm [di] [bx] [ax] modify [es] nomemory
    55. #endif
    57. int main()
    58. {
    59. int i, j, k;
    60. double z_i, z_r, c_i, c_r, tmp;
    61. double module;
    63. SetVmode( 0x13 );
    65. for( i=-160; i<160; i++) {
    66. c_i = ((double) i) / 100.0;
    67. for( j=-160; j<40; j++) {
    68. c_r = ((double) j) / 80.0;
    69. z_i = z_r = 0.0;
    70. for( k=0; k<LIMIT; k++) {
    71. tmp = z_r * z_r - z_i * z_i;
    73. z_i = 2 * z_r * z_i + c_i; // z = z * z + c
    74. z_r = tmp + c_r;
    76. module = z_r * z_r + z_i * z_i; // is |z| large enough?
    77. if( module > 1.0E16 ) break;
    78. }
    79. if( k<LIMIT) {
    80. PutPixel13( i+160, j+160, (k/15)*2+20);
    81. }
    82. else PutPixel13( i+160, j+160, 16);
    83. }
    84. if( kbhit() ) break;
    85. }
    87. getch();
    88. SetVmode(3);
    90. return 0;
    91. }
    Alles anzeigen


    Ist schon ein paar Jahre her, es kann sein das der Quelltext nach bearbeitet werden muss.
    Unter Borland wird ausser dem BCC der TASM benötigt :!:
    Watcom damals Version 1.4 oder 1.6?

    MfG bcc-fan

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von bcc-fan ()

  • Ich denke das sich neuere Windowsversionen und Compiler von den von mir gezeigten Spielereien entfernen.

    Die Quelltexte beruhen auf Besonderheiten bei der Adressierung des Speichers der alten CPUs, wie 8080 oder 8086 u.s.w..

    Bill Gates ( ? ) und/oder andere Mitstreiter gingen zu Beginn seiner Laufbahn davon aus das ein MB Speicher locker für so einen PC genügen würde :D

    Grob skizziert der Speicheraufbau damals 10 Blöcke mit je 64kB mehr oder weniger freier Speicher. Der 11te Block für Grafik. Der 16.Block für Kopien des Bios.
    Die Blöcke 12 bis 15 wurden manchmal mit "Klimmzügen" dem freien Speicher oder auch teilweise der Grafik zugeteilt. Es gab zu Beginn sogar Rechner unter DOS die noch weniger Speicher hatten. Ab der 386er CPU wurde die Speicherverwaltung aber deutlich geändert.

    Dann kamen OS2 und Windows NT die verbesserte Sicherheitsmechnismen mitbrachten. Da heisst, der Endnutzer soll möglichst nicht mehr direkt auf den Speicher zugreifen können. Das soll das Betriebssystem stabilisieren, wenn z.B. eine Anwendung abstürzt.

    So weit ein kurzer Abriss zur Geschichte ;)

    MfG bcc-fan

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von bcc-fan ()

  • Der DEV ist ja eine IDE unter der der Compiler MinGW 3.4.5 meist läuft.
    Meinen Informationen nach kann der MinGW nicht aus dem von mir zitierten Quelltext auf der Konsole Bilder darstellen, da er für die "alte" Speicherverwaltung nicht konzipiert ist.

    Da musst du, wenn du unter Windows mit DEV so was vorhast die Windowsunterstützung, also WinAPI und darauf aufbauende Programme nutzen.

    MfG bcc-fan

  • Die neuen VC++ helfen dir da auch nicht weiter - da müsstest du schon noch einen Oldie ausgraben.
    Denke der letzte VC der das noch konnte war der 1.5 :D

    Wir schreiben hier noch über Bilder direkt in den Speicher schreiben? ;)

    Auch ältere Compiler von Borland, Symantec( heute: Digital Mars ), Watcom, Microsoft und andere konnten Bilder in den Speicher schreiben.
    Aber nicht der MinGW, da der immer schon min 32bit ansprach.

    Wenn es WinAPI werden soll, alle neueren Versionen der oben aufgezählten Compiler können das.
    Aber die Dialekte die die Compiler verstehen unterscheiden sich ein wenig :huh:

    MfG bcc-fan

  • Die Grenzen IDE? Der DEV und einige andere sind/waren als Quelltext verfügbar. Wenn du Lust und Zeit hast wo sollen da die Grenzen sein?

    Okay, ich nehme an du meinst so wie der DEV meisst genutzt wird, also als Programm ohne das da noch was ergänzt wird. Der DEV wird schon einige Jahre nicht mehr weiterentwickelt - das sollten Delphi-Quellen gewesen sein. Es soll bei umfangreicheren Projekten zu Problemen gekommen sein, wenn ich das richtig deute, steuerte der DEV den MinGW nicht immer richtig an.

    Einige betrachten die IDE Code::Blocks als Nachfolger des DEV. Code:Block wurde mit dem MinGW übersetzt. Wenn du möchtest, darfst du den verbessern oder weiterentwickeln. Weiteres findest du auf der Seite von C::B. Man soll da alte Projekte des DEV importieren können und man kann etwa 20 Compiler mit C::B 10.5 ansteuern.

    Dies nur als kleiner Abriss zu IDE und Compiler.

    Die WinAPI wurde gleichzeitig mit Windows entwickelt, geistert also schon mehr als 20 Jahre durch die geneigte Programmiererwelt.
    Hier ein Tutorial:
    winprog.org/tutorial/

    Die NET Geschichte ist deutlich jünger.

    MfG bcc-fan

  • Ich würde dir empfehlen, wenn du Fenster machst, statt WinAPI eher auf WFC oder gleich .NET umzusteigen. Es ist zwar immer mal ganz praktisch wenn man WinAPI noch kann, aber effektiv nutzt das kaum einer noch um selber seine Fenster damit zu erstellen, der Code wird ziemlich unübersichtlich und länglich und es ist auch viel mit viel Studieren der MSDN verbunden. Besonders als Programmiereinstieg halte ich es für ungeeignet.
    Achja mit mode 13h direkt in den Grafikspeicher reinzuschreiben ist auch so Sache, die eher nur aus nostalgischen Gründen zu empfehlen ist. Damit kann man auch nicht wirklich Bilder sinnvoll darstellen, da die Auflösung und Farbtiefe stark begrenzt ist. Außerdem schaut sich niemand gerne Bilder in einer DOS-Box an :) Früher hat man das gemacht um effizient beispielsweise PC-Spiele in Fullscreen (320×200) realisieren zu können. @bcc-fan: den Kommentaren und defines nach, sollte es zumindest unter anderem mit Turbo-C++ gehen.
    ~ mfg SeBa

    Ich beantworte keine PMs zu Computer-/Programmierproblemen. Bitte wendet euch an das entsprechende Forum.

    [Blockierte Grafik: http://i.creativecommons.org/l/by-sa/3.0/80x15.png]

  • Ja sollte mit den alten Turbo C oder auch Turbo C++ laufen. Vor 15 bis 20 Jahren Turbo C + Turbo C++ = BCC

    Videomode 13 wie du schon schriebst: 320x200Pixel und 256 Farben, mehr ging damals nicht ohne Klimmzüge. Damals CPU 286 ;)
    Höher auflösende Videomodi gingen ab dem 386. Nur wer das highspeed nutzen wollte musste für jeden damaligen Graphikkartenchip die Software selbst optimieren.
    Mit dem Interrupt die Pixel ansprechen war universeller, aber deutlich langsamer.

    Borland, Inprise, Embarcadero oder wie die sich im Laufe der Zeit sonst noch nannten, hatten vor etwa 3 oder 4 Jahren noch mal Turbo-Produkte angeboten. Ob das mit diesen noch möglich ist 16bit Zielcode erstellen :?:

    Das als historische Info
    bcc-fan