Working towards a release V0.4

Working towards a release V0.4

Postby Edward_Lii » 08 May 2012, 19:55

Hello all,

The previous release (V0.3) has been out for some time now and I think it's time for the next release.
There are some big changes, including translation support, multiple resolution support and collectables.
Recently the progress is going slowly, I guess this is partially because we're all a bit busy but also because
implementing new features isn't something you do when there's a new release coming.

So I think it's important to list the things we need to do and create a V0.4 :)

Game
  • When resizing the window prevent it from going below 800x600. ---Done (for X11)
  • Invert the retrieved list of resolutions, right arrow for increasing makes more sense IMHO. --- Done
  • Find a solution for switching to fullscreen from a manually resized window, it will result in arbitrary resolution. ---Done
  • Fix the issues with long translation texts. ---Done
  • Fix the bug where the arrows of the translation listbox would overlap with the text (here). ---Done

Content
  • Update the Cloudscape theme to include newly added assets (collectables).
  • Add more levels (working on a sequel of Castle Rescue ;) )
  • Update the tutorial levelpack.
  • Add more music to the game, veav is willing to re-license some of his old work. :D ---Done

Pre RC
  • Create the .pot file and start a string freeze. ---Done
  • Create .pot files for the levelpacks that get bundled with the game. ---Done (except for the tutorial levelpack)
  • Let the translators do there job, add them to the wiki (Authors).
  • Make a new/updated trailer?

I think this is pretty much it, if there's anything missing just tell me.
The tasks on this list can be added to the bug/issue tracker, sadly I'm quite busy the next few days. :|
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: Working towards a release V0.4

Postby acme_pjz » 09 May 2012, 06:07

Hi,

Edward_Lii {l Wrote}:When resizing the window prevent it from going below 800x600.


It looks like SDL doesn't have this feature :| or I missed something...

Edward_Lii {l Wrote}:Find a solution for switching to fullscreen from a manually resized window, it will result in arbitrary resolution.


It looks like not so hard, just find the nearest fullscreen resolution

PS: I'd like to add some collectible and usable items, this will introduce some new control keys... I don't know if it fits the game's style...

PS2: Where is the level/levelpack uploading feature?
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: Working towards a release V0.4

Postby Edward_Lii » 09 May 2012, 15:03

Hello acme_pjz,

acme_pjz {l Wrote}:It looks like SDL doesn't have this feature :| or I missed something...

Then we'll have to find a workaround...
Perhaps if we can detect when the scaling is done we can update the window for 800x600. :think:

acme_pjz {l Wrote}:It looks like not so hard, just find the nearest fullscreen resolution

This gave me an idea, what if we could detect the current resolution and use that as fullscreen resolution.
The only problem is that this will conflict with the resolution settings, especially because it should be possible to run the game fullscreen in a chosen resolution.

acme_pjz {l Wrote}:PS: I'd like to add some collectible and usable items, this will introduce some new control keys... I don't know if it fits the game's style...

I think it's best to leave that for after the V0.4 release.
About the additions fitting the game style, I've ran into that a few times before, does feature X fit the style of the game?

What I think we should do after the release is to create a (detailed) roadmap all the way to V1.0.
This means that we should think how the finished game will look/feel and thus what fits and what doesn't.

ame_pjz {l Wrote}:PS2: Where is the level/levelpack uploading feature?

The upload feature requires a lot of server side coding and I kind of decided that it's better to keep it for V0.5.
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: Working towards a release V0.4

Postby acme_pjz » 09 May 2012, 15:38

Hi,

Edward_Lii {l Wrote}:Perhaps if we can detect when the scaling is done we can update the window for 800x600.


It's possible, just add some code in onVideoResize() function in Functions.cpp. Not sure it will introduce some weird behavior :|

Edward_Lii {l Wrote}:This gave me an idea, what if we could detect the current resolution and use that as fullscreen resolution.
The only problem is that this will conflict with the resolution settings, especially because it should be possible to run the game fullscreen in a chosen resolution.


:| I mean use available fullscreen resolution which is nearest to current window's size and not smaller than 800x600...
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: Working towards a release V0.4

Postby Edward_Lii » 09 May 2012, 17:03

Hello acme_pjz,

acme_pjz {l Wrote}:It's possible, just add some code in onVideoResize() function in Functions.cpp. Not sure it will introduce some weird behavior :|

I will try it if I have the time to try it. ;)

acme_pjz {l Wrote}::| I mean use available fullscreen resolution which is nearest to current window's size and not smaller than 800x600...

I understand, what I meant was that if we add a key for switching to fullscreen (say F11?) it would be best to go with the desktop resolution.
But I don't think we need to add such function.

For the actual selecting the nearest resolution, IIRC there's code for that already in the TitleMenu.cpp.
We only have to use that code in the fullscreen initialization code.
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: Working towards a release V0.4

Postby Edward_Lii » 13 May 2012, 11:25

Hello all,

