401

(58 odpowiedzi, napisanych Bałagan)

Adam Klobukowski napisał/a:

nosty: w porównaniu do zwykłego Kowalskiego bank jest uprzywilejowany, bo może wystawić bankowy nakaz egzekucyjny, a Kowalski nie może.

Fakt, choc i tak to sąd musi klepnąc wykonalnosc tej egzekucji.
Kowalski wystawia wezewanie do zaplaty, po czym idzie do banku i tez uzyskuje egzekucje choc poczeka sobie na to troche dluzej.

grzeniu napisał/a:

Sikor coś mi się nie zgadza. Chcesz wykupić mieszkanie to dlaczego zabezpieczeniem dla banku nie może być ta właśnie nieruchomość ?

grzeniu, teraz Ty pytasz naiwnie. Jeszcze NIGDY nie slyszalem o tym zeby bank zadowolil sie nieruchomoscia jako jedynym zabezpieczeniem od osoby prywatnej, chocby byla ona warta kilka razy wiecej niz kredyt. A to z powodu prawa jakie u nas jest. Sikor moglby nie zaplacic ani zlotowki a komornikowi pokazal kwit od lekarza ze jest chory i eksmisja do lokalu zastepczego moglaby wplynac negatywnie na stan zdrowia. Albo w miedzyczasie by sie ozenil i począł ;) I tym tytulem ekzekucyjnym z decyzja wykonalnosci bank sie moze podetrzec :P

402

(58 odpowiedzi, napisanych Bałagan)

grzeniu, ale nie o to bylo pytanie.  W poscie 10, sugerowales ze to Sikor nie powinien pozyczac pieniedzy od ludzi w takich kwotach.

A narzedzia windykacyjne bank ma chyba identyczne co kazdy Kowalski (przynajmniej te zgodne z prawem).

403

(58 odpowiedzi, napisanych Bałagan)

grzeniu napisał/a:

Tak dla włanego zdrowia to nie pożyczaj pieniędzy bezpośrednio od ludzi w takich kwotach.

Czemu? Tzn jesli i tak spisujesz umowe to czy prawnie jest roznica czy pozyczasz od prywatnej osoby czy od instytucji?

404

(99 odpowiedzi, napisanych Programowanie - 8 bit)

Pin napisał/a:

Czyli jak coś działa wyłącznie na HDD to jest bardziej złe, niż jak działa tylko po SIO?

Niepodwazalnie. SIO jest natywnym interfejsem do Atari 8-bit i wszystko powinno dzialac z SIO. Drugim naturalnym nosnikiem byl cartridge, ale programy musialy byc specjalnie dostosowywane zeby dzialac z cartridga.
A HDD do Atari to jednak wymysl naszych czasow.

PS. XXL'owi udalo sie xBiosem zmonopolizowac wszystkie watki we wszystkich kategoriach na tym forum. Powinien dostac jakas nagrode za animowanie spolecznosci czy cuś... :D

405

(1,754 odpowiedzi, napisanych Fabryka - 8bit)

Larek - witaj w klubie... wlasciwie napisalem to samo pare postow wyzej.

406

(5 odpowiedzi, napisanych Bałagan)

Ladnie tak sie smiac z trupa? :P
Zobaczcie daty ostatnich postow...

407

(166 odpowiedzi, napisanych Zloty)

grey, czy taka deklaracja jest dla Ciebie istotna? Tj cos rezerwujesz, obliczasz itp?

Bo ja w tej chwili swoje szanse oceniam na 90%. Problem w tym, ze dwa poprzednie lata tez bardzo chcialem pojechac i w ostatniej chwili cos mi stawalo na drodze, wiec w tym roku nie chce zapeszac :/

408

(21 odpowiedzi, napisanych Scena - 8bit)

Emulator is not a real Atari! :)

409

(1,754 odpowiedzi, napisanych Fabryka - 8bit)

jell, ale ja nie zartowalem piszac ze XXL wymusza stosowanie xBios w Mazazem w celu promocji rozwiązania. Tak sie wlasnie robi i jest to powszechna praktyka "marketingowa".
Czemu Onet wrzuca filmy na jakas tam wlasna platforme, a nie na youtuba, ktory jest przeciez standardem? No dobra, to moze nie do konca adekwatny przyklad, ale rozumiesz idee promocji.

To jest kwestia bardziej swiatopogladowa niz techniczna ;) XXL nie lubi dosow (ba! on nie widzi potrzeby nawet systemu operacyjnego ;). Ja jako czlowiek wychowany na magnetofonie go rozumiem.
Zawsze dziwilo mnie ze ludzie probuja na Atari stosowac praktyki z PC: wlaczam komputer odpalam dos'a i na tym uruchamiam programy i gry, ktore maja wracac do dosa. Po kolacji wylaczam komputer.

