🚀 go-pugleaf

Dnia 2011-04-10 23:15, Użytkownik Mateusz Ludwin napisał:
> Czy ktoś może mi wytłumaczyć, dlaczego w trybie planar możliwy był scrolling
> płynniejszy niż na PC? Chodzi o zrównoleglone kopiowanie z kilku bitplanów
> jednocześnie? 

Dzięki kościom graficznym i dostępie przez nie do pamięci CHIP.
Dawało to prawie 0,5 lub 1MB (A500) pamięci graficznej więc
mieściło się sporo ekranów i skrolling był płynny.
Na PC karty graficzne miały pamięci na dwa góra trzy ekrany.


Pozdrawiam

Rzecze RadoslawF:

> Dzięki kościom graficznym i dostępie przez nie do pamięci CHIP.
> Dawało to prawie 0,5 lub 1MB (A500) pamięci graficznej więc
> mieściło się sporo ekranów i skrolling był płynny.
> Na PC karty graficzne miały pamięci na dwa góra trzy ekrany.

To może raczej nie chodzi o wielkość pamięci (karta SVGA powinna pozwolić na
płynny scrolling np. w pinballach), tylko o możliwość przesunięcia adresu
pod którym zaczyna się pamięć ekranu?

Wpływ trybu planar na generowanie paralaksy jest dla mnie jasny (proste i
równoległe kopiowanie z maską bitową, czego nie da się zrobić w chunky, bo
trzeba skakać co n bitów na jeden bit maski), ale zawsze stykałem się ze
stwierdzeniem, że planar dawał też możliwość płynnego scrollingu.

Faktycznie było to widać od samego początku przy przesuwaniu ekranów w
Workbenchu. Coś takiego nie działa płynnie na PC nawet teraz.
-- 
Omniscient, omnipotent, omnipresent, without judgment

Mateusz Ludwin                             mateuszl [at] gmail [dot] com

On 04/10/2011 11:46 PM, RadoslawF wrote:
> Dnia 2011-04-10 23:15, Użytkownik Mateusz Ludwin napisał:
>> Czy ktoś może mi wytłumaczyć, dlaczego w trybie planar możliwy był
>> scrolling
>> płynniejszy niż na PC? Chodzi o zrównoleglone kopiowanie z kilku
>> bitplanów
>> jednocześnie?
>
> Dzięki kościom graficznym i dostępie przez nie do pamięci CHIP.
> Dawało to prawie 0,5 lub 1MB (A500) pamięci graficznej więc
> mieściło się sporo ekranów i skrolling był płynny.
> Na PC karty graficzne miały pamięci na dwa góra trzy ekrany.
>
>
> Pozdrawiam

Na miłość boską, co za bełkot.
Ale od początku (a właściwie od końca).

PC jako standard w tamtych czasach oznaczał kartę VGA.
Karta VGA miała 256kb pamięci. Dla takiego sprzętu tworzono gry.

Albo z lenistwa, albo z braku wiedzy twórcy na PC uczepili się trybu 13h 
(320x200x256) jak rzep psiego ogona.
Podejrzewam, że wygoda oraz liniowy dostęp do pamięci przeważył.
Było łatwo, szybko i przyjemnie, ale niekoniecznie ładnie.

Karta VGA oferowała tryb pracy zwany 'mode x'. Zalet cała masa. Można 
było zaadresować całą pamięć karty. Utworzyć wirtualne okno, płynny 
scrolling oraz statyczną "ramkę" na spodzie ekranu. Utworzenie trybu 
320x240 było możliwe co oznaczało normalny (tzn. kwadratowy) pixel.

Jako ciekawostkę należy zaznaczyć, że to ograniczenie (statyczna ramka 
na dole ekranu) wymusiło zmianę organizacji ekranu przy przenoszeniu 
pinball dreams na pc.

Wspomniany 'mode x' wymagał specjalnego adresowania pamięci.
Niestety programistów chyba to przerażało i pozycji wykorzystujących 
wspomniany tryb powstało niewiele. Kinka pinballi i produkcje ze studia 
x-land (adventures of robbo, electroman, heartlight).

Niestety sam płynny scorlling nie wystarczał. PC brakowało odpowiednika 
amigowego blittera. Dlatego po przesunięciu ekranu (zazwyczaj o 16px - 
taki wymiar zazwyczaj miał pojedynczy tile) trzeba było przerysować całą 
zawartość ekranu ręcznie i biedny procesor na piechotę malował po ekranie.

