V0.5 brainstorm thread

Re: V0.5 brainstorm thread

Postby Edward_Lii » 10 Oct 2012, 17:11

Hello bgalon_2000,

bgalon_2000 {l Wrote}:That is a good idea. Another possible way to go about that would be to show the whole puzzle on one screen. For example, when the player holds down ‘w’ (world) – the screen switches to a static view where the entire puzzle world is scaled down to a single screen. When the player lifts the finger – the game switch back to normal view. This allow a player to try to work out a solution before (and while) solving the puzzle.

This actually gave me another idea. :)
In XMoto there's a key that will zoom out (to a certain extent) and if the level is too large it will scroll along the level.
That way the user will see the whole level, but no matter how big the level, at a decent quality.
The zooming isn't really needed, but without zooming out the camera will have to to scroll both vertically and horizontally.

The only downside of zooming is that it will be terribly slow when using software rendering.
And generating a preview of the level would be a lot of work to implement...

bgalon_2000 {l Wrote}:P.S. I think you just extract the files to the levelpack folder.... might be wrong...

Yep, the levelpack folder can be placed in either of three locations.
Not sure what they are under Windows, but on Linux they are:
  • <data_path>/levelpacks/
  • ~/.local/share/meandmyshadow/levelpacks/
  • ~/.local/share/meandmyshadow/custom/levelpacks/

P.S. I will be away for a few days, hopefully I'll have some more time to work on Me and My Shadow after that.
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: V0.5 brainstorm thread

Postby charlie » 11 Oct 2012, 18:08

Can you make it into an FPS for 0.5? I'd like to be able to shoot people like on CoD.

:D
Free Gamer - it's the dogz
Vexi - web UI platform
User avatar
charlie
Global Moderator
 
Posts: 2038
Joined: 02 Dec 2009, 11:56
Location: Manchester, UK

Re: V0.5 brainstorm thread

Postby bgalon_2000 » 18 Oct 2012, 13:48

bgalon_2000 {l Wrote}:That is a good idea. Another possible way to go about that would be to show the whole puzzle on one screen. For example, when the player holds down ‘w’ (world) – the screen switches to a static view where the entire puzzle world is scaled down to a single screen. When the player lifts the finger – the game switch back to normal view. This allow a player to try to work out a solution before (and while) solving the puzzle.


Edward_Lii {l Wrote}:This actually gave me another idea. :)
In XMoto there's a key that will zoom out (to a certain extent) and if the level is too large it will scroll along the level.
That way the user will see the whole level, but no matter how big the level, at a decent quality.
The zooming isn't really needed, but without zooming out the camera will have to to scroll both vertically and horizontally.


A zoom (in / out) - even without a scroll, is a great idea - together with the tab key to move between me and shadow - that should provide enough of the view port required.
bgalon_2000
 
Posts: 15
Joined: 26 Sep 2012, 16:40

Re: [IDEA] Achievement System?

Postby Sauer2 » 18 Oct 2012, 18:02

Edward_Lii {l Wrote}:Hello,
leovilok {l Wrote}:Allways the same problem, people have nice block ideas but we don't want a bloated game ... what if there was a way of creating scripted block in addons level(packs) ? :think: :shock: but the huge amount of work will probably prevent you from doing that ...

I've thought about scripting support before and although I see some uses for it I'm afraid it will be misused.
Take for example XMoto, they have scripting support in their levels and there are some fun/impressive levels made thanks to that.
But there are also a lot of levels that are unclear, they change certain things without giving any graphical feedback (eg )
(And it's a lot of work to implement. :p )


Hi,
a way to prevent misuse/overuse of scripting features may be some kind of "light scripting", i.e. no real scripting language but a bunch of event triggers, predefined actions and logic gates like implemented in mari0.
http://www.youtube.com/watch?v=ioEdP3QTP4w

Of course, it's also a lot of work.


EDIT: the related mari0 blog entry: http://blog.stabyourself.net/post/28431938792/screenshot-marathon-se-day-6
User avatar
Sauer2
 
Posts: 430
Joined: 19 Jan 2010, 14:02

Re: V0.5 brainstorm thread

Postby Edward_Lii » 22 Oct 2012, 17:11

Hello all,

As discussed in the Level editor thread (here) I wanted to rewrite the collision system.
So after some tinkering with different approaches I came to the conclusion that the best system (and easiest :p ) solution is the one we have.
I've made some changes and committed them, they are in svn revision 517.

It's basically a rewrite, the main difference is that it first creates a list of gameObjects that will take part in the collision/movement.
In general there are no more than three (four at most) blocks involved per frame.
The system still uses two passes, horizontally and vertically and so some of the bugs in the previous system sill persist. :|

Another thing I tried was separating some stuff, the old system has a lot of things mangled into each other.
There are still some things left, like the theme state changing during the horizontal collision check.
Separating it will make it easier to extract the collision system so it can be used by both the player and the pushable blocks.
One thing the separation also fixed was the 'spikes behind block' bug, since the collision/movement part is already done when checking for spikes the player will never overlap with a solid block. :)