Tymczasem dla mnie symbolem Atari zawsze byla lewa reka wyciagnieta w strone wlacznika a palce prawej ulozone w charakterystyczne V :)
Przeciez prawie kazdy program na Atari ma w instrukcji wgrywania (nawet z dyskietki): "wlaczyc komputer trzymajac wcisniety Option". Dos i powroty do niego jest dobry czasami do specyficznej pracy uzytkowej, ale do gier i rozrywki to jakis zbedny bagaz... Gra potrzebuje wczytac dane, zapisac dane i szlus.

I tak, to co napisal electron to tez prawda: predzej czy pozniej wiedzialem ze musze nauczyc sie wykorzystywac DOS'a w ASM i troche mnie to przerazalo - dosow jest duzo, ta Sparta to juz wogole straszy mnie po nocach... A jak zobaczylem opis xBiosa dla programistow, to stwierdzilem ze super, mam problem z glowy i moge tego uzyc.

410

(27 odpowiedzi, napisanych Programowanie - 8 bit)

Adam nie troluj! Wypada chociaz wiedziec o czym mowa...
http://xxl.atari.pl/?p=1076

411

(27 odpowiedzi, napisanych Programowanie - 8 bit)

eee patrzac na tytul juz myslalem ze organizujesz walke na piesci... ;)

Sikor napisał/a:

6. Ciekawi mnie, czy XXL-owi (lub komuś innemu) uda się uzyskać tak samo niskie memlo przy XBiosie dla innych (od SIO) urządzeń - bo to jest inna sprawa, a póki co to nie jest pewne

A to ciekawe pytanie. XXL, czy jest mozliwosc ze memlo bedzie sie przesuwac przt bibliotekach obslugujacych kolejne urzadzenia, i bedzie to wymuszac reasemblacje programu napisanego pod obecną wartosc memlo?

412

(1,754 odpowiedzi, napisanych Fabryka - 8bit)

Bo to sie nazywa promocja rozwiązania :)
XXL osiagnalął juz cel nr 1 - o jego xBios'ie mowi sie na kazdym forum. Realizujecie jego plan nawet o tym nie wiedząc ;)

413

(320 odpowiedzi, napisanych Zloty)

kur... cala kolacje czytalem Wasza dyskusje :P Moze nie filozujcie ale dogadajcie sie konkretnie. Po prostu Grey i Pin obiecaja ze uruchomia kazdy program, ktory XXL napisze na zlot, a XXL obieca ze nie napisze zlosliwie takiego programu, ktorego uruchomic sie nie da ;)

414

(17 odpowiedzi, napisanych Programowanie - 8 bit)

HA! Dodanie SEI pomoglo.

Dodalem juz po inicjalizacji wszystkiego i po wykonaniu pierwszego VBLI, kiedy wszystkie cienie zostaly przepisane.
Dalej w kodzie juz nie uzywam zapisu do cieni wiec dziala.

Zjawisko zniknelo.

415

(17 odpowiedzi, napisanych Programowanie - 8 bit)

Kurcze jakis dziwny ten test - w kolejnych uruchomieniach na 130XE daje rozne wyniki!
Raz wyskoczyl mi blad "MMU: XL banking", a teraz za kazdym razem wyskakuje mi:
CPU: Illegal instructions... FAIL
Test failed: A=33 X=55 Y=01 P=30 M=11
Insn: 93 C4 60

Ale przed chwila na tej samej maszynie dwa razy przeszedl!

416

(17 odpowiedzi, napisanych Programowanie - 8 bit)

xxl napisał/a:

acid800 test atari goscia od Altirry

Obie Atarki przechodza wszystkie testy :)

drac030 napisał/a:

Ad sei: czy VBL-a używasz tzw. "opóźnionego"? Jeśli tak, to faktycznie, z SEI nie zadziała. Przewieś procedurę VBL na wektor natychmiastowy.

Cholera... musze sie jeszcze duzo nauczyc. Nie wiem jakiego VBLI uzywam, nie wiedzialem ze sa rozne :/
Ustawiam jak nizej, inaczej nie umiem:

       ldy #<vbli
       ldx #>vbli
       lda #$06
       jsr jsetvblv
       lda #64 
       sta NMIEN

417

(17 odpowiedzi, napisanych Programowanie - 8 bit)

xxl napisał/a:

acid800

Co to jest???

drac030 napisał/a:

Gdybym miał zgadywać, to pojawiają się jakieś syfy na sygnałach gniazda kartridża, które twój wynalazek interpretuje jako dodatkowe odczyty. Może to znowu nieśmiertelny problem z fi2.

