Xray:
  Cytat:
"He he fajnie. Popieram w 99% te slowa. I z niecierpliwoscia czekam na
efekty. Mam nadzieje ze moze w Ornecie w przyszłym roku ??"
 
Takie jest założenie.
   
Dracon:
  Cytat:
"czy też (nie)możliwymi brakami (?) umiejętności koderów"
   
Jeśli kogoś uraziłem to przepraszam - nie wysłowiłem się precyzyjnie.
Miałem na myśli bardziej kwestie realizacyjne, ale nie na tak niskim
poziomie jak kod programistyczny. Chodziło m.in o: przerwy między efektami (może to być czasami spowodowane aspektem technicznym - np. czasochłonną prekalkulacją w tle).

Odnośnie kwestii "pamięć na grafikę" vs kod.
   
Nie chodziło o całoekranową grafikę statyczną (zresztą takowej nie uznaję podczas dema i m.in z tego powodu mam zastrzeżenia do dema "Numen").
Zazwyczaj programiści na 8-bitowcach bawią się w tzw. rozpisywanie kodu, tzn. są w stanie poświęcić znaczne ilości pamięci na taki kod, który w stosunku do wersji nie rozpisanej stanowi wzrost wydajności w okolicach 10-15%, czyli praktycznie żaden, natomiast konsekwencje powszechnie są takie, że na resztę nie starcza miejsca - w tym przypadku na grafikę do tekstur, tła, itp., ale czasem także na takie rzeczy jak prekalkulowane, (prozaiczne) ścieżki lotu obiektów, których to obecność mogłaby znacznie podnieść odbiór. Kwestia zdawania sobie sprawy z tego co chce się osiągnąć. Ten błąd popełniałem w przeszłośći oczywiście także ja.
   
Tak naprawdę chodzi o pokazanie jak największej ilości urozmaiconej grafiki (statyczna nie ma z definicji maksymalnego urozmaicenia). Dlatego
pomaga w tym animacja oraz większa ilość pamięci poświęcona na grafikę. Rzecz jasna nie zawsze chodzi o prezentację animowanej, urozmaiconej grafiki bitmapowej, czasami pasuje animowana grafika z małym poziomem detalu, ale wówczas ciężar "odbioru" obrazu należy przenieść na inne aspekty prezentacji.

Cytat:
"czy raczej m.in. takie efekty jakie na atari pokazałeś w swoim "TRIP 6"
(czyli te eksperymenty z ekranem - trudno mi to jakoś nazwać !)"
   
Eksperymenty z ekranem?!? Nie rozumiem, doprecyzuj.

A propos "Trip6", to właśnie (w stopniu co prawda minimalnym, ale jednak) to demo stanowiło minimalny krok w kierunku zmiany filozofii. Nie
wiem czy dostrzegasz o co mi chodzi. To kwestia kompozycji muzyki,
braku statycznej grafiki (podczas efektu), wyglądu ekranu w sposób zunifikowany przez całe demo. Oczywiście występuje tam cała masa niedoróbek i m.in dlatego chcę zrobić znacznie lepszą prezentację, eliminując błędy i wprowadzając dodatkowe modyfikacje.
   
Poza tym ciekawa sprawa - dobra prezentacja nie musi koniecznie być tworzona długo. Myślę że poświęciliście mnóstwo czasu na zrealizowanie dema "Numen". Ja osobiście będę chciał uzyskać b. miły efekt minimalizując różnymi środkami czas.

Cytat:
"i czekam na kontakt (używasz jeszcze ICQ?)"
   
Nie. W pewnym momencie program stał się nie praktyczny ze względu na
obciążenie serwerów. Dałem sobie spokój.

Mowisz ze to demo (Trip6) to krok na przod. byc moze.
Zapytaj sie jednak przecietnego atarowca lub kazdego innego ktory ogladal 2 dema "Ass Kicker" i "Trip6" ktore mu w pamieci zapadlo.

