Screenshot Thread

[Mr.Zunz]

Trials of an amateur bot project.

https://i.imgur.com/bUSQP.png

Epic.
10epic.

[FEUP]

Epic.
10epic.

qft
filler

[SKU]

Working on a GUI/learning DirectX..



Yes, the CheckBox "X" is ****ed up!

Tried to do it ".NETish", there's one observer that notifies all it's subscribers of the current event about it. Boost.Signals/2 <3.

Current controls are Label, Panel, Button, CheckBox, Form.

Example of the "main window" class in the screenshot:

class MainWindow : public CForm
{
	/*
		Just to make sure the user doesn't encounter
		name clashes with CControl/CForm members.
	*/
	struct privates_t
	{
		CPanel* pMain;	
	} privates;

public:
	MainWindow() : CForm()
	{
		OnLoad();
		SetHandlers();
	}

	virtual ~MainWindow()
	{
		/*
			The observer takes care of control deletion unless
			set otherwise.
		*/
		if (privates.pMain && !privates.pMain->GetDestroyByGui())
		{
			delete privates.pMain;
			privates.pMain = NULL;
		}
	}

private:
	void OnLoad()
	{
		SetSize(300, 200);
		SetLocation(40, 40);
		SetVisible(true);
		SetCanMove(true);
		SetTitle("SKU::MAINWINDOW");

		privates.pMain = new CPanel();
		privates.pMain->SetVisible(true);
		privates.pMain->SetSize(300, 180);
		privates.pMain->SetLocation(0, 20);
		AddSubControl(privates.pMain);
	}

	void SetHandlers()
	{
		// Just a boring window, no need for events yet.
		// Example: someCheckBox->OnChecked(boost::bind(&Menu::MainFrameCheckBox_Checked, this, privates.cbMainFrame, _2));
		// Example Callback:
		/*
			BOOL Menu::MainFrameCheckBox_Checked(CCheckBox* pThis, EventArgs* e)
			{
				privates.mainWindow->SetVisible(pThis->GetChecked());
				return DONTCARE;
			}
		*/
	}
};

Thanks to Robske, Ramey and Boost.

[Robske]

U da man dawg

[Cypher]

Working on a GUI/learning DirectX..



Yes, the CheckBox "X" is ****ed up!

Tried to do it ".NETish", there's one observer that notifies all it's subscribers of the current event about it. Boost.Signals/2 <3.

Current controls are Label, Panel, Button, CheckBox, Form.

Example of the "main window" class in the screenshot:

class MainWindow : public CForm
{
	/*
		Just to make sure the user doesn't encounter
		name clashes with CControl/CForm members.
	*/
	struct privates_t
	{
		CPanel* pMain;	
	} privates;

public:
	MainWindow() : CForm()
	{
		OnLoad();
		SetHandlers();
	}

	virtual ~MainWindow()
	{
		/*
			The observer takes care of control deletion unless
			set otherwise.
		*/
		if (privates.pMain && !privates.pMain->GetDestroyByGui())
		{
			delete privates.pMain;
			privates.pMain = NULL;
		}
	}

private:
	void OnLoad()
	{
		SetSize(300, 200);
		SetLocation(40, 40);
		SetVisible(true);
		SetCanMove(true);
		SetTitle("SKU::MAINWINDOW");

		privates.pMain = new CPanel();
		privates.pMain->SetVisible(true);
		privates.pMain->SetSize(300, 180);
		privates.pMain->SetLocation(0, 20);
		AddSubControl(privates.pMain);
	}

	void SetHandlers()
	{
		// Just a boring window, no need for events yet.
		// Example: someCheckBox->OnChecked(boost::bind(&Menu::MainFrameCheckBox_Checked, this, privates.cbMainFrame, _2));
		// Example Callback:
		/*
			BOOL Menu::MainFrameCheckBox_Checked(CCheckBox* pThis, EventArgs* e)
			{
				privates.mainWindow->SetVisible(pThis->GetChecked());
				return DONTCARE;
			}
		*/
	}
};

