[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.