Ass kickera zna kazdy, kojarzy najmniejszy nawet fragment, a Trip6 (choc b. fajne i moim prywatnym zdaniem lepsze) zostaje gdzies tam w cieniu Ass Kickera.
O co chodzi ??     
Czasami ten Slide Show bardziej zostaje w pamieci.
No ale tego nie jestem wstanie wytlumaczyc.

uberatarian cholera :)

tak poza tym...
to musze sie wypowiedziec nt idei Konopa...
- po pierwsze rozpetlanie kodu, jak sam wiesz, to nie jest wcale 10-15% poprawy... osmiele sie stwierdzic ze dla okolo polowy efektow w Numenie roznica bylaby nawet kilkukrotna.
- brak miejsca na tekstury - wiele efektow jest optymalizawanych tak ze dziala szybko tylko dla tekstur np. 16x16 albo 64x64
-

jak sam widzisz, problemem bylo umieszczenie tak wielu efektow i grafiki, niestety na design nie starczylo tyle czasu ile chcielismy.. ale sluchaj.. moglismy wypuscic to demko teraz albo za rok... myslisz ze za rok ktos by to jeszcze ogladal? minimalizacja srodkow = cc65?
- jak to powiedzial Fox - jak fajnie byloby wystawic Numena, zajac #2 miejsce, odpalic to PeCetowcowi i powiedziec 'to zajelo 2gie miejsce na ostatnim party' (wyluzowanym glosem)
-

z ta mala plynnoscia, to troche sie zgodze... Fox nie bij! Fox chcial pokazac potege engine'u i miejscami mapy sa zbyt obszerne... ale sa miejsca ze smiga :)

a co mi tam zreszta...
Konop! Jak napiszesz demko, to sie tylko uciesze...
ze w demach brak designu to zawsze tak bylo...
troche demka aids czasem cos w sobie mialy...
no i 'cogito' ofkorz...
poza tym, na PC jest czesto tak, ze jak designer wymysli ze cos ma wygladac mniej wiecej tak i tak to koder jest to czesciej w stanie zrealizowac niz na atari...
takze, czekam na nowa epoke w demach na XLke :)
Numen moze dal komus kopa :)
oby nie byl to kop w kosmos, tylko kop do klawiatury...

Co do powrotu na scenę to osobiscie namawiam Pazura zeby zrobic jakies demko na Atari , byc może się uda ?

Jak widze jest troche wysrubowany poziom ale zobaczymy .

Zdazylem zauwazyc ze 3d rulez , mam nadzieje ze Pazur nie zrobi obiektu z 23000 vertex i 48000 faces - bo sie on nie zmiesci w pamieci atari  :D a tak powaznie to zobaczymy czy znajdzie troche czasu bo ostatnio jest bardzo zajety - jakby ktos chcial wiedziec to wlasnie jemu zawdzieczamy "popieprzone kurczaki " z jednej z reklam !

Acha - ma ktos moze dokladny opis (najlepiej w jezyku polskim ) do formatu obiektow z LW ?

Niestety moj sedziwy 65xe nie posiada rozszerzenia pamieci wiec bede musial mu zrobic - najlepiej na krotkim simie - bo co prawda pisze pod emulatorem ale efekty trzeba zobaczyc na oryginalnej atarce zeby nie bylo niespodzianek.

Mam nadzieje ze uda mi sie cos wymodzic do wakacji , pewnym problemem jest czas i reszta bylej (moze przyszlej) grupy.
Na razie niestety wszystko robie sam.

a juz myslalem ze bede mial monopol na obiekty 3D z LightWave w demkach na Atari XE/XL :)

jak kto ma jakis ciekawy obiekcik do zaoferowania do demka, chetnie przyjme, tak zeby max 24 sciany byly widziane przy kazdym obrocie
(na razie mam kule, torus). Jesli ktos ma kaczuszke z mala iloscia facow (moja liczy ich 205) to tez chetnie skorzystam.

   LIGHTWAVE 3D OBJECT FILE FORMAT

          by Allen Hastings
          revised  11/10/93
       (no w?asnie, do LW 3.5)

             t?umaczenie
          c0manch3 / aMn35tY
                Wst?p

