V0.5 Preparation thread

V0.5 Preparation thread

Postby Edward_Lii » 07 Aug 2018, 21:03

Hello all,

Long time no see. ;) Years ago development slowed down and I kind of just stopped working on it. From time to time I did consider picking it up again, but never got around to it.
So I was positively surprised to see the project under active development again after all this time and I hope to contribute my part again (I am listed as "active developer" in the AUTHORS file after all :p )

The goal of this thread is to gather the points still needed for a V0.5 release of Me and My Shadow. If you haven't already, be sure to read acme_pjz's latest post detailing the recent and not so recent changes:
https://acmepjz.github.io/meandmyshadow/2018/status-of-0-5-development-version.html

In short, there are plenty of new features and nice technical improvements:
  • Switch to SDL2 (thanks to oyvindln)
  • Achievements and statistics (thanks to acme_pjz)
  • Scripting support
  • Several improvements/additions to the blocks: pushable blocks, sizing of blocks and scenery (blocks)
  • Undo/redo in the editor (thanks to squarecross)

So, what is left to do? That's what we need to figure out in this thread!
The focus should be to ensure the above new features are stable and well (play) tested.
Also, since this is a game, we should not forget to provide new content compared to V0.4.1, this includes:
  • Updating the 'tutorial' levelpack to include the new features
  • Update the 'default' levelpack with some more levels
  • Introduce a new levelpack/additional levels(?)
  • (Nice to have) Update theme to accommodate for sizeable blocks
  • (Nice to have) Additional music tracks, don't get me wrong, I love the music, but it's omnipresent in all menus/levels/levelpacks.

At one point a string freeze should be introduced to allow the translations to be updated. Given the large interval since the last release, I don't expect all of the original contributors to be available, but we can at least try and contact them.
This will likely mean that we might end up with fewer supported languages than before or have a few translations that only cover part of the strings.

Any feedback or suggestion is welcome! :)
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: V0.5 Preparation thread

Postby charlie » 08 Aug 2018, 12:33

I would suggest that a teleporter covered with a pushable block should not work. That would make for some interest level designs (both where you need to push blocks off a teleporter or cover a teleporter that blocks a path).
Free Gamer - it's the dogz
Vexi - web UI platform
User avatar
charlie
Global Moderator
 
Posts: 2131
Joined: 02 Dec 2009, 11:56
Location: Manchester, UK

Re: V0.5 Preparation thread

Postby GunChleoc » 08 Aug 2018, 18:00

Glad to see this project is moving again. I'm still keeping an eye on it for translations :)
User avatar
GunChleoc
 
Posts: 502
Joined: 20 Sep 2012, 22:45

Re: V0.5 Preparation thread

Postby acme_pjz » 09 Aug 2018, 05:52

Here are my (incomplete) TODO list for V0.5.

  • I need to fix a couple of things before a V0.5 beta release. A few days are enough. Already fixed :cool:
  • Clarify the author/description/website/screenshot/license for the addons. Edward_Lii, do you have ways to contact the authors of them?
  • Fix of OSX build and packaging. I'd like somebody help me to make the OSX nightly build compile/packaging script run on Travis CI.
  • To be added...

Here are a list of incompatibilities between V0.5 and older version:

  • The input configuration file is incompatible with older version, vice versa. You may need to reconfigure keys.
  • The "button" state of Button block in the theme file is incompatible with older version. (All builtin and addon themes are fixed.) If you have designed other themes, you may need to fix them.
  • Various game logic changes which may break older replay. I try to hard to keep game logic compatible, but some of them are inevitable. If you find any incompatibilities, please tell me and I'll see if it can be fixed.
  • To be added...

------

charlie {l Wrote}:I would suggest that a teleporter covered with a pushable block should not work. That would make for some interest level designs (both where you need to push blocks off a teleporter or cover a teleporter that blocks a path).


This sounds reasonable. What is your opinion, Edward_Lii? I can implement it if the decision is made.

