RECT (rectangle) class additions. Are they are useful?

[Ulf]

I am working on making a game engine. 2D Raster type graphics to start with. In doing so, I am taking my time and immersing myself in each aspect of the engine development rather than just getting sprites drawing and moving, then trying to make a game.

Straight away I needed some extra functions in the RECT class. I didn't see them in the code.
I know this is simple, but I wanted to know if it's useful for everyone in general. I found them necessary, or at least practical.

I'm also working on adding extra mouse buttons into irrlicht, and a double click event. I've done the double click event, and the extra buttons for Windows, though untested yet. I can upload the changes I made to the irrlicht files later if anyone is interested.
I built the double click straight into the engine rather than changing the IGUIEnvironment and CGUIEnvironment as jox did for some unknown obscure reason?? (http://irrlicht.sourceforge.net/phpBB2/ ... uble+click).
I don't think jox's code works , certainly doesn't look like it.

Anyway

Here's the rect code

Code: Select all

//! (Re)Sets the rectangle to the parameters
void set(T x, T y, T x2, T y2)
{//! Modified by Ulf
	UpperLeftCorner.X = x;
	UpperLeftCorner.Y = y;
	LowerRightCorner.X = x2;
	LowerRightCorner.Y = y2;
}

//! (Re)Sets the rectangle to the parameters
void set(const position2d<T>& upperLeft, const position2d<T>& lowerRight)
{//! Modified by Ulf
	UpperLeftCorner.X = upperLeft.X;
	UpperLeftCorner.Y = upperLeft.Y;
	LowerRightCorner.X = lowerRight.X;
	LowerRightCorner.Y = lowerRight.Y;
}

//! (Re)Sets the rectangle so that it keeps the same dimensions, but anchors its Upper left corner at the position given.
void setUpperLeft(const position2d<T>& upperLeft)
{//! Modified by Ulf
	T w = LowerRightCorner.X - UpperLeftCorner.X;
	T h = LowerRightCorner.Y - UpperLeftCorner.Y;

	UpperLeftCorner.X = upperLeft.X;
	UpperLeftCorner.Y = upperLeft.Y;
	LowerRightCorner.X = upperLeft.X + w;
	LowerRightCorner.Y = upperLeft.Y + h;
}

//! (Re)Sets the rectangle so that it keeps the same dimensions, but anchors its left side at the position given.
void setLeft(T left)
{//! Modified by Ulf
	T w = LowerRightCorner.X - UpperLeftCorner.X;

	UpperLeftCorner.X = left;
	LowerRightCorner.X = left + w;
}

//! (Re)Sets the rectangle so that it keeps the same dimensions, but anchors its top side at the position given.
void setTop(T top)
{//! Modified by Ulf
	T h = LowerRightCorner.Y - UpperLeftCorner.Y;

	UpperLeftCorner.Y = top;
	LowerRightCorner.Y = top + h;
}

//! (Re)Sets the rectangle so that it keeps the same dimensions, but anchors its Lower right corner at the position given.
void setLowerRight(const position2d<T>& lowerRight)
{//! Modified by Ulf
	T w = LowerRightCorner.X - UpperLeftCorner.X;
	T h = LowerRightCorner.Y - UpperLeftCorner.Y;

	LowerRightCorner.X = lowerRight.X;
	LowerRightCorner.Y = lowerRight.Y;
	UpperLeftCorner.X = lowerRight.X - w;
	UpperLeftCorner.Y = lowerRight.Y - h;
}

//! (Re)Sets the rectangle so that it keeps the same dimensions, but anchors its right side at the position given.
void setRight(T right)
{//! Modified by Ulf
	T w = LowerRightCorner.X - UpperLeftCorner.X;

	LowerRightCorner.X = right;
	UpperLeftCorner.X = right - w;
}

//! (Re)Sets the rectangle so that it keeps the same dimensions, but anchors its bottom side at the position given.
void setBottom(T bottom)
{//! Modified by Ulf
	T h = LowerRightCorner.Y - UpperLeftCorner.Y;

	LowerRightCorner.Y = bottom;
	UpperLeftCorner.Y = bottom - h;
}

//! (Re)Sets the rectangle so that it keeps the same dimensions, but offsets its Upper left and Lower right X positions.
void offsetX(T x)
{//! Modified by Ulf
	UpperLeftCorner.X += x;
	LowerRightCorner.X += x;
}

//! (Re)Sets the rectangle so that it keeps the same dimensions, but offsets its Upper left and Lower right Y positions.
void offsetY(T y)
{//! Modified by Ulf
	UpperLeftCorner.Y += y;
	LowerRightCorner.Y += y;
}

//! (Re)Sets the rectangle so that it maintains its Upper left position, but changes its dimensions.
void setDimensions(const position2d<T>& size)
{//! Modified by Ulf
	LowerRightCorner.X = UpperLeftCorner.X + size.X;
	LowerRightCorner.Y = UpperLeftCorner.Y + size.Y;
}

//! (Re)Sets the rectangle so that it maintains its Upper left position, but changes its dimensions.
void setDimensions(const dimension2d<T>& size)
{//! Modified by Ulf
	LowerRightCorner.X = UpperLeftCorner.X + size.Width;
	LowerRightCorner.Y = UpperLeftCorner.Y + size.Height;
}

//! increases or decreases the width and height of the specified rectangle.
/** The InflateRect function adds xInflate units to the left and right ends of the rectangle and yInflate units to the top and bottom. */
void inflate(const T xInflate, const T yInflate)
{//! Modified by Ulf
	UpperLeftCorner.X -= xInflate;
	UpperLeftCorner.Y -= yInflate;
	LowerRightCorner.X += iXShrink;
	LowerRightCorner.Y += iYShrink;
}

void inflate(const position2d<T>& ptInflate)
{//! Modified by Ulf
	UpperLeftCorner.X -= ptInflate.X;
	UpperLeftCorner.Y -= ptInflate.Y;
	LowerRightCorner.X += ptInflate.X;
	LowerRightCorner.Y += ptInflate.Y;
}

//! Returns the Lower Left position.
position2d<T> getLowerLeft() const
{//! Modified by Ulf
	return position2d<T>(UpperLeftCorner.X, LowerRightCorner.Y);
}

Also, there should be typedef's for int and float rect as follows.

Code: Select all

//! Typedef for an f32 rect.
typedef rect<f32> rectf;	//! Modified by Ulf

//! Typedef for an s32 rect.
typedef rect<s32> recti;	//! Modified by Ulf

Is any of it useful?

[CuteAlien]

For double-clicks - certainly useful, but should preferably be platform independent. And that might even be the reason why they are not in yet (at least the reason why I have not added my patch for that so far), because doing that is a little more work than just passing on the corresponding events. X11 does not have an event for this, so we need to care about double-click time ourselves. Which now leaves the question - what to use on Windows if we already have to care about time in the engine: The own double-click, just the system-double-click or an own double-click initialized with system-time for double-clicks? Not sure what others would prefer here. Also there's the question if a doubleclick-event is additionally a click-event.
Feedback on that always welcome - I haven't found time yet to dig deeper into that. But it's something I've already missed myself a few times.

rectf and recti have already been added in svn and will be available in 1.6.

For others:
set would be fine, but I'm not sure if set or setRect should be used as other irrlicht classes mix that (plane uses "setPlane", vector uses just "set" for example). As other classes have similar set functions it probably should belong in rect.

setUpperLeft is imho the wrong name as it sounds like setting UpperLeftCorner which it doesn't. moveTo or setPosition would probably be better.

For the rest - I never missed them as they are all easy to code in 1-2 lines on need and it would inflate the interface a lot. So, not sure...

Also I think inflate wouldn't compile so far, did you test? ;-)

[Ulf]

For double-clicks - certainly useful, but should preferably be platform independent. And that might even be the reason why they are not in yet (at least the reason why I have not added my patch for that so far), because doing that is a little more work than just passing on the corresponding events.

Where is the extra work?
This is how I did the double click. It's simple. It's platform independent. I based it on jox's idea, but it works perfectly and makes sense.

Add the following in "CIrrDeviceStub.h"

Code: Select all

//! Added by Ulf
//! Used internaly by the IrrDevices to check if a double-click has occured.
virtual bool isDoubleClick(const SEvent& event, u32 time);

//! Added by Ulf
//! Sets the double-click speed in milliseconds.
virtual void setDoubleClickSpeed(u32 speed);

//! Added by Ulf
//! Used internaly by the IrrDevices to check if a double-click has occured.
struct SDoubleClick 
{
	SDoubleClick() : Speed(300),Time(0), X(0), Y(0), Type(EMIE_COUNT) {}
	u32 Speed; // speed in milliseconds
	u32 Time;  // time of last click
	s32 X, Y;  // mouse coordinates of last click
	EMOUSE_INPUT_EVENT Type;	// type of event e.g. EMIE_LMOUSE_DOUBLE_CLICKED
};
SDoubleClick DoubleClick;

And Add the following in "CIrrDeviceStub.cpp"

Code: Select all

//! Added by Ulf
//! Used internaly by the IrrDevices to check if a double-click has occured.
bool CIrrDeviceStub::isDoubleClick(const SEvent& event, u32 time)
{
	bool isDoubleClick = false;

	if (time - DoubleClick.Time < DoubleClick.Speed // make sure the 2nd click has happened within the double click speed
		&& DoubleClick.Type == event.MouseInput.Event // make sure it's the same mouse button
		&& event.MouseInput.X == DoubleClick.X // make sure the mouse hasn't moved
		&& event.MouseInput.Y == DoubleClick.Y)
	{
		/** Note: This is a double click, so set the double click time to 0
		so the next click can't be a double click. */
		DoubleClick.Time = 0;
		isDoubleClick = true;
	}
	else 
	{
		/** Note: This is the first click, so set the double click time to the
		click time so we can check for double click later. */
		DoubleClick.Time = time;
	}
	//! Set location of mouse click so we can check if the mouse moved since last click.
	DoubleClick.X = event.MouseInput.X;
	DoubleClick.Y = event.MouseInput.Y;

	//! Set the event type so we can check if it's the same mouse button as the previous click.
	DoubleClick.Type = event.MouseInput.Event;

	return isDoubleClick;
}

//! Added by Ulf
//! Sets the double-click speed in milliseconds.
void CIrrDeviceStub::setDoubleClickSpeed(u32 speed)
{
	DoubleClick.Speed = speed;
}

Then in each implementation of the device such as in "CIrrDeviceWin32.cpp" put the following:

Code: Select all

//! Modified by Ulf
/** Note: Now takes care of double clicks. */
case WM_LBUTTONDOWN:
	++ClickCount; //! Modified by Ulf
	SetCapture(hWnd);
	event.EventType = irr::EET_MOUSE_INPUT_EVENT;
	event.MouseInput.Event = irr::EMIE_LMOUSE_PRESSED_DOWN;
	event.MouseInput.X = (short)LOWORD(lParam);
	event.MouseInput.Y = (short)HIWORD(lParam);
	dev = getDeviceFromHWnd(hWnd);
	if (dev)
	{
		//! Get click time as soon as we can.
		irr::u32 clickTime = dev->getTimer()->getTime();

		//! Post the left button press event
		dev->postEventFromUser(event);

		//! Post a double click event if it was a double click.
		if (dev->isDoubleClick(event, clickTime))
		{
			event.MouseInput.Event = irr::EMIE_LMOUSE_DOUBLE_CLICKED;
			dev->postEventFromUser(event);
		}
	}
	return 0;

Note: Obviously, it needs to be done for each button.

Or for Linux "CirrDeciceLinux.cpp" put:

Code: Select all

case ButtonPress:
	//! Added by Ulf
	//! Get click time as soon as we can. For double click checking.
	irr::u32 clickTime = this->getTimer()->getTime();

case ButtonRelease:
	irrevent.EventType = irr::EET_MOUSE_INPUT_EVENT;
	irrevent.MouseInput.X = event.xbutton.x;
	irrevent.MouseInput.Y = event.xbutton.y;

	irrevent.MouseInput.Event = irr::EMIE_COUNT;

        switch(event.xbutton.button)
	{
	case  Button1:
		irrevent.MouseInput.Event =
			(event.type == ButtonPress) ? irr::EMIE_LMOUSE_PRESSED_DOWN : irr::EMIE_LMOUSE_LEFT_UP;
		break;

	case  Button3:
		irrevent.MouseInput.Event =
			(event.type == ButtonPress) ? irr::EMIE_RMOUSE_PRESSED_DOWN : irr::EMIE_RMOUSE_LEFT_UP;
		break;

	case  Button2:
		irrevent.MouseInput.Event =
			(event.type == ButtonPress) ? irr::EMIE_MMOUSE_PRESSED_DOWN : irr::EMIE_MMOUSE_LEFT_UP;
		break;

	case  Button4:
		irrevent.MouseInput.Event = EMIE_MOUSE_WHEEL;
		irrevent.MouseInput.Wheel = 1.0f;
		break;

	case  Button5:
		irrevent.MouseInput.Event = EMIE_MOUSE_WHEEL;
		irrevent.MouseInput.Wheel = -1.0f;
		break;
	}

        if (irrevent.MouseInput.Event != irr::EMIE_COUNT)
	{
                //! Post the button press event
		postEventFromUser(irrevent);
	
		//! Added by Ulf
		//! Post a double click event, if it was a double click.
		if (this->isDoubleClick(event, clickTime))
		{
			switch (event.MouseInput.Event)
			{
			case EMIE_LMOUSE_PRESSED_DOWN:
				event.MouseInput.Event = irr::EMIE_LMOUSE_DOUBLE_CLICKED;
				break;
			case EMIE_RMOUSE_PRESSED_DOWN:
				event.MouseInput.Event = irr::EMIE_LMOUSE_DOUBLE_CLICKED;
				break;
			case EMIE_MMOUSE_PRESSED_DOWN:
				event.MouseInput.Event = irr::EMIE_LMOUSE_DOUBLE_CLICKED;
				break;
			}
			dev->postEventFromUser(event);
		}
	}
	break;

That's all 3 buttons in Linux.

And.. That's it! for Windows and Linux.

By the way, which is the MAC implementation? What is the SDL implementation? Is that for Windows? I haven't looked at it yet.

X11 does not have an event for this, so we need to care about double-click time ourselves. Which now leaves the question - what to use on Windows if we already have to care about time in the engine: The own double-click, just the system-double-click or an own double-click initialized with system-time for double-clicks?

Maybe for it to be consistent between platforms it should NOT use the Windows built in double click events e.g. WM_LBUTTONDBLCLK. But I don't think it really matters too much. It's just timing.
Or maybe it should use WM_LBUTTONDBLCLK because windows is already handling the event so it would be more efficient, matching the efficiency of the Linux implementation that I provided..?

Not sure what others would prefer here. Also there's the question if a doubleclick-event is additionally a click-event.

I believe that in Windows a double click posts a click event, then a double click event. Can anyone confirm?
Also that seems to be the general consensus as far as what is wanted or needed. It is still a click after all! Yes?

Feedback on that always welcome - I haven't found time yet to dig deeper into that. But it's something I've already missed myself a few times.

Great, cause I want to improve it... and I have!
I think so.

For others:
set would be fine, but I'm not sure if set or setRect should be used as other irrlicht classes mix that (plane uses "setPlane", vector uses just "set" for example). As other classes have similar set functions it probably should belong in rect.

"set" functions should definitely be in rect. It makes it easier for all other classes that use its functionality. As you said, several classes implement it!

setUpperLeft is imho the wrong name as it sounds like setting UpperLeftCorner which it doesn't. moveTo or setPosition would probably be better.

Agreed. Sort of.
It is actually setting the Upper Left Corner, and keeping the same dimensions. I don't know, anyone, opinions?

For the rest - I never missed them as they are all easy to code in 1-2 lines on need and it would inflate the interface a lot. So, not sure...

I think all the set functions are useful. SetLeft, SetTop etc. though possibly they should be named something like MoveLeftTo, MoveTopTo.

I also think the setDimensions might be often used, so the user doesn't have to set the members individually.

The offset functions also make life easier for adjustments.

The way I did it, you can basically adjust and move the rect in every practical way in just one line of code. That is useful!

I don't see it as bloat. It's not much code, and it makes the rect class very powerful from a user perspective. It makes all the code using rect more elegant.
If it is easy to code but often used then it's not actually a waste of time to have is it?

Also I think inflate wouldn't compile so far, did you test?

Yes inflate compiles and works. Why wouldn't it?

By the way, CuteAlien, thanks for the great feedback.


Note: All this code works. I am implementing extra buttons into my irrlicht too!
So any help and knowledge from anyone about extra mouse buttons would be great.

For example, can more than 3 buttons be accessed in Linux?
It only seems to have 5 buttons defined, and 4 and 5 are the mouse wheel.
I know that doesn't mean more buttons can't be accessed.
So, what I wanted to know is, do extra mouse buttons in Linux work same as in Windows, as follows:
/* XButton values are WORD flags */
#define XBUTTON1 0x0001
#define XBUTTON2 0x0002
/* Were there to be an XBUTTON3, its value would be 0x0004 */

More precisely, I mean, in Linux are Button1 to Button5 defined as values 1, 2, 4, 8, 16.
And are the extra buttons accessed as values 32, 64, 128 and so on?
Or are there only 3 actual mouse buttons in Linux event system?

PS. I think inflate is useful. Also, getLowerLeft is useful for game programming when you want to order 2D sprites for drawing, based on y position. You need the lower left, not upper left.
I don't know if getLowerLeft is useful in other applications.

[Ulf]

My quote:

I believe that in Windows a double click posts a click event, then a double click event. Can anyone confirm?
Also that seems to be the general consensus as far as what is wanted or needed. It is still a click after all! Yes?

One point.
It MUST post a click event, and then a double click.
Or else when you don't do anything for double clicks, you won't receive the 2nd click event! Yes? Yes.

[hybrid]

Also I think inflate wouldn't compile so far, did you test?

Yes inflate compiles and works. Why wouldn't it?

Because you have used a wrong parameter name.

A general question: Where's set to be favored over assignment of a newly generated object? so writing r.set(x,y,z,a) should be largely equivalent in run-time to r=recti(x,y,z,a). So maybe we should instead deprecate the set methods instead?

I can confirm that X does not have a double-click event, only button_press and button_release messages are sent. This means that we need to send a button_press and button_release for every event, but also send a double click (and triple click?) for thos events that are fast enough. This must not rely on system dependent values, and the double click latency should use an Irrlicht default value, not a system dependent.

[CuteAlien]

Thanks for the work. I can't promise I find time this weekend already (some other patches on my todo), but I'll try to care at least about the double-click asap.

I wish we had made two threads for this - mixing up rect and double-clicks in one thread is a little confusing ;-)