Obiekty  LW s? zapisane jako pliki IFF
kt˘rych FORM jest okrežlony jako LWOB.
Obecnie FORM LWOB musi zawieraŤ chunki
PNTS,   SRFS   oraz   POLS  (w  takiej
kolejnožci).   Mo§e po nich wystepowaŤ
zero lub wiecej chunk˘w SURF.

              Chunk PNTS

Ten  chunk zawiera list? wsp˘?rz?dnych
X,Y i Z wszystkich punkt˘w w obiekcie.
Ka§da  wsp˘?rz?dna  jest zapisana jako
czterobajtowa                   liczba
zmiennoprzecinkowa  w  formacie  IEEE.
Dlatego  te§ liczba punkt˘w w obiekcie
jest   ograniczona  przez  podzielenie
d?ugosci  w  bajtach chunka PNTS przez
liczb?  12  (z  tego  co  wiem  LW nie
przyjmuje  obiektow  ktore maj? wiecej
niz 65536 punktow(!)).

Kierunek +X to prawo lub wsch˘d, +Y to
g˘ra,  +Z  to naprz˘d lub p˘?noc.  Dla
modeli  žwiata rzeczywistego jednostk?
jest  metr.   Wsp˘?rz?dne  s? wzgledne
wobec  punktu  obrotu  obiektu  (pivot
point) .

              Chunk SRFS

Ten    chunk    zawiera   list?   nazw
wszystkich   powierzchni   w  obiekcie
(s?owo  "powierzchnia"  w  LW  oznacza
zesp˘?  atrybut˘w  opisujacych kolor i
rodzaj   cienowania  (tak§e  tekstury)
grupy    polygonow).     Ka§da   nazwa
powierzchnia   wyst?puje   jako   ci?g
znak˘w   zako¤czonych   zerem.   Ježli
d?ugožŤ  ci?gu  (w??czajac  zero) jest
nieparzysta, dodaje si? dodatkowy bajt
zerowy.  Nazwy powierzchni powinny byŤ
czytane    z   pliku   p˘ki   zostanie
odczytana  iložŤ  bajt˘w,  kt˘ra  jest
okrežlona w chunksize.

              Chunk POLS

Ten  chunk  zawiera  list?  wszystkich
polygon˘w  w  obiekcie.  Ka§da pozycja
zawiera  liczb?  ca?kowita  m˘wiaca  o
iložci     wierzcho?k˘w,     nast?pnie
wyst?puje  wlažnie  taka  liczba liczb
calkowitych   :)  m˘wiacych  o  samych
wierzcho?kach   (odwo?anie   do  listy
punkt˘w),  potem mamy liczby calkowite
m˘wiace  o  numerze u§ytej powierzchni
(jako  indeks  do  list  powierzchni).
Liczba  wierzcho?k˘w  w polygonie moze
sie  wachac  od jednego do 200.  Lista
wierzcholkow   dla   kazdego  polygonu
powinna  si?  zaczynaŤ  od wierzcho?ka
wypuk?ego   i  ižŤ  zgodnie  z  ruchem
wskaz˘wek  patrzac od widocznej strony
polygonu    (polygony    w    LW    sa
jednostronne   opr˘cz   tych,  kt˘rych
powierzchnie   maj?   w??czon?   flag?
'double-sided').    Lista   punkt˘w  w
chunku PNTS jest numerowana poczynaj?c
od  zera, a lista powierzchni w chunku
SRFS  jest  numerowana  poczynaj?c  od
jedynki  (wi?c numery powierzchni moga
byc   zanegowne   aby   zawiadomic   o
istnieniu    szczeg˘?owych    (detail)
polygonow,  o czym poni§ej).  Polygony
powinny byc odczytywane z pliku dop˘ki
nie  zostanie  przeczytane tyle bajt˘w
ile ma chunk (zapisane w chunksize)

