[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#718323: another hyperrogue suggestion from debian reviewers




chrysn wrote:

zeno, i think i have forgotten to mention this in my mails: if you published the source directly as your version control system, and/or produce a .tar.bz2 file with your original source code (and third party additons like the music), things would be a little easier for us, and for other distributions too. (eg, f-droid likes to pull its sources from git or hg repositories).

I am used to my local version control and release scripts, so using a public git repository would be an additional hassle for me. But it could be indeed a good idea, I will think about it.

On Mon, Nov 25, 2013 at 12:34 PM, Damyan Ivanov <dmn@debian.org> wrote:
-=| chrysn, 23.11.2013 16:48:55 +0100 |=-
> On Sat, Nov 23, 2013 at 05:22:29PM +0200, Damyan Ivanov wrote:
> > I intent to work on all the points and eventually upload the
> > package, if that's alright with you. (I am already member of
> > pkg-games, cc-ed).
>
> if you find the time before i do, i'd of course appreciate contributions
> to the package source in the team repo and it being uploaded!

I think I addressed all my points. The result is in pkg-games Git[1].
I hope my contributions are not too invasive.

[1] http://anonscm.debian.org/gitweb/?p=pkg-games/hyperrogue.git

If the changes look alright to you, I'll upload soon.

I have only two wishes to upstream:

 * lower CPU consumption
   It seems the game redraws as often as it can, resulting in fps from
   60 to well over 100 when the window size is reduced. This is an
   overkill and a great laptop battery drainer
   The same can be observed with the android version (albeit with fps
   about 20, which is still too often, as the only moving things are
   the treasures, which could be redrawn more seldom, I think)

I have introduced a framerate limit. Also it now stops music and rendering if the window loses focus. I am not sure whether I should already release a new version with just this small change (some other changes might appear soon), but the changes are here:

 
* parallel build
   it is a small issue, but when the source has to be rebuilt numerous
   times (is when working on the packaging), employing all of the
   available CPUs would help.

I think changing this would take more time than it would save...

Thanks for the help! - Z

Reply to: