Niezalogowany (Zaloguj się)

Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

Vanilla 1.1.4 jest produktem Lussumo. Więcej informacji: Dokumentacja, Forum.

Portowanie mojego symulatora lotu na Atari

Od 1 do 37 z 37

- 1: CommentAuthorRoeoender
- CommentTime29 Dec 2023 21:12 zmieniony
Dzień dobry,
Kierowany podwójną nostalgią - do Atari 130XE, które mieliśmy z bratem od około 6 r.ż.
oraz do programowania z okresu studiów (około 2003 r.) w C/Asm na... kalkulator graficzny Casio Algebra FX 2
spróbowałem poznać jak takie "doroślejsze" niż BASIC programowanie wygląda na Atari.

W dawnych czasach na Atari największe emocje rozpalały we mnie symulatory lotu - Fighter Pilot, F15 Strike Eagle, Tomahawk,
stąd w 2003 na ww. kalkulator, na konkurs programistyczny stworzyłem kompletną grę/symulator "F-16 Falcon 2.0".
Odkopałem i zmontowałem trochę archiwalnych nagrań przedstawiających tą grę działającą na kalkulatorze -

Kierowany kolejną porcją nostalgii do obecnej próby reimplementacji mojej gry na małe Atari wybrałem MAD Pascala - Borland Pascala używałem dużo w czasach liceum.

MAD Pascal jest na prawdę wspaniały - dzięki bogatej bibliotece i przykładom ułatwia szybkie wdrożenie się.
Wręcz trudno mi uwierzyć, że aż tak dobrze to działa.
Np. stosuję dyrektywy BASICOFF i ROMOFF - trochę dziwię się, że pomimo tego nadal mogę używać funkcji bibliotecznych typu InitGraph, Writeln itp.
Stąd prośba, testowałem na emulatorach - Altirze i Atari 800, niestety nie mam sprawnego rzeczywistego Atari,
więc czy mógłby ktoś sprawdzić czy załączona, bardzo wczesna, ale już trochę funkcjonująca wersja (da się polatać) działa na prawdziwym sprzęcie?
- f_16_falcon_0_1.xex
- 2:
  
  CommentAuthorpancio
- CommentTime29 Dec 2023 21:12 zmieniony
odpalić się odpaliło.. ale nie umiem latać :-) a pomysł super!

edit.

Już umiem latać! strasznie mi to przypomina Mercenary... zapowiada się super gierka :-)

bez problemu odpalil sie pod SDX, na Atari 800XL
- 3:
  
  CommentAuthorKaz
- CommentTime29 Dec 2023 22:12
Ha! Nareszcie! Od wielu lat wspominam, że jednym z typów gier, której żaden Polak na Atari nie zrobił, jest symulator lotu i że może ktoś by się w końcu podjął! A tu proszę - taaaaaaka niespodzianka! Dzięki Roeoender, ogromnie trzymam kciuki za rozwój projektu i jeśli tylko będę mógł coś pomóc to śmiało pisz.

Testy na real Atari też u siebie zrobię. Nawet na kilku różnych modelach.
- 4: CommentAuthorZenon
- CommentTime29 Dec 2023 22:12
Jak to było.... polski lotnik, jak trzeba, poleci na drzwiach od stodoły...
Koniec roku a pomysły sypią się jak piasek w klepsydrze. Co jeszcze ludziki wygrzebią, pozostały dwa dni. Nie ma to i tamto, to musi być skończone. Swego czasu też latałem, na Atari oczywiście. Jedna z pierwszych gier to STEALTH, potem do oporu THE LAST STARFIGHTER.
- 5:
  
  CommentAuthorPeri Noid
- CommentTime29 Dec 2023 22:12
Pozwoliłem sobie nagrać małą próbkę odpaloną na Atari z Rapidusem.

