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

• Zapomniane hasło?
• Poproś o członkostwo

1. • 1: CommentAuthortbxx
   • CommentTime16 Dec 2025 11:15

    
   Platforma testowa: Atari 800XL + SUB-CART
   
   1. Gra nie ogarnęła tematu, gdy pokonałem przeciwnika przy jednoczesnym końcu czasu (efekt na video)
   2. Gra zawiesza się (czarny ekran) po obrazku "smash the car"

   • sf2subcart.mp4
2. • 2: CommentAuthortebe
   • CommentTime16 Dec 2025 11:38

    
   czy to wina beta wersji firmware SubCart-a? trzeba spróbować zreplikować taką sytuację w wersji bez SUBCart-a
3. • 3: CommentAuthorzbyti
   • CommentTime16 Dec 2025 11:57 zmieniony

    
   @tbxx problem pojawił się parokrotnie (w paru wairantach) podczas moich testów i wydawał się ostatecznie przez Vegę pokonany, być może jest jeszcze jakiś warunek brzegowy.
4. • 4: CommentAuthortbxx
   • CommentTime16 Dec 2025 12:08

    
   Po dalszych testach - wcześniej miałem podpięty komplet "rozszerzeń" do SUB-CART - PBI, DAC i SIO, po odpięciu wszystkiego gra się już nie zawiesza przy "smash the car". Później spróbuję inne kombinację "dodatków".
5. • 5: CommentAuthorvega1
   • CommentTime16 Dec 2025 12:26 zmieniony

    
   Gra była testowana na emulatorach ALTIRRA, ATARI800 oraz na oryginalnym sprzęcie z kartridżem XCART 2.0...wszystko działało..nie było zgłoszeń żadnych problemów
6. • 6: CommentAuthorAzdul
   • CommentTime16 Dec 2025 12:34

    
   Z moim Atari 600 XL + Ultimate 1 MB + SUB-CART działa po odpięciu SUB-CART-a od PBI i SIO.
   
   Z tym nowym firmware SUB-CART-a chyba coś jest nie tak - bo cart Tony też zaczął mieć problemy.
7. • 7: CommentAuthornosty
   • CommentTime16 Dec 2025 13:12

    
   Bardzo chętnie przeczytałbym artykuł, lub wywiad z autorem na temat działania AI i kolizji w grze. Chyba, że Vega woli to zachować jako "tajemnicę zawodową", to oczywiście rozumiem i nie nalegam.
8. • 8: CommentAuthortebe
   • CommentTime16 Dec 2025 13:19

    
   Pavros kiedyś odpowiadał na podobne pytanie, ogólnie jeśli dległość pomiędzy klatką zawodnika i przeciwnika jest w zadanym zakresie wówczas testujemy hit-point-y dla danej klatki animacji
9. • 9: CommentAuthorvega1
   • CommentTime16 Dec 2025 13:31

    
   @nosty nie jest tajemnica ale te rozwiązania są dość prymitywne więc nie ma się czym chwalić zbytnio ;p Aczkolwiek działa mi to w miarę dobrze.
10. • 10: CommentAuthortbxx
    • CommentTime16 Dec 2025 15:03

     
    1. Podpięcie kabla SIO (SUB-CART) nie zawiesza "smash the car", problem występuje przy podpięciu PBI
    2. skoro nie da się przyspieszyć gry, dało by się może spowolnić zegar? powiedzmy o 1.5x - jak dla mnie zbyt wiele pojedynków kończy się przez "time out"
11. • 11:
       
      CommentAuthorPeri Noid
    • CommentTime16 Dec 2025 15:17

     
    Ja obstaję przy swoim - animacja skoków jest skopana, ma za dużo klatek. Powinno się pominąć co drugą pozycję na ekranie w fazie lotu, gra by natychmiast odzyskała (lub uzyskała) wigor, którego teraz nie ma.
    
    Grafika boska.
12. • 12: CommentAuthortbxx
    • CommentTime16 Dec 2025 15:47

     
    Mam Sub-Cart dopiero od tygodnia i nie do końca ogarniam obsługę tego wynalazku :/
    Znalazłem przyczynę zawieszania się gry przy podłączonym PBI - wystarczy w menu wyłączyć Memory Expansion (PORT B)
13. • 13: CommentAuthortebe
    • CommentTime16 Dec 2025 16:44

     
    w VBXE też możesz użyć pamięci VBXE jako PORTB, no ale jeśli jednocześnie uruchomisz produkcję korzystająca z PORTB i będziesz używał grafiki VBXE to będzie konflikt