Ujemny   numer   powierzchni  polygonu
sygnalizuje  §e  polygon  ma  polygony
szczeg˘?owe    (detail)    (ktore   s?
rysowane  na  g?˘wnym polygonie i mog?
byŤ z nim na wsp˘?p?aszczyúnie.  W tym
wypadku,  nast?pna  liczba  w pliku to
liczba   ca?kowita   opisujaca   iložŤ
polygonow   dok?adnych  nale§acych  do
owego  polygonu.  Nastepnie jest lista
polygon˘w  dok?adnych,  w kt˘rej ka§da
pozycja   jest   w  formacie  opisanym
powy§ej  dla  zwyk?ych  polygon˘w  (za
wyj?tkiem - polygony dok?adne nie mog?
posiadaŤ    ju§    innych    polygonow
dokladnych).  Lista zwyk?ych polygonow
konczy  sie  na  tym.   Aby  sprawdziŤ
kt˘rej  powierzchni  u§ywa  polygon  z
negatywnym     numerem    powierzchni,
odcztujemy jego wartožŤ absolutn?.

              Chunk SURF

Kazdy   chunk  SURF  opisuje  atrybuty
pojedynczej  powierzchni.   Chunki  te
rozpoczynaja  sie  nazwa  powierzchni.
Nazwa  jest  zapisana jako ciag znak˘w
zakonczonych  jednym  lub dwoma zerami
(tak  jak  to  by?o w przypadku chunka
SRFS).    Po  nazwie  wyst?puje  seria
pod-chunkow, kt˘re s? takie jak chunki
IFF,   z   tym,  §e  ich  rozmiary  s?
okrežlone   poprzez  liczby  ca?kowite
'kr˘tkie'  (short)  zamiast  'd?ugich'
(long).   Oczywiste,  §e  liczba  tych
pod-chunk˘w   wzrožnie  ježli  zostan?
dodane   nowe   atrybuty  w  programie
(nowsze  wersje), a wszystkie nieznane
rodzaje  chunk˘w  zostan?  pomin?te  w
spožob   charakterystyczny   dla  IFF.
Pod-chunki powinny byŤ czytane z pliku
tak  d?ugo  jak  jest  to  okrežlone w
chunksize.

            Pod-chunk COLR

Ten   pod-chunk   zawiera  trzy  bajty
opisuj?ce    czerwon?,    zielon?    i
niebiesk?   sk?adow?   koloru  obecnej
powierzchni,   nastepnie   jest  bajt,
kt˘ry    ignorujemy   (powinien   mieŤ
wartožŤ zero).  Powierzchnia mo§e miec
wiec 24 bity koloru.

            Pod-chunk FLAG

Ten pod-chunk zawiera kr˘tk? ca?kowit?
kt˘rej  bity  opisuj?  r˘§ne opcje dla
bie§?cej powierzchni.  Obecnie jedynie
9    mniej   znaczacych   bit˘w   jest
wykorzystanych.  Opcje kt˘re ustawiaj?
bity   m˘wi?   o   (rozpoczynaj?c   od
najmniej    znacz?cego):     Luminacji
(swieceniu),    Outlinie    (obwodce),
Smoothingu,      Color      Highlights
(rozb?yskach  w  kolorze powierzchni),
Color  Filter  (kolor  filtrowania dla
przezroczystožci),  niprzezroczystožci
kraw?dzi,  (Opaque  Edge)  Transparent
Edge   (przezroczysta   kraw?dú),Sharp
Terminator, Double-Sided (powierzchnia
dwustronna)   i  Additive.   Dwa  bity
kraw?dzi  (Opaque  i  Transparent) nie
powinny byŤ ustawione jednoczežnie.

              Pod-chunki
    LUMI, DIFF, SPEC, REFL, i TRAN

Ka§dy  z  tych  chuk˘w  zawiera kr˘tka
liczb?   ca?kowit?   opisuj?c?   nast.
parametry    powierzchni:    žwiecenie
(luminosity),   rozproszenie   žwiat?a
(diffuse),  po?ysk (specular), odbicia
(reflection)       lub      ustawienia
przezroczystožci  (pod-chunk LUMI jest
nowy   dla  LW  3.0  i  zast?puje  bit
Luminancji    w    pod-chunku   FLAG).
WartožŤ  256 odzwierciedla 100% danego
parametru  (w  panelu  kontrolnym LW).
Jesli  te  pod-chunki  nie wystepuja w
chunku      powierzchni,     domyslnym
ustawieniem jest zero.

            Pod-chunk GLOS

Ten  pod-chunk  zawiera  kr˘tk? liczb?
ca?kowit?  opisuj?c?  wielkožŤ po?ysku
obecnej  powierzchni, i jest potrzebny
tylko  wtedy  gdy  wartožŤ ustawiona w
pod-chunku    SPEC   jest   niezerowa.
R˘§nym  poziomom rozb?ysku odpowiadaja
wartožci:   16  -  niska  (low),  64 -
srednia (medium), 256 - wysoka (high),
a   1024   jest  wartosci?  maksymaln?
(maximum)   (nowe   w  LW  3.0).   Ten
parametr  jest  zwi?zany z "wyra§eniem
b?ysku"   u§ywanym  w  wielu  modelach
ožwietlenia.

            Pod-chunk RIMG

Ten   pod-chunk  zawiera  nazw?  pliku
(w??czaj?c  ca??  žcie§k? zdefiniowan?
przez   u§ytkownika)   obrazka,  kt˘ry
b?dzie    u§yty    jako   mapa   odbiŤ
(reflection    map)    dla    bie§?cej
powierzchni.    Zn˘w,   ježli  d?ugožŤ
ci?gu znakow jest nieparzysta (??cznie
z  zerem  ko¤cowym),  dodajemy jeszcze
jedno  zero.   Ježli  ostatni? cz?žcia
ci?gu  jest "sequence", wtedy pierwsza
cz?žŤ ci?gu definiuje prefix (pierwsz?
cz?žŤ)    nazwy    sekwencji   (wtedy,
aktualna nazwa obrazka jest generowana
poprzez  dodanie  trzycyfrowej  liczby
klatek do prefix'u gdy wczytywany jest
obrazek    lub    sekwencja).    Ježli
ustawienie  odbiŤ  w  pod-chunku  REFL
jest niezerowe, ale sub-chunk RIMG nie
wyst?ouje,  wtedy  powierzchnia odbija
backdrop  nieba  i ziemi (backdrop nie
jest  obiektem,  dziala jak enviorment
-c0m)  ,  takze  gdy  uzywamy  pe?nego
ray-tracingu LW.

            Pod-chunk RSAN

Ten  pod-chunk  zawiera  czterobajtow?
liczb?    zmiennoprzecinkow?,    kt˘ra
opisuje  k?t  nachylenia spojenia mapy
odbiŤ.

            Pod-chunk RIND

Ten  pod-chunk  zawiera  czterobajtow?
liczb?  zmiennoprzecinkow? (w formacie
IEEE) kt˘ra opisuje stopie¤ refrakcji,
kt˘ry    jest   stosunkiem   pr?dkožci
žwiat?a  w pr˘§ni do predkožci žwiat?a
w  przezroczystym materiale.  Dlatego,
§e  žwiat?o  najszybsze jest w pr˘§ni,
wartožŤ  ta  powinna  byŤ  wi?ksza lub
r˘wna 1.0.

            Pod-chunk EDGE

Ten  pod-chunk  zawiera  czterobajtow?
liczb? zmiennoprzecinkow? (IEEE) kt˘ra
opisuje    przezroczystožŤ    kraw?dzi
obecnej   powierzchni.    WartožŤ   ta
powinna  si?  zawieraŤ  pomi?dzy 0.0 a
1.0.

            Pod-chunk SMAN

Ten          pod-chunk         zawiera
czterobajtow? liczbe
zmiennoprzecinkow?   (IEEE)  opisuj?c?
maksymalny    k?t    pomi?dzy    dwoma
polygonami (z??czonymi kraw?dzi?) przy
kt˘rym   mog?  zostaŤ  one  wyg?adzone
(phong?  -c0m) (wyra§one w stopniach).
Polygony  o  wi?kszym  k?cie  pomiedzy
nimi    b?d?    'zaostrzone'    (czyt.
niewyg?adzone :).

              Pod-chunki
CTEX, DTEX, STEX, RTEX, TTEX, i BTEX

ObecnožŤ  jednego  z  tych pod-chunk˘w
informuje,  §e  obecna powierzchnia ma
kolor,     rozproszenie,     odb?yski,
odbicia,  przezroczystožŤ  lu tekstur?
bumpingu.  Zawartožci? pod-chunka jest
ci?g  znak˘w  (jak  zwylke  zako¤czony
jednym lub dwoma zerami) opisuj?cy typ
tekstury  tak  jak  w  panelu Surfaces
LightWave'a.    Ježli   jeden  z  tych
pod-chunk˘w  b?dzie  w  žrodku  chunka
SUFR,  wszystkie podrz?dne, zwi?zane z
teksturami     pod-chunki     (opisane
poni§ej)    nawi?zuj?    do    obecnej
tekstury,   doputy,   dop˘ki   wyst?pi
nast?pny  CTEX, DTEX, STEX, RTEX, TTEX
lub  BTEX.   Obecnie mo§e byŤ zero lub
jeden  z  tych pod-chunkow (do szežciu
tekstur  - ka§da dla innego parametru)
w  ka§dym  chunku SURF (z tego co wiem
(bo  korzystam)  w  LW  5.0  mo§e  byŤ
wi?cej  ni§ jedna tekstura dla jednego
parametru (np.  dla przezroczystožci);
dodatkowo mo§na je w?aczaŤ w negatywie
i nak?adaŤ tekstur? jako kana? alpha -
žci?gn?            z           Newteka
nowsz? specyfikacj?).

            Pod-chunk TIMG

Ten  pod-chunk  opisuje  nazw? pliku z
obrazkiem (lub prefix sekwencji) kt˘ry
b?dzie    u§yty   jako   tekstura   do
mapowania.     Patrz   dok?adny   opis
pod-chunka RIMG.

            Pod-chunk TFLG

Ten  pod-chunk  zawiera  kr˘tk? liczb?
ca?kowit?,  kt˘rej bity w??czaj? r˘§ne
opcje  dla  obecnej tekstury.  Obecnie
(dla  LW  3  blah)  jest  u§yte siedem
mniej  znacz?cych bit˘w.  Opcjami tych
bit˘w   s?   (zaczynaj?c  od  najmniej
znacz?cego):
- mapowanie w osi X,
- mapowanie w osi Y,
- mapowanie w osi Z,
- koordynaty og˘lne (World Coords),
- negatyw tekstury,
-  rozmycie  pikseli (np.  przy bardzo
du§ym   zbli§eniu   tekstur   o  ma?ej
rozdzielczožci),
- antyaliasing tekstury.

Tylko  jeden  z trzech bitow mapowania
(X,Y,Z) moze byŤ w??czony.

Pod-chunki TSIZ, TCTR, TFAL, i TVEL

Te  pod-chunki  zawieraj?  trzy liczby
zmiennoprzecinkowe   (4  bajty,  IEEE)
kt˘re   opisuj?   parametry   (obecnej
powierzchni)   X,Y   i  Z  dla  žrodka
tekstury   (TCTR),   rozmiaru  (TSIZ),
zanikania  (TFAL)  lub  jej  pr?dkožci
(TVEL).   Pod-chunki  TCTR, TFAL, TVEL
s? potrzebne tylko wtedy, gdy zwi?zane
z nimi parametry s? niezerowe.

           Pod-chunki TCLR

Ten  pod-chunk  zawiera  cztery  bajty
opisuj?ce  kolor  tekstury  dla  danej
tekstury (mas?o mažlane), kt˘ry bedzie
modyfikowa?   tekstur?  (innymi s?owy,
powinien  wyst?piŤ wczežniej pod-chunk
CTEX).   Bajty opisuj? kolor tak jak w
pod-chunku COLR.

            Pod-chunk TVAL

Ten  pod-chunk  zawiera  kr˘tk? liczbe
rzeczywist?      opisuj?c?     wartožc
parametr˘w    tekstury   takich   jak:
rozproszenie,  rozb?yski,  odbicie lub
przezroczystožŤ,   powinien   wyst?pic
gdziež  po  DTEX, STEX, RTEX lub TTEX.
WartožŤ 256 odpowiada 100% w LW.

            Pod-chunk TAMP

Ten  pod-chunk  zawiera IEEE opisuj?c?
amplitud?  obecnej  tekstury bumpingu,
powinien   wyst?piŤ   wi?c  gdziež  po
pod-chunku    BTEX.     WartožŤ    1.0
odpowiada 100% w LW.

            Pod-chunk TFRQ

Ten  pod-chunk  zawiera  kr˘tk? liczb?
ca?kowit?  opisuj?c? liczb? úr˘de? fal
lub  zak?˘ce¤ (np.  dla Fractal Noise)
u§ywanych przez obecn? tekstur?.

     Pod-chunk TSP0, TSP1, i TSP2

Te pod-chunki zawieraj? IEEE (ka§dy po
jednej) opisuj?ce jeden ze specjalnych
parametr˘w    (tak    jak    kontrast,
turbulencje, d?ugožŤ fali).  KolejnožŤ
tych    parametr˘w   jest   taka   jak
kolejnožŤ ich wyst?powania na panelu w
programie  (ale,  k****,  pomys?).   W
przysz?ožci  (teraz?   LW5?)  mo§e ich
byŤ wi?cej dla danej tekstury.

      Przyk?ad pliku z obiektem

Prosty     obiekt     (z     cokolwiek
skomplikowanymi  powierzchniami)  jest
pokazany poni§ej aby przedstawiŤ pewne
mo§liwožci  FORM  LWOB.   Obiekt  jest
teksturowanym, bumpowanym, kwadratowym
polygonem  w  rzucie XY z b?yszcz?cym,
przezroczystm, §˘?tym tr˘jk?tem, kt˘ry
jest  polygonem szczeg˘?owym (detail).
Ka§da  linia  listingu  przedstawia 16
bajt˘w    w    heksie   :),   a   obok
odpowiedniki w ASCII (qrva, instrukcja
jak  dla  m?otk˘w).  Notatki pod ka§d?
lini?  powinny  byŤ  czytane  raczej z
lewej  do  prawej,  ani§eli  z g˘ry na
d˘?.