Domyślam się, że dopałka nie była planowana ale i tak fajnie to wygląda - trochę zbyt responsywnie nawet, rzekłbym. Bardzo fajny projekt, oby tak dalej!
- 6: CommentAuthorKonstantyn
- CommentTime29 Dec 2023 22:12
Fajna klimatyczna muzyczka, coś a`la "W starym kinie". :-) Może dałoby się zaimplementować do gierki? ;-)
- 7: CommentAuthorpin
- CommentTime30 Dec 2023 00:12
w przyszłości o ile taka zaistnieje, to jak by to było synchronizowane do ramki i generowało tyle fps ile wyrobi Atari to by przynajmniej na dopałkach CPU było zajebiście, bo teraz to na dopałce demo jest zdecydowanie zbyt szybkie. @Peri Noid - daj wszystkie banki na "fast" i odpal to ;)
- 8: CommentAuthorRoeoender
- CommentTime30 Dec 2023 13:12
Wow dziękuję za szybki i pozytywny odzew.

Możliwość, dzięki Wam weryfikacji, że to działa na prawdziwym sprzęcie naprawdę dużo dla mnie znaczy,
bo pozwala potwierdzić, że emulatory nie zwabiły mnie w jakieś maliny,
z których potem trudno by się było wygrzebać.

Sam jestem zdziwiony, że przez te wszystkie lata, o ile mi wiadomo,
nikt nie pokusił się o stworzenie czegoś grywalnego z prawdziwym wireframe 3D.

Dla mnie w tamtych czasach Tomahawk i F-15 (oraz oszałamiający "Behind Jaggi Lines" bo taką wersję miałem)
były absolutnie genialne (nawet wówczas nie wiedziałem, że był na Atari też Flight simulator),
ale niedawno jak zobaczyłem na YT przegląd symulatorów na C64 to szczęka mi opadła.
Stealth Fighter to właściwie wierny port F-19 z Peceta,
a Chuck Yeager AFT miał nawet wypełnianą polygonową grafikę.

Pokazuje to wyraźnie, że na małym Atari jest "ziejąca" nisza, która nie została jakoś nigdy wypełniona,
a przecież z powodu wolniejszego CPU ww. gry na C64 były właściwie turowe, na Atari pewnie chodziłyby lepiej.
Może kiedyś jakiś uzdolniony porter gier jak np. p. Mariusz Wojcieszek (w końcu zrobił już port 3D - Total Eclipse)
przeportują, któryś z topowych symulatorów z C64 - przynajmniej w zakresie lotu 3D.
Widziałem W.I.P. portu Elite'a - szkoda, że temat niedokończony.

Niemniej na razie zrobię co mogę by mój kod zaadoptować, przynajmniej do stanu podstawowej grywalności.
Duże obawy mam względem pamięci - zaraz po zrobieniu 3D i podstawowego modelu lotu już raz mi się skończyła,
potem była długa faza przerabiania z "eleganckiego pascala" na takiego mniej pamięciożernego,
teraz trochę więcej nadziei dało włączenie ROMOFF, ale bez kolejnych czasochłonnych optymalizacji się nie obejdzie.

W najbliższym czasie planuję zrobić przynajmeniej podstawowe strzelanie, a potem pewnie jakieś obrywanie.

Faktycznie widzę z filmiku Peri Noid, że strasznie mruga ale takie tematy będę robił stosunkowo późno,
bo niekoniecznie jestem przekonany, że pozostanę przy obecnym trybie graficznym i sposobie rysowania.

Odnośnie muzyki - na razie bardzo oszczędam pamięć stąd coś więcej poza odgłosami byłoby robione też raczej na końcu,
na razie w tle po prostu proponuję sobie puścić Danger Zone, oczywiście z kasety z decka Technicsa. ;)

Ten Rapidus to jakiś demon szybkości :)
Generalnie celuję w poczciwe "gołe" Atari,
ale sam jestem ciekaw jak sobie poradzi z bardziej obciążającą wersją -
w załączniku przesyłam zupełnie niesymulatorową wersję - ze swobodnie (6DOF) przesuwaną kamerą ('Drone cam')
na ekranie tytułowym jest opisana klawiszologia.
W tej wersji na raz jest obsługiwanych 7 obiektów 3D z dosyć dalekim trybem renderowania.

Oczywiście cieszę się ze wszystkich nagrań - jakby, ktoś zrobił takie ujęcie,
że faktycznie widać na nim F-16 Falcona lub załączoną wersję Drone na Atari na telewizorze/monitorze
z prawdziwym joystickiem to byłaby dla mnie podróż prawdziwie sentymentalna 30+ lat wstecz :).
- falcon_dronecam_0_1_1.xex
- 9:
  
  CommentAuthorPeri Noid
- CommentTime30 Dec 2023 14:12
Na Rapidusie mruga bo nie synchronizujesz się z ramką i przy czyszczeniu czasami najwyraźniej Rapidus robi to zbyt szybko. Ale to nieistotne, najważniejsze jest to, że w ogóle robi i wyświetla. Pocieszę cię, że podobnie zachowuje się Mercenary i Solo Flight. Za to najgenialniej do Rapidusa dopasowuje się Rescue on Fractalus (Behind Jaggi Lines). I, zdaje się, The Eidolon (tego nie próbowałem). Zerknij na moje filmiki, nagrałem to i owo.

Owszem, Rapidus to nisza. Ale miło by było, gdybyś tak to zrobił, żeby na dopałce to się skalowało. Bazowy sprzęt to wiadomo, podstawa. Natomiast rozszerzona pamięć teraz jest na tyle pospolity dodatkiem, że myślę, że spokojnie możesz celować w 128K (jeśli nie 320K). Zawsze to sporo więcej miejsca na assety.
- 10: CommentAuthortebe
- CommentTime30 Dec 2023 15:12 zmieniony
ambitny projekt, gratuluję :)

oprócz ROMOFF, pamięć można zyskać obniżając początkowy adres ładowania, który domyślnie jest ustawiony na $2000

najniżej można zejść do ok. $980 (-code:980), ładować plik przez XBOOT, albo FoxDOS

przenosząc kod z Borland Pascala, należy pamiętać że tam typ INTEGER był 16bit, w MP i FPC typ INTEGER to już 32bit, więc należy dokonać poprawki (BORLAND LONGINT -> INTEGER; BORLAND INTEGER -> SMALLINT)

pilnowanie typów, jeśli jest taka możliwość schodzić do typów bez znaku, jak najmniejszego rozmiaru

przyspieszyć rysowanie linii na pewno przyspieszy FASTGRAPH, mnożenie 8x8bit, 16x16bit przyspieszy FASTMUL ($f page), który można też umieścić pod ROM, oczywiście wszystkie przyspieszenia kosztem pamięci
- 11:
  
  CommentAuthorjhusak
- CommentTime30 Dec 2023 15:12
Leć w grafikę 7, 160x96, szybka do rysowania w pionie a i pamięci mniej. Możesz też w 2 kolory, wtedy jest jeszcze szybciej. Można optymalizować linie prawie pionowe i prawie poziome.
- 12: CommentAuthorRoeoender
- CommentTime30 Dec 2023 19:12
@tebe - ambitny projekt to Twój MAD Pascal - naprawdę czapki z głów za Twoje wieloletnie jego rozwijanie (przeczytałem cały, 34 stronicowy wątek na atariage i potem jeszcze ten z przykładami :) ) i danie masy przykładów w dystrybucji, chyba nie ma bardziej produktywnego i zapraszającego do kodowania środowiska dla Atari.

Trochę się spodziewałem, że po wyłączeniu ROMU będę musiał używać bibliotek zamienników Bocianu - typu CRT_text itp a tu na razie jak widać wszystko działa.

Co do typów - to tak jestem świadom, portuję z Watcom C (jak robiłem ten symulator na kalkulator w 2003 to przesiałem się na niego z Boland C 3.1 bo Watcom okazał się szybszy i potrafił dużo bardziej agresywnie obcinać nieużywany kod z biblioteki standardowej co okazało się zbawienne by wszystko pomieścić).
Dzięki za hinta z obniżeniem adresu startu - faktycznie jak znowu trafię na limit to będzie deska ratunku.

Fastgrapha używam od początku i z pomiarów rysowanie linii jest na tyle szybkie, że na razie nie jest priorytetem w optymalizacjach.
Typy w samym silniku 3d już optymalizowałem i faktycznie odkrycie FASTmula było decydujące by dać wiarę, że jednak da się z tego zrobić coś szybszego niż pokaz sladjów, tak że FASTMUL już dawno siedzi pod ROMem, tak jak stablicowane sinusy, arcusy i sporo globalów (szkoda że nie da się prosto podać definicji tablicy pod absolutnym adresem i jej od razu zainicjalizować - aczkolwiek poradziłem sobie stosując resource'y RCASM tak że jest wystarczająco elegancko).

Próbowałem też dostosować liczenie perspektywy tak by użyć stablicowanego dzielenia w zakresie 0-255 i faktycznie przyspieszyło to, ale kod miał jakiegoś buga i jednak potrzebuję większych wartości niż 255 - na razie nie chcę grzęznąć w detalach tak że wróciłem do zwykłego diva - priorytetem jest na razie portowanie funkcjonalności tak by osiągnąć grywalność. Przedwczesna optymalizacja itd - wiadomo.

Przerobienie zmiennych na globale zamiast przekazywania argumentami do procedur i ograniczanie pointerów też wygląda, że znacznie przyczyniło się do odchudzenia generowango kodu asm.
W samym asmie na razie zrobiłem właściwie tylko przesuwanie integera o dokładnie 8 bitów bo się dało szybciej.

@jhusak na razie celowo nie wiążę się z żadnym trybem graficznym - stosuję po prostu Pascalowe line (z moim "frontedem" przycinania wystających poza ekran współrzędnych) i putpixel - InitGraph(6) - czyli 2 kolorowy "mode B" w 80 liniach reszta tekstowa - po implementacji najistotniejszych funkcjonalności dla grywalności, zależnie od ilości pozostałej pamięci i CPU wybiorę rozmiar pola widoku 3d i stosowany tryb. Fajnie by mieć kolory, ale tryb 7 przy stronicowaniu (też nie jest powiedziane że będzie inaczej) żre za dużo pamięci CPU.
- 13: CommentAuthortebe
- CommentTime30 Dec 2023 21:12 zmieniony
ClipLine(x1,y1,x2,y2);

rysuje linie z przycięciem, okno definiują zmienne WIN_LEFT, WIN_RIGHT, WIN_TOP, WIN_BOTTOM (są one ustawiane na domyślne wartości podczas InitGraph)

ClipLine zamiast Line używa fLine (fast line)
- 14: CommentAuthorCharlieChaplin
- CommentTime31 Dec 2023 01:12
quote:

najniżej można zejść do ok. $980 (-code:980), ładować plik przez XBOOT, albo FoxDOS

/quote

... or uDOS by Stefan Dorndorf (memlo $0938).

->link<-

available for download with german and english instructions.
- 15: CommentAuthorRoeoender
- CommentTime31 Jan 2024 19:01 zmieniony
Dzień dobry,
Dla zainteresowanych trochę update'u na temat progresu projektu, trochę pytań i notatek.

Wybrałem tryb 7 160x64 an obszar 3D, czyli 4 kolory, ze stronicowaniem
jedną ze stron video po prostu umieściłem poniżej standardowego adresu ładowania $2000 minus rozmiar ekranu czyli $1600 beztrosko nadpisując cokolwiek by tam było,
z czasem może zejdę jeszcze niżej (na razie jak zapycham pamięć to robię etap optymalizacji pod kątem rozmiaru z dobrym skutkiem).
oraz 8 wierszy tekstowych na kokpit z przyrządami MFD, radar itp.

Mam już zaimplementowane (poza tym co już było widać):
* lockowanie celów naziemnych
* pociski niekierowane
* pociski kierowane powietrze-ziemia
(w sumie wygląda na to, że większość symulatorów pod tym względem dość oszukuje i tylko pokazuje proste animacje na duszkach - u mnie pocisk na prawdę leci i zmienia trajektorię do celu,
co prawda "po psiej krzywej" :) ale o ile pamiętam to wystarczało)
* czołgi mogą się stopniowo poruszać - może będą misje typu zniszczyć zanim dotrą do X.
* prosty radar celów naziemnych widoczny w kokpicie
* skalowana mapa
* dynamiczny mechanizm selekcji pobliskich obiektów - misja może zdefiniować 40 obiektów 3D (jak na koniec zostanie pamięci to może będzie więcej), a w czasie lotu co jakiś czas alogrytm na "short listę" przepisuje wskaźniki 16 będących w pobliżu samolotu.

Oczywiście do zaimplementowania zostało jeszcze sporo podstawowych rzeczy:
* Wrogie samoloty i ich pociski
* Wrogie AAA
* Decoye
* Detekcja samolotu przez radary i odpalanie pocisków ziemia-powietrze
* Może jak CPU pozwoli - bomby (CCIP)
* Generator misji

PYTANIE:
1. Ze względu na limit ~64Kb dla kodu chcę, tak samo jak to zrobiłem na kalkulatorze grę podzielić na dwa programy
W MAIN.XEX użytkownik dostałby logo MAD Pascala :), obrazki, wybrałby/wygenerował sobie misję, uzbrojenie, przejrzał mapę - wybory te zostałyby albo zapisane do pliku, albo umieszczone gdzieś w RAM gdzie nie zostanie to zczyszczone (tak bym wolał)
i MAIN.XEX odpalałby drugi program FLIGHT.XEX, który implementowałby symulator lotu korzystający z ww. zainicjalizowanych danych,
na koniec lotu FLIGHT.XEX oczywiście by też zainicjalizował jakieś podsumowujące lot dane i z powrotem odpalił MAIN.XEX.
Zrobiłem przymiarkę i pięknie to mi zadziałało z XBIOS-em, jak dla mnie XBIOS tutaj idelanie pasuje bo daje mi kilka dodatkowych kilobajtów RAM i daje też API xBIOS_LOAD_FILE realizujące uruchomienie programu.
Pytanie do specjalistów czy da się to zrobić jeszcze prościej? (zaznaczam kluczowe jest uzyskanie jak największej ilości dostępnej RAM, kosztem niskich adresów i możliwość uruchomienia programu z programu).

Trochę z "pamiętnika developera":
Generalnie pisze mi się wspaniale w MAD Pascalu + blibs, to jest zupełnie nowa jakość w porównaniu z tym przez co musieli przechodzić koderzy w "tamtych" czasach.
Od razu dostaje się szybką funkcję rysowania linii, szybką matematykę, wyłąćzenie ROM-u próg wejścia został obniżony bardzo nisko - chwała!

1. O ile pamiętam to Initgraph w fastgraph stosuje systemową inicjalizację trybu z display listą z adresem ekranu typu $bxxx co mi nie pasowało bo tam też chciałem mieć kod dlatego zrobiłem własną wersję,
która po prostu inicjalizuje display listę wg moich ustawień, bez odwołań do systemu, natomiast wielkim zaskoczeniem było dla mnie, że otrzymywałem po prostu czarny ekran.
Po kilku dniach walki okazało się, że gdy w resources.rc zasób wskazuje na adres pod ROM to DMA jest po cichu wyłączane, w pliku .lst widać:
```
mva #0 sdmctl
    sta dmactl