This is how I did the double click. It's simple. It's platform independent. I based it on jox's idea, but it works perfectly and makes sense.

I see - so you completely avoid using the Windows doubleclick. I still would like to find out the current speed-value which the system has for double-clicks if that is possible. So that value could be used for original initialization (which is btw. right now missing in the patch - speed is not initialized and therefore random). Also not sure if mouse-movement should be cared about in doubleclicks. I just checked on Linux in Firefox and movement is ignored there (but that could also be specific to the graphic-lib used by firefox). Can you check on Windows?

My question about sending doubleclick additional to click was pointless as I just noticed that Irrlicht has no click-event anyway ;-) So yeah, pressed-down and then double-click is the correct order.

The part with "case WM_LBUTTONDOWN" does no longer exist in the engine, that stuff was rewritten in current trunk. So have to see how that must be added in current Irrlicht.

By the way, which is the MAC implementation? What is the SDL implementation? Is that for Windows? I haven't looked at it yet.

Don't know - I also haven't looked yet. I can probably check for SDL, but I can't compile Mac.


About rect - I'm not really convinced about adding that many functions to the interface. Personally I prefer keeping library interfaces minimal. I agree that a set would fit - simply because similar classes have such a function. offset on the other hand was a function I only understood after reading it's source - I guess an operator+ would work better for me. And all the others, well - I certainly needed similar functionality already a few times, I just never missed it in rect itself. So not sure - what do others think? Lean interface or big interface prefered?

