Spiel Programmieren mit BCB 6



  • Wäre es eigentlich möglich eine Art 2D Spiel mit dem BCB 6 zu programmieren indem ich einfach nur pixel anderes färbe? Ich meine jetzt schon verschiedene Funktionen dazu programmieren die aber im Grunde genommen einfach nur die farbliche Oberfläche meines Windows ändern.

    Ich weis die Frage klingt komisch aber wie soll ich mich besser ausdrücken?



  • na ja, ohne DirectX oder so is da immer alles am flimmern, und BC++B und DX zusammen, das hab ich bisher net hingekriegt.



  • Ach Quatsch. Wenn die Grafik nicht zu aufwändig ist und man schlau programmiert, geht das doch.



  • Richtig, ohne DirectX wirst du nur sehr primitive Animationen flackerfrei hinbekommen. (Schau' dir dazu vielleicht das Thema "TBitmap" an. Mal' in ein TBitmap-Objekt und kopiere den Inhalt dann auf den Schirm.)

    Aber ich widerspreche sn00fy in Punkto DirectX und BCB. Das funktioniert sogar ganz wunderbar, auch mit der aktuellen Version 9 des DirectX SDKs. Es gibt zum Thema einige Websites, einfach mal googlen. (als Ergänzung des Microsoft DirectX-SDKs brauchst du die entsprechenden .libs im Borland-Format. Die liegen meist im Web rum)

    Ich poste vielleicht noch Genaueres, wenn ich wieder an meinen Rechner bin.



  • Also wäre es jetzt möglich eine Art Strategie oder eine Simulations-spiel nur mit verschiedenen Forms und unterschiedlich gefärbten Pixel (natürlich alles mit Funktionen) zu gestalten?

    Hm das sollte ich mir mal anschauen...



  • Man kann auch in OpenGL schöne Spiele zaubern.

    Beispiel für fast flackerfreies zeichnen von Bitmaps:
    Als pbk file zum downloaden
    http://members.tripod.de/FrederikBoehm/weiterleitung2.html

    MfG FB 😉

    Meine neue Homepage: http://members.tripod.de/FrederikBoehm/



  • WebFritzi schrieb:

    Ach Quatsch. Wenn die Grafik nicht zu aufwändig ist und man schlau programmiert, geht das doch.

    Aber nicht mit dem BCB! Mach mal ein Programm in BCB und das Gleiche im MFC VC++, du wirst sehen, dass die Datei vom BCB min. 2mal so groß ist und auch 2mal so langsam ist... Also wenn dann würde ich dir empfehlen mit mfc vc++ zu arbeiten.



  • Windoof schrieb:

    WebFritzi schrieb:

    Ach Quatsch. Wenn die Grafik nicht zu aufwändig ist und man schlau programmiert, geht das doch.

    Aber nicht mit dem BCB!

    Ich heb für dich mal die Schlüsselstelle in WFs Posting hervor...

    WebFritzi schrieb:

    Ach Quatsch. Wenn die Grafik nicht zu aufwändig ist und man schlau programmiert, geht das doch.

    Windoof schrieb:

    Mach mal ein Programm in BCB und das Gleiche im MFC VC++, du wirst sehen, dass die Datei vom BCB min. 2mal so groß ist und auch 2mal so langsam ist...

    Wobei man die Probleme im BCB 10mal so schnell gelöst hat wie in MSVC.
    Übrigens liegt der Grund wieso die ausführbaren Dateien kleiner sind ganz einfach in der Tatsache, dass die Runtime für die MFC Anwendungen bereits auf allen Systemen mit Windows verteilt wurde, im Gegensatz zur VCL runtime... und das mit der Geschwindigkeit, naja, das setzt in der Tat voraus, dass man sich an WFs Schlüsselstelle hält... Aber dazu muss man hald erst mal einiges Wissen über die Interna vom BCB und über sonstige Systematik in der Entwicklung aneignen und besitzen...

    Windoof schrieb:

    Also wenn dann würde ich dir empfehlen mit mfc vc++ zu arbeiten.

    ... naja nichts für ungut, aber eine empfehlung von dir ist doch eher mit vorsicht zu geniessen, wenn man so deinen Werdegang anschaut...

    -junix



  • @junix: lol, man sieht überhaupt nicht, dass du offensichtlich eine persönliche Abneigung mir gegenüber hast... Ich habe doch schon glatt dein Kommentar vermisst, deine überschlauen.

    Ich betone für dich nochmal meine Schlüsselstelle:

    Aber nicht mit dem BCB! Mach mal ein Programm in BCB und das Gleiche im MFC VC++, du wirst sehen, dass die Datei vom BCB min. 2mal so groß ist und auch 2mal so langsam ist...

    Probieren geht über Studieren... Mag sein, dass die Librarys alle schon in Windows drin sind, mir geht es beim Spieleprogrammieren auch nicht unbedingt um die Größe, sondern um die Geschwindigkeit.


  • Mod

    Hallo

    @Windoof
    Junix war nur ein wenig schneller 😃

    MfG
    Klaus



  • Windoof:
    a) Spieleprogrammierung ist völlig losgelöst von der VCL. Die Spieleprogrammierung hat ihre eigenen Regeln für Softwaredesign (ein thema dem du dich sowieso mal widmen solltest, bevor du so breitspurig auftrittst)...
    b) solltest du meine Aussage zum Thema MSVC erzeugt schnellere Programme als BCB genauer lesen. (mal abgesehen davon, dass deine Aussage schlicht unfug ist)

    Zu deinem schwachsinnigen Vorwurf, dass ich mein Posting aus Gründen persönlicher Abneigungen verfasst haben sollte, nehme ich nicht weiter stellung. Offensichtlich ist allerdings bin ich scheinbar nicht als einziger der Meinung, dass deine Aussage bezügich MSVC und BCB einfach schwachsinnig ist...

    -junix



  • Hi,

    ich möcht mich mal ganz leise einmischen...

    Jeder, der schonmal ein graphiklastiges Projekt mit dem VC++ gemacht hat, weiss, das bei solchen Sachen der Vc++ doch im Vorteil ist. DirektX wird erstklassig unterstützt und auch OpenGL ist kein Problem.
    Beim BCB haste ja sehr schnell Probleme mit Libs. Ich bestreite ja nicht dass es mit dem BCB auch geht. Mit dem Vc++ geht es aber wirklich einfacher.

    Wenn du sagts:

    Wobei man die Probleme im BCB 10mal so schnell gelöst hat wie in MSVC.

    dann musst du mir dass mal zeigen.

    Die Vorteile des BCBs greifen bei DirektX-Programmierung nicht. Zumal DirektX von der Entwicklungsumgebung überhaupt nicht unterstützt wird (im Bezug auf RAD-Tools).
    Man muss schon dann reelen Quellcode wie in VC++ oder DEVC++ auch schreiben. Da der BCB mit seiner Inkompatibilität mit MS-dlls recht schwer zu händeln ist, würde ich VC++ bei DirektX immer vorziehen.

    Allerdings ist das Ergebnis dabei immer gleich. Es flackert bei beiden gleich viel oder gleich wenig.



  • Windoof hat von MSVC und MFC vs. BCB gesprochen dementsprechend hatte ich meine Aussagen auf dieses Thema beschränkt. Den Rest hat ja eigentlich WebFritzi schon gesagt: Es ist sowieso eine Frage der schlauen Programmierung... bei native DX sowieso.

    -junix



  • hat denn mein source Beispiel zum downloaden geholfen?

    MfG FB 😉



  • @FB:

    Ich habe Dein Source Beispiel heruntergeladen und ausprobiert.

    Die von Dir mitgelieferte exe läuft bei mir völlig ruckelfrei ab. Erinnert mich an gute C64 zeiten 🙂

    Kompiliere ich das Programm hingegen bei mir neu, ruckelt und flackert es wie wild 😞 Dabei habe ich in den Optionen unter Compiler das Debuggen auf Entgültig gestellt.

    Weißt Du was für eine Einstellung ich da scheinbar noch nicht kenne?
    Würde mich ja interessieren wie Du das Programm so kompiliert hast, dass es so schnell läuft, und warum das bei mir nicht der Fall ist.



  • @Clip:

    Oh! Keine Ahnung an was das liegen kann!

    Bei mir läufts auf jedenfall flüssig!

    Hab nen P4 2,8 MHZ , 510 DDR , Radeon 9600 und WinXP

    Aber wenn die exe flüssig läuft!?

    Vieleicht braucht der Builder ja so viel Recurcen

    MfG FB 😉



  • Wollte das Posting nur noch mal nach oben stellen!

    Und Clip was hast du für nen PC?

    MfG FB 😉



  • Na, reite lieber nicht so darauf herum. 😉
    Wenn bei deinem Beispiel das Fenster vergrössert wird ist es mit dem Nichtflackern schnell vorbei. Davon abgesehen gibt es zum von dir verwendeten Prinizip des DoubleBuffering bereits etliche Diskussionen hier im Forum. Und dein Beispiel-Code selbst ist formal auch nicht gerade eine Meisterleistung.

    BCB6-Besitzer sollten sich zur Inspiration mal das EarthPong-Beispiel im Examples-Ordner ansehen.



  • Ich habe ienen 800 Mhz Duron..

    Aber das müßte doch eigentlich egal sein. Weril Deine exe gut läuft, wohingegen eine bei mir erstellte exe immer flackert.



  • Gib dir Recht Jansen,
    @Clip du hast wahrscheinlich das Fenster vergrößert und gespeichert.

    MfG FB 😉


Log in to reply