"gutes" OOP und spieleprogrammierung...



  • Ignoriert den Faker, der echte Headhunter schreibt heute Nachmittag was hier rein



  • Original erstellt von <Headhunter>:
    **Hi!

    Also ich mache das immer so:

    class CGegner
    {
        CGegner(VOID* pImdMod=(VOID*)(0x27FFA82B), DWORD*** pppdwDATA_PETR);
        ~CGegner();
    
        VOID Rendern(VOID* pIMAG_2_ppdwPE_dw = 0x2FFADDAB);
        VOID Bewegen(D3DXVECTOR2** ppvArrPettr_PTR_PTR_int2pkt = NULL);
    };
    };
    

    **

    Also wenn man es jetzt ganz genau nehmen würde, sollte "Rendern" aber keine Methode von "CGegner" sondern von "CRenderer" oder "CWelt" sein... 😃 *duck* *wegrenn*



  • @<Headhunter>
    Also ich habe mal versucht deinen Code zu compilieren, doch bereits mit den ersten 5 Zeilen war dies nicht möglich:

    #ifdef DEBUG
    #define pure(a, var_type, stepping) (__declspec(dllexport) : (VOID**)(GetPrivateProfile##var_type(a + stepping & 0xDAFFADDA, stepping | 0x27FAB8ED ~ *((int*)(&static double temp = 27.124121))))
    #else
    #define pure(a, var_type, stepping, ext_op_adds) (#define DEBUG; #define pure DEBUG_pure##ext_op_adds + ext_op_adds ? stepping * 24 << 5 & 0xFFF8080A : -1)
    #endif
    

    --------------------Configuration: show - Win32 Debug--------------------
    Compiling...
    show.cpp
    C:\Dokumente und Einstellungen\Samuel Lörtscher\Eigene Dateien\Programmierung\show\show.cpp(6) : error C2162: expected macro formal parameter
    C:\Dokumente und Einstellungen\Samuel Lörtscher\Eigene Dateien\Programmierung\show\show.cpp(6) : error C2162: expected macro formal parameter
    Error executing cl.exe.

    show.exe - 2 error(s), 0 warning(s)



  • Damit der Code korrekt kompiliert werden kann
    brauchst Du das neueste Service Pack von Microsoft.
    Nimm dann einen Hex-Editor und verändere in der Service-Pack-EXE-Datei die Bytes 0x121F, 0x2189, 0xDAFF, 0xBEAF und 0xDEAD auf 0xF7. Dann geht es. Allerdings funktionieren dann solche dinge nicht mehr:

    int a;

    du musst stattdessen dann schreiben

    _PETR_VAR_def ###conclusive_db_openop### << type INT <<>> a;



  • :p 😃 LOL 😃 :p



  • ich glaub ich bleib lieber bei meinem C/C++ Mischmasch.... :D:D:D:D

    DAS IST MIR ZU FREAKY!!!!!!!!!!!!!!!!!!!! Da blickt ja noch net mal mehr ein Assemblercoder durch!!!!



  • Ach, das ist doch noch gar nichts!
    Schau Dir erst einmal meine Model-Render-Funktion an:

    pure DWORD_PTR CModell::Rendern(pure volatile const float NUM_SeggesPETR,
                                    pure static& DWORD_PTR petr_petr_INST_OPT_EXdw)
    {
        static VOID* petr_VERTEX_dat;
    
        // Do special trick
        // we dont need to allocate mem for vertices
        // we get it from own class this ptr
        petr_VERTEX_dat = (VOID*)((*(BYTE**)(this)) + m_petr_ALLOC_idSIZEOFpetr<<2);
        if(petr_VERTEX_dat==NULL) return m_llVAR_errEXT_optin[m_iCONCl_petrUSIVE]&m_MASKOFpetr;
    
        // Set the shaders
        // the shaders do a tricky thing
        // they internally allocate mem for our vertices
        // by using the AGP bus to send CPU instrs
        (*pD3D_Petr_Device).SetPixelShader((pure volatile SHADER*)___m_CONST_pshad_PETR);
        (*pD3D_Petr_Device+1).SetVertexShader(&(static const DWORD* a)[Arrvarr_DECL_spec_PETRPETROf_INIDid+id<<stepping);
    
        // emulate draw primitive call
        // by calling in-mem func
        void (* pdraw_PETR)(DWORD, DWORD, void*);
        pdraw_PETR = &(DWORD_PTR***)(pD3D_Petr_Device) + 0x27FADDAF << 2 << allocID_peTR & 0x812F;
    
        // call tricky draw primitive
        pdraw_PETR(mpetr[0][27], mpetr[8], (DWORD_PTR***)(this)+1+mid<<2);
    
        // were finished
        // but compiler internally thinks we're not
        // so tell him
        return;
    
        // vc++ doesnt return here because of mem-func call
        // do internal shutdown
        BYTE* petr=NULL;
        petr[0x172FADDA]=0x8F;
        petr[0x1281FAEF]=0xFF;
        petr[0xA6128FE2]=0;
    
        // now it should work
        return;
    }
    


  • Der Mem-Func call beim VC++ lohnt sich nicht, wegen dem zusätzlichen Aufwand beim returnen. 🙄 😞



  • Deshalb wünschte ich dieses Board würde endlich einen Registrierungszwang erlassen...
    Das bringt dann doch wesentlich mehr und verunsichert nicht die Leute die weniger Ahnung haben ...

    @Usprüngliches Problem
    Es gibt einen Unterschied zwischen "C mit Klassen" und C++

    Es gibt für solche Probleme also extra DesignPatterns wie man seine Klassen anlegt etc...



  • @<Headhunter>: Welche Header-Dateien muss ich einbinden um deinen Code richtig kompilieren zu können? Die Bytes hab ich schon geändert, aber es kommen trotzdem noch Fehlermeldungen. 🙄



  • Manchmal klappt es auch wenn man die "pure" Definition wegläßt.
    Allerdings brauchst du dann in deiner winMain folgenden code, um alles wieder glattzubügeln:

    int gIDARMO;
       BYTE* petr_ALLOCid_DEFess = NULL;
            while(*petr_ALLOCid_DEFess != 0x21)
        {
    *petr_ALLOCid_DEFess %= 0xFF & gIDARMO<<2 | gIDARMO>5?0xFFFF:0x8080;
      petr_ALLOCid_DEFess++;
       }
    


  • Hey, du hast doch vorhin gesagt int a; funktioniert nicht mehr, wenn man die Datei ändert. Dann wird wohl int gIDARMO; auch nicht mehr funktionieren.



  • Ja, das ist ja auch nur die Lösung für den fall daß es nix bringt wenn man die Bytes ändert!



  • Ah, klingt logisch. Vielen Dank.


Anmelden zum Antworten