GunChleoc {l Wrote}:Glad to see this project is moving again. I'm still keeping an eye on it for translations :)


As for the translation, I try the Transfiex https://www.transifex.com/acmepjz/meandmyshadow/ but later on I found that there are some quirks on it, e.g. translation pushing/pulling bugs :| .

So meanwhile you can also use the classical translation workflow described in the wiki.
Last edited by acme_pjz on 09 Aug 2018, 10:20, edited 1 time in total.
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: V0.5 Preparation thread

Postby eugeneloza » 09 Aug 2018, 06:23

At one point a string freeze should be introduced to allow the translations to be updated.

When you have final version of English, ping me for Russian and Ukrainian :)
As far as I've understood according http://meandmyshadow.sourceforge.net/wi ... ranslating you just need a pull request with corresponding .po files, right?
User avatar
eugeneloza
 
Posts: 500
Joined: 22 Aug 2014, 12:15
Location: Ukraine

Re: V0.5 Preparation thread

Postby Edward_Lii » 09 Aug 2018, 09:40

acme_pjz {l Wrote}:Clarify the author/description/website/screenshot/license for the addons. Edward_Lii, do you have ways to contact the authors of them?

I'll try and see if I can contact them. Though, what should we do in case we don't know under which license an addon falls?

acme_pjz {l Wrote}:The input configuration file is incompatible with older version, vice versa. You may need to reconfigure keys.

I was thinking we should detect this somehow and perhaps reset the keybindings, as there might be people who still have an old configuration file.
Perhaps store a version in the config file, so we know when we load an old config and make the appropriate changes, though then someone might not be able to load up V0.4.1 (or older) afterwards.
We could also have a config file per version, and on startup if the file isn't there, check for the config file for the previous version and migrate the relevant settings (everything except the keybindings in this case).

acme_pjz {l Wrote}:This sounds reasonable. What is your opinion, Edward_Lii? I can implement it if the decision is made.

I think it's a really good idea and would indeed allow for some interesting puzzles, thanks for the suggestion charlie!
Some things to think about when implementing this:
  • We can play the same 'error' sound for when there is no existing destination, but how would the player know that the destination is temporarily blocked instead of not existing? (Ideally a level wouldn't have "broken" teleporters without destination, but they can)
  • In case the teleporter "auto" teleports, will the teleport commence once the destination becomes valid, or should the player/shadow move off and on the teleporter again (the latter is probably easier to implement)

Some other points I thought about while playing the game again, which mainly have to do with gameplay:
  • A player can't see from the appearance of the teleporter whether it will be a manual one or an automatic one. Maybe we can create a different appearance for them.
  • Both the switch and the button can exhibit different behaviour (toggle, on or off), but again, there is no way for the player to visually see this. The tutorial does point it out, but when you think about it, it's basically saying "switches might not do what you expect, good luck" :p
    Not sure how we should go about this, but at the very least the button and switch should become inoperable after activation if they are set to the 'on' or 'off' mode.
  • As the switch is also a block, the player can activate it as soon as it overlaps with the 40x40px block, but the player can also overlap multiple switch blocks if they are close enough and activate them all at once. Previously I didn't really mind that much, but after playing the level "Picture creator" I realized it would be nice to visually see which (if any) switches I would activate by pressing the interact key.
    Additionally we might want to make it so that you only ever activate one switch, for example the one you overlap/cover the most?

Other than that I'm still looking into some bugs regarding pushable blocks stacked on top of each other on top of moving blocks. And while playing I noticed quite a few times being "squashed" without actually being "squashed", not sure what caused that, but will try and get to the bottom of that.

GunChleoc {l Wrote}:Glad to see this project is moving again. I'm still keeping an eye on it for translations :)

eugeneloza {l Wrote}:When you have final version of English, ping me for Russian and Ukrainian :)
As far as I've understood according http://meandmyshadow.sourceforge.net/wi ... ranslating you just need a pull request with corresponding .po files, right?

