3,576

(106 odpowiedzi, napisanych Fabryka - 8bit)

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

3,577

(106 odpowiedzi, napisanych Fabryka - 8bit)

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.

3,578

(106 odpowiedzi, napisanych Fabryka - 8bit)

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.

3,579

(106 odpowiedzi, napisanych Fabryka - 8bit)

Pin napisał/a:

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.

3,580

(7 odpowiedzi, napisanych Programowanie - 8 bit)

pirx: ja algorytmy 3d znam :) Mniej wiecej to właśnie opisałeś to typowa technika, z tym że z-bufor pozwala czas oszczędzić, jak się go sprytnie zaimplementuje.

Pytałem raczej o jakieś specyficzne sztuczki, które umożliwiają robienie tego na 1.8 MHz :)

Swego czasu mój kumpel za czasów 386 zrobił bardzo wydajny engine z wypełnianiem i goraudem, a możliwe to było dzięki właśnie paru sprytnym sztuczkom jak całkowita rezygnacja z floatów i mnożeń - nie pamiętam o co tam biegało w szczegółach, ale to było cwane wykorzystanie prostej arytmetyki i przekształcenie równania trójkątów.

W przypadku 8-bitowych wolnych procesorów największy problem widzę w samym rysowaniu - wypełnienie wymusza postawienie znacznie większej ilości pikseli. Czy się mylę?

3,581

(6,151 odpowiedzi, napisanych Kolekcjonowanie)

No to ja wiem, a co innego? Kazda gra to była osobna płyta, względnia część to osobne romy. Natomiast podoba mi się zachowanie przy tym klimatu , przez zastosowanie klasycznej obudowy i co najwazniejsze kineskopu

3,582

(7 odpowiedzi, napisanych Programowanie - 8 bit)

Czy istnieją jakieś szczególne tricki umożliwiające tworzenie na 8-bit Atari sprawnie działającej animacji 3d z wypełnionymi wielokątami? Pytam bo widzę coraz więcej produkcji - zwłaszcza znakomity remake Control - a za czasów normalnego użytkowania, coś takiego uchodziło powszechnie za niemożliwe i dominowały wireframe'y. Nawet proste wypełnienie płaskiego wielokąta było pewnym wyzwaniem.

3,583

(6,151 odpowiedzi, napisanych Kolekcjonowanie)

Takie coś - multi coin-op.

http://allegro.pl/automat-arcade-300-gi … 96869.html

Były takie mini automaty do postawienia na stole i nie kosztowały mało. Poza tym nie ten rozmiar, ekran LCD zamiast kineskopu - nonsens. To jest o wiele lepsze właśnie ze względu na feeling :) Nawet wrzucanie monet zostało :)

3,584

(24 odpowiedzi, napisanych Bałagan)

Unikać policji :)

3,585

(106 odpowiedzi, napisanych Fabryka - 8bit)

So apparently it's passed translation :)

3,586

(106 odpowiedzi, napisanych Fabryka - 8bit)

Nie o to chodzi, jestem zwolennikiem klasycznych trybów, gdybym coś wyprodukował, w życiu nie byłoby to VBXE only. Chodzi o taką konstrukcję softu która będzie się dostosowywała do warunków - to oczywiście wymaga w miarę elastycznego api, opartego na mikrosterownikach. Do czego jak do czego, ale do takiego GUI VBXE wydaje się stworzone. Jeśli masz to mógłbyś używać tego samego softu ale np. w większej ilości kolorów lub wyższej rozdzielczości 640x192 .

Jeśli w oparciu o te GUI powstawały by programy, byłoby to coś na kształt miniwindowsa. Masz herkulesa, vga, svga - whatever , program chodzi tak samo, ale masz np. wiecej miejsca na ekranie albo wiecej kolorów. Wtedy taka biblioteka ma jeszcze więcej sensu

3,587

(106 odpowiedzi, napisanych Fabryka - 8bit)

Would you like to consider VBXE support if found?

3,588

(12 odpowiedzi, napisanych Bałagan)

dely napisał/a:

- klawiatura dowolna (byle nie chińska)

Za taką to byś musiał pewnie zdrowo dopłacić :)

