Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Nowa obudowa dla 800XL - zostało 36 dni Niewiele ponad miesiąc do końca kampanii.
Zmarł twórca języka BASIC Zmarł Thomas E. Kurtz twórca języka BASIC
Zmiana serwera atari.area Serwis przeszedł właśnie ważną aktualizację infrastruktury
4th Atari ASCII Compo - wyniki Dostępne są już wyniki tegorocznego ATASCII Compo.
thing neo 1.60 Olivier Landemarre wydał nową wersję desktopu Thing.
atari.area forum » Fabryka - 8bit » New GUI
Strony Poprzednia 1 2 3 4 5 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
.. po skrinszotach widze, ze pod sdx format katalogu jest pelny - z data i czasem. ogolnie wazna funkcjonalnosc.
jednej rzeczy tylko nie zrozumialem z tego wszystkiego. czy to gui bedzie na cartridge'u, czy w plikach? nie mam nic przeciwko modulowi, lecz mam nadzieje ze w finalnej wersji bedzie mozna to normalnie kupic - i mam nadzieje; w normalnej cenie.
.. no i wsparcie dla vbxe tez mile widziane ;) .. 640x238 hmmmm...
Pin: Czytaj też tekst, nie tylko obrazki, "skrinszoty" to na razie atrapy.
Grzybson: API do trs-desktopa? Niezły żart. ;)
640x238 hmmmm...
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.
VBXE modes would obviously solve a lot of problems (such as representing a 72dpi document on the screen), but the objective is to get something working on standard hardware first. Of course it's fairly easy to add VBXE support later: amend masking and screen RAM write routines, and adjust the size of the root (SCREEN) object in memory. But naturally when you introduce device independence, you introduce an overhead. "JSR write_byte" is many cycles slower than "STA (SCR),Y". Let's get the basics out of the way first. In any case, with VBXE's blitter, it would be difficult NOT to write a fast and responsive GUI. Or one could just use an ST. :)
Pin's meaning is especially hard to translate, ;) but SDX plus GUI is a match made in heaven. The system will use the full features of the Sparta FS, and will have a clock-widget in the top-right corner of the screen. You'll double-click on it to set the system time. Drag and drop files(s) from one folder to another. The usual basic GUI stuff.
Cartridge or files? Who knows. I'll make the best practical decision after taking everything into account. All my software has always been free. If it's on a cart, you'll have to buy yourself a flashable cart and flash the GUI onto it. It's it's on disk, there is zero financial outlay. :)
Cascading menus are now finished, and I've started the window/dialogue render routines, and the rest of the event handler. It will take several weeks to code up all the controls (scroll bars, text boxes, list boxes, buttons, etc, etc).
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.
Grzybson - znajdę źródła trs-desk to naskrobię skrótowy opis co i jak. I będzie paczuszka :)
@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. :)
That's what I mean - I suppose pixel-level operations on screen RAM for native modes , just for efficiency, but I suppose there is also higher level - like draw dialogue and draw window or draw title bar, set text etc. And I mean , that driver for another mode/device should replace that procedures, not drawing ones. Thanks to that , operations that you're doing just copying bytes in screen memory to i.e. move window, in VBXE driver you'll be able to use blitter. From higher level's code point of view, nothing's changed.
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 :)
A skadze znowu. To tylko kwestia zalozen przy tworzeniu i o to wlasnie chodzi - zanim zacznie sie tworzyc. GUI to nie stawianie pikseli na ekranie, czy rysowanie okien a do tego sprowadza się kwestia sterownika.
Jesli zaczniesz robic GUI koncentrujac sie na rysowaniu, to nie osiagniesz sukcesu bo to jest samo dno hierarchii kodu, zaplaczesz sie w szczegolach technicznych. Dlatego takie rzeczy robi sie dwuwarstwowo - tworzy sie biblioteke operacji ekranowych a nastepnie logike ktora z nich korzysta. Zmiana urzadzenia - to zmiana biblioteki. Przeciez GUI ma robic znacznie wiecej nic narysowac okienko.
Teraz, aby nie uderzyc w bariere wydajnosci, biblioteka , sterownik czy jak go nazwiemy, nie moze realizowac operacji atomowych typu postaw piksel, narysuj prostokat, tylko narysuj okno, ustaw tekst , przesun okno itp. Te operacje sa dostatecznie elementarne, zeby nawet ktos z zewnatrz mogl je zaimplementowac i dostatecznie zlozone aby uniknac miliarda skokow przy kazdej operacji na ekranie.
Programujac liniowo albo nie zrobi sie tego w ogole albo zajmie to lata, a i tak sledzenie bledow bedzie koszmarem. Wszystko jest kwestia kompromisu
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.
A skadze znowu. To tylko kwestia zalozen przy tworzeniu i o to wlasnie chodzi - zanim zacznie sie tworzyc. GUI to nie stawianie pikseli na ekranie, czy rysowanie okien a do tego sprowadza się kwestia sterownika.
Jesli zaczniesz robic GUI koncentrujac sie na rysowaniu, to nie osiagniesz sukcesu bo to jest samo dno hierarchii kodu, zaplaczesz sie w szczegolach technicznych. Dlatego takie rzeczy robi sie dwuwarstwowo - tworzy sie biblioteke operacji ekranowych a nastepnie logike ktora z nich korzysta. Zmiana urzadzenia - to zmiana biblioteki. Przeciez GUI ma robic znacznie wiecej nic narysowac okienko.
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.
Programujac liniowo albo nie zrobi sie tego w ogole albo zajmie to lata, a i tak sledzenie bledow bedzie koszmarem. Wszystko jest kwestia kompromisu
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
A skadze znowu. To tylko kwestia zalozen przy tworzeniu i o to wlasnie chodzi - zanim zacznie sie tworzyc. GUI to nie stawianie pikseli na ekranie, czy rysowanie okien a do tego sprowadza się kwestia sterownika.
Pamiętaj, że mamy - powiedzmy że 1.77Mhz i podejście do tematu grafiki bitowej od strony jeszcze dodatkowego sterownika finalnie na ekranie wyglądać może jak oglądanie filmu, gdzie na każdą sekundę przypada 2 klatki :D - To tak, jak byś chciał napisać cieniowanie Gourauda w Basicu. Wcale nie mówię, że się nie da. Da się - pytanie tylko jaki otrzymamy efekt finalny.
Nie neguję oczywiście chęci, lub tego co można ciekawego zrobić, bo różne niemożliwe cuda miałem okazję na Atari widywać - wszelako; chętnie pobawię się produktem finalnym ;)-
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
Pamiętaj, że mamy - powiedzmy że 1.77Mhz i podejście do tematu grafiki bitowej od strony jeszcze dodatkowego sterownika finalnie na ekranie wyglądać może jak oglądanie filmu, gdzie na każdą sekundę przypada 2 klatki :D - To tak, jak byś chciał napisać cieniowanie Gourauda w Basicu. Wcale nie mówię, że się nie da. Da się - pytanie tylko jaki otrzymamy efekt finalny.
Nie neguję oczywiście chęci, lub tego co można ciekawego zrobić, bo różne niemożliwe cuda miałem okazję na Atari widywać - wszelako; chętnie pobawię się produktem finalnym ;)-
Where's the question? Have you actually looked at this? :)
http://www.youtube.com/watch?v=mpx0gUpwyQo
OK - it's a menu. But there's a lot of processing going on there. I'm not saying that the finished product is going to run as fast as Windows. It would be insanity to expect such things. But it ought to be fast enough. I have not yet produced any slide shows... ;)
Dobra dobra my tu gadu gadu... a jak to ściągnąć i po testować na moim własnym malutkim ATARI ?
nie każdy ma tę możliwość ;)-
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...
Poczekać cierpliwie aż autor - flashjazzcat - upubliczni jakąkolwiek wersję. Na razie jest TYLKO działające demo menu, doczytajcie. Będzie, to na pewno dostaniemy w swoje łapki.
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.
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.
We will be waiting for your downloadable demo :-)
Few days... "Few" is so inexact unit of time :)
Indeed so... everything takes longer than expected, and I took a break from the GUI last week. However, I now return to the project refreshed and recharged, so expect something soon. However, it's more important to do everything right than to do everything fast. :)
Demo by the weekend, with overlapping windows: just need to code up the scrollbar scaling:
Strony Poprzednia 1 2 3 4 5 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
atari.area forum » Fabryka - 8bit » New GUI
Wygenerowano w 0.028 sekund, wykonano 64 zapytań