:D Really great to hear this, thanks in advance. I'll be sure to notify you when the string freeze is in effect. ;)
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: V0.5 Preparation thread

Postby acme_pjz » 09 Aug 2018, 10:44

Edward_Lii {l Wrote}:I'll try and see if I can contact them. Though, what should we do in case we don't know under which license an addon falls?


I don't know... do we need to remove them? :( I don't like that.

Here is the list of addons with license unclear:


----------------

I prefer this approach:

Edward_Lii {l Wrote}:We could also have a config file per version, and on startup if the file isn't there, check for the config file for the previous version and migrate the relevant settings (everything except the keybindings in this case).


because without SDL1.2 we can't deduce the actual key from the number (unless we copy some code from SDL1.2 header file :think: and I don't like to do that since it pollutes the code)

[EDIT] implemented in b450e27 :)

.....

Edward_Lii {l Wrote}:Additionally we might want to make it so that you only ever activate one switch, for example the one you overlap/cover the most?


I think activate multiple switches at once is OK. Personally I don't like the approach that only activates the nearest switch. Plus, it certainly will break old replays. :think:

Edward_Lii {l Wrote}: And while playing I noticed quite a few times being "squashed" without actually being "squashed", not sure what caused that, but will try and get to the bottom of that.


Yes, the half-baked collision detection code (written in 2012--2013 ?) has a lot of nasty bugs. I managed to fix most of them (see git rev 5269929, 1234a8f, 4a0fbf4, ... ) but there seems still bugs, for example in level 19 "subway surf" in Akos level pack you'll be squashed when you standing on a block moving up while another block moving up at a higher speed. :(

[EDIT] I think I fixed it in b8e6e7a :)
Last edited by acme_pjz on 10 May 2020, 17:59, edited 8 times in total.
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: V0.5 Preparation thread

Postby eugeneloza » 09 Aug 2018, 14:27

I'll be sure to notify you when the string freeze is in effect.

Don't get me wrong. I have no idea what "string freeze" is :) I just need final version of English text to start :)
(UPD) looked up in the Internet, yep. That's what I'm waiting for :)
User avatar
eugeneloza
 
Posts: 500
Joined: 22 Aug 2014, 12:15
Location: Ukraine

Re: V0.5 Preparation thread

Postby GunChleoc » 10 Aug 2018, 17:54

acme_pjz {l Wrote}:
GunChleoc {l Wrote}:Glad to see this project is moving again. I'm still keeping an eye on it for translations :)


As for the translation, I try the Transfiex https://www.transifex.com/acmepjz/meandmyshadow/ but later on I found that there are some quirks on it, e.g. translation pushing/pulling bugs :| .

So meanwhile you can also use the classical translation workflow described in the wiki.

Which are the bugs that you are referring to? I have used Transifex for years now and it's working well for me, so I'd be interested to know. They are also really good about responding to inquiries.

A problem for translators is that you can't watch an individual file on SourceForge, so there are no notifications for changes available. Manually keeping up with the number of projects that I maintain has become impossible. I do read this forum regularly though.
User avatar
GunChleoc
 
Posts: 502
Joined: 20 Sep 2012, 22:45

Re: V0.5 Preparation thread

Postby acme_pjz » 11 Aug 2018, 03:41

GunChleoc {l Wrote}:
acme_pjz {l Wrote}:
GunChleoc {l Wrote}:Glad to see this project is moving again. I'm still keeping an eye on it for translations :)


As for the translation, I try the Transfiex https://www.transifex.com/acmepjz/meandmyshadow/ but later on I found that there are some quirks on it, e.g. translation pushing/pulling bugs :| .

So meanwhile you can also use the classical translation workflow described in the wiki.

Which are the bugs that you are referring to? I have used Transifex for years now and it's working well for me, so I'd be interested to know. They are also really good about responding to inquiries.