```
i już nie włączane z powrotem - wystarczyło zrobić:
```
lda #$22
    sta sdmctl
```
i zadziałało - niestety nigdzie nie znalazłem opisu tego dość zaskakującego zachowania - chyba przydałby się opis tego zachowania w dokumentacji.

2. Nie wiem czy w MAD Pascalu da się jakoś porozkładać kod na segmenty? - np. by część kodu była od $2000, a część od $f000,
jako obejścię tej kwestii robię tak, że wszystko co nie jest kodem upycham jak najwyżej pod ROMEM-em i robię to dość agresywnie - np. dość skanibalizowałem bibliotekę fastgraph,
bo zauważyłem tam bardzo duże tablice pomocnicze rysowania linii:
```
color_bits: array [0..$3ff] of byte;
	lineLo, lineHi, div4: array [0..255] of byte;
```
zmieniłem je tak by były pod konfigurowalnymi absolutnymi adresami (oczywiście pod ROMem),
ponieważ korzystam też tylko z trybu 7 poupraszczałem też kod obcinająć trochę bajtów tu i tam.

3. Nie wiem czy w MAD Pascalu jest jakiś mechanizm wymuszania by jakaś tablica była zaraz po innej tablicy lub po prostu pod następnym wolnym adresem po wskazanym adresie
(znowu chodzi o umieszczanie zmiennych wysoko w pamięci),
obchodzę to w mało elegancki sposób:
```
g_fighter_conn_tab : array[0..2*FIGHTER_CONN_AMT-1] of Byte  absolute 
	three_d_models_address
	+ 3 * RenderCoordTypeSIZE * RUNWAY_VERT_AMT 	+ 2 * RUNWAY_CONN_AMT
	+ 3 * RenderCoordTypeSIZE * GRND_EXPL_VERT_AMT	+ 2 * GRND_EXPL_CONN_AMT
	+ 3 * RenderCoordTypeSIZE * TANK_VERT_AMT		+ 2 * TANK_CONN_AMT
	+ 3 * RenderCoordTypeSIZE * FIGHTER_VERT_AMT;
