Page 3 of 5 FirstFirst 12345 LastLast
Results 31 to 45 of 63
  1. #31
    _Debug_'s Avatar
    Join Date
    Jan 2013
    Gender
    male
    Location
    Hueco Mundo
    Posts
    436
    Reputation
    20
    Thanks
    170
    My Mood
    Angelic
    Perfect menu, good job.

  2. #32
    ZysorceN's Avatar
    Join Date
    Aug 2012
    Gender
    female
    Location
    California
    Posts
    68
    Reputation
    10
    Thanks
    912
    My Mood
    Aggressive
    may i ask how is this advanced? lol

  3. #33
    arun823's Avatar
    Join Date
    Jun 2010
    Gender
    male
    Location
    Los Angeles, California
    Posts
    524
    Reputation
    151
    Thanks
    1,887
    My Mood
    Amused
    Quote Originally Posted by ZysorceN View Post
    may i ask how is this advanced? lol
    The way in which the base handles class pointers is far more advanced than what I have seen in this section so far. Advanced, in a relative meaning, but in this case, true.
    Reversing is the only way to move forward.

  4. #34
    ~FALLEN~'s Avatar
    Join Date
    May 2009
    Gender
    male
    Location
    devenv.exe
    Posts
    529
    Reputation
    23
    Thanks
    326
    My Mood
    Inspired
    Quote Originally Posted by arun823 View Post
    USSR's Advanced D3D Menu v1.0

    This is a base Shadow and I mainly coded, basically I'm tired of coding for CA, basically got plain boring, mostly every feature is public so your hack isn't even as unique.

    Anyways, this is geared for learning purposes and there are things I have taken out, such as: Pattern Scanned off bytes for addresses, Personal Hook and Detour, I have also taken out the SDK folder since it would greatly impact the upload size, other than that, the base is as I had left it. This base, in my opinion, is the most advanced pub base released so far, no lag, no memory leaks, or my pet peeve, declaring variables within a function causing it to be rendered every frame creating lag. None of that, this base is as clean as it can get.

    Also the menu colors in this picture differ from what I had changed in the base I am releasing now.

    Screenshot:



    VS: 1

    VS: 2

    Credits:
    USSR(Me)
    @Shadow`
    WTF
    NeoIII
    Kotentopf
    Gordon
    @Ch40zz-C0d3r
    DrUnKeN ChEeTaH
    Gellin

    /Approve @GenesisJr @Allen2G @BACKD00R ?
    Well, first off, you're wrong. Declaring variables within a function ( assuming you arent creating pointers / dynamically allocating on the heap, etc ) is a lot faster than using the .bss( iirc ? ) section for globals or the heap for dynamic allocation. It's closer than main memory thus less reaching and better caching. This is the exact reason why vectors perform better than lists is because with a list you transverse the list until you find the right structure, you do this by dereferencing a bunch of pointers thus making code unpredictable therefore breaking the cache. Where as with a vector it's a linear search to the element with only 1 dereference vs a bunch. Also, I haven't even downloaded and looked at the source code but I'm sure you have some sort of memory leak / resource leak / etc. -Pyro

  5. The Following 3 Users Say Thank You to ~FALLEN~ For This Useful Post:

    Acea (02-19-2013),arun823 (02-19-2013),[MPGH]Flengo (02-19-2013)

  6. #35
    Killa233's Avatar
    Join Date
    Feb 2013
    Gender
    male
    Posts
    95
    Reputation
    10
    Thanks
    10
    What SDK do you use for your base arun823

  7. #36
    arun823's Avatar
    Join Date
    Jun 2010
    Gender
    male
    Location
    Los Angeles, California
    Posts
    524
    Reputation
    151
    Thanks
    1,887
    My Mood
    Amused
    Quote Originally Posted by Killa233 View Post
    What SDK do you use for your base arun823
    NOLF 2 SDK
    /2short
    Reversing is the only way to move forward.

  8. #37
    Jason's Avatar
    Join Date
    Apr 2010
    Gender
    male
    Location
    /dev/null
    Posts
    5,706
    Reputation
    907
    Thanks
    7,297
    My Mood
    Mellow
    Quote Originally Posted by ~FALLEN~ View Post
    Well, first off, you're wrong. Declaring variables within a function ( assuming you arent creating pointers / dynamically allocating on the heap, etc ) is a lot faster than using the .bss( iirc ? ) section for globals or the heap for dynamic allocation. It's closer than main memory thus less reaching and better caching. This is the exact reason why vectors perform better than lists is because with a list you transverse the list until you find the right structure, you do this by dereferencing a bunch of pointers thus making code unpredictable therefore breaking the cache. Where as with a vector it's a linear search to the element with only 1 dereference vs a bunch. Also, I haven't even downloaded and looked at the source code but I'm sure you have some sort of memory leak / resource leak / etc. -Pyro
    So much wrong it hurts.

    First off, the access time-difference between vectors and lists have absolutely nothing to do with caching. There is a reason both data structures exist and both have their place in programming.

    A list, due to its design, is better for insertion/deletion, but doesn't perform as well for looking up elements by index as it needs to traverse the list to find the next element.
    A vector, on the other hand, is comprised of one contiguous block of memory (think of it as a dynamic-length array). Because the memory is contiguous, accessing via index (the same as array notation) is an O(1) operation, compared to a list's typical O(n). But while accessing is faster using a vector, insertion and deletion are generally slower. The choice of which to use depends on how you plan to use the data structure:

    1) Are you creating the collection once and modifying it very rarely (if at all), but frequently looking up the values? If yes, use a vector.
    2) Is you collection dynamically generated/modified often at runtime and do you not need to perform specific lookups very often? If yes, use a list.

    Just general rules of follow, the situation should dictate the choice.

    As for declaring variables within a function. Yes, sometimes it's far more appropriate to declare your variables within the function scope so that they are automatically managed on the stack. However you sometimes see people doing things like:

    Code:
    IDirect3DTexture9 *pRedTexture;
    CreateTexture(pDevice, &pRedTexture, D3DCOLOR_XRGB(255, 0, 0));
    Every single function call. I don't care who you are, creating a brand new texture every frame is a huge waste of memory and processing time. It should be created once, then stored elsewhere.
    As for:
    Declaring variables within a function ( assuming you arent creating pointers / dynamically allocating on the heap, etc ) is a lot faster than using the .bss( iirc ? ) section for globals or the heap for dynamic allocation. It's closer than main memory thus less reaching and better caching
    You should probably stop talking about caching about now, as you don't really seem to understand it. While I agree that avoiding excessive use of globals makes your code nicer to read, easier to follow and more maintainable, most of your points are incorrect.

    While allocating memory on the stack is faster than allocating memory on the heap (in most cases, depending on the current heap complexity), access times between the two should be very close to similar. The "reach" and "distance" you describe is rubbish, for all you know the stack pointer may be "further away" than the address of the value you allocated on the heap. Also, the compiler knows the location of your globals at compile time and will specify this address in all instructions involving said global.

    i.e:
    Code:
    INT iAmAGlobal = 0;
    
    int main(int argc, char **argv) {
        iAmAGlobal = 1000;
        return 0;
    }
    At assembler level would look something like this (ignoring prologue & epilogue code)
    Code:
    .main
    mov dword ptr[0xCAFE], 1000
    xor eax, eax
    ret
    Where 0xCAFE is the address of the global. Globals aren't really performance costly (AFAIK), they just introduce buggy code and readability issues far more easily than most other variables with a limited scope.

    Quote Originally Posted by Jeremy S. Anderson
    There are only two things to come out of Berkley, Unix and LSD,
    and I donít think this is a coincidence
    You can win the rat race,
    But you're still nothing but a fucking RAT.


    ++Latest Projects++
    [Open Source] Injection Library
    Simple PE Cipher
    FilthyHooker - Simple Hooking Class
    CLR Injector - Inject .NET dlls with ease
    Simple Injection - An in-depth look
    MPGH's .NET SDK
    eJect - Simple Injector
    Basic PE Explorer (BETA)

  9. The Following 4 Users Say Thank You to Jason For This Useful Post:

    arun823 (02-19-2013),[MPGH]Flengo (02-20-2013),Saltine (02-20-2013),Shadow` (02-20-2013)

  10. #38
    ~FALLEN~'s Avatar
    Join Date
    May 2009
    Gender
    male
    Location
    devenv.exe
    Posts
    529
    Reputation
    23
    Thanks
    326
    My Mood
    Inspired
    Quote Originally Posted by Jason View Post


    So much wrong it hurts.

    First off, the access time-difference between vectors and lists have absolutely nothing to do with caching. There is a reason both data structures exist and both have their place in programming.

    A list, due to its design, is better for insertion/deletion, but doesn't perform as well for looking up elements by index as it needs to traverse the list to find the next element.
    A vector, on the other hand, is comprised of one contiguous block of memory (think of it as a dynamic-length array). Because the memory is contiguous, accessing via index (the same as array notation) is an O(1) operation, compared to a list's typical O(n). But while accessing is faster using a vector, insertion and deletion are generally slower. The choice of which to use depends on how you plan to use the data structure:

    1) Are you creating the collection once and modifying it very rarely (if at all), but frequently looking up the values? If yes, use a vector.
    2) Is you collection dynamically generated/modified often at runtime and do you not need to perform specific lookups very often? If yes, use a list.

    Just general rules of follow, the situation should dictate the choice.

    As for declaring variables within a function. Yes, sometimes it's far more appropriate to declare your variables within the function scope so that they are automatically managed on the stack. However you sometimes see people doing things like:

    Code:
    IDirect3DTexture9 *pRedTexture;
    CreateTexture(pDevice, &pRedTexture, D3DCOLOR_XRGB(255, 0, 0));
    Every single function call. I don't care who you are, creating a brand new texture every frame is a huge waste of memory and processing time. It should be created once, then stored elsewhere.
    As for:


    You should probably stop talking about caching about now, as you don't really seem to understand it. While I agree that avoiding excessive use of globals makes your code nicer to read, easier to follow and more maintainable, most of your points are incorrect.

    While allocating memory on the stack is faster than allocating memory on the heap (in most cases, depending on the current heap complexity), access times between the two should be very close to similar. The "reach" and "distance" you describe is rubbish, for all you know the stack pointer may be "further away" than the address of the value you allocated on the heap. Also, the compiler knows the location of your globals at compile time and will specify this address in all instructions involving said global.

    i.e:
    Code:
    INT iAmAGlobal = 0;
    
    int main(int argc, char **argv) {
        iAmAGlobal = 1000;
        return 0;
    }
    At assembler level would look something like this (ignoring prologue & epilogue code)
    Code:
    .main
    mov dword ptr[0xCAFE], 1000
    xor eax, eax
    ret
    Where 0xCAFE is the address of the global. Globals aren't really performance costly (AFAIK), they just introduce buggy code and readability issues far more easily than most other variables with a limited scope.
    Going to quote you now.. "So much wrong it hurts. " @Jason, you should probably go re-learn c++. Vectors are far better at inserting than a list is. Bjarne stroustrup has confirmed this even, unless you know more than the person who CREATED c++?

    I know for a fact it was stated at the 0x conference -> GoingNative 2012 | Channel 9

    You can get to the insertion point faster with a vector ( reducing cache misses, because of linear searching ) to insert data. Please guy, close your mouth.

    p.s your assembly code is incorrect.
    Last edited by ~FALLEN~; 02-20-2013 at 03:54 PM.

  11. The Following 2 Users Say Thank You to ~FALLEN~ For This Useful Post:

    R4v0r (02-20-2013),ZysorceN (02-20-2013)

  12. #39
    ZysorceN's Avatar
    Join Date
    Aug 2012
    Gender
    female
    Location
    California
    Posts
    68
    Reputation
    10
    Thanks
    912
    My Mood
    Aggressive
    Quote Originally Posted by ~FALLEN~ View Post
    Going to quote you now.. "So much wrong it hurts. " @Jason, you should probably go re-learn c++. Vectors are far better at inserting than a list is. Bjarne stroustrup has confirmed this even, unless you know more than the person who CREATED c++?

    I know for a fact it was stated at the 0x conference -> GoingNative 2012 | Channel 9

    You can get to the insertion point faster with a vector ( reducing cache misses, because of linear searching ) to insert data. Please guy, close your mouth.
    Someone learned the proper way

  13. #40
    R4v0r's Avatar
    Join Date
    Nov 2012
    Gender
    male
    Location
    London
    Posts
    234
    Reputation
    11
    Thanks
    141
    My Mood
    Amazed
    Quote Originally Posted by ZysorceN View Post
    Someone learned the proper way
    Indeed, @~FALLEN~ is a C++ master

  14. #41
    Jason's Avatar
    Join Date
    Apr 2010
    Gender
    male
    Location
    /dev/null
    Posts
    5,706
    Reputation
    907
    Thanks
    7,297
    My Mood
    Mellow
    Quote Originally Posted by ~FALLEN~ View Post
    Going to quote you now.. "So much wrong it hurts. " @Jason, you should probably go re-learn c++. Vectors are far better at inserting than a list is. Bjarne stroustrup has confirmed this even, unless you know more than the person who CREATED c++?

    I know for a fact it was stated at the 0x conference -> GoingNative 2012 | Channel 9

    You can get to the insertion point faster with a vector ( reducing cache misses, because of linear searching ) to insert data. Please guy, close your mouth.

    p.s your assembly code is incorrect.
    If by "insertion" you mean push_back() then yes, inserting to the END of a vector is and amortised O(1) operation. Inserting anywhere other than the end, though...
    std::vector

    Quote Originally Posted by cplusplus
    Compared to the other dynamic sequence containers (deques, lists and forward_lists), vectors are very efficient accessing its elements (just like arrays) and relatively efficient adding or removing elements from its end. For operations that involve inserting or removing elements at positions other than the end, they perform worse than the others, and have less consistent iterators and references than lists and forward_lists.
    Pretty much exactly what I said before. Get your facts straight before you start telling people to "relearn" a language. Even bringing up the cache is such a micro-optimization for something like this that it's not really worth mentioning, and should NOT dictate your choice in data structure.

    Sure, you can "get" to the insertion point faster in a vector (in that you know where you're going to be putting your data), however if this point is anywhere other than the end of the currently used block, you're going to have to perform a memory shift to reshuffle every element at an index >= to your insertion point by 1. Imagine it like trying to insert an item into the middle of an array without overwriting the data already at the insertion point. On the other hand, with a list or deque, you simply adjust the nodes at and around the insertion point to attach them to your new list node. O(1).

    Unless you're dealing with large, rapidly changing (i.e middle inserts and deletions) data sets, vectors are generally fine for most situations.

    Sigh at all the scrubs flocking to the guy who releases their hacks.

    Quote Originally Posted by Jeremy S. Anderson
    There are only two things to come out of Berkley, Unix and LSD,
    and I donít think this is a coincidence
    You can win the rat race,
    But you're still nothing but a fucking RAT.


    ++Latest Projects++
    [Open Source] Injection Library
    Simple PE Cipher
    FilthyHooker - Simple Hooking Class
    CLR Injector - Inject .NET dlls with ease
    Simple Injection - An in-depth look
    MPGH's .NET SDK
    eJect - Simple Injector
    Basic PE Explorer (BETA)

  15. The Following 2 Users Say Thank You to Jason For This Useful Post:

    arun823 (02-20-2013),[MPGH]Flengo (02-20-2013)

  16. #42
    ~FALLEN~'s Avatar
    Join Date
    May 2009
    Gender
    male
    Location
    devenv.exe
    Posts
    529
    Reputation
    23
    Thanks
    326
    My Mood
    Inspired
    Quote Originally Posted by Jason View Post


    If by "insertion" you mean push_back() then yes, inserting to the END of a vector is and amortised O(1) operation. Inserting anywhere other than the end, though...
    std::vector



    Pretty much exactly what I said before. Get your facts straight before you start telling people to "relearn" a language. Even bringing up the cache is such a micro-optimization for something like this that it's not really worth mentioning, and should NOT dictate your choice in data structure.

    Sure, you can "get" to the insertion point faster in a vector (in that you know where you're going to be putting your data), however if this point is anywhere other than the end of the currently used block, you're going to have to perform a memory shift to reshuffle every element at an index >= to your insertion point by 1. Imagine it like trying to insert an item into the middle of an array without overwriting the data already at the insertion point. On the other hand, with a list or deque, you simply adjust the nodes at and around the insertion point to attach them to your new list node. O(1).

    Unless you're dealing with large, rapidly changing (i.e middle inserts and deletions) data sets, vectors are generally fine for most situations.

    Sigh at all the scrubs flocking to the guy who releases their hacks.
    That "shift" is where the cache comes in bro, if it's a linear data structure it's VERY cheap to MOVE values after a deletion, seriously... just check the link I showed you. A double linked list has a exponential speed hit the more and more that get's shoved into it ( as far as data access goes ) why? Because you are accessing "randomly" following a bunch of pointers and checking for the right node is a lot more expensive than even searching through n items in a vector and checking. With the dereferences ( indirections ) and various branching you would create you would be wasting countless cycles to do the same thing with a vector, which was my whole point to begin with. Look up the x86 avg assembly clock times for the different operations.

  17. #43
    Jason's Avatar
    Join Date
    Apr 2010
    Gender
    male
    Location
    /dev/null
    Posts
    5,706
    Reputation
    907
    Thanks
    7,297
    My Mood
    Mellow
    Quote Originally Posted by ~FALLEN~ View Post
    That "shift" is where the cache comes in bro, if it's a linear data structure it's VERY cheap to MOVE values after a deletion, seriously... just check the link I showed you. A double linked list has a exponential speed hit the more and more that get's shoved into it ( as far as data access goes ) why? Because you are accessing "randomly" following a bunch of pointers and checking for the right node is a lot more expensive than even searching through n items in a vector and checking. With the dereferences ( indirections ) and various branching you would create you would be wasting countless cycles to do the same thing with a vector, which was my whole point to begin with. Look up the x86 avg assembly clock times for the different operations.
    I already said index-access is SLOWER in a list, I merely pointed out that a list has a valid time and a place in programming. For instance if I don't need one continuous large block of memory and I'm never (or rarely) accessing data at a specific index of my collection, I'll use a list. I often use lists when all I'm using them for is storage and iteration. If you're going to get down to clock speeds and processor caching when thinking about which STL container to use, you should be writing your own optimised container for whatever situation you find yourself in that requires such micro-optimisation.

    Just to clarify, though, I'm agreeing with you that a vector is faster and more appropriate in this situation
    Last edited by Jason; 02-20-2013 at 08:23 PM.

    Quote Originally Posted by Jeremy S. Anderson
    There are only two things to come out of Berkley, Unix and LSD,
    and I donít think this is a coincidence
    You can win the rat race,
    But you're still nothing but a fucking RAT.


    ++Latest Projects++
    [Open Source] Injection Library
    Simple PE Cipher
    FilthyHooker - Simple Hooking Class
    CLR Injector - Inject .NET dlls with ease
    Simple Injection - An in-depth look
    MPGH's .NET SDK
    eJect - Simple Injector
    Basic PE Explorer (BETA)

  18. #44
    Flengo's Avatar
    Join Date
    May 2010
    Gender
    male
    Location
    Ontario, Canada
    Posts
    15,708
    Reputation
    3319
    Thanks
    11,133
    My Mood
    Happy
    Getting a little off-topic and entering flame.

    You guys can make your final points but if you wish to continue, you can make a thread in the discussion section or debate over it externally

    I kindly ask of that.

    Thanks
    I Read All Of My PM's & VM's
    If you need help with anything, just let me know.
     
     
    VM | PM

    Publicist Since 04.04.2015
    Middleman Since Unknown - Unknown
    Global Moderator Since 08.01.2013
    Donator Since 05.29.2013

    Minion+ Since 04.18.2013

    District 187 Minion Since 04.04.2013
    Steam Minion Since 02.26.2013
    WarRock Minion Since 02.19.2013
    A.V.A Minion Since 02.13.2013
    DayZ Minion Since 01.21.2013
    Combat Arms Minion Since 12.26.2012
    Contributor Since 11.16.2012
    Member Since 05.11.2010


  19. #45
    ~FALLEN~'s Avatar
    Join Date
    May 2009
    Gender
    male
    Location
    devenv.exe
    Posts
    529
    Reputation
    23
    Thanks
    326
    My Mood
    Inspired
    Quote Originally Posted by Jason View Post


    I already said index-access is SLOWER in a list, I merely pointed out that a list has a valid time and a place in programming. For instance if I don't need one continuous large block of memory and I'm never (or rarely) accessing data at a specific index of my collection, I'll use a list. I often use lists when all I'm using them for is storage and iteration. If you're going to get down to clock speeds and processor caching when thinking about which STL container to use, you should be writing your own optimised container for whatever situation you find yourself in that requires such micro-optimisation.
    Already have, I have my own STL, runtime, and various frameworks for different types of projects. To be honest though there are better things than lists. Maps, tables, etc. I personally look at lists towards the end if I see nothing else viable. The reason is because of the structure of a linked list ( element + 2 ptrs ( forward and back ) ) and the amount of indirection that occurs. In terms of speed you want predictable patterns, limit random access, etc. Also, if there isn't a true need for a pointer / ref, you should try to avoid them. Inlining certain things also helps. So many people here haven't a single clue on what they're doing, it's rather upsetting, Although seeing a few knowledgeable people here is refreshing. I'll be honest @Jason, you restored a little bit of my faith for this site.
    @Flengo I never saw it really as flaming, more of a discussion. We all have our own styles, preferences and knowledge to share. I hope @Jason can see it the same way.
    Last edited by ~FALLEN~; 02-20-2013 at 08:33 PM.

Page 3 of 5 FirstFirst 12345 LastLast

Similar Threads

  1. [REQUEST]How work that :Warrock D3D Menu Hack
    By taylan in forum Programming Tutorial Requests
    Replies: 0
    Last Post: 01-26-2010, 10:06 AM
  2. D3D Menu (Request)
    By AeroMan in forum Visual Basic Programming
    Replies: 9
    Last Post: 11-14-2009, 06:02 AM
  3. D3D menu Help Please....
    By ~InsaneWayne~ in forum C++/C Programming
    Replies: 14
    Last Post: 11-08-2009, 10:00 PM
  4. My D3D menu closes :| ! Source attached
    By Jammy122333 in forum C++/C Programming
    Replies: 1
    Last Post: 06-15-2008, 02:38 PM
  5. [Help]D3D Menu
    By cothen12 in forum C++/C Programming
    Replies: 13
    Last Post: 01-18-2008, 05:28 PM