464F524D 0000019C 4C574F42 504E5453
00000054 3F800000 3F800000 00000000
           ^^^^^^^^ ^^^^^^^^ ^^^^^^^^

FORM....LWOBPNTS
...T?...?.......

Wsp˘?rz?dne  X,Y i Z punktu numer 0 s?
1.0,1.0,0.0 (format IEEE)

      ^^^^
Jest 84 bajty w chunku PNTS, wiec jest
siedem  punkt˘w  w obiekcie (84 / 12 =
7)

BF800000 3F800000 00000000 3F800000
BF800000 00000000 BF800000 BF800000
00000000 3F000000 BF000000 00000000
00000000 3F000000 00000000 BF000000
BF000000 00000000 53524653 00000012
53717561 72650000 54726961 6E676C65
               ^^^^

....?.......?...
................
....?...........
....?...........
........SRFS....
Square..Triangle

Nazwa    powierzczni   "Square"   jest
zako¤czona  dwoma  zerami  aby  liczba
bajt˘w ci?gu by?a parzysta.

0000504F 4C530000 00180004 00010000
                        ^^^^

..POLS..........

Pierwszy  polygon  ma trzy wierzcho?ki
(kt˘re s? punktami 1, 0, 2 i 3).

00020003 FFFF0001 00030005 00040006
                    ^^^^