[CuteAlien]

A general question: Where's set to be favored over assignment of a newly generated object? so writing r.set(x,y,z,a) should be largely equivalent in run-time to r=recti(x,y,z,a). So maybe we should instead deprecate the set methods instead?

Ah - posting took me so long that you answered in the meantime ^^. I guess I prefer "set" functions (but not for example "setPlane" or "setLine" in those classes) simply because it's less to type. Also maybe easier for beginners. But not really something I cared about so far.

This must not rely on system dependent values, and the double click latency should use an Irrlicht default value, not a system dependent.

OK, I guess if someone wants to use system settings for that he can still do so. I'm always a little reluctant coding stuff which is already coded by the OS, but I guess not much of a choice when you want to be platform independent :-(

[Ulf]

To Hybrid

I said:

Yes inflate compiles and works. Why wouldn't it?

Hybrid wrote:

Because you have used a wrong parameter name.

haha. True. The first inflate function had typo. I copied and pasted it while I was in the middle of changing the variable names. Sorry. It does all compile though when that typo is fixed.

Here is the corrected inflate:

Code: Select all

void inflate(const T xInflate, const T yInflate)
{//! Modified by Ulf
   UpperLeftCorner.X -= xInflate;
   UpperLeftCorner.Y -= yInflate;
   LowerRightCorner.X += xInflate;
   LowerRightCorner.Y += yInflate;
}