A problem for translators is that you can't watch an individual file on SourceForge, so there are no notifications for changes available. Manually keeping up with the number of projects that I maintain has become impossible. I do read this forum regularly though.


Well, last week I translated locally on my computer using Poedit. When I want to use "tx push -t -l zh_CN" nothing get uploaded :| I have to use "--force" flag :( Maybe there are some bugs on comparing file modification time.

[EDIT] Also, it looks like that Transfiex will delete translations whose original text was removed from .pot files. This causes Translation Memory get lost. The local editor, for example Poedit, simply comments out the removed translations, which can still be used in Translation Memory.
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: V0.5 Preparation thread

Postby acme_pjz » 11 Aug 2018, 09:13

@Edward_Lii, my plan is release V0.5 Beta version next weekend, at around Aug. 19. There are no code-wise tasks left in my checklist. Is this time period too short for you to find bugs?
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: V0.5 Preparation thread

Postby Edward_Lii » 11 Aug 2018, 15:31

acme_pjz {l Wrote}:Yes, the half-baked collision detection code (written in 2012--2013 ?) has a lot of nasty bugs. I managed to fix most of them (see git rev 5269929, 1234a8f, 4a0fbf4, ... ) but there seems still bugs, for example in level 19 "subway surf" in Akos level pack you'll be squashed when you standing on a block moving up while another block moving up at a higher speed. :(

Yeah, the collision system is indeed not great and it seems that a fix/tweak generally has some undesired side-effect. The current state of master seems okay, apart from one thing: pushable blocks :|
I tried simplifying the collision system as a POC, using the following notions:
  • All blocks except pushables can be updated without problem (as they don't influence each other)
  • All pushable blocks will update after all other blocks have moved
  • Rather than combining "base velocities" and movement "velocity", change it to two phases: "forced movement" and "voluntary movement"
  • Rather than pushing the player, his shadow or pushable blocks iteratively, determine the "forces" and push them out of the blocks (makes this step order independent)
The "forced movement" is the movement coming from the delta of the block the player or pushable block is standing on. After applying this movement, a check is done to see if there are any overlaps with blocks, if so a push "force" in each direction is determined to push the player or pushable block out of it. The current code for that can behave differently depending on the order of the blocks, the POC approach doesn't.

If the player or pushable block no longer collides after "forced movement", they can start "voluntary movement" (which does include gravity). This now becomes a lot simpler as it's simply seeing how many of the desired pixels it can move before it hits something. The standing on check is still a bit complex, to handle the 50% on conveyor belt and moving blocks scooping the player/pushable block up.

Even with those changes, quite a few problems remained, and they all had to do with the order in which the pushable blocks were moved. I tried to sort them using a heuristic that ensured any stack of pushables would be updated from bottom to top. But even that is not sufficient as not being part of a chain, does not mean you are not influenced by pushable blocks in the chain (or even will become part of the chain in that update). In the end I didn't manage to find a reliable ordering, so I opted for having the pushable blocks indicate failure and processing it in multiple rounds until stable or after X amount of rounds. The end result works, but not very nice :(

I've committed the code to a branch on my repo (wip/collision) if you want to try it out, I've also attached some testing levels I've used, which illustrate several of the problems/difficulties.
levels.zip
(1.09 KiB) Downloaded 422 times


acme_pjz {l Wrote}:I think activate multiple switches at once is OK. Personally I don't like the approach that only activates the nearest switch. Plus, it certainly will break old replays. :think:

I'm fine either way, I also think it's generally not a great idea to place switches in adjacent blocks, anyway. What should be done IMHO is give visual feedback which switches are going to be activated. Perhaps with an outline or something?
That way the player won't be surprised if they are overlapping the adjacent switch by only a pixel or two.

With regards to breaking old replays, we should indeed avoid it where we can, but almost any changes to the collision/movement/activation might break replays.
At the very least we should ensure we don't break levels with the changes we make.

I don't know... do we need to remove them? :( I don't like that.

I also wouldn't like that, on the other we can't have levels/levelpacks with unclear licenses in our repo. Most of them will still be around on the forum, so they won't be totally gone.
In any case, I have contacted everyone and awaiting there response, I have good hope that we will hear back from most of them :)

acme_pjz {l Wrote}:@Edward_Lii, my plan is release V0.5 Beta version next weekend, at around Aug. 19. There are no code-wise tasks left in my checklist. Is this time period too short for you to find bugs?

My biggest concern at this point are the pushable blocks. For the most part they work fine, but they are so sensitive to the block order, that it can be very tricky to make levels with.
If we were to release them in the state they are in, I would probably only use pushable blocks in "controlled environments", which rule out certain level ideas I had.

Other than that, I think next weekend would be nice for a beta release. Throughout the week I can find some time to do some final extensive testing. ;)
Afterwards, it would be all making levels, playtesting and translating.
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: V0.5 Preparation thread

