USSR's Advanced D3D Menu

[_Debug_]

Perfect menu, good job.

[ZysorceN]

may i ask how is this advanced? lol

[arun823]

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.

[~FALLEN~]

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

[Killa233]

What SDK do you use for your base arun823

[arun823]

What SDK do you use for your base arun823

NOLF 2 SDK
/2short

[Jason]

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:

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:

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)

.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.

[~FALLEN~]

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:

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:

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)

.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.

[ZysorceN]

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

[R4v0r]

Someone learned the proper way

Indeed, @~FALLEN~ is a C++ master

[Jason]

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

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.

[~FALLEN~]

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.

[Jason]

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

[[MPGH]Flengo]

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

[~FALLEN~]

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.