Odp: Zabawa z Turbo Basic XL
Prawie jak Tedec w Action :)
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Grawitacja 2024 Czas na kolejną edycję 8 bitowego GameJamu.
Tenebra na Atari ST/STE Wersja gry na duże atari.
Wyniki FujiCup 2023 Wyniki konkursu FujiCup na najlepszą grę dla 8-bit Atari w 2023 roku zostały ogłoszone!
TONY na małe Atari Nowa gra na małe Atari, w Hiresie, produkcja Rafała Dudka (brat XXL-a), Popmilo i Caruso.
Cosmic Hero 2 Bohater ratujący Ziemię w kryzysowej sytuacji powraca po 30 latach.
Strony Poprzednia 1 2
Zaloguj się lub zarejestruj by napisać odpowiedź
Prawie jak Tedec w Action :)
Wydaje mi się, że można przyjąć minimalny czas, jaki udało się uzyskać przy uruchomieniu programów, bo przecież nie synchronizujemy się z początkiem ramki więc start programu może wypaść równie dobrze na końcu i wynik jest wtedy zafałszowany o 1 w górę.
Edit: @seban: Fantastyczny pomysł z CLS!
Edit 2: Chociaż może właściwie uśrednienie jest sensowniejsze.
Ostatnio edytowany przez mono (2019-02-17 15:11:58)
problem w tym, że Seban się wyrwał jak Konop z Konopii i opublikował kod (więc ja zaraz po nim), a mieliśmy publikować same wyniki :)
przyznaje się bez bicia że bardzo pobieżnie przeczytałem post cobol80, dopiero potem doczytałem że mamy nie publikować kodu ... (no i potem doczytałem że wyniki mają być z TIME a nie TIME$, stąd moje brednio-wywody o zbyt małej precyzyjności TIME$) ... no ale wtedy to mleko się rozlało już... poza tym nie traktuję tego jako rywalizację czy konkurs, ale jako fajną zabawę :)
każda zabawa jest dobra, ale regulaminy to się czyta :)
no czyta, czyta... (tu moja wina jest niezaprzeczalna, chociaż było napisane "nie trzeba przedstawiać", co nie oznacza iż było to zabronione :P) ale praca zespołowa też jest fajna :) skoro kod się zrobił open-source to teraz społeczność ma szansę wycisnąć z niego ostatnie soki :)
Ostatnio edytowany przez seban (2019-02-17 15:33:43)
no dobra... to mamy stabilne 7:
0 PAUSE %0:DPOKE 19,%0:GRAPHICS 56:POKE 559,%0
2 POKE 48975,255:-MOVE 41297,41296,7679
3 PUT #6;125:? TIME
ubiegł mnie, no ;)
Ja we wszystkich wersjach czyściłem ekran tak:
CLS#6
Ale pomysły macie zarąbiste, trzeba przyznać.
@Seban - bez zerowania 18 mam wyniki kosmiczne,a to pewnie dlatego, że ja nigdy Atari nie wyłączam. Tak, więc zerowanie 18 musi być.
Na marginesie - właśnie zauważyłem, że program TDCa zerował zegar po GRAPHICS 24.
Hej!
Proszę bardzo, bez zerowania 18,19,20... i większości dirty hacków... 7 ramek...
10 PAUSE %0:PRV=TIME
11 GRAPHICS 56:POKE 559,%0:SCR=DPEEK(88)
12 POKE SCR,255
13 MOVE SCR,SCR+1,7679
14 PUT #6;125
15 DLT=TIME-PRV
16 ? DLT;" FRAMES",DLT*(1/50);" SEC."
ps) jeżeli PRV=TIME wstawisz po GR.24, to będziesz miał wynik 6 ramek. pokonaliśmy Action! :)
10 GRAPHICS 24:POKE 559,%0:PAUSE %0:PRV=TIME:SCR=DPEEK(88)
11 POKE SCR,255:MOVE SCR,SCR+1,7679
12 CLS #6
13 LN=PEEK(54283):DLT=TIME-PRV
14 ? DLT;" FRAMES",LN*%2;" LINES"
dokładniej 6 ramek i ~90 linii rastra.
Ostatnio edytowany przez seban (2019-02-17 17:32:53)
coś specjalnie dla PIN-a... 6 klatek... 66 linii.... ;-)
10 GRAPHICS 24:POKE 559,%0:PAUSE %0:PRV=TIME
11 POKE 41296,255:MOVE 41296,41297,7679:CLS #6
12 LN=PEEK(54283):DLT=TIME-PRV:? DLT;"FRAMES",LN*%2;" LINES"
btw. -MOVE jest wolniejsze.... 6 ramek 100 linii używając -MOVE.
Ostatnio edytowany przez seban (2019-02-17 17:57:46)
No tak z tym, że TDC nie wylączał ekranu. Nie mam Action! mógłby ktoś rzucić z ciekawości okiem jak by to wyglądało w Action! z wyłączonym obrazem ?
z włączonym ekranem 8 ramek, 134 linie. TBXL zabija to że wszystko właściwie dzieje się na liczbach FP. Ja i tak się dziwię ze z tyloma wywołaniami procedur z pakietu FP wychodzi wolniej tylko o dwie ramki jedną ramkę. (przy włączonym ekranie).
Ostatnio edytowany przez seban (2019-02-17 18:21:42)
Na marginesie jest jakas wersja Action! plikowa pod Spartę ?
EDIT: wersja v3.7x działa.
Wg testu TDC program wykonuje się jednak 13 jeśli wyzerujemy zegar na starcie.
Turbo BASIC XL wygrywa!!!
Ostatnio edytowany przez Cobol (2019-02-17 18:38:00)
Dodajmy - że Action! działa po kompilacji. Trzeba jakiś lepszy test wymyśleć, bo sama zamiana z jednego koloru na drugi jest za łatwa, jak widać. Poniżej wyniku sebana będzie ciężko zejść. Może by tak rysować koła od środka ekranu na zewnątrz i potem wymazywać kolorem tła. O, coś takiego (najmniej optymalnie jak można):
0 PAUSE %0:DPOKE 19,%0:GRAPHICS 24
1 COLOR %1:FOR I=%1 TO 96 STEP %2:CIRC
LE 159,96,I:NEXT I
2 COLOR %0:FOR I=%1 TO 96 STEP %2:CIRC
LE 159,96,I:NEXT I
3 ? TIME
Wynik: 1513 przed kompilacją, co ciekawe 1538 po kompilacji i zlinkowaniu ;) Da się sporo zejść z tego, a widać, co się dzieje na ekranie ;) Działajmy na włączonym ekranie. Po wyłączeniu ekranu na wersji niekompilowanej 1413, kompilowanej nie chciało mi się sprawdzać.
Ostatnio edytowany przez Sikor (2019-02-17 19:06:56)
tzn. tak... nie wiem jak wygląda kod TDC-a, nawet nie wiem gdzie go szukać... więc napisałem swój... (używałem action v3.6
)
BYTE RTC=$14
BYTE VCOUNT=$D40B
BYTE SDMCTL=$22F
PROC MAIN()
CARD SCR,VCN
BYTE FRM
GRAPHICS(24) RTC=0
SCR=PEEKC(88)
SETBLOCK(SCR,$1E00,$FF)
ZERO(SCR,$1E00)
VCN=VCOUNT FRM=RTC
GRAPHICS(0)
PRINTF("%E %U FRAMES",FRM)
PRINTF("%E %U LINES",VCN*2)
i wyszło mi:
jak się wyłączy ekran, wychodzi:
gdy zrobię tak jak piszesz, tzn. zeruję RTCLOCK przez wywołaniem GR.24, czyli:
to wychodzi:
ale gdy zastosuje się sztuczkę PIN-a z GR.56 (nie czyścimy pamięci ekranu) to wynik spada do:
UPDATE: Porównywanie TBXL i Action! jest trochę bez sensu, ponieważ TBXL działa na liczbach FP (zmienno-przecinkowych) a Action! tylko i wyłącznie na całkowitych. W dodatku Action! to kompilator, a TBXL jest właściwie interpreterem, piszę właściwie bo po wpisaniu linii następuje tokenizacja, przekształcenie wyrażeń arytmetycznych, ot taka wstępna kompilacja i optymalizacja w locie. Gdyby nie wbudowane w TBXL funkcje MOVE moglibyśmy jedynie sobie zerować/wypełniać te 8KB pamięci przez ładny kawałek czasu używając np. FOR...NEXT i POKE. Trwałoby to naprawdę jakiś koszmarny kawał czasu.
Ostatnio edytowany przez seban (2019-02-17 19:34:03)
Jakby ktoś chciał się bawić w dalszą walkę z Action!, to proszę:
BYTE RTC=$14
BYTE VCOUNT=$D40B
BYTE DMA=$22F
PROC VBL()
BYTE V
V=RTC
WHILE(V=RTC) DO OD
RETURN
PROC MAIN()
CARD SCR,VCN
BYTE FRM
GRAPHICS(24) DMA=0 VBL() RTC=0
SCR=PEEKC($58)
SETBLOCK(SCR,$1E00,$FF)
ZERO(SCR,$1E00)
VCN=VCOUNT FRM=RTC
GRAPHICS(0)
PRINTF("%E %U FRAMES %U LINES",FRM,VCN*2)
5 ramek, 38 linii rastra. aby było szybciej to już chyba tylko wstawki ASM :) bo te procedury biblioteczne SETBLOCK czy ZERO nie są jakieś super optymalne ;)
Ostatnio edytowany przez seban (2019-02-17 21:14:55)
Strony Poprzednia 1 2
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 2.844 sekund, wykonano 17 zapytań ]