W tamtym okresie bardzo popularną kartą był trident 9000. Popularna 
owszem, ale koszmarnie wolna. Kto trochę bardziej zaszalał mógł mieć 
trident'a 8900 z 1mb ramu. Karta ta, albo ilość ramu i wynikająca z niej 
forma dostępu do magistrali, sprawiała że szybsza była ze 2 razy.

Potem była przesiadka na SVGA, czyli dramat na 2 akty.
Raz, w dalszym ciągu brak blittera. Może i gdzieś tam był, ale zazwyczaj 
jego użycie sprowadzało się do rysowania kursora na ekranie.
Dwa, standardów miliony. Każda karta miała inną wizję uzyskania trybów 
svga. Sytuację trochę ratował standard VESA i program univbe.

Karty dalej były wolne. Nieliczny szczęśliwcy posiadali kartę tseng 
et4000. Ale co z tego? Fragmentacja rynku powodowała, że przy tworzeniu 
gier zazwyczaj równało się w dół.

Należy też wspomnieć o magicznym vsync. Płynny scorlling bez tearing'u 
wymaga vsync'a. Ale co zrobić jak w zależności od karty (i monitora) 
mogliśmy pracować w warunkach od 55 do 85Hz. Gra miała chodzić 
szybciej/wolniej?

Koniec końców płynnych platformówek było niewiele. A głupi kursor myszki 
zawsze sprawiał wrażenie ociężałego i migającego pod windowsem (w wersji 
trzeciej, potem było trochę lepiej).


Z drugiej strony mamy mocno zamkniętą architekturę amig. Chipset ten 
sam. Ekran zawsze  50Hz w pal i 60Hz w ntsc.
Blitter odwalał masę roboty. Sprzętowe spritey można było multiplikować 
tworząc dodatkowe "warstwy" obrazu. A do tego copperlist i praktycznie 
dowolna organizacja ekranu.

Powyższe zabawki powodowały, że programistom wystarczał 1 ekran z 
buforem 16px po brzegach. Scrolling był sprzętowy, a jak dochodziło do 
przewinięcia (16px) ekranu to sprytny koder używał technologii 'adaptive 
tilesets scrolling' oszczędzając przy tym masę roboty blitterowi.

Przykłady? Na początek proponuję rozłożyć grę "Fire and Ice" z 
technicznego punktu widzenia. A jak nam będzie mało to "Jim Power" 
zagwarantuje multum wrażeń.

Podsumowując, to nie tryb planar w amidze dawał takie efekty tylko 
dodatkowe specjalizowane układy scalone oraz stabilność rozwiązań.

ps.
utf8 z okazji roku 2011, jak ktoś nie zobaczy to może pomyśli nad zmianą

Rzecze Mike:

> Podsumowując, to nie tryb planar w amidze dawał takie efekty tylko 
> dodatkowe specjalizowane układy scalone oraz stabilność rozwiązań.

Więc co właściwie dawał sam tryb planar? Tylko "tanią" paralaksę i sprajty?
-- 
Omniscient, omnipotent, omnipresent, without judgment

Mateusz Ludwin                             mateuszl [at] gmail [dot] com

On 04/11/2011 09:19 PM, Mateusz Ludwin wrote:
> Rzecze Mike:
>
>> Podsumowując, to nie tryb planar w amidze dawał takie efekty tylko
>> dodatkowe specjalizowane układy scalone oraz stabilność rozwiązań.
>
> Więc co właściwie dawał sam tryb planar? Tylko "tanią" paralaksę i sprajty?

Obecność trybu plannar nie implikuje dostępności sprajtów oraz paralaxy.

Sprajty były jako dodatek z własnymi cyklami DMA.

Natomiast paralaxa wyszła przez przypadek. Bo skoro "GPU" był w stanie 
wciągać 5 bitplaneów na potrzeby trybu 32 kolorowego to niewielkim 
nakładem kosztów (krzemu) można było przeorganizować interpretację 
danych na zasadzie 3+2 (3 przedni plan, 2 tylni).

Tryb planar był ciekawym (innowacyjnym) podejściem do (rozwiązaniem) 
problemu: jak zaoferować tryby 2, 4, 8, 16, 32, 64 kolorowe nie robiąc 
przy tym zadymy w organizacji pamięci dla grafiki.