Bardzo prawdopodobne. Szczegolnie ze w 130XE jest ok. Niestety nie dysponuje akurat wieksza iloscia Atari do prob.

PS. Z SEI programi mi wogole nie dziala :/

418

(17 odpowiedzi, napisanych Programowanie - 8 bit)

Ciekawe... Zjawisko zaobserwowalem na 65XE (praktycznie nie dopalonym, tylko QMEG i SIO2IDE).
Natomiast na 130XE (1MB RAM, stereo, AKI) nie wystepuje niezaleznie od tego pod jakim systemem sprawdzam (a mam tam chyba nawet system z 800-ki).
Czyli jest to zwiazane z konkretnym modelem plyty pewnie.

No nic. Jak bede mial kilka urzadzen i wiecej osob bedzie moglo przetstowac to pewnie dojdziemy co to za cudo...

419

(17 odpowiedzi, napisanych Programowanie - 8 bit)

Nigdzie w programie nie korzystam z klawiszy, nie odczytuje rejestrow klawiatury.
Uzywam przerwan VBLI i DLI.

Przy ustawieniu $D580 zjawisko tez wystepuje. Przy $D5E0 tak samo (mam 32-bajtowa szerokosc obrazu).
Ale to przeciez nie ma znaczenia! Kazdy odczyt z dowolnego adresu strony D5 trafi na cartridge i "zje" dane przeznaczone dla Antica, niezaleznie gdzie jest pamiec obrazu.

Zaraz sprawsze jeszcze na tym pierwszym demie hi-res, oraz na innym egzemplarzu Atari.

EDITED: z wlaczonym QMEG'iem jest tak samo.

420

(17 odpowiedzi, napisanych Programowanie - 8 bit)

Trafilem na dziwne zjawisko testujac "Tomka". Dokladnie na tym tescie:
http://www.youtube.com/watch?v=kfnsgPS6vdg

Nie moge tego pokazac, ale w momencie kiedy naciskam dowolny klawisz (oprocz shifta rzecz jasna), to obraz na jedną ramkę, lekko sie przesuwa w lewo od pewnej linii (rożnej w rożnych probach). Nie wiem czy dobrze obserwuje, ale przesuniecie wynosi nieraz 1 bajt, a nieraz 2 bajty. Takie szarpniecie o czasie trwania 1 ranmki (na oko) ale zauwazalne.

Wyjasnienie:
Obraz jest w trybie graficznym. Adresy pamieci dla kazdej linii ustawione są na $D500. "Tomek" po odebraniu rozkazu "generuj dane obrazu dla Antica" podaje kolejne bajty, tak jak Antic je czyta ze strony $D5. Przyjmuje sie przy tym, ze nic innego oprocz Antica nie bedzie robilo odczytu ze strony $D5.
Jesli wiec obrazem szarpie od pewnej linii w lewo, to oznacza ze DOKLADNIE w momencie nacisniecia klawisza "cos" dokonuje odczytu (lub dwoch) ze strony $D5xx. W ten sposob "zabiera dane" przeznaczone dla Antica i caly obraz przesuwa sie o bajt lub dwa w lewo na czas rysowanej wlasnie ramki.
Innego wytlumaczenia nie ma.

Pytanie:
Co i po co czyta ze strony $D5 w momencie nacisniecia klawisza?

421

(11 odpowiedzi, napisanych Programowanie - 8 bit)

zalezy od szybkosci gry... ja chce zrobic szybką :)
a zobacz to:
http://www.youtube.com/watch?v=hHmzO2RI … re=related
Tenchi opisal te gry jako "bullets hell" :D
Dalbym glowe ze statek zawadza o pociski a energii mu nie ubywa (lub to cheat).
Takze wszystko jest wkestia konwencji i przyzwyczajenia do regul gry.

422

(11 odpowiedzi, napisanych Programowanie - 8 bit)

Nie czytales wczesniej? Przyblizasz ksztalt obiektow za pomoca prostokatow. Wykrywasz czy sie nakladaja.

423

(11 odpowiedzi, napisanych Programowanie - 8 bit)

Dzieki Panowie! Faktycznie nawet zlozone ksztalty mozna opisac za pomocą kilku - kilkunastu kwadratow, co w wiekszosci przypadkow moze byc wystarczajace.
Widze jednak, ze do zagadnienia nalezy podchodzic bardzo indywidualnie.

Ale moge zaimplementowac w Tomku najprostsza detekcje na zasadzie obiekt = prostokat o wymiarach obiektu. Lub nawet bardziej zlozoną, gdzie obiekt = lista prostokątow o zdefiniowanych wymiarach i polozeniu wzgledem lewego gornego rogu obiektu.