A general question: Where's set to be favored over assignment of a newly generated object? so writing r.set(x,y,z,a) should be largely equivalent in run-time to r=recti(x,y,z,a). So maybe we should instead deprecate the set methods instead?

Can that be done if it's a pointer? I don't believe so.
Anyway, if we want to change the member values, why should we create a new object? That's my perspective.

I can confirm that X does not have a double-click event, only button_press and button_release messages are sent.

Yes I saw that Linux didn't have a double click. That's why I didn't use WM_LBUTTONDBLCLK etc. for the Windows double click. I did it the same as the Linux. But it's even easier to use the windows double click events.

This means that we need to send a button_press and button_release for every event, but also send a double click (and triple click?) for thos events that are fast enough. This must not rely on system dependent values, and the double click latency should use an Irrlicht default value, not a system dependent.

If so, then the Windows implementation should be as I did it.
The same as the Linux, using the DoubleClick struct, and testing for double click in the single click event section, then posting the click and the double click if it's within the time limit.

I don't think triple clicks are useful, or practical actually. Anyone else?

Hybrid, you seem to know something about Linux.
Can Linux access more than 3 mouse buttons? (not including 4 & 5 which are the mouse wheel)

Because I have implemented the extra buttons into the windows version. It's untested as I need to get a mouse with more than 3 buttons!
By the way, I had to include several extra defines in the function