O ile tryby 2, 4 i 16 kolorowe ładnie się upychają w bajcie to co z 
pozostałymi?
Co więcej przy trybach chunky konstrukcja blittera byłaby mocno 
skomplikowana.

On 2011-04-11, Mike <niemam@asd.ppl> wrote:
> On 04/10/2011 11:46 PM, RadoslawF wrote:
>> Dnia 2011-04-10 23:15, Użytkownik Mateusz Ludwin napisał:
>>> Czy ktoś może mi wytłumaczyć, dlaczego w trybie planar możliwy był
>>> scrolling
>>> płynniejszy niż na PC? Chodzi o zrównoleglone kopiowanie z kilku
>>> bitplanów
>>> jednocześnie?
>>
>> Dzięki kościom graficznym i dostępie przez nie do pamięci CHIP.
>> Dawało to prawie 0,5 lub 1MB (A500) pamięci graficznej więc
>> mieściło się sporo ekranów i skrolling był płynny.
>> Na PC karty graficzne miały pamięci na dwa góra trzy ekrany.
>>
>>
>> Pozdrawiam
>
> Na miłość boską, co za bełkot.
> Ale od początku (a właściwie od końca).
>
> PC jako standard w tamtych czasach oznaczał kartę VGA.
> Karta VGA miała 256kb pamięci. Dla takiego sprzętu tworzono gry.
>
> Albo z lenistwa, albo z braku wiedzy twórcy na PC uczepili się trybu 13h 
> (320x200x256) jak rzep psiego ogona.
> Podejrzewam, że wygoda oraz liniowy dostęp do pamięci przeważył.
> Było łatwo, szybko i przyjemnie, ale niekoniecznie ładnie.

Wiesz, alternatywą były tryby 16-kolorowe, które miały straszliwie porąbany
dostęp do pamięci.

> Karta VGA oferowała tryb pracy zwany 'mode x'. Zalet cała masa. Można 
> było zaadresować całą pamięć karty. Utworzyć wirtualne okno, płynny 
> scrolling oraz statyczną "ramkę" na spodzie ekranu. Utworzenie trybu 
> 320x240 było możliwe co oznaczało normalny (tzn. kwadratowy) pixel.

Chodzi ci o ręczne stworzenie nowego trybu poprzez zapisy do rejestrów VPT?
Bo "gotowego" takiego trybu nie było w standardowej VGA. Z adresowaniem
pamięci też nie tak hop-siup, w tym pierwszym megabajcie były przewidziane
zakresy adresów dla karty graficznej i tego się zmienić nie dało (przynajmniej
jeśli chodzi o "czystą" VGA). Dlatego całą zabawa z oknami i stronnicowaniem
pamięci przy SVGA.

Poza tym z VGA był taki problem, że wszystkie operacje trzeba było przepchnąć
przez magistralę ISA, która demonem prędkości nie była.
Teoretycznie blittera można było zastąpić kontrolerem DMA, ale i tak wąskim
gardłem byłą szyna.
Tak naprawedę dopiero PCI i przejście w tryb 386 rozwiązało sprawę i można
było normalnie zaadresować całą pamięć karty, w dodatku z rozsądną szybkością.

> Wspomniany 'mode x' wymagał specjalnego adresowania pamięci.
> Niestety programistów chyba to przerażało i pozycji wykorzystujących 
> wspomniany tryb powstało niewiele. Kinka pinballi i produkcje ze studia 
> x-land (adventures of robbo, electroman, heartlight).

> Należy też wspomnieć o magicznym vsync. Płynny scorlling bez tearing'u 
> wymaga vsync'a. Ale co zrobić jak w zależności od karty (i monitora) 
> mogliśmy pracować w warunkach od 55 do 85Hz. Gra miała chodzić 
> szybciej/wolniej?

Ale to akurat nie problem. Problem jest taki, że nie przepchniesz całej
pamięci graficznej przez ISA na vblank-u, po prostu czasu braknie.
Praktyczna prędkość przesyłu to było jakieś 2MB/sek.
Tu po prostu Amiga zjadałą PC-ta na śniadanie, bo nawet "wolna" pamięć
chip to była rakieta.

-- 
Konrad Stępień

