-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi,
Eero Tamminen wrote: > Hi, > > ext Frantisek Dufka wrote: >>> And if the game doesn't disable the double pixeling properly (e.g. if it >>> crashes or freezes), user needs to reboot the device. Not very nice >>> either... >>> >> So what happened to idea mentioned here year ago to modify Xsp (or >> whatever) API so that pixel doubling is flag of each display update >> separately? I.e. every update would be not pixel doubled unless told so >> by flag with each update. This is how it works on kernel framebuffer >> level anyway. I would double this. Even through we could switch to lower resolution, it would still be beneficial to have option to have just some parts of the screen pixeldoubled. One of these cases is a game which would draw everything (except static gui parts) pixeldoubled when the scenery moves and then draws everything in hi-res when the scenery freezes (and only small parts of the scenery moves). >> >> It is bad to turn in on and off because any other display update >> (infoprint) can mess it up. If we had blitting API in Xsp with pixel >> doubling flag settable per update this problem would go away. >> <snip> > > Also, it would be good to support the standard resolutions like 320x200 > (with black borders) so that more programs would work unmodified. Many > games/emulators want a specific resolution. > For example SDL gets smallest res which is equally as big or bigger than requested and gives a window of requested size having black borders around it (I am talking obviously about fullscreen behavior here). Of course, there is some games which doesn't use SDL but plain X, but even in this case when you request fullscreen window, you will get one and if you draw into 0,0 you end up having your "small window" in topleft corner. Of course there is many possibilities for clipping problems and other things breaking up, but the point is, if you want to write a resolution specific game, you probably want to use SDL. > >> Pixel doubled resolutions would be nice and would be improvement over >> current situation indeed. What we will miss with this solution is having >> some parts of screen pixel doubled and some not > > Games can already do this on 770 by setting pixel doubling on after > blitting the more detailed graphics. But as you said RandR doesn't > support that. Besides, the infoprints would still look funny. Not > as funny as with pixel doubling, but they would be too large and > as window manager positions them right aligned, they would be clipped > from the left instead of right like with Xsp. :-) > > What is really needed is a flag that is window specific. > In theory it could be possible that one window (or one client) thinks that the resolution is 400*240 but it really isn't for other clients. In fullscreen world, this is rather simple and you would get for example hi-res infoprints on top of pixeldoubled game window. But again, I'm not the most specialized on these things, so it might be that doing this would be _really_ dirty. > >> like nice control area with nice static graphics and main pixel >> doubled game area. > > I don't think it would be a great loss if the whole window would be > pixel doubled. The screen is 226 DPI. Pixel doubled it would still > 113 DPI, i.e. more accurate than most (CRT) monitors. A bonus would > be that game would use less memory for its graphics (as they are > smaller) and you don't need to modify the game to support two screen > resolutions. IMO this is a loss. There is many things which you could do with the blit-specific doubling. If it is possible to have both, why to drop another (unless we are speaking about something which might potentially break things)? - -- Kuisma -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGNb8KHIcMorDK+qsRAizOAJ9i6oWLrw6hjSzpRi0/nuCh3yaD9gCfZXoH 2f8CS2naOgKGmXPiD9sgLhY= =PIKI -----END PGP SIGNATURE----- _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