But as I said before some bugs are still present, mainly Transfering from moving block to stable ones.
This one can quite easily be solved but I'm not sure what the wanted behaviour is.
  • The moment the player is one pixel on the moving block, move him along.
  • The moment the player is one pixel on a solid block let him stay there.
  • Go for a 50/50 approach, whichever block the player is mainly on.
  • Keep on moving block until the player is off, but also keep him on a solid block until the player is fully on the moving block.

Sauer2 {l Wrote}:a way to prevent misuse/overuse of scripting features may be some kind of "light scripting", i.e. no real scripting language but a bunch of event triggers, predefined actions and logic gates like implemented in mari0.
http://www.youtube.com/watch?v=ioEdP3QTP4w

Of course, it's also a lot of work.

EDIT: the related mari0 blog entry: http://blog.stabyourself.net/post/28431 ... n-se-day-6

Sorry for the late reply.
This is quite a good idea, but such systems never work for me.
Placing the gates always end up being a mess, while writing it in a (simple) scripting language is just a matter of &&, ||. :p
I think that if we decide to go for such a system we either simulate some sort of signal running through, or chain the conditions together.
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: V0.5 brainstorm thread

Postby Sauer2 » 22 Oct 2012, 23:14

Edward_Lii {l Wrote}:Placing the gates always end up being a mess...

That reminds me of earlier GUI editors, where one had to place non-GUI compenents - such as timers or connectors - on the form.
To prevent such a mess, you could place the gates on a grid, seperated from the normal level editor, which would also kind of limit the overuse of gates by gridsize.
Of course, this would be a lot of extra work; GUI related work. :p
I think that if we decide to go for such a system we either simulate some sort of signal running through, or chain the conditions together.

Could you explain, what you mean by that? Having a list of conditions per event?
User avatar
Sauer2
 
Posts: 430
Joined: 19 Jan 2010, 14:02

Re: V0.5 brainstorm thread

Postby Edward_Lii » 23 Oct 2012, 08:07

Hello all,

I've made some progress on the pushable block, it works mostly now, but I don't quite like the implementation.
First of all the collision/movement code is (almost) the same in the Block and the Player class but they don't use the same method(s).
I had to change the levelObjects vector to public and add five fields to the Block class.
Anyway I have attached a patch containing the changes.
pushable.diff
(11.04 KiB) Downloaded 109 times


Sauer2 {l Wrote}:Could you explain, what you mean by that? Having a list of conditions per event?

The signal approach is simple, once the player steps on or off a button or toggles a switch the linked gates will be checked.
The gates on their turn check if the change of input changed their output, if it did they check the linked gates.
This can either be done in one go or with events, the downside of the latter is that it will take some time before the end result.
But the former makes it possible to end up in an endless loop, imagine a AND-gate one input is a button, the other comes from a NOT gate.
The output of the AND-gate is linked to the NOT-gate's input, meaning that when the player stands on the button the AND-gate is true.
AND on -> NOT of -> AND off -> NOT on -> AND on -> etc...

The chaining approach I mentioned requires some work to be done at the start of the level.
Either we try to create a truth table or set up an equation that outputs one when true.
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: V0.5 brainstorm thread

Postby Edward_Lii » 23 Oct 2012, 21:03

Hello all,

I've made some progress regarding scripting.
I decided to try and implement Lua and it is easier than I expected. :D