wieczor napisał/a:

Metoda bitowa jest szybka i dokładna

Szybka powiadasz... No to daj mi sensowny algorytm detekcji kolizji bitowej miedzy 32 obiektami o wymiarach do 64x64 piksele nakladanymi na grafike tla. Jak by nie kombinowac trzebaby dla wszystkich obiektow ktore choc w czesci sie pokrywaja robic operacje bitowe "kazdy z kazdym". IMHO nawet 40MIPS'owy PIC by mi sie spocil :P

Ale nie wykluczam w przyszlosci implementacji rozkazu "sprawdz kolizje biotowe obiektu X z pozostalymi".

424

(9 odpowiedzi, napisanych Sprzęt - 8bit)

Hehhe dzieki wieczor, ale akurat kiepsko trafiles, bo slomiany zapał to moja najgorsza zmora ;) Dwa inne prawie skonczone dobre projekty czekaja juz u mnie w kolejce na niewiadomo kiedy...

To w sumie to nie jest najgorsza rada: wyobrazam sobie mozliwosc, ze kazdy kto chce developowac na Tomka gry i zmieniac firmware, musi kupic zestaw developerski Microchipa (jakies 140zl chyba), co umozliwiloby mu od razu tez poprawianie firmware. To faktycznie nie sa wielkie pieniadze.

Mozna wiec w ten sposob tworzyc i wydawac fajne gry.

Ale w PIC'u bedzie mozna przechowywac max. tylko jakies 64 - 96KB danych dla Atari. Wiec wieksze gry beda musialy ladowac do niego np dane kolejnych leveli itp. (na cartridgu bedzie pamiec EPROM do 512 lub 1024KB).
Wiec flashowanie jest konieczne.

No i docelowo chce zeby uzytkownik koncowy mial mozliwosc wykorzystwania raz zakupionego sprzetu do roznych gier. To tez wymusza zmiane firmware z poziomu Atari.

Lepiej wiec pomyslec zawczasu.

425

(11 odpowiedzi, napisanych Programowanie - 8 bit)

Potrzebuję wiedzy w tytulowym temacie:

Jak wydajnie wykrywac kolizje obiektow?

Znalazlem w sieci pare tekstow ale okazaly sie one srednio przydatne w kontekscie Atari.
Pytam pod kątem pisania gry na "Tomka", ale nie zakladam z gory, ze bedzie to robil koprocesor.
Sprawa nie jest trywialna jesli na ekranie ma byc kilkanascie duzych obiektow o nieregularnych ksztaltach. A uwzgledniajac np pociski moze ich byc kilkadziesiat!

Generalnie sa dwie metody:
1. Bitowa (czyli jakies operacje bitowe i wykrywanie ktore pixele sie pokrywaja - podobnie jak w PMG sprzetowym na Atari)
2. Obliczeniowa bazujaca na odleglosciach.

Pierwsza jest dokladniejsza, ale np XXL sugerowal mi niejednokrotnie ze odrzuca ja zazwyczaj bo jest "za dokladna" czyli ze denerwujaca jest smierc bohatera jesli zawadzi o cos jednym pixelem. Wiec stosuje metode obliczeniowo-odleglosciową.
Ale są sytuacje w ktorych precyzja jest bardzo wazna: np kiedy w platformowce jesli bohater staje przed opadajacymi smiercionosnymi obiektami (np. Henry's House).

Druga metoda wydaje sie latwiejsza, ale jest tak jesli obiekty maja w miare "ogrągly", zwarty ksztalt ;) czyli np okragle pociski trafiajace w niewielekie przeszkadzajki o wymiarach 10x10 pixeli. Tu przyblizenie oparte na odleglosci miedzy srdodkami obiektow jest wystarczajace zeby dobrze sie gralo. Ale co jesli obiekt bedzie duzy o bardzo nieregularnym ksztalcie? Kiedy trzeba sie zmierzyc z czyms takim jak to:
http://www.youtube.com/watch?v=MQvEUX5I … age#t=273s

Do tej pory wykombinowalem, ze moznaby zrobic wykrywanie kolizji troche inaczej: zrobic przyblizenie ksztaltu kazdego obiektu w nizszej rozdzielczosci, np na znakach (czyli na siatce 40x24) i wykrywac kolizje jesli pokrywaja sie "znaki" zajmowane przez dwa obiekty. To powinno dac zadowalajacy rezultat np w strzelankach.
Ale skutkuje to koniecznoscia dublowania animacji na tej "znakowej siatce kolizji".

Chcialbym wiec prosic praktykow o pare slow na temat metod jakie wykorzystywali w swoich grach. Szukam inspiracji i rozwiazan, ktore moglbym zaimplementowac :)