On 04/12/2011 02:01 PM, Konrad Stepien wrote:
>> Wspomniany 'mode x' wymagał specjalnego adresowania pamięci.
>> Niestety programistów chyba to przerażało i pozycji wykorzystujących
>> wspomniany tryb powstało niewiele. Kinka pinballi i produkcje ze studia
>> x-land (adventures of robbo, electroman, heartlight).
>
>> Należy też wspomnieć o magicznym vsync. Płynny scorlling bez tearing'u
>> wymaga vsync'a. Ale co zrobić jak w zależności od karty (i monitora)
>> mogliśmy pracować w warunkach od 55 do 85Hz. Gra miała chodzić
>> szybciej/wolniej?
>
> Ale to akurat nie problem. [...]

oO

Prosta gra na amigę (pal): statyczny ekran z 1 obiektem (małym) 
poruszającym się z prędkością 1px/vblank, przy okazji animowana (co 10 
ramkę zmiana klatki).
Ilość danych do przewalania przez cpu śmiesznie mała. Karta VGA sobie 
poradzi bez problemu.

Teraz proszę powiedz mi jak "bez problemu" mogę przeportować tę grę na 
PC zakładając, że wylosuję PCty które mają vsync od 55Hz do 85Hz.
Oczywiście trzymając się tematu, czyli z zachowaniem idealnej/amigowej 
płynności oraz bez tearingu.

Twórca emulatora WinUAE, a i pewnie każdego innego emulatora oraz ich 
użytkownicy będą Tobie dozgonnie wdzięczni za rozwiązanie tego 
"banalnego" acz kilkuletniego problemu.

On 12/04/2011 17:56, Mike wrote:

> Teraz proszę powiedz mi jak "bez problemu" mogę przeportować tę grę na
> PC zakładając, że wylosuję PCty które mają vsync od 55Hz do 85Hz.
> Oczywiście trzymając się tematu, czyli z zachowaniem idealnej/amigowej
> płynności oraz bez tearingu.

To akurat dokładnie w ten sposób w jaki tworzy się gry nie zmieniajace 
prędkości gdy zegar CPU się zmienia. Liczniki. PC ma dostępne przerwania 
których częstotliwość możesz dokładnie ustawić do żadanej. Na tych 
instalujesz proste procedury zmieniajace wartości odpowiednich 
zmiennych. A procedura na VBLANK ma przerysować na ekran zgodnie z 
_aktualna_ wartościa zmiennych. Efekt bedzie taki, ze:

a) zawsze rysujesz na vblank - brak migotania/page flippingu
b) predkosc transformacji zawsze jest ta sama - taka jaka czestotliwosc 
ustawisz licznikom
c) to co sie zmieni to predkosc update'u ekranu , czyli raz bedzie to 55 
Hz a raz 85 Hz , tylko ze w tym drugim przypadku update nastapi 
czesciej/ o odpowiednio mniejsza ilosc pikseli ; o ile sie zmiesci w 
czasie to bedzie jeszcze bardziej plynny

Proste rozwiazanie, w zasadzie - czysto algorytmiczne zagadnienie.
I stosowane przez demosceniarzy - jak widac w dosowych demach z lat 
90-ych takie problemy nie wystepuja. No , ale sa programisci i 
programisci myslacy ;)

Jumal

On 04/13/2011 04:36 PM, Jumal wrote:
> On 12/04/2011 17:56, Mike wrote:
>
>> Teraz proszę powiedz mi jak "bez problemu" mogę przeportować tę grę na
>> PC zakładając, że wylosuję PCty które mają vsync od 55Hz do 85Hz.
>> Oczywiście trzymając się tematu, czyli z zachowaniem idealnej/amigowej
>> płynności oraz bez tearingu.
>
> To akurat dokładnie w ten sposób w jaki tworzy się gry nie zmieniajace
> prędkości gdy zegar CPU się zmienia. Liczniki. PC ma dostępne przerwania
> których częstotliwość możesz dokładnie ustawić do żadanej. Na tych
> instalujesz proste procedury zmieniajace wartości odpowiednich
> zmiennych. A procedura na VBLANK ma przerysować na ekran zgodnie z
> _aktualna_ wartościa zmiennych. Efekt bedzie taki, ze:
>
> a) zawsze rysujesz na vblank - brak migotania/page flippingu
> b) predkosc transformacji zawsze jest ta sama - taka jaka czestotliwosc
> ustawisz licznikom
> c) to co sie zmieni to predkosc update'u ekranu , czyli raz bedzie to 55
> Hz a raz 85 Hz , tylko ze w tym drugim przypadku update nastapi
> czesciej/ o odpowiednio mniejsza ilosc pikseli ; o ile sie zmiesci w
> czasie to bedzie jeszcze bardziej plynny