The only problem I encountered so far is that lua is a C library and doesn't play nice with C++.
Since the scripts will all be ran "inside" the levels I decided to implement the script API in the Game class, but I can't register class member functions...
One possible solution is using (or creating) a C++ wrapper for Lua so that the wrapper will handle the member function pointers.

Another solution is moving the script API to the Functions.cpp file, since those functions aren't member functions of any class.
This even allows scripts to access the MusicManager making it more flexible, if we implement that of course. :p
The only downside is that it gets harder to access the actual levelObjects vector, first of we have to cast currentState to a Game pointer, which we can "safely" do during the execution of a script.
But this also means that the levelObjects vector needs to become public.
Considering that I also required this for implementing the pushable block I think we should change the access modifier to public and/or implement some way of retrieving the array.

Suggestions are welcome! ;)
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: V0.5 brainstorm thread

Postby Sauer2 » 23 Oct 2012, 22:32

*wild guess*: Haven't there been projects like Luabind to integrate Lua into C++? Not sure how good they are, though.
User avatar
Sauer2
 
Posts: 430
Joined: 19 Jan 2010, 14:02

Re: V0.5 brainstorm thread

Postby acme_pjz » 24 Oct 2012, 06:32

Hi Edward_Lii,
Edward_Lii {l Wrote}:The only problem I encountered so far is that lua is a C library and doesn't play nice with C++.
Since the scripts will all be ran "inside" the levels I decided to implement the script API in the Game class, but I can't register class member functions...


Think about how do people write object oriented code in pure C :) The answer is using friend member functions :)
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 585
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: V0.5 brainstorm thread

Postby Sauer2 » 24 Oct 2012, 17:34

acme_pjz {l Wrote}:Hi Edward_Lii,
Edward_Lii {l Wrote}:The only problem I encountered so far is that lua is a C library and doesn't play nice with C++.
Since the scripts will all be ran "inside" the levels I decided to implement the script API in the Game class, but I can't register class member functions...


Think about how do people write object oriented code in pure C :) The answer is using friend member functions :)


I'm curious: Is this how one does declare static functions in C++ (static as in C#/Java)?
Or is more common to create functions directly in the namespace scope?
User avatar
Sauer2
 
Posts: 430
Joined: 19 Jan 2010, 14:02

Re: V0.5 brainstorm thread

Postby Edward_Lii » 24 Oct 2012, 17:46

Hello Sauer2,

Sauer2 {l Wrote}:I'm curious: Is this how one does declare static functions in C++ (static as in C#/Java)?
Or is more common to create functions directly in the namespace scope?

I'm not sure but I think if you need an independent static function you can declare it in the namespace scope (e.g. math functions).
When the function is a member of a class you simply render that method static using the 'static' keyword.
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: V0.5 brainstorm thread

Postby Sauer2 » 24 Oct 2012, 18:25

OK, thanks for clearing that up.
User avatar
Sauer2
 
Posts: 430
Joined: 19 Jan 2010, 14:02

Re: V0.5 brainstorm thread

Postby Edward_Lii » 23 Nov 2012, 17:56

Hello all,

At the moment spikes and moving spikes won't collide with the player or the shadow.
This isn't needed since upon collision they die, but what should happen to a pushable block?
For some reason it is very weird to see the pushable block "fall" through the spikes.
So I think the pushable block should collide with spikes, this way spikes can be "covered" with pushable blocks.

Another thing I'm not sure about is the behaviour when the player (or shadow) is standing on multiple blocks, some of which are moving.
At the moment the order the blocks appear in the levelObjects vector determine the behaviour.
It should be order-independent but what should it be:
  • Always go with the moving block, in case of multiple choose the "fastest".
  • Go for the one the player is standing on the most (pixel wise).
  • Toggle the block the player is standing one, when he's fully of the normal block he will follow the moving block, until he's fully of that.

Suggestions are welcome. :)
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: V0.5 brainstorm thread

Postby acme_pjz » 24 Nov 2012, 07:24

Edward_Lii {l Wrote}:Go for the one the player is standing on the most (pixel wise).


I think this is better :) not sure the code complexity
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 585
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: V0.5 brainstorm thread