```
Czyli de facto na piechotę liczę gdzie wypada następny wolny adres.

4. O ile pamiętam ClipLine dziwnie działał gdy cała linia była poza zakresem SetClipRect - zamiast nic rysować rysowała 1 piksel - dlatego używam swojej wersji, która de facto stosuje ten sam algorytm.
Teraz jak już stosuję "skanibalizowaną" fastgraph to już i tak nie istotne.

5. Czy jest jakiś limit na liczbę "uses"? Projekt obecnie składa się z 22 plików pas i ostatnio mam problem nawet z dodaniem "uses b_crt" - kompilacja zgłasza randomowe miejsce gdzieś w bibliotece standardowej, np.:
```
D:\dev\atari\tools\Mad-Pascal-1.6.9\jlibs\system_atari.inc (237,4) Error: Syntax error, '.' expected but ';' found
```
6. Trochę brakuje jednocześnie możliwości podania adresu tablicy i jej inicjalizacji, coś w stylu CRT_keycode: array [0..255] of char absolute $f000 = (...) obchodzę to stosując resources.rc z rcasm.

7. Widzę, że b_crt też "beztrosko" rezerwuje sobie tablicę 256 znaków CRT_keycode bez możliwości podania adresu - możliwe że też skanibalizuję. :)

Jeszcze raz podkreślam MAD Pascal jest fantastyczny i powyższe to tylko opis sposobów jak sobie radzę z ew. pytaniem czy da się to robić lepiej a nie jakieś uwagi.
- 16:
  
  CommentAuthorKaz
- CommentTime31 Jan 2024 19:01 zmieniony
Fantastycznie! A szukając informacji o psiej krzywej dla samolotów, żeby się dowiedzieć więcej, jak to jest zrobione, znalazłem ciekawy materiał:

PS. Pozwoliłem sobie dodać u Ciebie znaczniki [ code ] i [ /code ] co pozwala wyróżnić fragmenty programu i zwiększa czytelność.
- 17:
  
  CommentAuthoramarok
- CommentTime31 Jan 2024 20:01
@Roeoender, rewelacja! Gratuluję pomysłu i chęci napisania symulatora lotu na małe Atari.

Cieszę się, że wybrałeś MadPascala - witaj w klubie :).

Sam wiem jaką to daje łatwość w tworzeniu oprogramowania. Zwłaszcza prototypowanie jest bardzo szybkie. Czasem trzeba przejrzeć plik lst i ręcznie optymalizować kod, ale nie jest to kłopotliwe. Czasem trzeba również napisać coś w assemblerze, ale bardzo ładnie komponuje się to z głównym kodem. MadPascal rządzi :)

Ad1. Podział na poszczególne programy jest dobry tym bardziej jeśli chcesz, żeby gra działała na komputerze z 64kB RAM. Myślę, że czas oczekiwania na przeładowanie nie powinien być problemem jeśli nie będzie to występowało zbyt często.

Ad2. Możliwość podziału kodu czy zmiennych na segmenty byłoby wspaniałą sprawą. Co jakiś czas pojawia się ten temat na forum i myślę, że warto o tym rozmawiać. Może wspólnie namówimy tebe do wprowadzenia takiej zmiany. Osobiście bardzo też tego potrzebuję :D

Ad3. W kwestii dokładnego ułożenia danych też miewam podobny problem i sobie radzę w taki sam sposób jak Ty.

Ad5. Ja już jakiś czas temu zrezygnowałem z używania wielu plików pas i zamiast nich używam plików inc. Przykładowo w moim ostatnim projekcie, grze platformowej, są 44 takie pliki i jeden główny plik pas z listą dyrektyw dołączających fragmenty kodu. Wcześniej zauważyłem, że jak miałem zmienne w plikach pas, które były używane wielokrotnie (drzewiasta struktura użyć plików pas) to takie zmienne były zwielokrotniane. Pewnie była to jakaś starsza wersja kompilatora albo ja coś robiłem nieprawidłowo. Tak czy inaczej pozostaję przy plikach inc a kolejność dyrektyw {$I} pozwala mi zgrubnie określić ułożenie kodu w pamięci co się czasem przydaje.

Ad6. Robię dokładnie tak samo ja Ty czyli przez ładowanie zasobów.

Trzymam kciuki za realizację projektu i życzę wytrwałości oraz motywacji do zakończenia projektu.
- 18: CommentAuthortebe
- CommentTime1 Feb 2024 01:02 zmieniony
obecna wersja MP to 1.7.1, w pliku CHANGELOG są informacje o zmianach

limit modułów UNITS ustawiony jest na 256

uwagę bardziej należy zwrócić na tokens (unlimited), idents (limit 16384), blocks (limit 16384), types (limit 1024)

65 lines compiled, 2.06 sec, 18397 tokens, 1180 idents, 203 blocks, 7 types

przykład użycia 24 modułów

->link<-
- 19: CommentAuthorRoeoender
- CommentTime1 Feb 2024 10:02
@Kaz dziękuję, podejrzałem jak się to tu robi i będę formatował.

@amorak dziękuję za przeczytanie mojej przydługiej wiadomości i potwierdzenie, że te rozwiązania mają sens, a nie że gdzieś błądzę - wielkie dzięki!

@tebe ściągnąłem 1.7.1 i mam ten sam błąd - niestety wygląda na to, że jednak trafiam na jakiś limit w uses (może wielokrotne uses z różnych unitów i ich zależności się naliczają?).

Robię coś takiego, stan początkowy który działa ok, w jednym z podunitów:
```
implementation
	uses
		global_vars,
		globals, 
		three_d_render,
		math_sim;
```
Ta wersja loguje:
```
280 lines compiled, 17.69 sec, 33427 tokens, 2550 idents, 361 blocks, 14 types
```
dodaję do listy b_crt (nota bene ten b_crt jest już pomyślnie użyty w innych podunitach więc o ile rozumiem tu nie powinno to wpłynąć na limit tokenów):
```
implementation
	uses
		global_vars,
		globals, 
		three_d_render,
		math_sim,
		b_crt;
```
Efekt:
```
Mad Pascal Compiler version 1.7.1 [2024/01/30] for 6502
Compiling falcon.pas
D:\dev\atari\tools\Mad-Pascal-1.6.9\lib\system_atari.inc (237,4) Error: Syntax error, '.' expected but ';' found
```
Ale teraz z listy usuwam np. "math_sim," a zostawiam b_crt:
```
implementation
	uses
		global_vars,
		globals, 
		three_d_render,
		b_crt;
		// math_sim;