d) straciliśmy płynność animacji. Obiekt zamiast przesuwać się o 1px w 
czasie 1/50 sekundy (na vblanku) będzie się co jakiś czas zatrzymywał na 
2 klatki.
Nie potrzeba wprawnego oka aby zauważyć, że obiekt "skacze", zwłaszcza 
jeśli wcześniej siedzieliśmy przed amigą.

-1 za brak umiejętności czytania ze zrozumieniem.

> Proste rozwiazanie, w zasadzie - czysto algorytmiczne zagadnienie.
> I stosowane przez demosceniarzy - jak widac w dosowych demach z lat
> 90-ych takie problemy nie wystepuja. No , ale sa programisci i
> programisci myslacy ;)

Szkoda, że mało wśród nich praktykujących. Jak przychodzi co do czego to 
nagle się okazuje, że wszyscy teoretycy ;)

On 2011-04-13, Mike <niemam@asd.ppl> wrote:
> On 04/13/2011 04:36 PM, Jumal wrote:
>> On 12/04/2011 17:56, Mike wrote:
>>
>> a) zawsze rysujesz na vblank - brak migotania/page flippingu
>> b) predkosc transformacji zawsze jest ta sama - taka jaka czestotliwosc
>> ustawisz licznikom
>> c) to co sie zmieni to predkosc update'u ekranu , czyli raz bedzie to 55
>> Hz a raz 85 Hz , tylko ze w tym drugim przypadku update nastapi
>> czesciej/ o odpowiednio mniejsza ilosc pikseli ; o ile sie zmiesci w
>> czasie to bedzie jeszcze bardziej plynny
>
> d) straciliśmy płynność animacji. Obiekt zamiast przesuwać się o 1px w 
> czasie 1/50 sekundy (na vblanku) będzie się co jakiś czas zatrzymywał na 
> 2 klatki.

Ojej, tego nie unikniesz, chyba, że założysz sobie, że nic nigdy nie będzie
się poruszało z inną prędkością niż 50pixeli/sek. Ale z NTSC też masz problem.
Tak szczerze mówiąc, to VGA jest newet lepsza, bo "czysta" VGA ma ściśle określone
częstotliwości w poszczególnych trybach.
[...]

>> Proste rozwiazanie, w zasadzie - czysto algorytmiczne zagadnienie.
>> I stosowane przez demosceniarzy - jak widac w dosowych demach z lat
>> 90-ych takie problemy nie wystepuja. No , ale sa programisci i
>> programisci myslacy ;)
>
> Szkoda, że mało wśród nich praktykujących. Jak przychodzi co do czego to 
> nagle się okazuje, że wszyscy teoretycy ;)

Super panie praktyk. Na razie to pokazałeś 2 posty wcześniej, że nie bardzo
rozumiesz jaka jest różnica przy robieniu emulatora a robieniu nowego programu.
Po prostu nie da się prewnych rozwiązań tak prosto przenieść (niektorych
nie da się w ogóle). Natomiast akurat przerysowywanie na vblank-u na PC
robiło się bez problemu, problem był jak trzeba było przerysować cały ekran
(tak jak właśnie w pinballu) bo nie wyrabiała ISA.

-- 
Konrad Stępień

On 04/14/2011 05:50 PM, Konrad Stepien wrote:
>> d) straciliśmy płynność animacji. Obiekt zamiast przesuwać się o 1px w
>> czasie 1/50 sekundy (na vblanku) będzie się co jakiś czas zatrzymywał na
>> 2 klatki.
>
> Ojej, tego nie unikniesz, chyba, że założysz sobie, że nic nigdy nie będzie
> się poruszało z inną prędkością niż 50pixeli/sek.

Tu nie chodzi o to, że ja coś chcę osiągnąć tylko o główny wątek.
Czyli dlaczego ta sama gra na PC traci na płynności względem amigi.
Główne czynniki zostały wymienione.

> Ale z NTSC też masz problem.

Nie ja mam problem tylko twórcy w tamtych czasach mieli.
Czy sobie radzili? Różnie.