Postby Edward_Lii » 24 Nov 2012, 18:28

Hello acme_pjz,

acme_pjz {l Wrote}:
Edward_Lii {l Wrote}:Go for the one the player is standing on the most (pixel wise).


I think this is better :) not sure the code complexity

I tried implementing it this way and got it working pretty quick.
Only a few lines of code did what I wanted, but not what I expected.

Basically the player would swap block each frame between a stationary block and a moving block.
{l Code}: {l Select All Code}
2px on stationary - 0px on moving block
2px on stationary - 1px on moving block
2px on stationary - 2px on moving block (Object order dictates which block the player is standing on)
2px on stationary - 3px on moving block
 (Moving block moves player towards the stationary block)
3px on stationary - 3px on moving block (Object order dictates which block the player is standing on)
3px on stationary - 4px on moving block
 (Moving block moves player towards the stationary block)
4px on stationary - 4px on moving block

etc...

10px on stationary - 10px on moving block (Object order dictates which block the player is standing on)
10px on stationary - 11px on moving block (Player is 21px wide so the moving block will return and since 11>10 takes the player with him)

If the block order is the other way around, the player would be left on the stationary block.
So this implementation doesn't fix anything, still levelobject order dependent.

After some fiddling I came up with a system that works order independent. ;)
Basically it will keep the player at the stationary block when standing still (even if he sticks out more than 50%).
This also means he will "step off" without doing anything if he hangs 50% off the moving block.
The only thing that is still level order dependent is when two moving block 'touch' each other with the player hanging of one.

Give the new system a try and tell me what you think, and if you find any bugs please report them here. :)

P.S. Pushable blocks now collide with spikes and moving spikes.
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: V0.5 brainstorm thread

Postby odamite » 25 Nov 2012, 18:19

Hello Edward_Lii,

Good work there with the collision system. It has worked fine so far and I didn't notice any bugs. :)

Edward_Lii {l Wrote}:After some fiddling I came up with a system that works order independent. ;)
Basically it will keep the player at the stationary block when standing still (even if he sticks out more than 50%).
This also means he will "step off" without doing anything if he hangs 50% off the moving block.
The only thing that is still level order dependent is when two moving block 'touch' each other with the player hanging of one.

I'm not sure about this behaviour. I agree with the 50% thing but why the player is always pushed to a stationary block? For me it would be more logical if the player would always stay on block standing 50% no matter if it's moving or not. Remember that this is just my opinion and I would like to know what you think.

Edward_Lii {l Wrote}:P.S. Pushable blocks now collide with spikes and moving spikes.

Also great work with the pushable blocks. They're a nice addition to the game. Currently there're some strange behaviour with moving blocks and crushing but I'm sure that they will be fixed in the future.
User avatar
odamite
 
Posts: 166
Joined: 16 Jan 2012, 16:28

Re: V0.5 brainstorm thread

Postby Edward_Lii » 28 Nov 2012, 16:55

Hello all,

Currently I'm working on changing the LevelEditor to use the GUI system instead of the mishmash it is now.
I got a bit carried away and am now working on the GUIWindow class to support dragging and resizing.
It is kind of working, but not very user friendly since the cursor doesn't indicate the window can be resized at the borders.

So I'm looking into ways of setting a custom cursor, this can be done in two ways:
- Making use of SDL's built in methods SetCursor, CreateCursor and the SDL_Cursor class.
- Hide the built-in cursor and draw a SDL_Surface at that location.

Personally I think we should go for the former one, but should I make it global or only use it in the LevelEditor.
If I make some sort of CursoManager we can use custom cursors throughout the game, we could even make the cursor themable.
Or is this unneeded and should I keep it for the LevelEditor only?

odamite {l Wrote}:For me it would be more logical if the player would always stay on block standing 50% no matter if it's moving or not.

I kind of agree, but I couldn't find a (easy) way to implement that in an order independent way.
The problem is that when the player is a bit on both blocks but not on one for 50% yet, the order will have a influence.
This can be omitted by adding a certain priority list for blocks so that the involved blocks will be ordered in the same way, but this feels a bit over the top.

And I quite like the system that the user will have to actively step/jump on a moving block before getting taken with it.

