Bugfixes

Bugfixes

Postby squarecross » 03 Mar 2014, 02:53

I have attached my attempt at some minor bugfixes and behaviour changes.
The changes allow for pushable blocks to move on conveyor belts and on horizontally moving moving blocks. There are some questionable behaviour changes with the pushable blocks though; now the player can move any number of singly stacked at a time and still cannot move two blocks lined up horizontally. I thought this was alright and I suppose makeshift stairs could be created and moved around because of this. Is there some kind of outlined behaviour for pushable blocks?
The player now moves with a moving pushable block.
The shadow no longer slides along the top of an immobile pushable block when the player is pushing against it.
The shadow and player when one is on top of the other and they are on a conveyor belt and the person on the bottom is stopped, the person on the top no longer slides across.
The player no longer gets jittery feet when they are standing on a pushable block that is on top of a moving block that is going downward.
I removed calls to the prepareFrame() function because there were some odd bugs with pushable blocks falling through moving blocks. Reseting dx, dy, xVel, and yVel makes it challeging for objects earlier in the loop to be exposed to changes in other objects, i.e if the pushable blocks are added to the map earlier than moving blocks then they cannot know if the moving block has moved because it is reset each loop. The way I changed the loop now is that xVel get reset after a move, but dx, dy, and yVel are not reset.

There was a FIXME in Main.cpp whose logic seemed fine so I did what it asked, it seems fine.

I hope I didn't break anything.

Also how does one remove some of this redundancy from svn diff? It seems to show lines that are the same removed then added.

Edward_Lii I recall that in some obscure post you mentioned that you had a doxygen script. If you could send that I would appreciate it.
Attachments
patch.diff
(8.66 KiB) Downloaded 67 times
squarecross
 
Posts: 8
Joined: 01 Mar 2014, 19:06

Re: Bugfixes

Postby Akien » 03 Mar 2014, 11:15

Hi squarecross,

Thanks for your patch, I hope the devs will be able to use it to improve Me and My Shadow :)

As for your question about redundancy in the svn diff, if you check the diff with "cat -v patch.diff", you'll see that it's due to the way the end of line is handled.
I think the source file was edited in a Windows environment, whereas you did you fix in Unix (or the other way around), and thus changed the end of line character in some lines.

See e.g.:
{l Code}: {l Select All Code}
Index: src/Player.h
===================================================================
--- src/Player.h        (revision 686)
+++ src/Player.h        (working copy)
@@ -101,7 +101,9 @@
        ^M
 protected:^M
        //Rectangle containing the player's location.^M
-       SDL_Rect box;^M
+       SDL_Rect box;
+       //Rectangle containing the other's last location.
+       SDL_Rect boxOther;^M
        ^M
        //The x and y velocity.^M
        int xVel, yVel;^M

The "^M" character shows DOS/Windows line-ending characters IIUC.
User avatar
Akien
 
Posts: 734
Joined: 22 Feb 2014, 13:14

Re: Bugfixes

Postby Edward_Lii » 03 Mar 2014, 20:39

Hello squarecross,

First of all, thank you very much for your contribution. :)
I'm really sorry I'm not as active as I would like to be.

squarecross {l Wrote}:The changes allow for pushable blocks to move on conveyor belts and on horizontally moving moving blocks. There are some questionable behaviour changes with the pushable blocks though; now the player can move any number of singly stacked at a time and still cannot move two blocks lined up horizontally. I thought this was alright and I suppose makeshift stairs could be created and moved around because of this. Is there some kind of outlined behaviour for pushable blocks?

The behaviour of pushable blocks isn't well defined, but the behaviour you described is fine IMHO.
I can imagine the difference in vertical stacked and horizontally placed pushable blocks being used in puzzles.

squarecross {l Wrote}:I removed calls to the prepareFrame() function because there were some odd bugs with pushable blocks falling through moving blocks. Reseting dx, dy, xVel, and yVel makes it challeging for objects earlier in the loop to be exposed to changes in other objects, i.e if the pushable blocks are added to the map earlier than moving blocks then they cannot know if the moving block has moved because it is reset each loop. The way I changed the loop now is that xVel get reset after a move, but dx, dy, and yVel are not reset.

I honestly can't remember why the prepareFrame method was written, you're approach seems better.
It probably solved some bugs regarding saving/loading a state, which might be resolved in other ways by now.
That's something that bugs me a lot, the save/loading at checkpoints causes/has caused many bugs in the past and is generally quite hard to test (manually).