Thanks to Robske, Ramey and Boost.

The end result is sexy, good job. However the code is really fugly.

Are you trying to learn C++ as you go? Or is this more of a "screw it, I just wanna get it working then leave it".

If its the latter, I'd suggest doing your GUI framework in C# with just a very light C++ base (simply to inject, set up the CLR, etc).

If its the former however, I'd suggest getting a decent C++ reference, as the way you're doing things currently is (for lack of a better word) 'yuck' (and not just a little yuck, a LOT yuck).

[SKU]

The end result is sexy, good job. However the code is really fugly.

Are you trying to learn C++ as you go? Or is this more of a "screw it, I just wanna get it working then leave it".

If its the latter, I'd suggest doing your GUI framework in C# with just a very light C++ base (simply to inject, set up the CLR, etc).

If its the former however, I'd suggest getting a decent C++ reference, as the way you're doing things currently is (for lack of a better word) 'yuck' (and not just a little yuck, a LOT yuck).

First off, thanks alot for the feedback.

Right now it's really more of a 'learning' project. I have no use for it, I'm just bored and always wanted to have a DirectX based gui. I want to keep everything in C++ however, hosting a CLR is not an option.

Mind elaborating a bit on the last part? I'm really new to using boost, so I'm happy I even got the observer/subscriber stuff to work as intended. About the "struct privates_t" - that's not something I usually do, I just wrote a little class to show how one could easily create a window. I didn't put much thought into the Form -> user defined window transition yet, had other stuff to worry about. Any tips on how to get the 'yuck' out would be appreciated if you have the time and care enough.

[Cypher]

First off, thanks alot for the feedback.

Right now it's really more of a 'learning' project. I have no use for it, I'm just bored and always wanted to have a DirectX based gui. I want to keep everything in C++ however, hosting a CLR is not an option.

Mind elaborating a bit on the last part? I'm really new to using boost, so I'm happy I even got the observer/subscriber stuff to work as intended. About the "struct privates_t" - that's not something I usually do, I just wrote a little class to show how one could easily create a window. I didn't put much thought into the Form -> user defined window transition yet, had other stuff to worry about. Any tips on how to get the 'yuck' out would be appreciated if you have the time and care enough.

Unfortunately that's difficult becuase you've only posted a small snippet of the code, if you wanted to show me some more in private though I'd take a look for you.

Anyway, based on the very limited code you've posted...