odamite {l Wrote}:Currently there're some strange behaviour with moving blocks and crushing but I'm sure that they will be fixed in the future.

I've noticed that too, I think it has something to do with the fact that the block has higher velocities than the average moving block and the player/shadow pushes the block instead of the other way around.
Meaning that sometimes the player/shadow will be pushed aside, as if the player had walked into it and sometimes gets squashed.
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: V0.5 brainstorm thread

Postby odamite » 28 Nov 2012, 20:02

Hello Edward_Lii,

Edward_Lii {l Wrote}:Currently I'm working on changing the LevelEditor to use the GUI system instead of the mishmash it is now.
I got a bit carried away and am now working on the GUIWindow class to support dragging and resizing.
It is kind of working, but not very user friendly since the cursor doesn't indicate the window can be resized at the borders.

That's nice to hear. Hopefully we'll end up with more user-friendly level editor. ;)

Edward_Lii {l Wrote}:So I'm looking into ways of setting a custom cursor, this can be done in two ways:
- Making use of SDL's built in methods SetCursor, CreateCursor and the SDL_Cursor class.
- Hide the built-in cursor and draw a SDL_Surface at that location.

Personally I think we should go for the former one, but should I make it global or only use it in the LevelEditor.
If I make some sort of CursoManager we can use custom cursors throughout the game, we could even make the cursor themable.
Or is this unneeded and should I keep it for the LevelEditor only?

I agree with you that the former is better. I believe there're more possibilies with it but it should work as well as the other option. In my opinion custom cursors could be a really nice addion to game's user interface. It makes the GUI more usable because we can give hints about different actions like resizing windows or indicating a text area. I also think that we shouldn't have any kind of theme support because I believe there's no need for it. We just need to have a high quality default cursors which works with both dark and light themes.

Edward_Lii {l Wrote}:I kind of agree, but I couldn't find a (easy) way to implement that in an order independent way.
The problem is that when the player is a bit on both blocks but not on one for 50% yet, the order will have a influence.
This can be omitted by adding a certain priority list for blocks so that the involved blocks will be ordered in the same way, but this feels a bit over the top.

And I quite like the system that the user will have to actively step/jump on a moving block before getting taken with it.

I understand and there's nothing wrong with the current system. It could be a little confusing at first if it works only in one direction. But now it's working well and better than before so I would say that there's no need to modify it anymore. :)
User avatar
odamite
 
Posts: 166
Joined: 16 Jan 2012, 16:28

Re: V0.5 brainstorm thread

Postby odamite » 29 Nov 2012, 15:13

Hello again,

Just some more thoughts about the custom cursors. I think that it's most needed in level editor but for consistency it should be everywhere in the game. In level editor it can be easily used to indicate which tool is currently used and also for other actions like resizing, dragging and writing.

I don't think that we need original and custom cursors for this. There are already many cursors available online. Here are some I found:
http://kde-look.org/content/show.php/OpenZone?content=111343 - Good sharp edges, under X11 license
http://jimmac.musichall.cz/themes.php?skin=7 - Really smooth cursors based on vector graphics, under MIT license

What do you think?
User avatar
odamite
 
Posts: 166
Joined: 16 Jan 2012, 16:28

Re: V0.5 brainstorm thread

Postby odamite » 30 Nov 2012, 13:11

Hello everyone,

