On Wed, 03 Aug 2005 22:04:36 +0200 Helge Hafting <[EMAIL PROTECTED]> wrote:
Hi.
First of all, thank you for the problem report.
> Package: cuyo
> Version: 1.8.5-1
> Followup-For: Bug #208688
>
>
> Some levels, particularly the second level (embroidery) overloads my
> 1800MHz opteron to such an extent that it is unplayable.
I wasn't able to reproduce the problem. On my computer (and on some
others), this level works without problems. (In fact, I had the problems
you describe on some old and slow computers, but only with levels which
do a lot of animation, like tennis.) Could you tell me exactly which of
the levels are slow on your computer, so I can try to figure out what's
the problem? (I'm especially wondering because indeed, embroidery is a
level with very simple graphics.)
What you also could do to help me finding the problem is: I attached a
modified version of the level description file for embroidery. I'm
suspecting the background picture of being the problem, so I commented
it out. Could you try this modified level and tell me if the problem
still persists? To do that, you simply can save the file somewhere.
I assume you're calling it "embr.ld". Then type "cuyo embr.ld" and
start the game. (When you start cuyo this way, embroidery will be the
only available level.)
Immi
PS: Of course, the handling of high-load-situations in cuyo is awful,
and it's somewhere on my to-do-list to improve this, but I don't have so
much time for cuyo and anyway, I would like to rewrite the graphics part
entirely.
>
> It uses way too much cpu for the very simple graphichs displayed - the simple
> graphichs could be done by a 1990's (or even 1985) machine with no problems.
> The game itself is _excellent_, but the graphichs programming is a bad joke.
>
> The level is playable in the beginning, although it uses an insane amount of
> cpu for doing very little. It ruins itself just when the fun begins, that is,
> when rows gets passed back and forth between players depending on success.
>
> Then the game uses so much cpu that it delays itself, and it does not process
> keypresses at aÃll while the row is transferred and some time before and
> after.
> This gives the computer player a huge advantage - the human player can only
> sit
> and see his pieces fall slowly down with no control. Pressing keys have
> no effect until much later.
>
> Because of this enormous delay in handling keypresses, the human seems to play
> very bad - just letting the pieces fall in a heap in the middle. And so
> the computer gets another row transferred, causing so much further delays that
> another row gets transferred. And so on - until the game is lost.
>
> I have lost many a good game to this silliness. It gets much worse if the
> machine is under a light load, such as a niced compile or another user
> doing something. Zero load means the level sometimes is barely playable,
> and sometimes not at all. Too bad for an otherwise nice game -
> I really like cuyo. Only a few levels are like this, most levels
> works fine! Please look into how the graphichs is done, this cannot be
> that hard to fix.
>
> This is on amd64 - it is equally bad on i386.
>
>
> -- System Information:
> Debian Release: testing/unstable
> APT prefers testing
> APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Shell: /bin/sh linked to /bin/bash
> Kernel: Linux 2.6.13-rc5
> Locale: LANG=no_NO.UTF-8, LC_CTYPE=no_NO.UTF-8 (charmap=UTF-8)
>
> Versions of packages cuyo depends on:
> ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries
> an
> ii libgcc1 1:4.0.1-2 GCC support library
> ii libqt3c102-mt 3:3.3.4-3 Qt GUI Library (Threaded runtime
> v
> ii libstdc++5 1:3.3.6-5 The GNU Standard C++ Library v3
> ii zlib1g 1:1.2.2-4 compression library - runtime
>
> cuyo recommends no packages.
>
> -- no debconf information
>
>
--
--------------------------------------------------------------------------
Immanuel Halupczok www.karimmi.de www.croco-puzzle.com
--------------------------------------------------------------------------
embr.ld
Description: Binary data
