No i w kolorach. Ogólnie dobrze jest przyjąć filozofię z "dużych" GUI - uniezależnienie od rozdzielczości i ilości kolorów - nic na sztywno. Po prostu system pobiera tryb zdefiniowany jako rozdzielkę i ilość kolorów i używa takich parametrów do rysowania. Łatwo potem dopisać sterownik do czegoś innego np. do VBXE. Takie było zresztą założenie windy - pójdzie i na superduper hipercolor svga w srylionie kolorów i na herkulesie w dwóch. Bez żadnego wpływu na zasadniczy kod. A sterownik jest sprawą producenta.

Nawet nie sam autor musiałby suport dla VBXE robić - wystarczy aby określił API dla takowego, czyli parametry i funkcje rysujące interfejs, pobierające rozmiar ekranu (oczywiście system musi być do tego dostosowany a nie zakładać na sztywno 320x200 w dwóch kolorach) - powiedzmy w postaci tablicy w systemie. Wtedy ktoś za pomocą specyfikacji może te podstawowe funkcje napisać i podpiąć w odpowiednich miejscach i chodzi. Dla uproszczenia można by zrezygnować z ustawiania trybów czy ich listy - to wszystko zajmuje pamięć. Tylko napisać osobne sterowniki dla 640x328 albo 320x200 w hi-color. A standardowy obsługuje gr 8 i z bani. Jak ktoś się uprze to może i gr 15 dopisać :) Dlatego fajnie by było aby pomyśleć o kolorach w 2-kolorwym trybie obsługiwanych jako progowanie czy prosty tint.

I like your point of view - I'm sure it will be excellent piece of software. What about overhead - I think to avoid it's quite enough to build screen API and driver entry points not basing on atomic operations like drawing pixels or lines, but just more complex tasks as: draw a window (that one can be to general, but it's just an example) or draw polygon at layer X.

@wieczor: most of the screen handling for the UI (clearing window areas, drawing frames, etc) bypasses pixel-level operations and works directly with the screen RAM. As I've said elsewhere, it's simply essential for the sake of speed. Drawing primitives (circles, diagonal lines, flood fills, etc) will be a completely separate concern. Indeed, depending on how much room the UI consumes (at the moment, it's about 6KB of code), the drawing library could be loaded solely by those apps which require it (e.g. a drawing program), otherwise it's just taking up space 90% of the time.

Naturally, with successive optimisations, "draw dialogue" and "draw window" will share the same base code. I'm starting to write all the dialogue controls now, and this means designing structures for the header file, writing all the methods, expanding the dispatcher. It will take months of steady progress. :)

Ostatnio edytowany przez flashjazzcat (2011-02-07 15:42:16)

wieczor :) - nic nie mówię, lecz wydaje mi się, iż dostosowanie GUI ze zwykłego Atari do pracy pod VBXE oznacza jego napisanie od zera :)

What - rewriting the whole GUI from scratch? I have around 2,500 lines of code, and only 500 lines of code (those in the GFX.S module) are concerned with drawing to the screen. And of those 500 lines of code, there are about 20-30 direct writes to the screen RAM. Moreover, GFX.S hasn't grown in size for weeks (while GUILIB.S grows exponentially). There is much more to a GUI than drawing lines and blitting. The bulk of the system is all about object manipulation.

Exactly so. Most of the GUI operations are reducible to:

- Clear an area of the screen
- Move an area of the screen to a back-buffer
- Move buffered background data back to the screen
- XOR an area of the screen
- Draw a horizontal/vertical line
- Blit a bitmap to the screen (an icon or alpha character)

This is all pretty straightforward and re-usable code (e.g. the code to draw boxes and drop-shadow boxes simply calls the draw horizontal/vertical line routine a few times). To implement VBXE support, one would change the clipping limits, re-write PARTS of GFX.S, replace certain code with blitter operations, etc. Not a trivial task, but probably only a month's work.

As for drivers, why on earth would I concern myself with a device independent screen driver when I'm writing a GUI for an Atari 8-bit? 99.9% of these machines have a fixed 1bpp 320x192 display. Why overload screen draw operations with multiple levels of indirection, varying screen dimensions, etc, just to have a system which runs sluggishly but which is easier to convert for VBXE use?

The fact is, it would be better to regard GFX.S as the "driver", and to think in terms of "draw line", "render bitmap", and "clear screen area" as the lowest-level operations. There are half a dozen such operations at the moment, and this code is all we need to re-write to implement support for VBXE modes.

Well said. Of course the "proper" way would be to render everything at the pixel level and simply implement a driver which provides the low-level interaction with the screen. But this is an Atari 8-bit with a 6502 processor. I said at the start that the GUI would have to employ "techniques normally seen in games and demos". How many demos draw to the screen using the CIO? :D

Ostatnio edytowany przez flashjazzcat (2011-02-08 20:25:46)

Niekoniecznie tak musi wyglądać, przecież operacje rysowania okien i innych elementów tak czy owak wywołuje się jako procedurę nie? Czy ta sama część kodu jest powtarzana w każdym miejscu gdzie ma być użyta :) Równowaga Panowie równowaga. Jak masz duże bloki zamknięte w procedurach to i skoków masz mało. Bloki logiczne. Sam pisałem - nie ma procedury rysowania piksela, to byłby nonses.

Poza tym nie patrz na sterownik jak na taki windowsowy. Tu by bardziej pasowało określenie - biblioteka

Dobra dobra my tu gadu gadu... a jak to ściągnąć i po testować na moim własnym malutkim ATARI ?

Pin: to trzeba coś zrobić byśmy i my mieli tę możliwość ;-) pytanie tylko jak ?!
Bo to co widać na you tube jest bardzo ale to bardzo obiecujące... Nawet wydaje się fajniejsze od diamond gosa...

Have a look over at the Atari Age forum to see how the project is progressing. I considered it more important to make significant progress on the core code than release frequent demos. I am currently working on a resource manager (having done a complete re-write of the menu manager) and when this is closer to completion I will release another demo for people to play with. It will demonstrate a movable/sizeable window with a complete set of controls, as well as the menu system and some static icons on the desktop.

Ostatnio edytowany przez flashjazzcat (2011-02-22 13:21:57)

Progress is slow, but the scrollbars are working:

http://www.youtube.com/watch?v=2H1xJUF3jes

A downloadable demo with a movable, sizeable window (or two) will be available in the next few days. After that, I'll take a short break to do other things, then come back and optimize what I've written, do some more planning, and then start the dialogue handler and the virtual window coordinate system.

Few days... "Few" is so inexact unit of time :)