General:
* On one hand, you're doing it partially C-style. With raw pointers, manual resource management, and (I assume) return codes to signify failure.
* On the other hand, you're doing it partially C++-style. With the use of Boost.Signals2, functors, binding, classes, etc.
* You should be doing it 100% C++-style (as it's obvious from your use of Boost.Signals2 that you want to use C++, not C or "C with Classes")

Suggestions:
* Get rid of the raw pointers, and use either references or smart pointers, depending on the semantics required.
* I have no idea why you think the 'privates' struct is necessary, but it shouldn't be...
* Unless your library is 100% header-only or template-based you should separate interface and implementation. That means you declare your functions in a header, then define them in a source file. It's better style and it can dramatically improve compile-times in large projects.
* Put your library in a namespace, otherwise your type names may clash with ones that the user has defined.

Small stuff:
* If your base classes destructor is explicitly virtual, then the derived classes destructor is implicitly virtual, so the qualification in MainWindow is redundant.
* Explicitly calling the constructor of the base class is unnecessary (and tbh I've never seen anyone do it before so I'm not even sure if it's legal*). Base constructors are called automatically.
* Don't prefix class names with 'C'. Just call your Form class Form, your Window class Window, etc. There should be no need to worry about naming clashes with other types, because you should be using a namespace anyway.

There's a bunch of other stuff which I assume is relevant, however without seeing more of your codebase I can't be sure so I'll just leave it at that for now.

EDIT:

* I checked and it is, I knew you could do it for parametized constructors, as that's obviously a necessity, I've just never seen anyone bother to do it for a default constructor.

[SKU]

Unfortunately that's difficult becuase you've only posted a small snippet of the code, if you wanted to show me some more in private though I'd take a look for you.

Anyway, based on the very limited code you've posted...

General:
* On one hand, you're doing it partially C-style. With raw pointers, manual resource management, and (I assume) return codes to signify failure.
My whole GUI library doesn't use many raw pointers, only Boost.shared_ptrS (except for the control containers, will changed that). No idea why I didn't use them here, guess that was a bit too rushy.

* On the other hand, you're doing it partially C++-style. With the use of Boost.Signals2, functors, binding, classes, etc.
* You should be doing it 100% C++-style (as it's obvious from your use of Boost.Signals2 that you want to use C++, not C or "C with Classes")
Indeed, and I try to do so, sometimes I'm just too lazy.

Suggestions:
* Get rid of the raw pointers, and use either references or smart pointers, depending on the semantics required.
Noted

* I have no idea why you think the 'privates' struct is necessary, but it shouldn't be...
Haha, yeah.. Was thinking if I should use some kind of special naming convention for the 'user defined members' to distinc them from the base classes' stuff, but that's just utterly retarded.

* Unless your library is 100% header-only or template-based you should separate interface and implementation. That means you declare your functions in a header, then define them in a source file. It's better style and it can dramatically improve compile-times in large projects.
Every other class in the GUI library uses source files. I retardedly started writing the example class in the library project and not in the test-exe/dll project, so I quickly made it header only... again, lazyness 4tw..

* Put your library in a namespace, otherwise your type names may clash with ones that the user has defined.
Noted

Small stuff:
* If your base classes destructor is explicitly virtual, then the derived classes destructor is implicitly virtual, so the qualification in MainWindow is redundant.
Didn't know that, thanks

* Explicitly calling the constructor of the base class is unnecessary (and tbh I've never seen anyone do it before so I'm not even sure if it's legal). Base constructors are called automatically.
Same
* Don't prefix class names with 'C'. Just call your Form class Form, your Window class Window, etc. There should be no need to worry about naming clashes with other types, because you should be using a namespace anyway.
Noted

There's a bunch of other stuff which I assume is relevant, however without seeing more of your codebase I can't be sure so I'll just leave it at that for now.

Again, thanks alot! Comments added in the quote. I really appreciate it. Once I've finished the basics of the gui, I'll completely rewrite it (again) and then I'd love to come back to you taking a closer look at the implementation. Cheers.

[Cypher]

Btw, if you're using DirectX 'raw' (i.e. without a high level wrapper), you should use CComPtr to wrap the DX interfaces. It's effectively a shared_ptr for COM objects.

P.S. You may alreayd know about and be using CComPtr, but obviously without access to your code I can't tell, so I figured I'd bring it up just in case. The more you can let the compiler automate for you, the better. RAII ftw.

[berserk85]

My first Adt tile rasterised with voxel by Recast

[namreeb]

Lookin' good!

Edit: Are you going to generate these ahead of time and load them on demand? Or will you generate them as you play?

[berserk85]

Lookin' good!

Edit: Are you going to generate these ahead of time and load them on demand? Or will you generate them as you play?

I'm going to create it one time and than use it ...

After get crazy with c array allocation (stupid me) I can get a good working CompactHeightField


Btw ... This project will not only work with Wow ^^

[Nesox]

Debugging the RaF mode for Honorbuddy

[-Ryuk-]

Debugging the RaF mode for Honorbuddy

Well done

I don't use it because I cant afford to but it looks good none the less

[Viano]

I know it is nothing for u all but I finally managed to hook notepad's MessageBoxW in C++ with the detours library