Odp: Krótki tutorial w Turbo Basicu XL do gier (pseudo)paragrafowych
Też:-) A co powiesz na ===
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Silly Venture 2024 SE - stuff Dostępny jest już stuff z zeszłomiesięcznego party Silly Venture 2024
FujiCup FujiCup ma na celu wspieranie sceny gier retro, dając uczestnikom szansę na pokazanie swojego talentu
Echa Silly Venture 2024 SE Są już dostępne wyniki Silly Venture 2024 SE
Uaktualnienie firmware do The400 Poprawki do "fizycznego" emulatora ośmiobitowych komputerów i konsol Atari.
Akcja - Wsparcie w reverse-engineering Wspierajmy tych, którzy do tej pory zrobili wiele!
atari.area forum » Programowanie - 8 bit » Krótki tutorial w Turbo Basicu XL do gier (pseudo)paragrafowych
Strony Poprzednia 1 2 3 4 5 6 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
Też:-) A co powiesz na ===
Ostatnie zdanie tylko a propos ostatnich komentarzy wyżej, że "przesiadając się z Atari XL/XE na PC-ta w latach 90-tych", nigdy w życiu nie musiałem (oprócz na zaliczenie przedmiotu i zapomnieć) korzystać tych dziwnych znaczków chaosów śmieciowych typu C lub UNIX, dzięki Bogu, czyli Mnie.
Jedyna ciekawostka, jaką poznałem przenosząc się z Atari BASIC na Turbo Pascal 5.5., to znak przypisania
:=
zamiast zwykłego
=
Więcej dziwności nie pamiętam, hmm...
Do dziś czuję się programując, jakbym był nadal na Atari XL/XE, tylko trochę więcej możliwości i osiągi, szersze zakresy zabawy, możliwe, że aż w nieskończone wszechświaty, tak bym to ujął - jednak czy Atari XL/XE, czy PC, nie widzę za bardzo różnicy w komforcie pracy, ani różnicy narzędzi, systemów, etc. - nic, zero, oczywiste. To te same komputery i narzędzia w sumie, chociaż zubożenie układów graficznych na PC spowodowało kataklizm typu ZX Spectrum, Windows programowe, zamiast sprzętowe, etc. - same zagłady PC-tów po drodze, oczywiste... wszystko przez C, UNIX i ZX Spectrum, oczywiste...
Ale już niedługo będzie powrót do Atari, czyli do dobrych komputerów, a nie śmieci, oczywiste...
Ostatnio edytowany przez Smaku (2019-03-11 23:33:05)
Bo programowanie to cały czas te same matematyczne kombinacje, bez względu na stopień zaawansowania sprzętu, a wynikiem każdego programu ciągle pozostają obrazy i dźwięki, ewentualnie włączone lub wyłączone jakieś linie sterujące czymś tam, nic więcej.
Z tym że proponował bym już więcej nie zaśmiecać koledze Sikorowi wątku-tutorialu o pisaniu gry w TBXL, ja się wyłączam i czekam na kolejny odcinek od Sikora.
@Mq:
Zgoda a propos programowania, ale ze zwróceniem uwagi, że sprzęt sprzętowi nierówny, więc programując w obojętne czym (kto co lubi, to sobie używa), nadal wykonuje program na sprzęcie. I w tym miejscu dopiero zaczyna być widać różnice w efektach, oczywiste.
Więcej nie zaśmiecam. Potwierdzam, prawda, true. amen.
@mono. Tego to jeszcze nie widziałem. Chociaż lubie -ne
Część trzecia, czyli dwa słowa o grafice i pliku DOSowym.
Miło mi, że na forum pojawiaja się komentarze i poprawki mojego kodu. Zgodnie z ustaleniami dziś postaram się pokazać jak stworzyć plik uruchamiany spod DOSu (lub dowolnego loadera). Ale ponieważ ma to być gra, w dodatku z grafiką - zacznijmy od niej.
Całą gra ma być w trybie graficznym (bo mi tak wygodnie z pewnych względów, ma zawierać grafikę, itp., itd.). Niestety, nie doczekałem się pomocy grafika, więc muszę sam coś zaimprowizować. Całość robimy w trybie jednokolorowym (dla niektórych: dwukolorowy, barwa i odcień). Tak działa nasze Atari (o ile nie korzystamy z artefaktów, ale te to na CRT i głównie w NTSC). Lubię, jak gra ma jakiś tytuł. Postanowiłęm, że do dzisiejszej części dorobię taką namiastkę. Ponieważ w tym trybie standardowo mamy rozdzielczość 320x192 punkty, proporcje piksela 1:1 (co jest bardzo ważne), bardzo wygodnym narzędziem są wszelkiego rodzaju edytory graficzne na PC (oczywiście można grafikę zrobić na Atari, Macu czy nawet Atari ST czy Amidze), w moim przypadku z możliwością zapisu/eksportu w formacie GIF (bo z takich narzędzi korzystam na Atari i w tym tutorialu). Obsługi programów nie będę tutj uczył - napiszę tylko, że w naszym przypadku korzystam z darmowego GIMPa.
Dobrze, stworzyłem sobie grafikę w odpowiednim formacie i rozdzielczości - ponieważ mam zamiar tytuł wyświetlać także podczas gry, założyłem, aby grafika nie była zbyt duża, powiedzmy 320x40 pikseli, oczywiście w jednym kolorze. Grę nazwałem oryginalnie "Tutorialowa gra paragrafowa" i zmodziłem z tego grafikę o zadanych rozmiarach, po czym przekonwertowałem ją na grafikę jednobitową i zapisałem w formacie GIF. Całość umieściłem na dyskietce roboczej (stworzyłem na potrzeby tutorialu kolejną dyskietkę - grafika.atr - osobiście preferuję większe obrazy, ale poradzimy sobie). Zakładając, że ktoś korzysta z pojedynczej stacji dyskietek postaram się przeprowadzić teraz drogich czytelników przez proces konwersji, przy czym zaczniemy od liczenia: 320px w szerokości daje nam w tym trybie graficznym 40 bajtów, mamy 40 linii, czyli 40x40=1600 bajtów - tyle docelowo zajmie nasza grafika.
Zabieramy się za konwersję. Ponieważ tu grafika zajmuje całą szerokość ekranu do testów napiszemy sobie prosty programik w TBXL do wycięcia bloku, ale najpierw trzeba wszystko przekonwertować. Wczytujemy dyskietkę roboczy_tools.atr i program do konwersji (jv.com). Po pojawieniu menu programu za pomocą klawisza "M" wybieramy tryb Gr.8 BW - jest to nasz docelowy tryb graficzny (nawiasem mówiąc - proponuję się w wolnej chwili pobawić tym programem). Podmieniamy w stacji naszą dyskietkę na obraz grafika.atr. Teraz możemy ją wylistować (D), można podać maskę lub wcisnąć RETURN (bo całość mamy w stacji D:). Upewniamy się, że jest tam nasz GIF - wybieramy "L", następnie *.gif (mamy ten jeden póki co, więc po co się męczyć z nazwą?), możemy zmienić sposób dzielenia szerokości i wysokości (tu bez zmian) i wczytujemy (Return). Po wczytaniu widzimy nasz obraz, naciskamy klawisz START i całość zapisujemy - dla grafik w 8-mym trybie graficznym ja zwyczajowo daję rozszerzenie .8, ale może być dowolne, więc naciskam "S" i wpisuję "TYTUL.8" (wpisujcie bez apostrofów). Zapisał nam się plik w 8-mym trybie graficznym. Teraz podmieniamy dyskietkę na taką z dosem, "Z" i jesteśmy w DOSie.
Proponuję wczytać TBXL. Podmieniamy dyskietkę na ą z grafiką i teraz proponuję Wam chwilę przerwy od gry. Napiszemy sobie krótki programik do naszej grafiki. Przepiszmy uważnie ten kod:
10 OPEN #1,4,0,"D:TYTUL.8":BGET #1,$60
00,7680:CLOSE
11 GRAPHICS 24:POKE 710,0
12 MOVE $6000,DPEEK(88),1600
13 GET KEY
14 OPEN #1,8,0,"D:TYTUL.DAT":BPUT #1,$
6000,1600:CLOSE
Proponuję zapisać to sobie, na przykład jako "TESTGR.TB". Uruchamiamu (RUN) - na ekranie po chwili ukaże się nasz tytuł. Robimy DIR i co widzimy - plik TYTUL.DAT, który jest sporo krótszy od TYTUL.8 - ma dokłądnie 1600 bajtów.
Co dokłądnie robi nasz mini program? Otwieramy kanał pierwszy do odczytu, wczytujemy pod adres $6000 7680 bajtów, uruchamiamy ósmy tryb graficzny bez okna tekstowego (8+16=24), przepisujemy pierwsze 1600 bajtów na ekran (linia 12), po naciśnięciu klawisza otwieramy pierwszy kanał do zapisu i zapisujemy dane na dyskietkę. Pamiętamy o każdorazowym zamykaniuu otwartych kanałów - dobra praktyka!
Teraz tak - zaraz kilka osób się przyczepi, że przecież mogłem otworzyć dwa kamnały od razu (jeden odczyt, drugi zapis) i polecieć całość za jednym zamachem (pierwsze 1600 bajtów pliku), mogłem wczytać od razu na ekran (zamiast $6000 od razu dpeek(88)) - itp. Nie zrobiłęm tego, aby pokazać mechanizm działania i pewien sposób trzymania danych w pamięci komputera.
Czas określić miejsce w pamięci, gdzie będziemy trzymać nasz tytuł. Proponuję tuż pod fontami, pamiętamy, że one siedzą od adresu $9C00, wpiszmy w TBXL:
?HEX$($9C00-1600)
Wyskoczy nam wynik: 95C0, czyli naszym docelowym adresem będzie $95C0. Kto chce, może skorzystać z metody Open... itd, ale jak widzicie - pliki nam się mnożą. Proponuję wczytać teraz Super Packera, i po kolei:
1. L (czyli load) i podajemy DANE.DAT (nasze fonty, przypominam)
2. F (wczytanie danych niebinarnych) i podajemy TYTUL.DAT, podajemy adres 95C0, sprawdzamy, czy jest przed fontami (jest - 9BFF)
3. S (zapisujemy) i podajemy DANE.DAT - nadpisujemy nasz plik z danymi
4. Q - wychodzimy do DOSu
Uwaga! Pamiętamy, aby w stacji były odpowiednie dyskietki! Wynik zapisujemy na naszej roboczej dyskietce z programem w TBXL!
Teraz wczytujemy TBXL. dajemy komendę BLOAD"D:DANE.DAT" i możemy sprawdzić, czy dane siedzą w pamięci:
GR.8:MOVE$95C0,DPEEK(88),1600:POKE756,$9c
Powinniśmy mieć tytuł na górze ekranu oraz polskie literki z control. Zakłądam, że wszystko jest ok. Pamiętamy, aby uzupełnić nasz plik z adresami o odpowiedni wpis - $95c0-$9fff grafika tytułowa - aby potem ich nie zadeptać. Wczytujemy nasz plik z grą (LOAD"D:GRA0.TB"). Zmodyfikujemy sobie póki co tylko procedurę INTRO, proszę o własnoręczne przepisanie zmian:
99 ------------------------------
100 PROC INTRO
101 GRAPHICS 24:POKE 710,0:POKE 709,
15:POKE 756,$9C
102 MOVE $95C0,DPEEK(88),1600
142 COLOR %1:TEXT 10,100,"Tu będzie i
ntro"
150 IF PEEK(53279)<>6 THEN 150
190 ENDPROC
199 ------------------------------
Pomijając fakt, że będzie to procedura mocno zmieniana w kolejnym odcinku - wykonajmy nasze zadanie, czyli pokażę jak wykonać plik wczytywany z DOSu lub loadera. Zapiszmy całość jako GRA1.TB (ja zawsze zmieniam numer jak coś robię - w razie wpadki mogę wrócić do poprzedniego pliku. Można też tworzyć sobie tylko dwa pliki i je nadpisywać naprzemiennie, nie polecam natomiast zapisywać zmian zawsze na tym samym pliku, bo mogą pojawić się problemy i czasem ciężko będzie do nich wrócić).
Jeszcze sprawdzam, zy wszystko jest ok - RUN.
Jeśli wszysko w porządku - wczytujemy nasz kompilator (DOS i TBC.COM). Wciskamy 1 (numer stacji dyskietek z naszym źródłem), następnie klawiszamy kursora wybieramy nasz plik źródłowy (GRA1.TB) i naciskamy return. Jeśli wszystko będzie w porządku (no errors) - program poprosi o podanie nazwy dla skompilowanego programu (podajemy bez rozszerzenia) - GRA1.CTB, potem naciskamy N (nie chcemy kolejnej kopii), control-D (wyjście do DOS), Y (potwierdzenie) i sprawdzamy nasz katalog (DIR). Niestety, jak tam spojrzymy - mamy tylko 63 wolne sektory (ach, ta pojedyncza gęstość), a sam runtime ma... 88 (jak ktoś stworzył sobie większego ATR-a to nie będzie miał problemu). Na potrzeby tutoriala tworzę nowy ATR, tam przegrywam wyłącznie plik linker, runtime2.exe oraz nasz skompilowany program - ja go nazwałem kompilat.atr (do ściągnięcia).
Po wgraniu DOSa wkładamy do stacji nasz dysk i wczytujemy linker (LINKER.COM) - i tu uwaga, oryginalny linker wymaga, aby plik RUNTIME2.EXE był w stacji nr 1. O.k., podajemy nazwę naszego programu (pełna śzieżka) - D:GRA1.CTB, następnie nazwę pliku wynikowego - D:GRA1.CO (Uwaga! Z premedytacją dalem rozszerzenie CO - potrzebujemy dograć nasze dane! Gdy nic nie dogrywamy - mamy już gotowy plik!). Wciskamy Return i KONIECZNIE klawisz Esc po zapisaniu! (dopiero on zamyka plik). Wkłądamy dyskietkę z DOSem i mossadem, wciskamy D (wyjście do DOS), wczytujemy mossada i po kolei:
1. R D:GRA1.CO <return> - wczytanie "naszej gry"
2. R D:DANE.DAT <return> - wzytanie brakujących danych
3. W D:GRA1.COM <return> - zapis całej gry
4. Q T - wyjśie do DOSu (musi być w stacji)
Teraz już możemy wczytać naszą grę spod DOSu! Sprawdźcie sami...
Oczywiście, zamiast Mossada można użyć nawet DOSa, ale dla mnie jest to wygodne narzędzie, co więcej - ma spory bufor pamięci. W następnym odcinku spróbujemy nieco doszlifować nasz program binarny i zająć się ekranem inta. Jak zwykle liczę na odzew ze strony forumowiczów i czekam na uwagi.
Dzięki za kolejny odcinek, teraz widzę jak mocno skomplikowałem ci prace :)
Dzisiaj nie dam rady, ale jutro po testuję/pobawię się tym odcinkiem.
Również dzięki za kolejny odcinek.
Sikor, czy na potrzeby tutorialu na obecnym etapie, nie lepiej było by jednak zmienić trochę koncepcję ogólną i zrobić na tyle dużego atr-a, żeby wszystko dało się robić na jednej "dyskietce"?
Myślę, że wówczas opisy były by bardziej przejrzyste, a same operacje dyskowe nie zajmowały by tak dużo miejsca w opisach, dzięki czemu i Tobie było by to łatwiej pisać i czytelnikom było by łatwiej czytać, rozumieć i testować. Tak sobie myślę, że bardziej gładko by się przechodziło przez ten tutorial, gdyby założyć, że robimy to na potrzeby naszej nauki w emulatorze: przecież każdy czyta tutorial na pececie, ściąga na nim te pliki, więc najszybciej też jest je przetestować na emulatorze. Następnie kto ma ambicję przenieść to na prawdziwe Atari, to sobie poradzi już we własnym zakresie układając dyskietki jak mu wygodniej. Ja osobiście wolał bym mieć wszystko w jednym atr i nie zastanawiać się co jest w którym i którą dyskietkę w jakiej kolejności przekładać.
Sam nie lubię emulatorów, ale tutorial łatwiej się w tym wypadku tak testuje. Z kolei ja np. na prawdziwym Atari używam SIO2SD, więc też jest mi wszystko jedno jaki duży jest atr - im większy tym lepiej.
To tylko propozycja, niech się może jeszcze raz wypowiedzą osoby, które wcześniej optowały za takimi a nie innymi gęstościami.
ekhem to moja wina :rolleyes:
Myślę, że ja już sobie na prawdziwym sprzęcie poradzę, Sikor, zrób tak aby było łatwiej dla wszystkich :)
Ostatnio edytowany przez lopez (2019-03-17 16:14:43)
ok - do następnej części zrobię dużego ATR-a, a każdy w razie potrzeby sobie wypakuje i przegra na mniejsze atr-y nawet pod emulatorem. Czekam na wrażenia i pytania do tej części ;)
Dopiero dzisiaj znalazłem chwilę czasu na tutorial i ponieważ po ostatnim odcinku dodałem sobie "dla ułatwienia" do kodu:
1 BLOAD "D:DANE.DAT"
to dzisiaj spędziłem trochę czasu szukając dlaczego mi nie działa po zrobieniu pliku *.COM ;)
Troszkę mylące to zapisywanie raz w HEX a raz w DEC :)
MOVE $95C0,DPEEK(88),1600
Mam prośbę czy możecie polecić jakąś książkę gdzie takie adresy (88...) są dokładniej to opisane?
No i czekam na kolejną część:)
Ostatnio edytowany przez lopez (2019-03-23 21:27:40)
Hej!
Z przyczyn zdrowotno-czasowych kolejny odcinek pewnie w przyszłym tygodniu. Co do adresów - póki co starczy Ci "Atari Basic" Miguta.
Teraz tak - Bload powinien Ci zadziałać po kompilacji i zrobieniu pliku, ale, jeśli łączysz plik w całość (jak jest w tutorialu) - to i tak dołączasz ten plik, więc jest to zbędna linia. Oczywiście te dane musisz mieć na dyskietce, a program po skompilowaniu jeszcze zlinkowany.
Jak dam radę (będę poza domem) - to dziś może wrzucę większego ATR-a, aby wszystko było w jednym miejscu - według sugestii.
Co do adresów DEC/HEX - łatwiej mi lokalizować wgrywając, ale... Wychodzą przyzwyczajenia z Atari Basica i niestety/stety część adresów pamiętam w DEC po prostu i łatwiej mi to pisać. Nic poza tym - ale zawsze można sobie przerobić, szczególnie ucząc się. Przepraszam za zamieszanie z tym, jeśli taka wola ludu - będę przerabiał na HEXy, aby wszystko było ok. Tak będzie lepiej?
Aha, i dzięki za odzew, bo już myślałem, że nikt z tego nie korzysta.
Hej Sikor, wczoraj złapałem się na tym, że stałem pod kioskiem ruchu jakbym czekał na Bajtka, a w nim Klan Atari :-) Rozpieściłeś nas a teraz cooooo...? :-) Zdrówka życzę!
Sikor, rób tak jak ci wygodniej, w sumie to i lepiej dla mnie jak muszę poszukać, więcej zostaje w głowie.
ps. właśnie nie miałem DANE.DAT na dyskietce dlatego nie działało :)
@lopez: sprawa wyjaśniona
@pancio.net - coś tam między odcinkami zrobię, ważne, że jest jakiś odzew, więc chce się robić. A że nie chcę tego po łebkach robić? Dlaego odpuściłęm terasz, za tydzień max kolejny odcinek, a może w tygodniu już ;)
Jak dam radę czasowo - wieczorem sklecęwiększego atr-a z aktualnymi danymi.
Sikor, tych trzech-czterech czytelników zawsze masz, a może więcej, którzy się nie przyznają:-) Ja chętnie czytam, nie testuję bo nie mam czasu, ale na razie wszystko to co podajesz odpalam sobie wirtualnie w głowie i wszystko mi działa:-) Trochę żartobliwie to piszę, ale na serio, analizuję sobie kod, przypominam sobie z rozrzewnieniem Basic z dzieciństwa, i chętnie odnoszę to do TBXL, którego bardzo żałuję, że nie znałem w tamtych latach, bo na pewno bym używał. W Basicu za dzieciaka robiłem bardzo dużo, aż okazało się, że gry takiej jak Robbo nie da się zrobić, wtedy próbowałem assemblera, ale za mały byłem, żeby skumać o co tam chodzi, nie miałem materiałów, nie miałem w otoczeniu żadnego guru, który wiedział by co to w ogóle jest assembler, no i poległem z programowaniem aż do czasów gdy robiłem później gry w assemblerze na pecetach. Dziś z perspektywy czasu patrząc, gdybym miał wtedy TBXL, to dziś pewnie był bym takim drugim Larkiem:-) hehehe:-) - bo jego wspomnienia jak czytam, to jakbym czytał swoje.
Tak że Sikor, pisz dalej, pisz, a nawet jeśli dziś nie będzie bardzo wielu czytelników, to myślę, że Twój tutorial na koniec można spokojnie zebrać w całość i zrobić z tego książkę choćby w pdf, a na pewno nie raz ludzie do tego jeszcze będą sięgać.
Edit: aha, nikomu się nie pali, więc rób ze spokojem wtedy kiedy masz czas i kiedy Ci się chce - tylko nie przerywaj i dokończ robotę:-)
Ostatnio edytowany przez Mq (2019-03-24 21:52:27)
Czas na kolejną rzecz...
Część trzecia i pół, czyli szukamy grafiki...
Miałem cichą nadzieję, że pojawi nam się jakiś grafik, ale skoro nie ma - musimy sami wziąć się do roboty. Czas na fabułę, ale ta się dopiero tworzy i będzie powstawać w trakcie. Dziś będziecie mieli... Pracę domową.
Dobrze, ustaliliśmy, że nasza gra będzie miała grafikę w rozdzielczości 80x80px - każde 8px to jeden bajt, 80px w linii to 10 bajtów, 80 linii - czyli 800 bajtów. Załóżmy, że potrzebujemy 10-ciu grafik (dziesięć lokalizacji), aby sprawę utrudnić - postanowiłęm, że gra będzie się toczyć na stacji kosmicznej. Postaram się przeprowadzić Was przez proces konwersji grafiki na przykładzie jednego obrazu i Gimpa.
Na początek wyszukujemy grafikę - pamiętamy, że nasz obrazek będzie maleńki,do tego jednokolorowy - więc nie przesadzajmy ze szczegółami, grafika powinna być w miarę czytelna. Cała akca będzie się toczyć we wnętrzu, więc czegoś takiego szukamy. Ja na tapetę wziąłem ten obrazek: http://application.denofgeek.com/images … Alien3.jpg - po kolei opiszę co i jak zrobiłem:
- prawy klawisz myszy i kopiuj obraz
- gimp=>plik=>utwórz=>ze schowka - i w tym momencie sprawdzam sobie rozdzielczość, wystarczy nam 72 dpi
- następnie sobie nieco powiększam obraz i kadruję to co potrzebuję, mniej więcej do kwadratu (teraz to nie jest jeszcze takie ważne) - ja to sobie wyciąłem (plik 1.jpg - gifa zapiszę dopiero jako wynik)
- podciągam sobie wartości, aby uwypuklić szczegóły (zazwyczaj wystarczy krzywa tonalna, czasem troszkę innej zabawy, wszystko zależy od obrazka)
- zmieniam tryb kolorów na szarości
- jeszcze deczko przekontrastowuję (2.jpg)
- skalujemy do zadanej wielkości (80x80px, lekka deformacja zazwyczaj nie szkodzi - 3.jpg)
- próbujemy przekonwertować do jednego koloru, można próbować zarówno z ditheringiem, jak i bez. Jeśli efekt jest w miarę zadowalający - przechodzimy dalej, jeśli nie - najpierw bawimy się dalej (barwienie, filtry, redukcja kolorów - różnie bywa). W moim przypadku zredukowałem kolory, zastosowałem trzy filtry (ostatni to film rysunkowy) i zrobiłem konwersję na tryb jednokolorowy z ditheringiem (5.jpg)
- ostatni, żmudny etap - to powiększenie rysunku i ręczne poprawki. Niestety, w większości grafik są niezbędne. Jak skończymy pracę - eksportujemy to do gif-a (p1.gif).
Oczywiście to co napisałem to duże uproszczenie. Świadomie nie podaję tutorialu w GIMP-ie (używam wersji 2.8 jakby co) - każdy może robić w czym innym, jeden woli Painta, inny ma Photo Shopa czy Photo Painta - narzędzie nie gra roli. Zasygnalizowałem tylko kierunek prac i opisałem jak ja to robię.
I teraz obiecana praca domowa - prośba do Was, aby przygotować 8-9 grafik pod naszą grę, na zasadzie - link do oryginału i wynik w GIFie. Chciałbym, abyście mieli to przetrenowane - na podstawie grafik postaram się napisać scenariusz gry. Proszę o nadawanie nazw px.gif - gdzie za x wstawiamy numer. Niestety, Atarowskie DOSy nie lubią nazw zaczynających się od cyfr. W tym tygodniu będę na Grawitacji, więc macie około tydzień czasu - w następnej części sobie to wszystko ułożymy na Atari, a w kolejnej kodujemy pierwsze rzeczy użytkowe...
PS: w załączeniu omawiana w tekście grafika
Ło pieronie... jestem pierwszy przy tablicy... postaram się coś wymodzić w tzw. międzyczasie w zakrzywionej czasoprzestrzeni... :-)
Aha, aby nie było - zamysł scenariusza mam w głowie, ale ponieważ chciałbym, aby coś w głowach po tutorialu zostało - zmodyfikuję co nieco na podstawie grafik od Was.
Moje wypociny, słabe, ale może się coś nada. Niestety grafikiem nigdy nie byłem i nie będę :)
ps. grafiki ściągnięte z google i przerobione, więc co do praw autorskich to nie mam pojęcia.
ale przydałby się jeszcze dołączony plik ;)
Faktycznie coś nie wyszło :)
nonono... Wykorzysta się ;)
Będzie chwila przerwy, bo zmarł mi brat i nie jestem w nastroju. Ale grafikę szykujcie.
Przyjmij wyrazy szczerego żalu i współczucia z tego powodu.
Strony Poprzednia 1 2 3 4 5 6 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 0.098 sekund, wykonano 8 zapytań ]