Explosion : Scabbical[Topblast base v1.6][Multi-Threading, Integrated Settings, Plus]

[topblast]

Present isn't in another thread. Unless you explicitly spawn threads from with your hooked present, it will be executed from within the game's main thread. Just because you hook is defined within your dll, when it's actually called it will be called from whatever thread called Present in the first place as you're just redirecting execution into your function from whatever thread was calling Present.

While it's true that single-core processors can handle multiple threads, it's not actually the same as multi-threading on a multi-core machine. Basically what happens on a single core system is that the processor rapidly context-switches between the various existing threads according to its task scheduler, it does this so rapidly that it appears all threads are running concurrently, when in reality only 1 thread at a time is being handled. Multiple core systems are capable of running a number of threads proportionate to the number of cores (except with processors capable of hyper-threading).

I see, so i was thinking of rebuilding the base in general, and I came up with basic threads 3 threads (at run time)

• Hooked Present/ What ever
• HackThread
• Menu Thread

in the current base each menu will have its own thread, and that can be stress on a processor if to much menus are used. What i guess i can do is like how the Present and stuff have Frame per second, the menu thread can have Menus per second, and using this measurement change the sleep time. Because as more and more menus are being added the MPS will slow, and since the Input Operations and Drawing are all done on the Menu thread a varying Sleep time will keep the Menus well times.

The Menus will be rendered in the Menu thread simply, a static array of Menus are all drawn in a for loop(cant wait till C++ AMP to test that stuff in this base). a Value in the Menu class to tell if the menu is initialized or not.

Note: A lot of people must be saying that I am wasting my time with all this stuff in for these public bases. I will tell u this, I program for fun , I like to challenge myself. And mostly the VIP people are making they stuff and keeping it all to them self, and forgetting where most of them came from, THE PUBLIC HACK ZONE.

[Jason]

Well, in reality I think you should be focusing more on optimizing your drawing methods than trying to spawn a dickload of threads everwhere, as well as optimizing the way you render menus.

Consider this: Most D3D applications don't leverage threading for their drawing. They are capable of drawing large scenes at 60FPS or whatever in a single thread, drawing some simple boxes and text for your menu shouldn't be much more on top of the numerous models they create and draw every second.

Fuck threading, look into caching. There's a lot of increased performance to be had there.

I.e:

You menu isn't moving at the moment? Cache the textures and all the drawing info, no need to rape the GPU with continuous texture locks every frame. Until the menu repositions itself there is no reason to keep putting textures into video memory.

That's just one example, if you have more knowledge about D3D there are undoubtedly heaps of ways to reduce how much unnecessary processing you do every scene.

[topblast]

Well, in reality I think you should be focusing more on optimizing your drawing methods than trying to spawn a dickload of threads everwhere, as well as optimizing the way you render menus.

Consider this: Most D3D applications don't leverage threading for their drawing. They are capable of drawing large scenes at 60FPS or whatever in a single thread, drawing some simple boxes and text for your menu shouldn't be much more on top of the numerous models they create and draw every second.

Fuck threading, look into caching. There's a lot of increased performance to be had there.

I.e:

You menu isn't moving at the moment? Cache the textures and all the drawing info, no need to rape the GPU with continuous texture locks every frame. Until the menu repositions itself there is no reason to keep putting textures into video memory.

That's just one example, if you have more knowledge about D3D there are undoubtedly heaps of ways to reduce how much unnecessary processing you do every scene.

Thats true, but those application have the everything drawn from scratch, and my drawin method is already pretty much optimized. Where all the boxes and stuff are first stacked, then drawn as one. instead of drawing all of them individually.

[Shadow`]

Wow dude, just went through the code and I have to say this is very impressive!

[.DLL]

Gonna use this a menu test. X)
Nice release. :3

[kevinsel]

thank you work base file

[demtrios]

Good Job Bro !

[topblast]

Thanks, still noone can make a hack with it I bet ur all just stealing the detours

[supercarz1991]

who knows. i'm sure there will be a hack eventually

[topblast]

yea wee see about that

[supercarz1991]

yea wee see about that

what i honestly believe it is, is the fact maybe this base is too "advanced" for the coder level of this section, and it's scaring some coders off since we haven't ever seen "multi-thread" and such before

[demtrios]

Good Job Bro !

[topblast]

Good Job Bro !

STFU already

---------- Post added at 02:15 PM ---------- Previous post was at 02:14 PM ----------

what i honestly believe it is, is the fact maybe this base is too "advanced" for the coder level of this section, and it's scaring some coders off since we haven't ever seen "multi-thread" and such before

the whole purpose of this base is so they can learn something new. A coder look at me and told me the only way to get a EXE to call is DLL is to hook it.

[demtrios]

I've even forgotten what had already been commented bad ta not know if the English is very good 'cause I used the google translator XD

[iDarkness]

Nice. Ima try and make a lil d3d for CA EU.