Some thoughts on the recent addition of resizable windows.
Although it's quite useful and feels kind of nifty, there are still some rough edges, some of which are hard to solve.
At the moment it gives a slightly unpolished feel.

Problems:
    - The screen flickers during resizing (it should be black until resizing is done)
    - The window can be resized below 800x600 and we can only resize it back afterward.
    - The GUI's need to be recreated/repositioned upon resizing.
    - We don't know what someones WM will do.
I think the last one needs some clarification, the problem is that we don't know what a WM will do and how.
Take for example the rescaling, one WM might send resize events all the time while the other might send only one at the end of the resizing.

Another issue is that the WM can now place/size the window how he wants since the window is resizable.
If I snap my window to the screen (kind of maximizing) KDE will remember that, so the next time I run it it will be at the resolution 1920x1080, even thought I might have configured it differently.
Either we find solutions to these problems, preferably in an abstract way, not writing workarounds for every possible WM/DM or we remove this feature.

And as far as I can see there aren't many games that have a resizable window.
So do we need it?

Feedback is welcome. ;)
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: Working towards a release V0.4

Postby acme_pjz » 13 May 2012, 13:46

Hi,

Edward_Lii {l Wrote}:- The screen flickers during resizing (it should be black until resizing is done)

....

I think the last one needs some clarification, the problem is that we don't know what a WM will do and how.
Take for example the rescaling, one WM might send resize events all the time while the other might send only one at the end of the resizing.


Yes, it varies. For example in Windows there is an option of window manager whether send resize events during sizing or only one at the end of the resizing...

Edward_Lii {l Wrote}:Another issue is that the WM can now place/size the window how he wants since the window is resizable.
If I snap my window to the screen (kind of maximizing) KDE will remember that, so the next time I run it it will be at the resolution 1920x1080, even thought I might have configured it differently.
Either we find solutions to these problems, preferably in an abstract way, not writing workarounds for every possible WM/DM or we remove this feature.

And as far as I can see there aren't many games that have a resizable window.


I don't know, AFAIK Battle for Wesnoth has sizable window, maybe you can try it and check the code (it uses SDL too)

Edward_Lii {l Wrote}:So do we need it?


If you want to temporarily disable it just comment out SDL_RESIZABLE in createScreen() function...