```
i program się kompiluje poprawnie (oczywiście musiałem zakomentować kilka użyć funkcji z math_sim, ale to nie ma znaczenia).
Taki eksperyment robiłem już kilka razy zawsze z takim skutkiem, że musiałem usunąć jakieś uses by dodać inny - zaczałęm stopniowo po prostu łączyć unity w większe - dzięki czemu pozbywałem się jednego uses i mogłęm dodać nowy, ale wolałbym dążyć dokładnie w drugą stronę - mieć dużo małych skoncentrowanych na jednym tasku unitów.
- 20: CommentAuthortebe
- CommentTime1 Feb 2024 10:02
podeślij przykład takiego programu jeśli możesz, to ułatwi znalezienie błędu
- 21: CommentAuthorRoeoender
- CommentTime1 Feb 2024 15:02
Ok w załączniku falcon_uses_diag20240201.zip - bardzo ogołociłem projekt z treści i nadal problem występuje - pozostawiłem oryginalny zakres uses w poszczególnych plikach, include'y itp.
Kompilacja za pomocą compile_debug.bat.
Powinien wystąpić błąd:
```
Mad Pascal Compiler version 1.7.1 [2024/01/30] for 6502
Compiling falcon.pas
D:\dev\atari\tools\Mad-Pascal-1.6.9\lib\system_atari.inc (237,4) Error: Syntax error, '.' expected but ';' found
```
Natomiast po zmianie w definitions.pas - usunięciu użycia b_crt w linii 14 powinno spowodować, że projekt się kompiluje.

Dziękuję za diagnozowanie problemu.
- falcon_uses_diag20240201.zip
- 22: CommentAuthortebe
- CommentTime1 Feb 2024 18:02 zmieniony
pobieżnie sprawdziłem, rzeczywiście wyszedł poza zakres tablicy w której sprawdzał powiązane moduły, 256 to za mało

okazuje się że do tablicy z modułami ładuje też wszystkie includy

p.s.
nowa, poprawiona wersja MP na githubie
- 23: CommentAuthorRoeoender
- CommentTime1 Feb 2024 19:02
Super, na nowej wersji działa też pełny projekt. Drobna zmiana, a ma wielki wpływ na możliwość lepszego podziału kodu na moduły.
Dziękuję za szybkie rozwiązanie.
- 24: CommentAuthorRoeoender
- CommentTime29 Jun 2024 23:06
Długo nic tutaj nie pisałem, co nie oznacza, że projekt się nie rozwijał,
wręcz przeciwnie z zacięciem godnym lepszej sprawy, prawie codziennie zarywając noce rozwijam ten projekt dalej.

Właściwie to nazwa wątku jest już nieaktualna, ponieważ nie jest to już dawno żadne portowanie tylko stworzenie nowego symulatora,
w pełni dostosowanego do specyfiki, możliwości i ograniczeń małego Atari.

Tu podziękowania dla wszystkich zwłaszcza polskojęzycznych twórców retro filmików na youtube - zwłaszcza wielogodzinnych wywiadów/wspomnień
- oczywiście "AtariOnline PL" (zwłaszcza cykl "spowiedź autora"), "Atari Retro Fan", "Loading...", "Retro Impressions", "Szafa z grami" i wiele innych. Nocne kodowanie, słuchając tych wszystkich historii z lat naszej "młodszej młodości" było fantastycznym doświadczeniem.

Gra pod względem funkcjonalności już jest właściwie napisana, wszystko co dało się zmieścić już jest (chwała ograniczeniom bo można by rozbudowywać w nieskończoność), teraz jest jeszcze proces polerki, dopieszczania grafik, dostosowywania poziomu trudności i finalizowania projektów misji.

Zastanawiałem się czy robić generator randomowych misji, ale stwierdziłem że istotne jest poczucie "przejścia gry" (będzie obrazek finałowy) i zdecydowałem się na stworzenie kampanii predefiniowanych, ręcznie zaprojektowanych, około 10-15 misji, z mikrofabułą
składających się na kampanię dziejącą się na granicy Polsko - Królewieckiej.
Generalnie nie chciałem wchodzić w obecne, smutne realia wojny Rosyjsko - Ukraińskiej,
więc trochę śladami Strike Commandera historia dzieje się w nieodległej przyszłości z trochę "dowymyśloną",
ale celowo raczej mało prawdopodobną wizją przyszłej sytuacji geopolitycznej.

Jedna być może kontrowersyjna decyzja jaką podjąłem, jest taka, że nie będę robił kolorwania ziemi na zielono i nieba na niebiesko,
tak jak jest to np. w Fighter Pilot/F-15 Strike Eagle/Tomahawk, pozostałem przy czarnym tle i wireframe jak np. w arcade'owym Battlezone (podobnie jak już jest w załączonych wcześniej demkach).
Po prostu latając testowo misje stwierdziłem, że w ogóle tego nie postrzegam jako braku, bo bardziej skupiam się na rozwijającej się sytuacji na polu walki, czarny dodaje też mrocznej powagi sytuacji, można po prostu sobie przyjąć, że misje toczą się w nocy.
A dzięki temu zaoszczędziłem sporo bajtów na inne funkcjonalności/mechaniki i być może ciut FPS-ów.
No i nie oszukujmy się jeśli ktoś chce dobrej grafiki, to wystarczy odpalić Microsoft Flight Simulator 2020, Falcon BMS lub DCS na PC - zwłaszcza w VR - polecam :).
Dla mnie istotna była przede wszystkim grywalność - współczesne symulatory często swym realizmem stanowią za wysoki próg wejścia -
nie ma chyba obecnie dobrego odpowiednika symulatorów Microprose typu F-15,F-19,F-117 które bardzo dobrze balansowały realizm z grywalnością.
Z kolei dawne Atarowskie symulatory miały bardzo kulawy model lotu/sterowanie (Tomahawk był szczytnym wyjątkiem, ale to akurat symulator śmigłowca), nie przekonywały mnie pociskami i wybuchami 2D robionymi na spritach - u mnie wszystkie pociski, a nawet działko latają w 3D, przeciwnicy nie pojawiają się znikąd tylko startują z lotnisk itp.
A może jeszcze kiedyś ktoś udowodni, że da się zrobić i szybszy i ładniejszy symulator. :)

Zaskakująco dużo czasu zajęło mi zrobienie części "naziemnej" tj. ekranów opcji uzbrajania/briefingów/debriefingów itp wyświetlanych przed i po starcie.
Zrezygnowałem z robienia wersji "na kasety", dzięki czemu mogłem wykorzystać wszystkie zalety stacji dysków (doczytywanie) i 130Kb miejsca - podzieliłem program na 3 XEX-y i skorzystałem z dobrodziejstw XBIOS-a w celu przechodzenia między nimi, zapisywania stanu kampanii i doczytywania skompresowanych obrazków i muzyki.
Wielkie dzięki dla xxl(!) za to oprogramowanie, bo dzięki prostemu API bardzo ułatwia bezproblemowe zaimplementowanie tych funkcjonalności i jeszcze pozwala odzyskać sporo pamięci.
Na upartego pewnie handlarze na giełdzie mogliby zrippować stan gry zaraz po rozpoczęciu danej misji i tak sprzedawać każdą z tych -nastu misji osobno na kasetach :)

Gra będzie miała muzykę tylko na ekranach naziemnych ("poważne symulatory nie grają muzyczek w locie" ;) albo "dla prawdziwego pilota najlepszą muzyką jest dźwięk dopalacza i odpalanych rakiet" ;) ).
Jeszcze parę miesięcy temu, dzięki fantastycznym bibliotekom MAD Pascala, w 5 minut po prostu dodałem CMC player,
przesłuchałem kilkaset utworów z SAP Archive w celu wyszukania czegoś co by w miarę pasowało i developersko wybrałem jeden utwór tak by mi testowo grał i miejsce na muzykę w RAM-ie rezerwował.
I po wielu miesiącach słuchania ciągle jednego i tego samego... tak już mi ten utwór się zlał w jedność z symulatorem, że już z innym utworem go sobie nie wyobrażam.
Jak się na szczęście okazało autorem utworu okazał się sam Jakub Husak, po drugie szczęśliwie okazało się, że utwór miał dawno temu trafić do pewnej gry, ale jakoś tak wyszło, że w końcu gra została wydana bez niego.
Napisałem do Jakuba i hurra! Zgodził się na jego użycie - jeszcze raz dziękuję! Na razie nie będę zdradzał, o który utwór chodzi. :) Jakby co klawiszem Option można wyłączyć muzykę.

Jeszcze przede mną do rozwiązania jeden z dwóch najpoważniejszych problemów informatyki - na szczęście nie muszę inwalidować cache'y zatem do rozwiązania mam tylko drugi problem - problem nazewnictwa - a dokładniej nazwania samej gry.

Pierwotna nazwa to "F-16 Falcon".
Ma tę wadę, że jest bardzo generyczna i zbyt podobna do istniejących (co prawda na innych platformach, ale jednak) symulatorów.
Na Atari ST jest "Falcon", który wyewoluował w bardzo znanego na PC Falcon 3.0 i do dziś rozwijanego Falcon 4 BMS.
Nie chcę by gra była traktowana jako jakiś remake, bo jednak jest moim autorskim symulatorem z własnym modelem lotu, logiką "pola walki"
i ficzerami inspirowanymi całą listą różnych symulatorów z lat 80/90.
Myślałem, by nazwać z polska "F-16 Jastrząb", nawet zrobiłem już taki wariant ekranu tytułowego w Rasta Converterze,
ale taka nazwa mogłaby wprowadzać w błąd i sugerować, że jest polskojęzyczna, a to (jak na razie) nie prawda - wszystko po angielsku.
Nie chciałbym tytułem zmylić obcokrajowców, no i nadal to nazwa bardzo generyczna.

"F-16 Night falcon"? pasowałoby do czarnego tła, ale ekran tytułowy mam już fajny dzienny i nie chcę narzucać interpretacji nocnej.

"F-16 Viper Strike"?
"F-16 FREEDOM FALCON"?
"F-16 RAID OVER KRÓLEWIEC" - fajne nawiązanie, ale mogłoby sugerować, że to shooter a nie symulator, no i za długa, może jako podtytuł.
"F-16 Semper Optimi" - tu ciekawostka bo "Semper Optimi - Zawsze Najlepsi" to motto 31 Bazy Lotnictwa Taktycznego Poznań-Krzesiny, czyli jednej z baz polskich F-16.
Niestety sam mam problem tą nazwę zapamiętać :) I nie wiem czy do końca mógłbym wykorzystać to motto jako nazwę, jasne mógłbym się skontaktować z bazą, ale obawiam się, że słysząc o "symulatorze" mogliby się czuć troszkę jednak zawiedzeni po tym co by zobaczyli :)
Może ktoś ma jakiś pomysł (czata GPT już przesłuchałem)? Nazwa musi być krótka bo mi się na ekranie tytułowym nie zmieści i koniecznie "F-16" na początku.

Do testów w końcu kupiłem sobie używany Atari 130XE, ale już po zakupie okazało się, że ma on oba rodzaje błędów GTIA :( -
szkoda bo już wcześniej do prezentacji obrazków w części naziemnej zacząłem używać trybu GTIA 10 (piksele 4x1, 9 kolorów).
Tu do opracowania grafiki bardzo przydał się Atari Graphics Studio by TeBe/Madteam.
Pierwotnie myślałem by do upikęszenia symulatora obrazkami użyć Rasta Convertera ale okazało się, że nawet przy kompresji te obrazki są po prostu zbyt ogromne.
Dlatego w rasta jest tylko ekran tytułowy.
Duża szkoda bo jest wiele pięknych zdjęć naszych polskich F-16, które można by pewnie zaadaptować.
By poczuć klimat polecam pooglądać trochę filmików na YT o polskich F-ach - np.

albo z facebooka 31. Bazy - ->link<-

Nie wiem jak wy, ale ja jak oglądam takie sceny, jeszcze z naszą polską szachownicą na statecznikach, to przechodzą mnie ciary.

W załączniku przesyłam przykładową pozostałość z prób z RastaConverterem.

Muszę jeszcze rozkminić jak z XBIOSem zrobić wyświetlanie progresu podczas wczytywania XEX-a, bo są wielgachne, więc się długo wczytują,
a obecnie pojawia się brzydki tekstowy ekran a'la basic, ale jeszcze po prostu się za to nie zabrałem.

I mam też jakiś sporadyczny bardzo drobny glitch w doublebufferingu obrazu czasami podczas naciskania klawiatury - zapewnie chodzi o sprzętowe IRQ, muszę o tym też więcej poczytać.

A no i planuję zgłosić symulatorek na ABBUCA - przynajmniej będzie deadline :).
Obraz ATR buduję z opcjami dir2atr.exe -m -E -B xboot.obx mam nadzieję, że spełni to ich wymagania regulaminowe, bo fizycznej stacji dysków nie mam, tylko sdrive mini Lotharka.

Zastanawiam się czy w ogóle powstał kiedykolwiek *polski* symulator lotu na małe lub duże Atari, albo szerzej na jakiejkolwiek platformie
oraz kiedy powstał ostatni symulator lotu na małe atari? Trochę się dziwię, że przez te wszystkie lata raczej nic nowego nie powstało, widziałem tylko konwersję kodu FS1 bodajże z Apple'a, ale to nie to samo co napisana od zera gra.
- f16_taking_off_afterburner.xex
- 25: CommentAuthortebe
- CommentTime30 Jun 2024 12:06 zmieniony
nie znam żadnego tytułu symulatora z polskimi programistami

co do IRQ, to wyłącz je
```
lda #0
  sta $10		; irq disable
  sta irqen
