4. (überflüssige) Demo

(überflüssige) Demo

  • ?

    ***c:\ZweiD\Renderer\CFastRender.cpp(38) : warning C4244: '=' : Konvertierung von 'double' in 'float', möglicher Datenverlust
    c:\ZweiD\Renderer\CFastRender.cpp(39) : warning C4244: '=' : Konvertierung von 'double' in 'float', möglicher Datenverlust
    c:\ZweiD\Renderer\CFastRender.cpp(127) : warning C4244: '=' : Konvertierung von 'double' in 'float', möglicher Datenverlust
    c:\ZweiD\Renderer\CFastRender.cpp(212) : warning C4244: 'Argument' : Konvertierung von 'double' in 'float', möglicher Datenverlust

    VISUAL C++ 7.0

    😃 😃 😃

    Edit by Headhunter : Friendly mode enabled 😃 😃

    [ Dieser Beitrag wurde am 16.01.2003 um 14:36 Uhr von Headhunter editiert. ]

    0
  • N

    Edit by Headhunter : Friendly mode enabled 😃 😃

    *rofl*

    Ähm, TGGC, kannst Du vielleicht nächstes Mal die Dateinamen alle klein schreiben oder bei den #includes zb statt "stdafx.h" "StdAfx.h" verwenden? Linux ist nämlich case-sensitive... 🙂
    Aber alle Achtung, das ist ja schon um einiges übersichtlicher als die Ursprungsversion(en)!

    0

  • Eigentlich passt ja alles, ausser das stdafx.h/cpp gross sind. Das ist aber nicht mein Fehler weil VC++ dieses Files selbst anlegt. Habs jetzt klein gemacht, sollte passen.

    0
  • N

    Original erstellt von TGGC:
    Eigentlich passt ja alles, ausser das stdafx.h/cpp gross sind. Das ist aber nicht mein Fehler weil VC++ dieses Files selbst anlegt. Habs jetzt klein gemacht, sollte passen.

    Ich schau am Abend mal rein, danke! 🙂

    0
  • N

    Dieser Beitrag wurde gelöscht!
    0

  • Dein Archiv ist kaputt oder mit irgendwelchem zu zip inkompatiblem Zeug gepackt (Linux is eben' Mist 😉 ). raw Dateien hab ich immer mit PSP geöffnet, was aber ab jetzt nicht mehr nötig ist, denn:

    Es gibt eine neue Source Version auf dem Server.

    0
  • N

    Original erstellt von TGGC:
    Dein Archiv ist kaputt oder mit irgendwelchem zu zip inkompatiblem Zeug gepackt (Linux is eben' Mist 😉 ).

    Mein Archiv ist mit bzip2 gepackt und völlig in Ordnung, das kann mittlerweile jeder halbwegs vernünftige Windows-Packer lesen, Du solltest es Dir uU auch mal anschaun, denn Deine Zip-Source-Version ist 21K groß, meine mit bzip2 9.2K! :p

    Ich check mal die V2...

    0
  • N

    So, ich habe eine Linux-Version, ich lade sie mal hoch...
    edit: ein umfangreicheres Makefile ist IMO nicht sinnvoll

    [ Dieser Beitrag wurde am 20.01.2003 um 12:42 Uhr von nman editiert. ]

    0
  • N

    Dieser Beitrag wurde gelöscht!
    0

  • So, WinRar 3.00 konnte es entpacken (*hint*). Die Sache kann man nicht mehr mit dem VC 6.0 kompilieren, da du den include der pch geändert hast. Wenn du kompatibele Änderungen machen möchtest, dann benutzte doch bitte ein #define, welches du dann im makefile setzen könntest.

    0
  • N

    Die Änderungen in der stdafx.h waren nötig weil \ als Verzeichnistrenner nicht portabel ist, ich kann nicht nachvollziehen warum / ausgerechnet hier nicht funktioniert...
    Naja, mal ein bisschen probieren...

    edit: Ah, Erleuchtung, es liegt am (korrekten) #include "**../**stdafx.h", seltsam, aber gut, das lässt sich leicht beheben...

    [ Dieser Beitrag wurde am 20.01.2003 um 13:31 Uhr von nman editiert. ]

    0
  • N

    Jetzt sollte es auch der MSVC++ kompilieren können, die neue Version ist hochgeladen und ihre MD5 ist ee0c3936e978c42d470349aea882fbe8.

    0

  • nope funzt nicht 😞
    Müssen dann wohl doch immer 2 Versionnen bleiben?!

    0
  • N

    *grr* Das gibts doch nicht, mein Code ist korrekt, ich weiß nicht was dieser schrottige Compiler daran auszusetzen hat! 😡

    Ich start mal mein Windows und schaus mir an, irgendwie muss das doch gehen... 🙄

    0

  • Man muss nunmal die pch's als erstes inkludieren, kann wieso finuzt das bei dem linux Teil nicht?

    0
  • N

    Weil stdafx.h nicht im gleichen Verzeichnis wie die Renderer-Dateien ist sondern eben eines höher, (..) ich weiß nicht warum der VC++ das kompiliert, das ist so nicht richtig.
    (Genausowenig wie ich weiß warum er mein korrektes #endif beim Workaround nicht will.)

    0
  • N

    Dieser Beitrag wurde gelöscht!
    0

  • Oh nein, warum sollen die denn deaktiviert sein, ich will ordentlich arbeiten?

    0
  • N

    Original erstellt von TGGC:
    Oh nein, warum sollen die denn deaktiviert sein, ich will ordentlich arbeiten?

    Weil das in der Form ein VC++-only-Feature ist, du musst Dich entscheiden, PCHs oder portabler Code.
    (Ich habe noch immer nicht verstanden, was an PCHs so toll sein soll, dass jemand deswegen auf Portabilität verzichten möchte; warum kannst Du nur mit PCHs vernünftig arbeiten? 😕 )

    0

  • Original erstellt von nman:
    [quote]Original erstellt von TGGC:
    [qb]Oh nein, warum sollen die denn deaktiviert sein, ich will ordentlich arbeiten?

    Weil das in der Form ein VC++-only-Feature ist, du musst Dich entscheiden, PCHs oder portabler Code.
    (Ich habe noch immer nicht verstanden, was an PCHs so toll sein soll, dass jemand deswegen auf Portabilität verzichten möchte; warum kannst Du nur mit PCHs vernünftig arbeiten? 😕 )[/QB][/QUOTE]

    Weil's viel schneller kompiliert, in dem Fall verzichte ich auf die Kompatibilität!

    0
Anmelden zum Antworten