I tried out the custom cursor with a SDL_Surface following the mouse. It worked really well and I also implemented several different cursor graphics for different actions. But I ran into a problem: in dialogs the dimmed background isn't updated so it doesn't clear the cursor so it leaves a trail behind. How could this be resolved? :(

I came up with couple of solutions:
  • Use SDL_Cursor. The downside is that the cursor can only have 2 colors: black and white so no good-looking antialiased borders or drop shadows.
  • Update the dimmed background. However is this really necessary only for good-looking cursors?
Any ideas? :think:
User avatar
odamite
 
Posts: 166
Joined: 16 Jan 2012, 16:28

Re: V0.5 brainstorm thread

Postby Edward_Lii » 30 Nov 2012, 14:33

Hello odamite,

odamite {l Wrote}:I don't think that we need original and custom cursors for this. There are already many cursors available online. Here are some I found:
http://kde-look.org/content/show.php/Op ... ent=111343 - Good sharp edges, under X11 license
http://jimmac.musichall.cz/themes.php?skin=7 - Really smooth cursors based on vector graphics, under MIT license

What do you think?

The first one is quite simple and the black one with white outline looks like the default SDL one.
The second one looks very familiar somehwo :think: ... ah, it's my default cursor theme. :D

odamite {l Wrote}:Update the dimmed background. However is this really necessary only for good-looking cursors?

This won't be an easy tasks, since it's already a bit hacked together.
Not impossible though, but as you said just for some (minor) eye-candy.

odamite {l Wrote}:Use SDL_Cursor. The downside is that the cursor can only have 2 colors: black and white so no good-looking antialiased borders or drop shadows.

I think this is the best solution, the default SDL cursor looks fine and the cursor is hidden during gameplay anyway.
So maybe we should use the BlackSlim cursor set from the first link. (MIT license)
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: V0.5 brainstorm thread

Postby odamite » 01 Dec 2012, 00:19

Hello Edward_Lii,

Oh no. I have messed up things... :(

I created my own cursor code and committed to SVN. This replaced changes from your previous commit... :o Both commits are basically the same but with little differences. I think that we should dismiss my commit because your seems to be better and continue from there. Sorry for all this. What should we do? :|
User avatar
odamite
 
Posts: 166
Joined: 16 Jan 2012, 16:28

Re: V0.5 brainstorm thread

Postby Edward_Lii » 01 Dec 2012, 00:32

Hello odamite,

odamite {l Wrote}:Oh no. I have messed up things... :(

I created my own cursor code and committed to SVN. This replaced changes from your previous commit... :o Both commits are basically the same but with little differences.

It's partially my fault, I knew you were trying out some custom cursors, I should have communicated better that I was working on a implementation.
Anyway, I'm actually quite surprised by the similarities between our versions.

odamite {l Wrote}:I think that we should dismiss my commit because your seems to be better and continue from there. Sorry for all this. What should we do? :|

To be honest, there are some things I liked more in my implementation, but yours contains some things mine is lacking.
I don't have the time to do it now, but I think it would be best to revert the commit, but keep the following:
  • Add the remove and drag cursors to the Cursors.h file.
  • Name the enumeration CursorTypes and prefix the entries with CURSOR_ (fits better with the other enums)
  • The implementation in the GUIObjects.

One thing I'm not sure is how to manage the types, should all GUIObjects manage it himself or should it for example be decided by the GUIObjectRoot?
Maybe it should always be set to POINTER at the start of each update and only change if a GUIObject needs it to change, that way it will automatically return normal if the cursor leaves the GUIObject.

P.S. For some reason it doesn't feel in place when the cursor turns to the POINT type when hovering over buttons.
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: V0.5 brainstorm thread

Postby odamite » 01 Dec 2012, 12:32

Hello Edward_Lii,

Edward_Lii {l Wrote}:To be honest, there are some things I liked more in my implementation, but yours contains some things mine is lacking.
I don't have the time to do it now, but I think it would be best to revert the commit, but keep the following:
  • Add the remove and drag cursors to the Cursors.h file.
  • Name the enumeration CursorTypes and prefix the entries with CURSOR_ (fits better with the other enums)
  • The implementation in the GUIObjects.

That sound good to me. Are you going to do it? Or am I doing it? We don't want any more conflicts with commits, right?

Edward_Lii {l Wrote}:Maybe it should always be set to POINTER at the start of each update and only change if a GUIObject needs it to change, that way it will automatically return normal if the cursor leaves the GUIObject.

Isn't my implementation using this method? It seems to be working pretty well and it eliminates need for mouse leave events in widgets. :)

Edward_Lii {l Wrote}:P.S. For some reason it doesn't feel in place when the cursor turns to the POINT type when hovering over buttons.

You may be right. There's already the arrows indicating a mouse hover. But what do you think about the other places with POINT cursor like in checkboxes or level select screen? Should there be a POINT cursor at all?
User avatar
odamite
 
Posts: 166
Joined: 16 Jan 2012, 16:28

Who is online

Users browsing this forum: No registered users and 1 guest