................

Polygon     szczeg˘?owy     ma    trzy
wierzcho?ki  (kt˘re s? punktami 5, 4 i
6).
               ^^^^
Wyst?puje jeden polygon dok?adny
           ^^^^
Kodem  powierzchni pierwszego polygonu
jest  jeden  wi?c u§ywa on powierzchni
numer   jeden   ("square")  i  posiada
polygony dok?adne.

00025355 52460000 00AE5371 75617265
      ^^^^ ^^^^
..SURF....Square

To  zaczyna  opis powierzchni nazwanej
"square".
  ^^^^
Polygon   dok?adny  u§ywa  powierzchni
numer 2.

0000434F 4C520004 C8C8C800 464C4147
00020000 44494646 00020100 43544558
                             ^^^^^^^^
..COLR......FLAG
....DIFF....CTEX

Nast?pny       zestaw      pod-chunk˘w
zwi?zazanych    z   kolorem   tekstury
powierzchni.
                        ^^^^
Rozproszenie powierzchni "square" jest
ustawione na 100 %.

0012506C 616E6172 20496D61 6765204D
    ^^^^ ^^^^^^^^ ^^^^^^^^ ^^^^^^^^
..Planar Image M

Kolorem    tekstury    jest   planarne
mapowanie obrazka w pliku ram:Laura