Code: Select all

LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)

Irrlicht already defines the mouse wheel there..

Code: Select all

#ifndef WM_MOUSEWHEEL
#define WM_MOUSEWHEEL 0x020A
#endif
#ifndef WHEEL_DELTA
#define WHEEL_DELTA 120
#endif

I'll get back with that in a week or so.

And I'll make sure to make a separate thread!

[Ulf]

Cutie Alien,

I still would like to find out the current speed-value which the system has for double-clicks if that is possible. So that value could be used for original initialization (which is btw. right now missing in the patch - speed is not initialized and therefore random)

I'm not sure what you mean. Missing from my patch? I set the speed to 300ms in the DoubleClick struct. It can be modified at run-time.
Windows double click speed can be set in the GUI as well. Open Mouse settings in Control Panel. It doesn't show a value, but can be changed.

By default, Windows double click speed is 500ms, apparently.

http://www.downloadsquad.com/2008/04/28 ... d-setting/

The website recommends setting it at more like 250ms. 300 seems fine.

Also not sure if mouse-movement should be cared about in doubleclicks. I just checked on Linux in Firefox and movement is ignored there (but that could also be specific to the graphic-lib used by firefox). Can you check on Windows?

Yes in Windows, it matters. It should matter.
You don't want to double click on something that you are moving across. If you want to double click something then you want to point at it, or else it's not a double click, it's random fast clicking hahaha.