Postby acme_pjz » 11 Aug 2018, 18:46

Hi Edward_Lii,

...... so the plan is use the collision system in current master branch in V0.5 Beta version and wait until we figure out a new collision system for pushable blocks? Or release a final version anyway if the time period expires (a few months)?

Edward_Lii {l Wrote}:Even with those changes, quite a few problems remained, and they all had to do with the order in which the pushable blocks were moved. I tried to sort them using a heuristic that ensured any stack of pushables would be updated from bottom to top. But even that is not sufficient as not being part of a chain, does not mean you are not influenced by pushable blocks in the chain (or even will become part of the chain in that update). In the end I didn't manage to find a reliable ordering, so I opted for having the pushable blocks indicate failure and processing it in multiple rounds until stable or after X amount of rounds. The end result works, but not very nice :(


I have an ad-hoc idea: in the collision subroutine, sort the pushable blocks by their y coordinate, if y coordinates are equal then sort by x coordinates. By this way the collision result is deterministic, although it's still depend on block order, but it doesn't depend on the order of blocks added to the level editor, only depend on the coordinates they showed on screen.

[EDIT] I have read this article https://godotengine.org/article/godot-3 ... ematicbody and the situations in the last 2 gifs are a little bit like to the case you mentioned.

Edward_Lii {l Wrote}:I've committed the code to a branch on my repo (wip/collision) if you want to try it out, I've also attached some testing levels I've used, which illustrate several of the problems/difficulties.


I'll try it in a few days, since I'm get a little busy now.

Edward_Lii {l Wrote}:I'm fine either way, I also think it's generally not a great idea to place switches in adjacent blocks, anyway. What should be done IMHO is give visual feedback which switches are going to be activated. Perhaps with an outline or something?
That way the player won't be surprised if they are overlapping the adjacent switch by only a pixel or two.