61700000 54494D47 000A5241 4D3A4C61
75726100 54464C47 00020004 5453495A
                        ^^^^
ap..TIMG..RAM:La
ura.TFLG....TSIZ

Flaga  bit˘w  wskazuje §e obrazek jest
mapowany wzgl?dem osi Z.

000C4000 00003FC0 00003F80 00005443
    ^^^^ ^^^^^^^^ ^^^^^^^^ ^^^^
..@...?...?...TC

Rozmiary  X,Y,Z tekstury to 2.0, 1.5 i
1.0

4C520004 00000000 42544558 000E4672
                    ^^^^^^^^
LR......BTEX..Fr

Nast?pny zestaw pod-chunk˘w nale§?cych
do   tekstury   bumpingu   powierzchni
"Square"

61637461 6C204275 6D707300 54464C47
0002000A 5453495A 000C3DCC CCCD3DCC
    ^^^^
actal Bumps.TFLG
....TSIZ..=...=.

Flaga   bit˘w  wskazuje  na  aktywacj?
wsp˘?rz?dnych globalnych.

CCCD3DCC CCCD5441 4D500004 3FC00000
                           ^^^^^^^^
..=...TAMP..?...

Amplituda  bumpingu wynosi 150% (1.5 w
IEEE)

54465251 00020001 53555246 00000044
                  ^^^^^^^^