squarecross {l Wrote}:There was a FIXME in Main.cpp whose logic seemed fine so I did what it asked, it seems fine.

I thought so too, but for some reason didn't risk introducing any bugs by removing it hence the FIXME.
Anyway, we'll see if it brings any unpleasant surprises.

squarecross {l Wrote}:I hope I didn't break anything.

I hope so too. ;)

squarecross {l Wrote}:Edward_Lii I recall that in some obscure post you mentioned that you had a doxygen script. If you could send that I would appreciate it.

I once made a simple bash script that functioned as input_filter for doxygen, I've attached it.
Warning: it isn't very pretty and quickly bashed together, making assumptions about the comment format, etc...
IIRC it worked for most (if not all) source files of meandmyshadow.

Akien {l Wrote}:I think the source file was edited in a Windows environment, whereas you did you fix in Unix (or the other way around), and thus changed the end of line character in some lines.

All the source files have Windows/DOS end of line characters, purely because the initial version had them that way.
Another thing I noticed about the patch is that the indentation isn't always the same as the rest of the source, we use a tabs instead of spaces.
If you could fix the patch and reupload it.

Anyway, thanks again. I'll be testing your changes some more to see if I can find any (new) bugs.
Attachments
convert.txt
(948 Bytes) Downloaded 73 times
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 770
Joined: 20 Dec 2010, 16:46

Re: Bugfixes

Postby squarecross » 04 Mar 2014, 03:27

Hey guys,
Akien {l Wrote}:I think the source file was edited in a Windows environment, whereas you did you fix in Unix (or the other way around), and thus changed the end of line character in some lines.

Edward_Lii {l Wrote}:All the source files have Windows/DOS end of line characters, purely because the initial version had them that way.
Another thing I noticed about the patch is that the indentation isn't always the same as the rest of the source, we use a tabs instead of spaces.
If you could fix the patch and reupload it.

Hmm I see.
Here you go.

Edward_Lii {l Wrote}:I once made a simple bash script that functioned as input_filter for doxygen, I've attached it.
Warning: it isn't very pretty and quickly bashed together, making assumptions about the comment format, etc...
IIRC it worked for most (if not all) source files of meandmyshadow.

Thank you.

Is there priority on any feature of the game right now?
Attachments
patch.diff
(7.11 KiB) Downloaded 64 times
squarecross
 
Posts: 8
Joined: 01 Mar 2014, 19:06

Re: Bugfixes

Postby Edward_Lii » 09 Mar 2014, 15:08

Hello squarecross,

squarecross {l Wrote}:Here you go.

Thanks, I've applied your patch and committed it to svn (rev. 687).

squarecross {l Wrote}:Is there priority on any feature of the game right now?

There isn't really a feature that is needed right now, mainly because for V0.5 we intend to polish up the (half) implemented features in svn.
Enhancements and bugfixes to the level editor are always welcome.

As for the release after that, there's a lot that can be added feature wise.
One (big) thing I would like to change is the frame rate, at the moment it's a constant 40fps.
My idea is to keep the update ticks at 40Hz and let the frame rate vary (and/or capped at 60fps).
The visual elements should be interpolated based on their current and previous position.
In order to implement this it might be an idea to split the blocks and player into a model and a view, which in turn would make a proper/full openGL rendering system easier.

Anyway, if you have an idea for a feature, or have questions about the code, feel free to ask. ;)
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 770
Joined: 20 Dec 2010, 16:46

Re: Bugfixes

Postby odamite » 09 Mar 2014, 19:36

Edward_Lii {l Wrote}:As for the release after that, there's a lot that can be added feature wise.
One (big) thing I would like to change is the frame rate, at the moment it's a constant 40fps.
My idea is to keep the update ticks at 40Hz and let the frame rate vary (and/or capped at 60fps).
The visual elements should be interpolated based on their current and previous position.
In order to implement this it might be an idea to split the blocks and player into a model and a view, which in turn would make a proper/full openGL rendering system easier.

That's a great plan for the next version. A great read about implementing this kind of game loop is this article. Also for more information, see the "See also" section at the bottom of that article.

Also in the future it maybe smart to migrate from SDL1.2 to SDL2.0. By doing this, we'll get hardware accelerated rendering and support for Android and iOS though this also means that support for some non-modern systems has to be dropped and parts of the code base must the rewritten. However I believe that it's worth it. Migration guide on SDL wiki is pretty good.
User avatar
odamite
 
Posts: 166
Joined: 16 Jan 2012, 16:28

Who is online

Users browsing this forum: Yahoo [Bot] and 1 guest

cron