14. • 14:
       
      CommentAuthorJacques
    • CommentTime16 Dec 2025 17:55 zmieniony

     
    Nie no, rdzeń VBXE z EXT-RAM występuje w obu wersjach (FX i GTIA). Serio jest jakiś problem z FX w wersji R?
15. • 15: CommentAuthortebe
    • CommentTime16 Dec 2025 18:34

     
    chodzi o to że jeśli będziesz miał RamDysk który korzysta z PORTB na VBXE a potem wczytasz jakiś obrazek (*.BMP) do pamięci VBXE aby go wyświetlić to uszkodzisz RamDysk PORTB na VBXE, oba te typy
    pamięci razem nie mogą współistnieć bez ryzyka konfliktu
16. • 16:
       
      CommentAuthorgienekp
    • CommentTime16 Dec 2025 18:54

     
    Zapytam z ciekawości bo w sumie to nie wiem. PORTB wstaje po resecie $FF. Jak jest 64kB to nie ma za bardzo wyjścia i bit 3/4 nie mają znaczenia. Ale jak jest atari130xe to wybiera bank 4?
    To co jest jeżeli taki SUB czy inny wynalazek emuluje pamięć, to po uruchomieniu ATARI zakres $4000-$7FFF idzie na dzień dobry z rozszerzenia?
17. • 17: CommentAuthorvega1
    • CommentTime16 Dec 2025 19:11

     
    @tbxx
    "skoro nie da się przyspieszyć gry, dało by się może spowolnić zegar? powiedzmy o 1.5x - jak dla mnie zbyt wiele pojedynków kończy się przez "time out" "
    
    zapisałem...jeżeli powstanie wersja z poprawkami za jakiś czas to mogę to zrobić...to tylko jeden rozkaz do zmiany :)
18. • 18: CommentAuthorAzdul
    • CommentTime16 Dec 2025 19:45 zmieniony

     
    >>Mam Sub-Cart dopiero od tygodnia i nie do końca ogarniam obsługę tego wynalazku :/
    >>Znalazłem przyczynę zawieszania się gry przy podłączonym PBI - wystarczy w menu wyłączyć Memory Expansion (PORT B)
    
    Potwierdzam, z grą wszystko jest OK. Trzeba tylko wyłączyć Memory Expansion przed próbą uruchomienia carta SF2 - i można zostawić podłączone SIO i PBI. Okazuje się, że ja też nie ogarniam Sub-Carta ;-).
19. • 19: CommentAuthorCharlieChaplin
    • CommentTime16 Dec 2025 21:57

     
    Strange, I have 512k XRAM enabled and Axlon disabled in the Subcart and SF2 works.
    (PBI, SIO and DAC cables are all connected.)
20. • 20: CommentAuthortbxx
    • CommentTime16 Dec 2025 22:01

     
    Właśnie robiłem test dla tmp i na 512KB działa dopiero na 1MB się zawiesza
21. • 21: CommentAuthoriSiek
    • CommentTime16 Dec 2025 22:31

     
    To samo jest z Bubble Bobble :) zatem raczej koderski feature a nie bug!
22. • 22: CommentAuthorzbyti
    • CommentTime16 Dec 2025 22:40

     
    wy się cieszcie, że lustrzane rejestry nie poszły w ruch byście mogli zagrać tylko na legitnym Atari :D
23. • 23:
       
      CommentAuthorJacques
    • CommentTime16 Dec 2025 23:11

     
    Na Rapidusie polecam ustawić tylko #1 na Fast read i dodatkowo WŁĄCZYĆ waitstates.
    Gra ładnie przyspiesza, ale jeszcze nie jak szalona i daje się przyjemnie grać i kontrolować :-) Czasem tylko pojawia się krótkie miganie tła, ale to pikuś przy grywalności.
24. • 24: CommentAuthorvega1
    • CommentTime17 Dec 2025 08:46 zmieniony

     
    @Jacques a to miga na każdej planszy? każda plansza ma osobne procedury przerwań DLI....może gdzieś "STA WSYNC" pominąłem...
    
    ps1
    gdyby udało się upchać dane klatek w miejszej przestrzeni to mógłbym rozpisać chociaż klatki jak wojownicy skaczą i znacznie ten element gry przyśpieszyć (bo to chyba najwolniejsze jest):
    
    zamiast:
    lda (data_bak),y \ ora (data_ora),y \ and (data_and),y \ sta (data_scr),y+
    
    byłoby:
    lda (data_bak),y \ ora #$xx \ and #$xx \ sta (data_scr),y+
    
    dodatkowo jeżeli mamy bajt $00, który nie musimy rysować to można dać tylko:
    iny
    
    2 cykle to już naprawdę szybko :)