1/ rozdzielność pal/ntsc
Produkty robione na amigę+st były kastrowane do 320x200 bo biedne ST nie 
potrafiło więcej uzyskać linii.
Były też produkcje tylko dla pal w 320x256.

2/ frametrate
W większości przypadków wersja ntsc chodziła po prostu szybciej lub pal 
wolniej w zależności od tego który region był pierwotny.

Pozwolę sobie zacytować kogoś bardziej kompetentnego od nas wszystkich:
: Only a few amiga games have "real" ntsc versions, the majority
: was either written for the pal territory, marketed in the pal
: territory or at least worked in pal properly.

> Tak szczerze mówiąc, to VGA jest newet lepsza, bo "czysta" VGA ma ściśle określone
> częstotliwości w poszczególnych trybach.

Tak argumentując to można próbować udowadniać, że teraz amiga jest 
lepsza od PC.
Liczy się to co końcowy użytkownik otrzyma, a na papierze to różne 
rzeczy tworzono. A to rewolucję MMX, nowy windows szybszy od 
poprzedniego oraz wspaniały directx, który był dobrym kierunkiem, ale 
jakoś nikt nie wspomniał, że producenci sprzętu nie potrafią pisać 
sterowników (s3, cirrus logic, gravis, opti).

>> Szkoda, że mało wśród nich praktykujących. Jak przychodzi co do czego to
>> nagle się okazuje, że wszyscy teoretycy ;)
>
> Super panie praktyk.  Na razie to pokazałeś 2 posty wcześniej, że nie bardzo
> rozumiesz jaka jest różnica przy robieniu emulatora a robieniu nowego programu.

Błędny wniosek. Proszę sobie przypomnieć czego dotyczy temat.

> Po prostu nie da się prewnych rozwiązań tak prosto przenieść (niektorych
> nie da się w ogóle). Natomiast akurat przerysowywanie na vblank-u na PC
> robiło się bez problemu, problem był jak trzeba było przerysować cały ekran
> (tak jak właśnie w pinballu) bo nie wyrabiała ISA.

Eh... powtórzę, bo widzę, że ciężko...
W pinballu nie trzeba było nic przerysowywać dzięki 'mode x'.
Pionowy scrolling był robiony _sprzętowo_. Kulka oraz flippery rysowane. 
Natomiast znaczna część "animacji" tworzona zmianami w palecie ekranu.

On 2011-04-14, Mike <niemam@asd.ppl> wrote:
> On 04/14/2011 05:50 PM, Konrad Stepien wrote:
>>> d) straciliśmy płynność animacji. Obiekt zamiast przesuwać się o 1px w
>>> czasie 1/50 sekundy (na vblanku) będzie się co jakiś czas zatrzymywał na
>>> 2 klatki.
>>
>> Ojej, tego nie unikniesz, chyba, że założysz sobie, że nic nigdy nie będzie
>> się poruszało z inną prędkością niż 50pixeli/sek.
>
> Tu nie chodzi o to, że ja coś chcę osiągnąć tylko o główny wątek.
> Czyli dlaczego ta sama gra na PC traci na płynności względem amigi.
> Główne czynniki zostały wymienione.

Głównym czynnikiem była słaba przepustowość magistrali ISA i organizacja
pamięci PC-ta (wielkość "okna" dla grafiki).
Cała reszta jest wtórna.

>> Ale z NTSC też masz problem.
>
> Nie ja mam problem tylko twórcy w tamtych czasach mieli.
> Czy sobie radzili? Różnie.
>
> 1/ rozdzielność pal/ntsc
> Produkty robione na amigę+st były kastrowane do 320x200 bo biedne ST nie 
> potrafiło więcej uzyskać linii.

A to akurat nieprawda. Tyle, że niestety każdy komputer (PC,Ami,ST) obsługiwał
grafikę inaczej, dlatego trzeba by grę pisać w zasadzie 3 razy.

> Były też produkcje tylko dla pal w 320x256.
>
> 2/ frametrate
> W większości przypadków wersja ntsc chodziła po prostu szybciej lub pal 
> wolniej w zależności od tego który region był pierwotny.
>
> Pozwolę sobie zacytować kogoś bardziej kompetentnego od nas wszystkich:
>: Only a few amiga games have "real" ntsc versions, the majority
>: was either written for the pal territory, marketed in the pal
>: territory or at least worked in pal properly.
>
>> Tak szczerze mówiąc, to VGA jest newet lepsza, bo "czysta" VGA ma ściśle określone
>> częstotliwości w poszczególnych trybach.
>
> Tak argumentując to można próbować udowadniać, że teraz amiga jest 
> lepsza od PC.