There is one thing I noticed. I been testing, and it appears that a mouse move event is triggered after a mouse button Release. Not after a mouse press, just release. Does that seem normal or correct? I don't figure that as any kind of problem.

The part with "case WM_LBUTTONDOWN" does no longer exist in the engine, that stuff was rewritten in current trunk. So have to see how that must be added in current Irrlicht.

Huh? How can it not be? It's a Windows event handler and so must use the Windows parameters! Not sure what you mean. I have to look and see.
What, have they made their own definitions? What for? Anyway...

offset on the other hand was a function I only understood after reading it's source - I guess an operator+ would work better for me.

Hmmm... No it wouldn't work at all to do what I'm trying to do. With a += operator, you can't offset the Width or Height value. You can only write a function to do one or the other. I've already thought about that.

I wanted access to setting any single, or combination of values in one line of code and without creating extra objects.

and all the others, well - I certainly needed similar functionality already a few times, I just never missed it in rect itself. So not sure - what do others think? Lean interface or big interface prefered?

Well, if you look at some other libraries, wxWidgets for example, my RECT class would still be tiny, and it works much more naturally than the wxWidgets one for example.

[Ulf]

PLEASE,

No more posts on this thread. I'm moving it and splitting it into 2.

Thank you.

[Ulf]

Here is the new thread for the RECT class changes:

http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=34165

Here is the new thread for the Mouse Double Click:

http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=34164

[hybrid]

Next time please ask the admins *before* doing this thread splitting on your own.

[CuteAlien]

Next time please ask the admins *before* doing this thread splitting on your own.

Uh, *redface* he did. I just didn't want to split because double-click is basically accepted already and I simply didn't want to spend time now on splitting up that thread :(