25. • 25:
       
      CommentAuthorJacques
    • CommentTime17 Dec 2025 09:07

     
    @vega1
    Musiałbym jeszcze sprawdzić na których miga, ale raczej na więcej niż jednej, a czy na każdej - okaże się ;-)
26. • 26: CommentAuthortebe
    • CommentTime17 Dec 2025 10:29

     
    ja piszę program dla PC, który wciąga klatki i tworzy zoptymalizowany kod ASM lda (),y / and # / ora # / sta (),y
    
    taki program reaguje też na sytuację gdy mamy 'and #$00' lub 'and #$ff' i odpowiednio zmienia ASM
    
    podobne podejście jest w demie Ilusia dla Twistera, każdy kąt obrotu to rozpisany kod w ASM, podajesz tylko adres tekstury
    
    scrolle DYPP (Different Y Pixel Position), falujący scroll w Hires, zmieniający pozycję Y co piksel, tworzysz bitmapę z kształem 320x... następnie program analizuje kolumna po kolumnie (kolory Y0..Y1 reprezentują pozycję Y fonta) i tworzy kod ASM uzwględniając powtarzanie pikseli, powstaje gotowy program który udało mi się zmieścić w 20 tys cykli (1 ramka PAL)
    
    Shanti77 w swoim silniku multiplexowanych duchów też w ten sposób to realizuje, ma rozpisane w ASM klatki animacji spritów
27. • 27: CommentAuthorvega1
    • CommentTime17 Dec 2025 10:39 zmieniony

     
    @tebe jakbyś mógł udostępnić? to nie będę musiał tego w PASCAL-u pisać na PC :) zawsze szybciej :)
    
    edit...program na PC już napisany :) ma szansę to działać
28. • 28: CommentAuthortebe
    • CommentTime20 Dec 2025 19:16

     
    ->link<-
    
    przykład jest dołączony do silnika Shanti (mic2shp)
29. • 29: CommentAuthorvega1
    • CommentTime20 Dec 2025 20:21

     
    dzięki tebe :) ..w sumie sam ogarnąłem
    
    rozpisałem klatkę skoku zangief-a...fajnie przyśpieszyło..jest tak jak byc powinno 2x szybciej
    
    niestety zużycie pamięci też x2 :( a pamięci nie ma...
    
    czyli da się 2x przyśpieszyć skakanie w SF2 dla dużych postaci ale brak pamięci....
30. • 30: CommentAuthortebe
    • CommentTime20 Dec 2025 20:41 zmieniony

     
    doświadczenie level up :)
    
    zawsze można zrobić cart 8MB ;)
    
    gdyby to nie był cart tylko RAM, można trzymać spakowane/rozpisane dane klatek i dekompresować w wyznaczony obszar banków, w końcu nie potrzebujemy wszystkich postaci naraz, są tylko max 2 na ekranie
31. • 31: CommentAuthorvega1
    • CommentTime21 Dec 2025 08:48

     
    udało się przyśpieszyć rysowanie a dodatkowo nowe klatki zajmują już jakoś 1,5x więcej pamięci...ale już nie 2x...czyli nie jest już źle.
    
    mam pomysł jak zrobić 1=1 dla nowych klatek odnośnie pamięci...aczkolwiek rysowanie spowolni trochę...ale i tak powinno być szybciej niż kiedyś....wyjdzie w trakcie testów
32. • 32:
       
      CommentAuthorgienekp
    • CommentTime21 Dec 2025 13:18 zmieniony

     
    A te rozpi(a)sane kody to nie można jakoś "uwspólnić"? Chyba, że każdy to totalny unikat.
    
    W sumie to nikt chyba nigdy nie projektował carta ROM+RAM.
33. • 33: CommentAuthortbxx
    • CommentTime21 Dec 2025 13:45

     
    A Prince of Persia z carta nie wymaga czasem 128KB RAM?
    btw... Sub Cart przy pliku CAR 4MB pozwala jeszcze na włączenie 576KB RAM...
34. • 34: CommentAuthortebe
    • CommentTime21 Dec 2025 13:47

     
    klatki teoretycznie można skrócić jeśli mają wspólne elementy, np. tułów się zmienia, a nogi mają stałą sekwencję
    
    niekiedy stosuje się dekompresję RLE dla klatek spritów
    ->link<-
    
    ale mam wątpliwości czy dla tak szybkiej gry RLE da jakąś korzyść a nie spowolni tylko bardziej