Jeszcze parę lat temu tak. Teraz wszystkie funkcje amigi (scrollingi,
sprite itp) można zwalić na procesor 3D, tak działa np. linuxowy beryl,
gdzie każde okno jest osobną teksturą, ma własny obszar pamięci, a
procesor karty składa obraz do kupy, przykrywając niewidoczne okna itp.
Tak samo można zrobić sprite i wszystkie możliwe scrollingi.

> Liczy się to co końcowy użytkownik otrzyma, a na papierze to różne 
> rzeczy tworzono. A to rewolucję MMX, nowy windows szybszy od 
> poprzedniego oraz wspaniały directx, który był dobrym kierunkiem, ale 
> jakoś nikt nie wspomniał, że producenci sprzętu nie potrafią pisać 
> sterowników (s3, cirrus logic, gravis, opti).

Akurat jeśli rozmawiamy o VGA to raczej chodzi o gry dla DOS-a.
Direct-x to już zdecydowanie czasy kart na PCI, gdzie nie ma problemu
z przepustowością czy organizację pamięci (za to faktycznie dochodzą
problemy ze sterownikami).

>>> Szkoda, że mało wśród nich praktykujących. Jak przychodzi co do czego to
>>> nagle się okazuje, że wszyscy teoretycy ;)
>>
>> Super panie praktyk.  Na razie to pokazałeś 2 posty wcześniej, że nie bardzo
>> rozumiesz jaka jest różnica przy robieniu emulatora a robieniu nowego programu.
>
> Błędny wniosek. Proszę sobie przypomnieć czego dotyczy temat.

Pisałeś, że jakby to było takie proste, to twórcy UAE dawno by to zrobili.
Niestety, ale emulator to zuuuuupełnie inna sprawa.

>> Po prostu nie da się prewnych rozwiązań tak prosto przenieść (niektorych
>> nie da się w ogóle). Natomiast akurat przerysowywanie na vblank-u na PC
>> robiło się bez problemu, problem był jak trzeba było przerysować cały ekran
>> (tak jak właśnie w pinballu) bo nie wyrabiała ISA.
>
> Eh... powtórzę, bo widzę, że ciężko...
> W pinballu nie trzeba było nic przerysowywać dzięki 'mode x'.

Ja ponawiam prośbę o wyjaśnienie co to jest "mode x". Aż nawet przeczytałem
sobie wczorej dokumentację od kart EGA/VGA i nic tam takiego nie ma.
Oczywiście, może sobie pod VGA zrobić własny tryb (np. bez problemu można
przeprogramować VGA tak, żeby dało się ją podłączyć do zwykłego telewizora).
Można też zmienić organizację pamięci, dużo można jak się pogrzebie.

> Pionowy scrolling był robiony _sprzętowo_. Kulka oraz flippery rysowane. 
> Natomiast znaczna część "animacji" tworzona zmianami w palecie ekranu.

Sprzętowy scrolling to akurat VGA miała "od zawsze" i w standardzie.
Jest to dokładnie opisane w dokumentacji, w odróżnieniu od "mode x"
którego zwyczajnie nie ma.

-- 
Konrad Stępień

Dnia 2011-04-15 12:50, Użytkownik Konrad Stepien napisał:

>>> Ale z NTSC też masz problem.
>> Nie ja mam problem tylko twórcy w tamtych czasach mieli.
>> Czy sobie radzili? Różnie.
>>
>> 1/ rozdzielność pal/ntsc
>> Produkty robione na amigę+st były kastrowane do 320x200 bo biedne ST nie 
>> potrafiło więcej uzyskać linii.
> 
> A to akurat nieprawda. Tyle, że niestety każdy komputer (PC,Ami,ST) obsługiwał
> grafikę inaczej, dlatego trzeba by grę pisać w zasadzie 3 razy.

To widać nie widziałeś konwersji SimCuty2000 z Maka na Amigę.
:-)


Pozdrawiam

> Chyba muszę przekopać swoje pudła z dyskietkami,
> może gdzieś tam się poniewiera SimCity.

IIRC to w negatywnym. Szybciej chyba dzialalo pod ShapeShiterem...
A moze mieszam cos... skleroza sie klania.

