> > BTW, if anyone would try to create a *real* graphical > > shell (not just a program launcher), I mean... an entire > > graphical environment, with standard libraries for input, > > windows, system resources and so on, Screen 6 is the > > natural choice. > Not at all. If such a library would be created it should be hardware > independant
Shevek, remember we're talking about MSX. It's nonsense talking about "hardware independent GUI" on MSX. Making such abstraction layers will cause your GUI to be slower due to the great overhead. > The > implementation may start as screen 6 only, but it should be no problem > to port it to screen 5, 7 and 8 (and higher for 2+). SCR5 and 8 are useless for a GUI. 256x192 isn't practical for a GUI. SCR7/10/11/12 needs too much memory. For example, SCR6 needs 27.5Kb for an entire 512x212 screen. SCR7 needs 54kb. And you know that a GUI is, by nature, a big memory consumer. Also, if things are slow in SCR6 (where you can plot 4 pixels with a single byte), they will be even slower in SCR7 (where you plot only 2 pixels with a byte - SCR8 is even worse). > It would be really bad > if you write an image viewer and it can only be used in screen 6. Sure. But MSX has limitations and they must be workarounded. In this case, I think that allowing a GUI application to change temporarily the screen mode to show a picture in full screen is the best solution. Adriano Camargo Rodrigues da Cunha ([EMAIL PROTECTED]) Diretor Executivo - A&L Software http://www.alsoftware.com.br http://www.alsoftware.com.br/adrianpage -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