3,589

(85 odpowiedzi, napisanych Bałagan)

O cholera gdzie to jest?! I do kiedy?!

O kurcze do jutra :) Świetnie - ide zaraz z rana :)

3,590

(6,151 odpowiedzi, napisanych Kolekcjonowanie)

Ciekawe co na to uczestnicy :) Jakieś tantiemy by się przydały :)

3,591

(23 odpowiedzi, napisanych Emulacja - 16/32bit)

AS... napisał/a:

nie zesra się odtwarzacz...! Od kilku lat oglądam hd z dźwiękiem min. dts 5.1 i np. mam jakiś koncert depeche mode rip hd, zajmuje 9gb wraz ze ścieżką dźwiękową w dts 5.1 1.5 mega bita, ale ktoś wpadł na pomysł i udostepnił ścieżkę dźwiękową w formacie flac 5.1 dts hd ex czy jakoś tam. ścieżka waży jakies 4gb i spokojnie obecne komputery dają radę (ja jadę od kilku lat na laptopach i wszystko się da odtworzyć :)

Jeśli ma tylko 9GB to jest kompresja , nie ma bata.

A bez kompresji to ty piszesz o ścieżce dźwiękowej - to to jest pikuś. Spróbuj strumień VIDEO bez kompresji  - mowa była o filmiku :)

3,592

(47 odpowiedzi, napisanych Sprzęt - 8bit)

No cóż, latka lecą, łapki zaczynają latać... :) Setę walnij przed operacją :)

Ja skrobię po prostu ostrym nożem - wystarcza - lub lekko papierem ściernym, aż zmatowię.

3,593

(47 odpowiedzi, napisanych Sprzęt - 8bit)

A szlifujecie końcówki przed pocynowaniem? Bo jak chcecie nałożyć cynę na taką pogalwanizowaną końcówkę to życzę zdrowia - szybciej faktycznie stopicie obudowę.

3,594

(23 odpowiedzi, napisanych Emulacja - 16/32bit)

Bez kompresji to odtwarzacz się zesra na skutek objętości strumienia :) Z kompresją, ale trzeba się trochę na tym znać żeby nie skopać i dla widza było to niezauważalne.

3,595

(20 odpowiedzi, napisanych Bałagan)

No taką kropeczkę to nie tylko on by chętnie zchrupał :)

3,596

(27 odpowiedzi, napisanych Sprzęt - 16/32bit)

Nie mam takiego doświadczenia jeśli chodzi konkretnie o ST, ale ogólnokomputerowe mi podpowiada po opisanych objawach że jednak coś z pamięcią. A dokładniej z jakimś jej konkretnym obszarem.

3,597

(1,653 odpowiedzi, napisanych Bałagan)

Tzn nie ma jak nie ma, a te gniazda przypominające ISA to co to jest? Może jakieś karty zewnętrze? I da się do tego podłączyć coś klasycznego na starej krawędziówce?

3,598

(253 odpowiedzi, napisanych Kolekcjonowanie)

Mi 12 w kremie zadziałała. Silniejszego trochę bym się bał. Na amidze 500 zostały mi smugi - trochę duża obudowa , mały pędzel no i efekt. Da się tego pozbyć już sprawdzałem, ale trochę dłużej trzeba powalczyc :)

3,599

(253 odpowiedzi, napisanych Kolekcjonowanie)

Apropos - czy spotkaliście się z nawrotem zażółcenia? Mam jakieś takie wrażenie że to wraca po niedługim czasie, a może mi tylko w oczach się mieni :)

3,600

(2 odpowiedzi, napisanych Emulacja - 8bit)

Ach to Win7 jest tu przyczyną? No tak, nowy lapek to zapomniałem że coś jeszcze się zmieniło... Czyli... A spróbuję w trybie XP... Chociaż ogólnie chodzi bez problemu. Bardziej spodziewałbym się, że karcie na współdzielonej pamięci gdzieś się wtrynia...

A co do Altirry - król , królem. A800 jest dla mnie zdecydowanie wygodniejszy w obsłudze. Jak ktoś do Altirry dorobi taki interfejs, to psze bardzo :)