Maybe we can rephrase the tip in the corner of screen as "press DOWN key to activate <number> switches" and highlight the switches if there are at least 2 switches will be activated (we don't highlight it if there is only one) ?

Edward_Lii {l Wrote}:My biggest concern at this point are the pushable blocks. For the most part they work fine, but they are so sensitive to the block order, that it can be very tricky to make levels with.
If we were to release them in the state they are in, I would probably only use pushable blocks in "controlled environments", which rule out certain level ideas I had.


My idea is use current collision code for V0.5 beta release, and we add "Pushable blocks are experimental, there are bugs especially multiple blocks stack together case ... please don't rely on strange behavior when designing levels utilizing pushable blocks ..." to the beta release note.
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: V0.5 Preparation thread

Postby bgalon_2000 » 11 Aug 2018, 22:58

acme_pjz {l Wrote}:
Edward_Lii {l Wrote}:I'll try and see if I can contact them. Though, what should we do in case we don't know under which license an addon falls?


I don't know... do we need to remove them? :( I don't like that.

Here is the list of addons with license unclear:



Hi All!

Nice to see this back in action. A few month ago, I noticed it went onto GitHub, but nobody was seem to be doing much.

Can't contribute to development - don't really have the time - but would love to do additional level packs with the new features.

As for Twelve Pits - At the time I didn't even consider a license, but if we need one, then I prefer the GPLv3 license. What license are we using for the software? If it's MIT then I think that's compatible. Let me know if that is okay.

Also, if I develop additional levels - should I become a part of the GitHub project? It's been a while since I done any serious development.

bgalon_2000
bgalon_2000
 
Posts: 15
Joined: 26 Sep 2012, 16:40

Re: V0.5 Preparation thread

Postby acme_pjz » 12 Aug 2018, 04:19

Hi,

bgalon_2000 {l Wrote}:As for Twelve Pits - At the time I didn't even consider a license, but if we need one, then I prefer the GPLv3 license. What license are we using for the software? If it's MIT then I think that's compatible. Let me know if that is okay.


GPLv3 license for levels seems a little bit weird, but I think it's OK :) The game itself is GPLv3 of course. See here https://forum.freegamedev.net/viewtopic ... 351#p54979 for previous license discussions.

bgalon_2000 {l Wrote}:Also, if I develop additional levels - should I become a part of the GitHub project? It's been a while since I done any serious development.


No, you don't need to (but of course you can) do that. You can either

  • still use this forum for posting levels/levelpacks,
  • or you can create a GitHub project by yourself for your levels if you want to share all the work-in-progress levels with others.
  • If you want to upload addon by yourself (beware the addon zip and metadata format is still undocumented, please test on your computer first), you can fork the addon repository and submit a pull request.
Last edited by acme_pjz on 13 Aug 2018, 19:04, edited 1 time in total.
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: V0.5 Preparation thread

Postby GunChleoc » 12 Aug 2018, 11:08

acme_pjz {l Wrote}:Well, last week I translated locally on my computer using Poedit. When I want to use "tx push -t -l zh_CN" nothing get uploaded :| I have to use "--force" flag :( Maybe there are some bugs on comparing file modification time.

I never push anything from the command line except for the .pot updates, so I haven't run into this bug before. Definitely worth telling the Transifex team about.

acme_pjz {l Wrote}:[EDIT] Also, it looks like that Transfiex will delete translations whose original text was removed from .pot files. This causes Translation Memory get lost. The local editor, for example Poedit, simply comments out the removed translations, which can still be used in Translation Memory.

I have never sourced fuzzy translations from po files, because I just use Virtaal's translation memory. So, it would be interesting to hear from the other translators. Unless we have bigger translation teams, it doesn't really matter, unless POEdit doesn't keep its own translation memory for you to source the strings from? I have only ever used it for its validation functions, because I prefer working with Virtaal.
User avatar
GunChleoc
 
Posts: 502
Joined: 20 Sep 2012, 22:45

Re: V0.5 Preparation thread

Postby acme_pjz » 12 Aug 2018, 16:44

Today it works... I update the messages.pot locally, "tx push -s", then I update the zh_CN translation locally, then "tx push -t -l zh_CN" works. However, it uploads all zh_CN translations, including those which are unmodified at all.

Also, the po files obtained by "tx pull" looks weird, too, for example in https://github.com/acmepjz/meandmyshado ... cale/de.po you can see something weird like "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE" and "charset=CHARSET".

.......

(It gets off-topic since we're in V0.5 preparation thread, not Transfiex bug reporting thread.)

@GunChleoc : Should I invite you to the language team or you send a request to me on Transfiex?
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: V0.5 Preparation thread

Postby GunChleoc » 13 Aug 2018, 08:37

acme_pjz {l Wrote}:Today it works... I update the messages.pot locally, "tx push -s", then I update the zh_CN translation locally, then "tx push -t -l zh_CN" works. However, it uploads all zh_CN translations, including those which are unmodified at all.

Yep, it doesn't track that, you'd need to restrict the resource manually with -r. I always upload manually via the web interface when I translate something, because we don't accept pull requests for translations on my project.
User avatar
GunChleoc
 
Posts: 502
Joined: 20 Sep 2012, 22:45

Re: V0.5 Preparation thread

Postby acme_pjz » 20 Aug 2018, 18:25

@Edward_Lii,

What is the progress of bug hunting?

Unfortunately, I found another bug regarding collision: <https://github.com/acmepjz/meandmyshadow/issues/19>. I have a fix to it, but it will introduce game mechanics changes, i.e. the player can carry shadow when it is moving left or right (but still can't carry when jumping). So my opinion is leave this bug in V0.5 :| and we change the game mechanics (??) in V0.6. What do you think?

So the beta release date is delayed, maybe Wednesday or next weekend? :|
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: V0.5 Preparation thread

Postby Edward_Lii » 21 Aug 2018, 20:00

acme_pjz {l Wrote}:So my opinion is leave this bug in V0.5 :| and we change the game mechanics (??) in V0.6. What do you think?

Agreed, I don't see a nice/easy way to resolve this in time for V0.5. This would mean trying to avoid levels relying on the current behaviour, which, luckily, shouldn't be to hard as (fast) conveyor belts and having to stand on the shadow or vice versa is probably not a good idea for a level anyway. Whether or not we should change the game mechanic or not, we should still discuss. Since we are probably going to tackle the collision system for V0.6 we might still be able to find a way to make this behave consistenly.

It doesn't happen with pushable blocks, because they don't transitively look for the block the bottom one is standing, but check the block directly below it. So if anything blocks the forced movement, the blocks on top would take over the adjusted delta (possible lagging behind a frame due to the order of the pushable blocks in the level). So if we would know the "delta" of the player/shadow, caused by the forced movement, we could resolve this in the same way. Given that we now (in the latest commit) order the collision/movement of the player and shadow depending on who is holding the other, we won't have the problem of lagging a frame behind, but currently both forced and voluntary movement is combined.

This sadly made me realize that in my collision system PoC, there is a bit of a problem. While splitting forced and voluntary movement makes things simpler and more straightforward, it introduces some weird behaviour in combination with conveyor belts. :|
The conveyor belt causes forced movement, which, when blocked, will be resolved by clamping the player/shadow to the blocking element. Any "excess" forced movement is lost, meaning that during voluntary movement, the player can walk against the direction of the conveyor belt, although will be pushed back the next frame. This was likely the reason why the two were combined into one in the first place in the current collision system.

acme_pjz {l Wrote}:What is the progress of bug hunting?

So far didn't have as much time as I hoped, apart from the several bugs I fixed. There is one bug I occasionally encounter with rendering, where in overlays the background flicker. Though, that seems related to my window manager and/or SDL2, so not entirely sure it's in our code or even fixable, but I would still like to have a look if I can find the cause.
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: V0.5 Preparation thread

Postby acme_pjz » 22 Aug 2018, 04:41

Edward_Lii {l Wrote}:So if we would know the "delta" of the player/shadow, caused by the forced movement, we could resolve this in the same way. Given that we now (in the latest commit) order the collision/movement of the player and shadow depending on who is holding the other, we won't have the problem of lagging a frame behind, but currently both forced and voluntary movement is combined.


Yes, the proposed bug fix by me will transfer the capped and combined forced and voluntary movements, but the current game mechanics is only transfer forced movements.

Edward_Lii {l Wrote}:There is one bug I occasionally encounter with rendering, where in overlays the background flicker. Though, that seems related to my window manager and/or SDL2, so not entirely sure it's in our code or even fixable, but I would still like to have a look if I can find the cause.


This bug doesn't occur on my computer, both Windows and Linux (Ubuntu based Puppy Linux) :| So maybe it's indeed a graphics driver problem?
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: V0.5 Preparation thread

Postby Edward_Lii » 23 Aug 2018, 07:44

acme_pjz {l Wrote}:This bug doesn't occur on my computer, both Windows and Linux (Ubuntu based Puppy Linux) :| So maybe it's indeed a graphics driver problem?

I think I've figured it out and it's indeed related to the graphics driver/graphics stack, but the way we approach things is also partially to blame.

When we render a GUIOverlay, we don't render the underlying state any more (unless we resize the window). We rely on the fact that what we've drawn stays there and only redraw the GUI objects on top.
However, at least in my case, the game is clearly double buffered, whenever we flip the screen, we get the other buffer, which can contain a different "backdrop" which is slightly older. This can result in small "jumps", after a resize.
The really weird part is that occasionally it seems a third "buffer" shows up that is even older (when opening the overlay for a new levelpack, it can be a screen from the fade transition or even the main menu(!)).
This generally occurs when I move the window from one screen to another, frantically resize the window or when some other application runs with vsync on a different monitor (and gets focus).

As a crude way to remedy this I changed the resize code in the overlay to render the underlying state + dim thrice and flip the screen each time. Lo and behold the above mentioned behaviour was gone when resizing.
Now this is obviously not a real solution. I think the best approach would be to always ensure we render the full screen, meaning for GUIOverlays we render the underlying state, dim screen and then the overlay.
My only concern is that our render methods are not always void of logic, meaning we might have animations or other things going on in the background while the overlay is present.

In any case, while it is probably due to the combination of graphics driver/window manager/etc I have, I don't think this would be too uncommon.
We should simply not make any assumptions about the current state of the buffer and start our rendering with a clear (or ensure we redraw the entire screen).
For the record I'm experiencing this on a laptop with Intel integrated graphics attached to multiple monitors on Linux with KDE (both with and without hardware accelerated window management).
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: V0.5 Preparation thread

Postby acme_pjz » 23 Aug 2018, 08:40

Edward_Lii {l Wrote}:When we render a GUIOverlay, we don't render the underlying state any more (unless we resize the window). We rely on the fact that what we've drawn stays there and only redraw the GUI objects on top.
However, at least in my case, the game is clearly double buffered, whenever we flip the screen, we get the other buffer, which can contain a different "backdrop" which is slightly older. This can result in small "jumps", after a resize.


OK... it's indeed problematic with double buffer enabled :|

Edward_Lii {l Wrote}:As a crude way to remedy this I changed the resize code in the overlay to render the underlying state + dim thrice and flip the screen each time. Lo and behold the above mentioned behaviour was gone when resizing.
Now this is obviously not a real solution. I think the best approach would be to always ensure we render the full screen, meaning for GUIOverlays we render the underlying state, dim screen and then the overlay.


I think there may be a problem regarding render the underlying state in the msgBox code, since it uses its own event loop.

Edward_Lii {l Wrote}:My only concern is that our render methods are not always void of logic, meaning we might have animations or other things going on in the background while the overlay is present.


I think it's probably OK if the animations are still playing when a dialog pops up in the level editor :|

------

I haven't checked the existing code yet, maybe I'll check later. Meanwhile, will you submit a pull request later?
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: V0.5 Preparation thread

Postby acme_pjz » 26 Aug 2018, 04:48

Hi all,

I have just released the V0.5 Beta version. :) You can find the files here: https://sourceforge.net/projects/meandm ... s/0.5beta/ currently there are Win32 and Linux64 binaries as well as source packages. Can anyone fix the Mac OS X build?

You can read the announcement here: https://acmepjz.github.io/meandmyshadow ... eased.html
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: V0.5 Preparation thread

Postby GunChleoc » 26 Aug 2018, 10:20

I have just created a pull request with a small fix to the translation system: https://github.com/acmepjz/meandmyshadow/pull/21
User avatar
GunChleoc
 
Posts: 502
Joined: 20 Sep 2012, 22:45

Who is online

Users browsing this forum: No registered users and 0 guests

cron