TFRQ....SURF...D

To  jest  pocz?tek  opisu  powierzchni
nazwanej "Triangle"
             ^^^^
Tekstura     bumpingu     ma     jedn?
cz?stotliwožŤ  zak?˘ce¤.   (np.Fractal
Noise)

54726961 6E676C65 0000434F 4C520004
F0B40000 464C4147 00020000 44494646
^^^^^^^^
Triangle..COLR..
....FLAG....DIFF

Kolor   powierzchni   "Triangle"  jest
§˘?ty  (240  czerwony, 180 zielony i 0
niebieski).

0002009A 53504543 000200CD 474C4F53
                        ^^^^
....SPEC....GLOS

Po?ysk materia?u jest ustawiony na 80%
(205 z 256)

  00020100 5245464C 00020033 5452414E
                        ^^^^
....REFL...3TRAN

Mapa  odbiŤ powierzchni wynosi 20% (51
z  256)  lecz  nie wyst?puje pod-chunk
RIMG,  wi?c  powierzchnia  odbija  t?o
(enviorment :).
      ^^^^
Powierzchnia  ma  wysoki (high) po?ysk
(256).

00020066                          ...f
    ^^^^
Powierzchnia jest w 40% przezroczysta.

Powierzchnia  "Triangle"  nie  posiada
tekstur,     nie     wyst?puj?    inne
powierzchnie  wi?c  obiekt  ko¤czy sie
tutaj.

              Comanche/Amnesty & aGOny

Pelc jest khem khem swego rodzaju moim znajomym i niestety nigdzie sią nie pojawi, bo Atari już go zupełnie nie interesuje. :-(

To może zagadałbyś z nim?? Może ma gdzieś jakieś niepublikowany stuff na atari, który mógłby udostępnić??