```
p.s.
W FASTGRAPH najszybsza procka rysująca linię to fLine
- 26:
  
  CommentAuthorJacques
- CommentTime30 Jun 2024 14:06 zmieniony
Może F-16 Hawky Falcon?
Nawiązywałoby to do nazwania naszych sokołów "jastrzębiami", brzmi dość dźwięcznie i podobnie do F-16 Fighting Falcon.
Co do braku zieleni i niebieskiego nieba to jednak moim zdaniem degradacja, takie czarno-białe szkielety zawsze kojarzyły mi się ze starszą generacją symulatorów, trochę szkoda, bo to Atari z dobrą paletą, a nie ZX Spectrum. Opcja wyboru kolorystyki byłaby bajką :-)
- 27: CommentAuthorilmenit
- CommentTime1 Jul 2024 08:07
Świetny projekt, symulatorów lotu na A8 mało, a tym bardziej mało dobrych.
Odnośnie rysowania linii tu był wątek na AtariAge: ->link<-
Ciekawa optymalizacja rysowania "flicker free" była dodana do gry Elite. Tam dla szybkości nie ma podwójnego buforowania, ale linie są usuwane rysowaniem ich ponownie czarnym kolorem. Optymalizacja polega na zmianie kolejności rysowania i kasowania linii: ->link<-
- 28:
  
  CommentAuthorPecus
- CommentTime1 Jul 2024 15:07
Fajne. U mnie na altirze (mój standardowy konfig odpowiadający sprzętowi, który posiadam) wywala się po spacji na obrazku tytułowym.

Znając życie super kompatydebilny ze wszystkim xBios :)
- 29: CommentAuthorRoeoender
- CommentTime1 Jul 2024 15:07
@tebe tak po wyłączeniu IRQ nie ma glitchy, będę tylko jeszcze musiał zaimplementować własne czytanie klawiatury, ale są na ten temat materiały.

@tebe - tak najpierw sam próbowałem zaadaptować jakąś prockę z różnych topiców, ale potem zorientowałem się, że w Twoim MAD Pascalu jako fLine już jest właśnie ta procka, którą chciałem zaadaptować :)
Naprawdę szacunek za takie dopracowanie bibliotek.
Na ekranie "About" w grze w szczególności uwzględniam też tego oryginalnego autora algorytmu (Eru):
```
Tools used:
MAD-Pascal by TeBe/Madteam
library line drawing by Eru/TQA&TeBe
MAD-Assembler by TeBe/Madteam
Atari Graphics Studio by TeBe/Madteam
MAD Studio by Gury
Rasta Converter by ilmenit
xBIOS by xxl
BLIBS by Bocianu
Altirra by Avery Lee
```
@Jaques

Ciekawy pomysł z tym Sokołem Jastrzębim, ale niestety nie skradł mego serca. :) Szukam dalej.

Co do grafiki - bynajmniej nie będzie czarno-biała czy monochromatyczna - wręcz przeciwnie - wybuchy będą czerwone, lecące pociski będą mrugać na szaro-czerwono, samoloty i niektóre budynki szare, góry i lasy zielone, itp.
HUD też jak przystało jest wyświetlany na zielono więc by się zlewał z zieloną ziemią.
Temat nie-kolorwania ziemi/nieba jest dla mnie na teraz raczej zamknięty przynajmniej do czasu domknięcia wszystkich innych istotnych dla publikacji na ABBUC-a kwestii.
Nie mam już wolnego RAM-u - gdy się teraz okazuje, że jeszcze muszę coś dodać by obsłużyć jakiś corner-case to by uzyskać tylko kilkanaście bajtów na jednego if-a spędzam kilka godzin, zazwyczaj ubrzydzając kod pascalowy - nie chcę tego więcej robić.
Wiem, że nawet jakbym dodał kolorowanie nieba/ziemi to zaraz i tak by ludzie narzekali, że gra jest niegrywalna bo za wolno działa.
Ponad miesiąc na początku spędzałem na optymalizowaniu 3D i w pewnym momencie trzeba powiedzieć dość, starczy i pójść z tematami do przodu, już i tak chyba w świecie Atari mamy za dużo wspaniałych ale niepokończonych projektów gier (osobiście czekam na Laser Squad i Elite).

@ilmenit
Tak jak napisałem wyżej do TeBe - zapoznawałem się z różnymi algorytmami m.in z tamtego forum,
a potem się okazało że Tebe zaadoptował bardzo dobry (z prekomputacją) algorytm Eru tak, że go z drobnymi modyfikacjami stosuję.
Z pomiarów wynika, że obecnie to nie prędkość rysowania linii ma znaczenie tylko obracanie dalekoodległych punktów
(jak się rysuje np. górę to jedne jej punkty są blisko a inne bardzo daleko). Ale obecnie freeze na zmiany w 3D.

Co do Elite to autor tego repo co wskazałeś zrobił szczegółową dezasemblację z opisami i zrobił całą stronkę z artykułami tłumaczącymi wszystkie algorytmy i mechaniki w tym 3D - bardzo polecam wszystkim - może kogośzainspiruje do napisania własnej gry 3D ->link<-

Jest też seria filmików bazująca na tych tłumaczeniach kodu -

Czytałem to wszystko, ale mój "silniczek 3D" powstał dużo wcześniej niż te dezasemblacje bo w 2004 roku i to go teraz zaadaptowałem, bo przynajmniej swoje rozumiem :)
Zapewne da się go ulepszać, ale tak jak napisałem wyżej - na razie stop z optymalizacjami 3D.
Tym bardziej, że ten "sprytny" mechanizm rysowania linii w Elite wykorzystuje właśnie fakt, że tłem jest zawsze czarna przestrzeń, a linie białe - dzięki czemu XOR-ując może łatwo wymazywać po śladzie linie pobierane ze stosu.
A to by mi prawdopodobnie zablokowało zarówno kolorowe linie jak i ew. rysowanie nieba/ziemi w przyszłosći bez mrugania.
Nota bene o tym, że ich algorytm da się przerobić tak by PRAWIE nie mrugał skapnęli się dopiero po wydaniu pierwszej wersji - tak że pierwsze wersje na Acornie i Spectrumie bardzo mrugały :), jak widać chociażby tutaj

Pierwotnym ich celem było przede wszystkim zmniejszenie ilości pamięci zjadanej przez podwójne buforowanie.

Wynik i feedback po ABBUC da mi też jako taki pogląd, w jakim stopniu rozwijanie tego jest dla "community" fajne/istotne.
Jeśli nie spodoba się to po prostu będę robił tylko to co będę uważał za "fun" w tym projekcie,
a nie sądzę bym miał ciśnienie by z 4 FPS uzyskać 5 FPS jeśli prawie nikogo to nie będzie interesowało
- jestem bardziej zorientowany na "gameplay" niż algorytmikę - np. bardziej "fun" byłoby dla mnie zrobienie generatora randomowych misji,
bo przynajmniej dla mnie replay value by był większy (trudno dać się zaskoczyć misją, którą się samemu zaprojektowało ;) ).

@Pecus tamto "tech demo" jest bardzo archaiczne, wszelkie błędy i zawieszenia są zapewne moją winą i być może w obecnej wersji już ich nie ma (testuję na real 130XE (Ale starczy 64Kb) z SDrive micro).
- 30: CommentAuthorCharlieChaplin
- CommentTime3 Jul 2024 18:07 zmieniony
new name: F16 F(l)ight Simulator
alternative name: F16 Fighter Pilot 2024
(unofficial training program for ukrainian fighter jet pilots)
sponsored by Atari 8Bit Computers

option: day mission / night mission
select: 1) practice: take off and landing
2) practice: flying at very low height and between cityscapes (street canyons)
3) practice: aiming at and hitting different moving/non-moving targets (trains, tanks, drones, fighter jets, artillery, etc.)
4) mission: attack tanks, trains and artillery
5) mission: fend off drones
6) mission: air fights against MIG and SU jets

... and don't use Lenslok system !
- 31: CommentAuthorRoeoender
- CommentTime3 Aug 2024 11:08
Po wielu godzinach strawionych na wyborze nazwy w końcu wybrałem "F-16 Falcon Strike" - nazwa nawiązuje, ale nie bezpośrednio do klasycznego F-15 Strike Eagle czy Strike Commander, ma w sobie Falcon, jeszcze nie występuje w google, więc łatwo będzie mi wyszukać gdzie ktoś coś o niej pisze, a skrót FS brzmi jak flight simulator więc jest wystarczająco ok. :)

Pod koniec developmentu nie dość, że nie miałem za bardzo miejsca w RAM to coraz częściej trafiałem też na ABBUCowy limit rozmiaru dyskietki (130kb) - stąd dodałem kompresję obrazków i muzyki za pomocą Lz4 (znowu gotowce od xxl i Mad Pascala się bardzo przydały), potem dodałem jeszcze dość prymitywną kompresję tekstów briefingów 4 znaki zapisywane na 3 bajtach + tokenizacja kilku najczęściej powtarzających się wyrazów: "ENEMY", "AIRBASE", "DESTROY" itp :)

Duuużo więcej czasu niż pierwotnie sobie oszacowałem zajęło zaprojektowanie, przetestowanie i jako takie zbalansowanie tych 15 misji w kampanii, zwłaszcza, że settingiem "ENEMY AMOUNT" gracz może wybrać poziom trudności każdej misji (Strategicznie rozlokowani dodatkowi przeciwnicy). Właściwie 2 miesiące to głównie robienie i oblatywanie misji, a tylko w międzyczasie jakieś zmiany w ficzerach gry.

Zostało kilka dni do terminu ABBUCA i jeszcze 3 misje do doszlifowania i stwierdziłem, że mimo wszystko muszę jeszcze spróbować ile faktycznie z resztki FPS-ów które zostały zjadłoby rysowanie zielonej ziemi i niebieskiego nieba - podszedłem do algorytmu najprościej jak to możliwe - linię horyzontu już miałem przecież namalowaną więc tylko od górnego końca horyzontu do dolnego końca drugiej strony horyzontu "fillować" bajty na zielono z końcowym bajtem dostosowanym do faktycznej pozycji piksela w bajcie (1 bajt to 4 piksele) i wypełnienie reszty poniżej lub powyżej horyzontu (zależnie czy lot normalny czy odwrócony) zielonym + zmiana koloru tła z czarnego na niebieski + oczywiście kilka wariantów zależnie od orientacji samolotu, zakomentowałem kod rysowania kokpitu by to się w RAM zmieściło i... w sumie działało dość szybko - strata jakoś 0,6 FPS (co przy FPS-ach na poziomie 2-7 powiedzmy nie jest wcale mało ale też nie jest zauważalnie dużo). Tak, że faktycznie chciałem ten ficzer mieć - tylko jak uzyskać sporo więcej RAM-u - po długich poszukiwaniach zdecydowałem się na pozbycie się korzystania z funkcji fastdiv bo jak się okazało nie używam jej do czegoś wyraźnie FPS-owożernego, a funkcja ta linkowana z fdiv.obx widocznie stosowała jeszcze jakieś dodatkowe tablicowanie (ponad to z FASTMUL), tak że rezygnacja zwolniła ogromną ilość kilkuset (może nawet pod kilobajt) bajtów co pozwoliło zmieścić wypełnianie ziemi i jeszcze zostawić sporo bajtów. Uff!

Natomiast okazało się oczywiście że inne części gry słabo komponują się zielonym tłem - np. zielony HUD albo maskowanie części kokpitu czarnymi spritami - tak, że sporo rzeczy musiałem pozmieniać. Dodatkowo niebieskie niebo/tło powodowało brzydką ramkę wokół ekranu - tu nie wiem jak się z tym profesjonalnie radzi więc zrobiłem najprościej - na DLI zmieniam kolor w poziomie z czarnego na niebieski i potem od kokpitu ponownie na czarny, a ramkę po lewej i prawej stronie maskuję czarnymi spritami :) I tu się okazała pierwsza różnica między Altirrą i prawdziwym ATARI bo przynajmniej na moim telewizorze te sprity musiały być bardzo szerokie by coś niebieskiego jednak na krawędziach niewystawało, a na Altirze wystarczyłby szeroki missile.
Dodałem jeszcze prosty ficzer - że im leci się wyżej tym niebo ma ciemniejszy odcień niebieskiego ale też dodatkowo im jest się wyżej tym zielony ziemi staje się bladziej bladawy - co znacznie pomaga ocenić kiedy się przywali w ziemię :)

2 dni przed terminem ABBUCA będąc w połowie lotu jednej z ostatnich już misji nagle zniknęły wszystkie obiekty 3D - mimo, że ileś razy już na tej samej wersji leciałem i nic nie znikało... WTF? Na szczęście stało się to na Altirze więc mogłęm zachować stan gry i potem zabawa z analizą assemblera co jest przyczyną. Po paru sesjach okazało się, że w pewnym miejscu zrobiłem optymalizację sprawdzania odległości punktów na mapie z 3d na 2d ale kod porównywania został przywrócony z innych powodów by porównywał wymiary 3d przez co niezainicjalizowana była wartość Y i to powodowało błąd. Uff.

Tak, żę 31 lipca wysłałem finalną wersję mojej gry na konkurs ABBUC. Jak widzę z poprzedniej edycji minie sporo czasu zanim gra zostanie upubliczniona członkom ABBUC, ale za jakiś czas myślę, że nagram na YT filmik angielskojęzyczny instruktażowy "jak w to się gra". Na razie sobie odpocznę od kodu i zależnie od przyjęcia na ABBUC może w przyszłości coś dalej będę rozwijał.

Była to niewątpliwie niezła przygoda i przede wszystkim dziękuję TeBe za wspaniałe narzędzia bez których na pewno nie szarpnąłbym się na to przedsięwzięcie i Jakubowi Husakowi za udostępnienie muzyki.
- 32:
  
  CommentAuthorpirx
- CommentTime3 Aug 2024 17:08
szacun! jak juz wygrasz to dostepnij zrodelka to sie przyspieszy :))))
- 33: CommentAuthorCharlieChaplin
- CommentTime3 Aug 2024 18:08 zmieniony
Already playtested your game (since I am creating the Abbuc magazine diskettes). There is only one problem: I did never fly a real plane and do not know how to do this. So I also do not know how to do this in almost all flight simulators, including the ones for the A8. I am only good in crashing a plane (or helicopter, like e.g. in Thomahawk) very fast.

Hopefully I am the only one with this problem, because otherwise I fear that besides a lot of work went into this A8 program, it will not score high. (I can say the same to Doom/W3D, I never played any of these or similar games on the PC or other computers and thus it is no surprise that I am not good when playing them on the A8.)

Anyways, good luck with your program and thanks a lot for taking part in the Abbuc Software Contest !!
- 34: CommentAuthorRoeoender
- CommentTime4 Aug 2024 16:08
Cześć, dzięki za informacje.
Cóż, jestem świadomy, że symulatory lotu nie są najbardziej mainstreamowym gatunkiem gier.
Ale w realizacji tego projektu nie kierowałem się chęcią wygranej (wówczas pewnie planowałbym jakąś nie zatrudną, kolorową platformówkę :) ).
Chciałem trochę spłacić dług wdzięczności wobec 3 symulatorów na Atari: Fighter pilot, F-15 Strike Eagle i Tomahawk
bo granie w nie w wieku około 8 lat, jak teraz o tym z nostalgią myślę, mocno zaważyło na moim dalszym życiu -
rozwinęły moje zaintereswanie komupterami i programowaniem dzięki czemu mam do dziś pasjonującą pracę oraz rozpaliło drugą wielką pasję - do lotnictw,a którą mogłem po wielu latach zrealizować jako pilot szybowcowy.
Stąd chciałem się odwdzięczyć robiąc na Atari jeszcze jeden, mam nadzieję dobry, symulator wojskowego myśliwca na małe Atari,
jeśli ta gra wciągnęłaby kogoś w lotniczą pasję choćby tylko na komputerach byłoby mi bardzo miło :)

Co do grania w symulatory - myślę, że jest duża różnica między osobami, które po prostu nie mają ochoty grać w symulatory lotu,
od osób które tylko myślą że są one dla nich za trudne/ich nie rozumieją i stąd często się rozbijają i zniechęcają.
Dla tych pierwszych oczywiście nie ma ratunku :) Ale dla tych drugich jak najbardziej myślę, że mój symulatorek byłby dobrym startem.
Celowo wprowadziłem wiele ułatwiających gameplay decyzji by uprzyjemnić naukę nowicjuszom - np. mapa prezentuje informacje o wszystkich celach/wrogach w pobliżu gracza - w rzeczywistości piloci mogą śledzić przeważnie tylko cele w dość wąskim stożku przed samolotem (trochę tak jakby świecili latarką), mapa pokazuje też pozycję wszystkich pocisków i praktycznie nie ma w grze losowości tak, że da się wiele rzeczy przewidzieć - stąd gra się staje bardziej strategiczna/taktyczna i zawsze wiadomo co się zrobiło źle - by to poprawić w następnym locie. Dodatkowo za pomocą "difficulty settings" można sobie znacząco ograniczyć skalę niebezpieczeństw, tak że realizację misji można sprowadzić wówczas do postępowania wg kilku prostych do nauczenia reguł. Choćby lądowanie - zmora nowicjuszy - staje się bardzo schematyczne/proste gdy się zna/chce się poznać odpowiednią procedurę - budowania kręgu nadlotniskowego - w samolocie gdy podejście nie idzie dobrze zawsze można odejść na drugi krąg (o ile jeszcze ma się paliwo:) ) - w szybowcach nie mamy tego luksusu :)

Myślę, że dla tych co się przełamią i zechcą się nauczyć - symulatory lotu w stylu tych z lat 80/90 mogą być świetnym wprowadzeniem - dużo więcej w nich taktyki niż żmudnego wkuwania obsługiwania skomplikowanych systemów pokładowych jak to jest we spółczesnych "symulatorach kokpitu" jak niektórzy nazywają słynny DCS. :)

Myślę, że najlepszym rozwiązaniem (któe dla nas w młodości nie było dostępne) będzie jak nagram trochę instruktażowych filmików na YT - bo grę testowałem na 14-latku i o ile na początku miał duży problem by cokolwiek zrobić to po kilku minutach instruktażu już był w stanie bezpiecznie lądować na poziomie HARD i niszczyć cele naziemne :).

W klubie mieliśmy 60letnich uczniów szybownictwa, tak że dla chcących na naukę nigdy nie jest za późno. :)

Czy możesz podać kiedy mniej więcej gra będzie udostępniana klubowiczom, tak bym wiedział ile mniej więcej czasu mam na przygotowanie filmików?
- 35:
  
  CommentAuthorpirx
- CommentTime4 Aug 2024 20:08
no tak, największy problem to może być z obsługą, nikt nie będzie czytał instrukcji...
co gorsza może też nie obejrzeć filmiku :(
nie ma już na to czasu i miejsca, ale taki wbudowany tutorial level by mógł pomóc -
"press this to start engine"
"press that for full throttle"
"press something to retract landing gear"
"PULL UP PULL UP"
"press other to lock target"
"jesteś na ścieżce i na kursie"
"odchodzimy na drugi krąg"
"słychać strzały"

itp.
- 36: CommentAuthorRoeoender
- CommentTime4 Aug 2024 22:08
Trochę to przewidziałem, bo w grę wbudowany jest help z pełną klawiszologią, jest kilka misji treningowych by poćwiczyć lądowanie i w spokoju atakowanie celów, konkursowe ograniczenie dyskietki do 130kb nie pozwala jednak na prowadzenie za rączkę gracza (a kilkudyskietkowa wersja by tylko wprowadzała zamieszanie) - od tego też lepszy jest YT by użytkownik nie musiał czytać napisów tylko sobie pooglądał i posłuchał. W help i about jest też link do strony z pełną instrukcją gdzie dodam linki lub osadzę filmiki.
- 37:
  
  CommentAuthorpirx
- CommentTime5 Aug 2024 14:08
:thumbsup:

Od 1 do 37 z 37