BTW: There are some bugs in Main.cpp svn r374: the type of lastResize is uninitialized and if(lastResize.type=SDL_VIDEORESIZE){ ... it should be lastResize.type==SDL_VIDEORESIZE, maybe this cause the flickering...
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: Working towards a release V0.4

Postby Edward_Lii » 13 May 2012, 13:56

Hello acme_pjz,

acme_pjz {l Wrote}:Yes, it varies. For example in Windows there is an option of window manager whether send resize events during sizing or only one at the end of the resizing...

I assume that if it's set to the end it will look a bit smoother.

acme_pjz {l Wrote}:I don't know, AFAIK Battle for Wesnoth has sizable window, maybe you can try it and check the code (it uses SDL too)

I didn't expect it but I encounter the same issues in Battle for Wesnoth.
The window resolution doesn't match the configured resolution, because of KWin, and the screen flickers during resizing.

I was even surprised when I saw some parts not being scaled/updated after scaling the window up in Battle for Wesnoth.

acme_pjz {l Wrote}:BTW: There are some bugs in Main.cpp svn r374: the type of lastResize is uninitialized and if(lastResize.type=SDL_VIDEORESIZE){ ... it should be lastResize.type==SDL_VIDEORESIZE, maybe this cause the flickering...

That's not the problem, the fixed version also causes flickering. :|

I'm still not sure, there is an advantages, but IMHO it doesn't weigh up against the (minor) glitches it produces...

EDIT: Also not 100% sure it's related, but recently I get a lot of OpenAL underrun errors when the meandmyshadow window has no focus after resizing.
This isn't really a problem but for some reason meandyshadow starts consuming a lot of memory (~3GiB). :?
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: Working towards a release V0.4

Postby acme_pjz » 14 May 2012, 04:09

Hi,

Edward_Lii {l Wrote}:EDIT: Also not 100% sure it's related, but recently I get a lot of OpenAL underrun errors when the meandmyshadow window has no focus after resizing.
This isn't really a problem but for some reason meandyshadow starts consuming a lot of memory (~3GiB). :?


Weird :| Is it after resizing window a lot?
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: Working towards a release V0.4

Postby Edward_Lii » 14 May 2012, 14:17

Hello acme_pjz,

acme_pjz {l Wrote}:Weird :| Is it after resizing window a lot?

I tested it some more and it seems that the openAL underrun errors are unrelated to this.
After resizing the window a bit, not that much, say scaling it up and then back to ~800x600 is enough to cause it.

It's really strange, because all is fine (not that much memory usage) until I change focus from the game window to the desktop or another application.
It doesn't matter if the window is still visible or not. :|
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: Working towards a release V0.4

Postby acme_pjz » 14 May 2012, 15:54

Hi,

Edward_Lii {l Wrote}:It's really strange, because all is fine (not that much memory usage) until I change focus from the game window to the desktop or another application.


Maybe the window manager keep sending messages when the window lost focus :| And there is some bug in SDL code misunderstand the meaning of the message... Try add some console printing code in function which processed window resize event and see if the terminal will print something weird
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: Working towards a release V0.4

Postby Edward_Lii » 14 May 2012, 16:05

Hello acme_pjz,

acme_pjz {l Wrote}:Maybe the window manager keep sending messages when the window lost focus :| And there is some bug in SDL code misunderstand the meaning of the message... Try add some console printing code in function which processed window resize event and see if the terminal will print something weird

I tried to detect what is causing this but couldn't find anything. :|

When the memory usage increases there are no SDL_RESIZE events sent.
Also the "memory increase" rate can vary, sometimes it grows very slowly (+0.1GiB per 10s) and sometimes it's skyrocketing (+0.2GiB in 2-3s).
The openAl errors mentioned before can appear after my ram is full, but again it depends on the speed. Presumably because if it increases fast it will have to swap a lot more.
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: Working towards a release V0.4

Postby acme_pjz » 15 May 2012, 05:04

Hi Edward_Lii,

:(

Try insert some code to SDL_CreateRGBSurface (i.e. #define SDL_CreateRGBSurface to something else in the game's header then in a separate cpp file implement it, print some debug output then fallback to original function ) ... Does Valgrind help?
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: Working towards a release V0.4

Postby Edward_Lii » 15 May 2012, 15:20

Hello acme_pjz,

Good news, I found the source of the problem. :D
Thanks to odamite for suggestion to try it with the SDL renderer, the problem was related to the fact that the openGL texture wasn't freed.

acme_pjz {l Wrote}:Does Valgrind help?

I have tried Valgrind and it didn't report a memory leak, at least not in the quantities that we're needed to explain it.
There where however some occasional bytes lost once in a while somewhere inside libasound (openAL).

But there are still problems left and I found a new one. :cry:
The workaround for windows below 800x600 doesn't play nicely with X11.
X keeps sending resize events when the window is scaled below 800x600 but isn't.

This doesn't pose a problem since it onVideoResize method handles this, but it does bring some strange behaviour with it.
First of all meandmyshadow suddenly receives key events, even if the window doesn't has focus.
And for some reason the fade out effect doesn't work, but fade in works fine.

I think we should really find a proper solution for this.
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: Working towards a release V0.4

Postby Edward_Lii » 17 May 2012, 09:59

Hello all,

I've been trying to fix some things regarding the resizable window and sadly this can't been done through the window interface SDL gives us.
The only solution I've found is to retrieve the (window manager specific) window handle from the SDL window and configure it to our needs.

What this means is that we need to write WM/DM specific code in order to get the desired result.
My idea was the following, get the window handle and do some wm specific code if supported.
Basically we whitelist the window managers we support (presumably the Win32 and X11 ones), in other cases we disable it by default and allow the user to enable it.

Also one more thing, it might be best to only set the SDL_RESIZABLE flag when not fullscreen, believe it or not, but for some reason GNOME3 resized the "fullscreen window".
Removing the resizable flag will assure that the chosen resolution will be used in fullscreen mode.
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: Working towards a release V0.4

Postby odamite » 23 Jun 2012, 13:19

Hello everyone,

There isn't many coding tasks left. Sadly I've found some bugs which happens during resizing the window:
  • In level editor dimming background doesn't resize
  • When resized while dialog open, dimmed background goes black and dialog doesn't recenter. This isn't a big problem. However resizing in key config dialog, almost entire screen goes black including the dialog. This alone makes the whole game unusable. :(
User avatar
odamite
 
Posts: 166
Joined: 16 Jan 2012, 16:28

Re: Working towards a release V0.4

Postby Edward_Lii » 23 Jun 2012, 14:28

Hello odamite,

odamite {l Wrote}:There isn't many coding tasks left. Sadly I've found some bugs which happens during resizing the window:
  • In level editor dimming background doesn't resize
  • When resized while dialog open, dimmed background goes black and dialog doesn't recenter. This isn't a big problem. However resizing in key config dialog, almost entire screen goes black including the dialog. This alone makes the whole game unusable. :(

I encountered something similar once before, but couldn't point out the cause of it.
Resizing the window during a popup/dialog reproduces this bug, and it's quite a bad bug to be honest.

Basically every resize during a "temp" gui will fail one way or another (some cases a segfault, black background, unresponsive GUI). :|
I think the problem is that the GUIObjectRoot pointer points to the wrong GUIObject, so the resize should be done by the temporary GUI but the resize() method of the currentState is called.

One solution would be to create a global GUIObject pointer that is used for storing the actual GUIObjectRoot when creating a dialog instead of a local pointer.
That way the resize method of the states can still access the GUI of the state and its elements.
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Who is online

Users browsing this forum: No registered users and 1 guest