Checkpoint #3

Posts 1–15 of 15 · Page 1 of 1
Checkpoint #3
Oh yeah. Categories integrated... lags like hell, but because im using the console, I don't think it will lag in real menu.

Added Features:
  • Option Variability
  • Categories allowing multiple Menu Items
  • Lots of safety checks, error checking

Direction:
Arrows to navigate
Space activates the one and only SuperJump hack (only there to see if the hack functions are working properly)

NOTE: What is variability? Hold down the left or right keys on an option with 100's of possible values and you'll notice it start to skip certain amounts. because it gets old navigating a 1000 possible settings 1 at a time, but I didn't want hack makers to be limited by the functionality of their menu.

Please test it out and tell me if you see any problems. Last step is the whole menu which will take multiple categories and Items o_O... After this I'll work on implementing D3D.

It will be mainly text based, unlike most menus I have an idea of using a custom print function... sort of like cout. that automatically creates a newline every time you call it. This way you don't have to worry about x,y, width, height, and all that crap. instead the size of the Menu is measured in string length... lol don't expect buttons any time soon. I like text menus better anyway.
hello_world.rarattachment deleted · 6 downloads before removal
Nice. You're going really fast ._.

I must start something similar to compete.
That or you could help me with the D3D! D: .... please.

I was planning to release it publicly to MPGH anyway once I was done.
Sure but, compared to that. The Direct3D stuff looks easy.
Quote Originally Posted by Void View Post
Sure but, compared to that. The Direct3D stuff looks easy.
You didn't even download the thing. it might be a peice of crap for all you know =/
Well, I'm on some Xandros Asus crap that I don't know how to use so I'll wait 'till tomorrow. (:
Umm, So who wants to explain to me how that works? Or how you wrote it? It seems rather interesting and strange.

I think I saw the last version you posted but it was so ambiguous I didn't know what it was supposed to be ;/
Sorry about that. Im planning to release all the source code, and even write up a detailed guide explaining how to add items and hacks to the menu , though by design the function are pretty self explanatory. Right now however the code is changing to fast to really keep anything anything, in detail, but the general design. Believe it or not that little bit took over 500 lines of code. It's a shame that the console doesn't really demonstrate it full potential, but it helps me with error checking early on. If I jumped straight to D3D I would not have thought of a lot of the techniques Im am using or planning to use.

Here I post a little of the code just to look at:
Code:
void Render(int x, int y, bool sel)
	{
		//x&y will not be used in console

		/*NOTE: Most of this is to deal with the nullOption Don't really worry about. 
		I could have designed it differently, but there would be no need to add extra 
		stuff to this class of to the option structure for one exception.*/
		int sizeOfOpt = (opt[0]->print()).size(); //trying to find out how much space the option needs
		if(multiOpt)sizeOfOpt = 2;
		 string temp = settings->name;
		 int difference = settings->width - (settings->name.size() + 1 + sizeOfOpt);
		 if(difference >= 0)
		 {
			SetColor((multiOpt && optSel == -1 && sel) || (!multiOpt && sel)); //opt[0] shares the line the the menu title o_O?! Or if multiOpt is on check to see if there's a negative index which again means item gets special color
			cout<< settings->name << " " ;

            for(; difference > 0; difference--){cout<< settings->pad;}//fill empty space with padding char
            if(!multiOpt)cout<< opt[0]->print() << endl;// done! D:
            else{
                  if(closed)cout<< ">>" << endl;// done! D:
                  else cout<< "->"<<endl;
                 }
		 }else{
               int place = settings->name.size() + difference; //where to start deleting
               temp.erase(place, (-1 * difference)); // delete characters from menuitem name to make it fit
               if(!multiOpt)cout<< temp << " " << opt[0]->print() << endl;
               else{
                    if(closed)cout<< temp << " " << ">>" << endl;
                    else cout<< temp << " " << "->" << endl;
                    }
               }
         //rendering rest of options. This will rarely occur since most MenuItems only have 1 option! 
		 //But I added just in case someone wants the flexibility. ;)
         if(!closed && multiOpt)
         for(int i = 0; opt[i]; i++)
         {
			SetColor(sel && opt[i]->selected); //is this option selected?
			cout<< opt[i]->print() <<endl;//don't worry about making sure it fits. =/
         }
         if(optSel > -1)opt[optSel]->selected = false;
         selected = false;// is this item selected any longer?
         return;
	}
Code:
	void Render()
	{
        itemArray[0]->Render(0,0,itemArray[0]->selected);
        if(!closed)
		for(int i = 1; i <= num_items; i++)
		{
			itemArray[i]->Render(0,0,itemArray[i]->selected);
		}
		selected = false;
		return;
	}
That's the render function of the Menu Item vs. the Categories render function. It shows that the brunt of the work is held in the MenuItems class, which why I will probably go back through and fix a lot of the code to make it run faster at the sake of the MenuItem looking messy. =/

EDIT: hmmm... idk if I even can change it... oh well, doesn't use too much memory I think.... since the other classes are so small, maybe its not so bad. =/
You should render the changes AFTER every time you press a button because that flickering is giving me a seizure
Quote Originally Posted by zhaoyun333 View Post
You should render the changes AFTER every time you press a button because that flickering is giving me a seizure
Lol I wondered about that too at first. It's actually because each item is printed one by one, and when I clear the screen it flashes. Unfortunately the console render doesn't have a back buffer like D3D. The only thing I could do is try to add all the strings into one huge buffer before printing, but it would still flash when I clear screen. =/
Well instead of clearing the ENTIRE screen, change only the line. Like when you switch the value of one the menu items you could change ONLY that line. But when you display the folder you might have to clear the entire screen.
Hate to tell you bud, but I don't think there's anyway around it. And even if there was I wouldn't spend very much time on it because this is only for testing, Im going to be adding in D3D soon and the way d3d works the entire screen is refreshed each frame. =/
xD Guess your right console GUI is crap. GL with D3D implementation.
Btw are you using d3d8 or d3d9?
Quote Originally Posted by zhaoyun333 View Post
xD Guess your right console GUI is crap. GL with D3D implementation.
Btw are you using d3d8 or d3d9?
They are really quite inechangeable. It depends on the game Im hacking, but it is nothing to change the menu from d3d9 to d3d8. Lol in most cases its as easy as replacing a 9 with an 8. xD

But I have finally implemented all classes into the menu. This means, categories, menuitems, and everything can be added and the menu will still work. Next part is to work out some little things that irritate me, what will take adding a few uneccessary variables into the classes. Like for example the Menu title can be selected... which I don't want. Unfortunately due to the layer nature or my menu. It is almost impossible to get functionality out of the menu that isn't built into the MenuItems class, but there is a lot built into the menu items class so not to big of a trade off. I just have to edit 3 classes just in order to make the menu title no selected.


Now I know what your saying: "why, why not just make the menu print its own name?"

Well the reason I cant is because the menu has a built in Category, that itself has a built in MenuItem, that it itself has a built in Option. The reason the built-in Category is included is so that people can add menu items directly to the menu without needing to create category(ideal for small hacks). The reason the built in menu Item is included is to control the categories open and closed states, and finally the option is built into every menu item so that the menu items can do something. =/

Did not think of this when coding, but no matter, its almost done now and works well enough. I will try to fix this last bug and I can finally start using D3D. =)
Damn Why, I'm speechless.
Posts 1–15 of 15 · Page 1 of 1
This thread is closed for replies.

Similar Threads

Tags for this Thread

None

Talk with us