35. • 35: CommentAuthortebe
    • CommentTime21 Dec 2025 13:49

     
    W sumie to nikt chyba nigdy nie projektował carta ROM+RAM.

    
    
    a nie było tak z Bomb Jack od GR8
36. • 36:
       
      CommentAuthorgienekp
    • CommentTime21 Dec 2025 14:05

     
    No bo tak na logikę, skoro cart się rozrasta bo trzeba ROMowo procki na wszystkie kombinacje zrobić to zabrać ROM i w to miejsce dać RAM.
    Powiedzmy, cart ma 512kB flasha i 512kB RAM. To co w cześci flash to w zasadzie spakowane data, a to co w RAM to już sama rozgrywka.
    Przy takim założeniu to jakby naturalnie jedna gra robi się od razu w wersji ATR+rozszerzenieRAM i stock+cart. Czyli jak ktoś ma rozszerzone ATARI to w zasadzie może pracować na ATR. A jak masz stocka to pakuj carta.
    Tu i tu bank 16kB. Co prawda w innych adresach, ale przy rozpakowywaniu. to kwestia ewentualnie dodania offsetów.
37. • 37: CommentAuthorCharlieChaplin
    • CommentTime21 Dec 2025 14:05

     
    Bomb Jack and Yie Ar Kung fu by GR8.
    (Afair 512k ROM + 512k RAM, therefore very expensive back then.)
    
    mega-hz not only designed The!Cart but also various Mega-Carts named MegaMax, some of them with ROM+RAM. ->link<-
38. • 38:
       
      CommentAuthorgienekp
    • CommentTime21 Dec 2025 14:15

     
    Ile w zasadzie potrzeba RAMu na taką grę (jedną planszę/rozgrywkę)?
39. • 39: CommentAuthorvega1
    • CommentTime21 Dec 2025 14:22

     
    np: BISON zajmuje 33banki x 16KB = 528KB...mniejsze postacie mogą zajmować mniej...
    
    - każda klatka jest przesuwana o 2piksele(4bity)...płynniejszy przesuw X
    - do tego mamy maski (AND) dla tych klatek...rysowanie na tle
    - no i jeszcze jest prawa/lewa strony
    
    dlatego aż tyle....
40. • 40:
       
      CommentAuthorgienekp
    • CommentTime21 Dec 2025 14:30

     
    Czyli wersja 2MB(ROM)+1MB(RAM).
    No to jeszcze pytanie czy wtedy potrzeba 2MB ROM?
41. • 41: CommentAuthorvega1
    • CommentTime21 Dec 2025 14:34

     
    wtedy można zastosować kompresje i rozpakowywać do RAM-u
    myślę, że spokojnie z 4MB w 2MB się to spakuje
42. • 42:
       
      CommentAuthorgienekp
    • CommentTime21 Dec 2025 14:42

     
    A te procki to trzeba rozpakować jako wcześniej policzone na PC? Czy można je wyliczyć podczas rozpakowywania?
43. • 43: CommentAuthorvega1
    • CommentTime21 Dec 2025 14:45 zmieniony

     
    w tej chwili procedury rysujące są w RAM a dane w ROM...nic nie jest rozpakowywane
    
    dopiero teraz jak rozpisuje klatki to jest na PC to przygotowywane...ale też nic niespakowane
44. • 44: CommentAuthortebe
    • CommentTime21 Dec 2025 14:52

     
    jak gra zacznie zbyt szybko działać Vega dojdzie do wniosku że warto przesuwać o 1px zamiast 2px ;)
45. • 45:
       
      CommentAuthorgienekp
    • CommentTime21 Dec 2025 14:59

     
    A dobra chyba kumam. No bo jakby tak udało się, że ATARI coś policzy a nie tylko rozpakuje i dało by się to jakoś mądrze uprządkować.
    To cart 512kB+512kB jest prosty jak konstrukcja cepa i można by go polutować nawet lutownicą do rynien.
46. • 46: CommentAuthorvega1
    • CommentTime21 Dec 2025 15:11 zmieniony

     
    @tebe: wystarczyłoby tylko 4 klatki (te od chodzenia)..reszty nie trzeba :)
    na przeszkodzie stoi tylko brak pamięci...
47. • 47: CommentAuthorvega1
    • CommentTime23 Dec 2025 14:15

     
    fajnie przyśpieszyło rysowanie po rozpisaniu niektórych klatek :)
    pomimo, że i tak można szybciej ale oszczędzam pamięć :)