Enyway - milo sie Was czyta. Kontynuujcie :)

pozdrawiam,
Vituniu.

W dniu 2011-04-15 15:18, RadoslawF pisze:
> Dnia 2011-04-15 12:50, Użytkownik Konrad Stepien napisał:
>
>>>> Ale z NTSC też masz problem.
>>> Nie ja mam problem tylko twórcy w tamtych czasach mieli.
>>> Czy sobie radzili? Różnie.
>>>
>>> 1/ rozdzielność pal/ntsc
>>> Produkty robione na amigę+st były kastrowane do 320x200 bo biedne ST
>>> nie potrafiło więcej uzyskać linii.
>>
>> A to akurat nieprawda. Tyle, że niestety każdy komputer (PC,Ami,ST)
>> obsługiwał
>> grafikę inaczej, dlatego trzeba by grę pisać w zasadzie 3 razy.
>
> To widać nie widziałeś konwersji SimCuty2000 z Maka na Amigę.
> :-)

W sensie pozytywnym, czy negatywnym? Tzn. na Ami działa lepiej?

Chyba muszę przekopać swoje pudła z dyskietkami, może gdzieś tam się 
poniewiera SimCity.

-- 
Pozdrawiam.

Adam.

On 13/04/2011 17:53, Mike wrote:

> d) straciliśmy płynność animacji. Obiekt zamiast przesuwać się o 1px w
> czasie 1/50 sekundy (na vblanku) będzie się co jakiś czas zatrzymywał na
> 2 klatki.
> Nie potrzeba wprawnego oka aby zauważyć, że obiekt "skacze", zwłaszcza
> jeśli wcześniej siedzieliśmy przed amigą.
>
> -1 za brak umiejętności czytania ze zrozumieniem.
>

Miło że sobie przyznałeś :) Ode mnie dodatkowy za brak wyobraźni. Obiekt 
porusza się o 1px co 1/50 sekundy. Jeśli VBLANK jest częściej to 
przesunie się tylko w tych cyklach w których trzeba. Oczywiście, 
najlepiej by było żeby to było 100Hz, 150Hz, wielokrotność. Ale szczerze 
- nie zauważysz tego. Natomiast page flipping zauważysz od razu. I w 
przypadku 50 Hz najwyżej czasem zatrzyma się na jedną.

>> Proste rozwiazanie, w zasadzie - czysto algorytmiczne zagadnienie.
>> I stosowane przez demosceniarzy - jak widac w dosowych demach z lat
>> 90-ych takie problemy nie wystepuja. No , ale sa programisci i
>> programisci myslacy ;)
>
> Szkoda, że mało wśród nich praktykujących. Jak przychodzi co do czego to
> nagle się okazuje, że wszyscy teoretycy ;)

Demoscenowcy piszący pod DOSem nagminnie to praktykowali. Takoż twórcy 
gier. Nie pamiętam page flippingu czy migotania w tamtych grach. 
Niestety - od momentu przejścia pod system "wysokiego" poziomu 
separujący Cię doskonale od sprzętu, jest to nieosiągalne. Tu spieprzył 
MS - skoro programiści już nie mają do tego dostępu, to oni powinni o to 
zadbać

Jumal

Mateusz Ludwin <nie@spamuj.org> napisał(a): 

> Czy ktoś może mi wytłumaczyć, dlaczego w trybie planar możliwy był scrolling
> płynniejszy niż na PC? Chodzi o zrównoleglone kopiowanie z kilku bitplanów
> jednocześnie? 

Chytra sztuczka. Na amidze wyświetlanie obrazu mogło się zacząć od dowolnego
miejsca w pamięci.
Np rozdzielczość 320x356.
Przy jednej klatce wyświetlamy obraz do jednego bitplanana od adresu x do
adresu x+10240.
Przy następnej wyświetlamy od adresu x+40 do adresu x+10240+40.
I mamy przesuw o jedną linię (40 bajtów) w dół bez żadnych dodatkowych operacji.
Proste nie?
Nie było to związane z bitplanami.
Ten sam pomysł działał również na c64, gdzie obraz był chunky pixels.
Na pc tego nie zrobili, bo mieli to gdzieś.
Jak pc staniały na tyle że ludzie zaczęli pc kupować do domów, zaczęła się era
3d i scroling był niepotrzebny.


-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/