[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] fVDI drawing bugs
Hi,
On torstai 13 syyskuu 2012, Helmut Karlowski wrote:
> Eero Tamminen, 12.09.2012 23:38:10:
> > Tester binaries and sources for demonstrating these issues can
> >
> > be found from here:
> > http://koti.mbnet.fi/tammat/hatari/devel.shtml#vditest
> > http://koti.mbnet.fi/tammat/open.shtml#filler
>
> The first version that does not crash on aranym - great!
>
> I don't know where the errors are
You see them only if you have fVDI.
> and what to do to win this game
There's no "win" condition, but you can try to get better points.
> but it's fun :-)
Thanks!
Idea wasn't mine, it was originally a browser Flash game which
came 3rd on a design competition with theme "ball physics".
I liked the idea so much (partly due to its simplicity) that
I wanted to write a native version myself. Took a few years
before I got around to that, but now it's finally here. :-)
> Seems the fullscreen-issue can be closed?
Well, I think application needing to create a dummy menubar
to get desktop menu redrawn after app exits, is a really
ugly[1] workaround for something that I consider a regression
in AES.
I think it's a regression because all preceeding single TOS AESes
redraw desktop menubar just fine when application exits, without
need for this kludgery.
Probably the easiest/smallest fix would be if XaAES (and
other multitasking AESes that have the same issue) would
issue redraw for the desktop menubar when:
* form_dial(FMD_FINISH...) is called with co-ordinates
overlapping the menubar, or
* a window which originally given co-ordinates overlapped
the menubar, is closed.
- Eero
[1] If one would just need to call a function or two it
wouldn't so bad, but needing to construct a full menu
OBJECT tree structure to avoid XaAES freezing, is what
makes it ugly/annoying. The code alone is a sizable
part of a small test program, especially as one needs
to have it in all similar programs.