03.07.2021 10:19
[#1]
[C] OS, Kick v39 - v36 (v35) Pytania
Chcę zjechać w projekcie z funkcji v39+ do v36 i stąd pytania. Zjechanie by było na opakowania odpowiednich funkcji i w przypadku v39+ to bym używał odpowiednich funkcji a w przypadku v36 podpierał bym się zamiennikami.
1. Podstawowe pytanie czy warto zjechać do v36, czy założyć, że każdy kto chce uruchomić program/grę pod OS to raczej ma v39+ i trochę szybszy procek ?.
2. Czy jest coś w stylu ObtainPen dla Kick v36 ?
3. Czy aby zamienić AllocBitMap to lepiej użyć AllocRaster czy AllocMem i co zrobić w przypadku bitmapy typu INTERLEAVED (grzebać samemu w structurze BitMap ??? )
4. A może zjechać aż do v34 i czy to jest możliwe w przypadku powyższych funkcji i czy to nie jest fatalny pomysł
1. Podstawowe pytanie czy warto zjechać do v36, czy założyć, że każdy kto chce uruchomić program/grę pod OS to raczej ma v39+ i trochę szybszy procek ?.
2. Czy jest coś w stylu ObtainPen dla Kick v36 ?
3. Czy aby zamienić AllocBitMap to lepiej użyć AllocRaster czy AllocMem i co zrobić w przypadku bitmapy typu INTERLEAVED (grzebać samemu w structurze BitMap ??? )
4. A może zjechać aż do v34 i czy to jest możliwe w przypadku powyższych funkcji i czy to nie jest fatalny pomysł
03.07.2021 11:35
[#2]
Re: [C] OS, Kick v39 - v36 (v35) Pytania
@asman, post #1
Swego czasu mialem ten sam dylemat gdy pisalem jedna z gier. Udalo mi sie (chyba) zjechac tylko do V36.
AllocBitMap() zamienilem na AllocRaster(). Niby mam wpisane:
bm->Flags |= BMF_INTERLEAVED;
i chyba dziala (przekopiowalem to od kogos).
link.
Choc i tak zostal skrytykowany. Mozliwe ze jest niepoprawny.
Jakbys chal zejsc ponizej, trzeba sie jeszcze pozbyc takich funkcji jak OpenWindowTag(), OpenScreenTag()
i zastapic je poprzez OpenWindow(), OpenScreen(); ale to akurat nie problem.
Co do ObtainPen();,to sie nie wypowiem.
Ostatnia aktualizacja: 03.07.2021 11:41:08 przez Phibrizzo
AllocBitMap() zamienilem na AllocRaster(). Niby mam wpisane:
bm->Flags |= BMF_INTERLEAVED;
i chyba dziala (przekopiowalem to od kogos).
link.
Choc i tak zostal skrytykowany. Mozliwe ze jest niepoprawny.
Jakbys chal zejsc ponizej, trzeba sie jeszcze pozbyc takich funkcji jak OpenWindowTag(), OpenScreenTag()
i zastapic je poprzez OpenWindow(), OpenScreen(); ale to akurat nie problem.
Co do ObtainPen();,to sie nie wypowiem.
Ostatnia aktualizacja: 03.07.2021 11:41:08 przez Phibrizzo
03.07.2021 12:11
[#3]
Re: [C] OS, Kick v39 - v36 (v35) Pytania
@asman, post #1
A moim zdaniem każda Amiga dosłownie za grosze może mieć V39, a dla programisty obecność v39 naprawdę dużo ułatwia.
Programistów coś robiących dla Amigi jest jak na lekarstwo, szkoda czasu na obejscia, trzeba po prostu korzystać z ułatwień v39 i dążyć do finiszu swojego projektu. I jest to jak najbardziej koszerne, już Commodore wypuściło tą wersję systemu dla A500 i innych Amig.
Programistów coś robiących dla Amigi jest jak na lekarstwo, szkoda czasu na obejscia, trzeba po prostu korzystać z ułatwień v39 i dążyć do finiszu swojego projektu. I jest to jak najbardziej koszerne, już Commodore wypuściło tą wersję systemu dla A500 i innych Amig.
03.07.2021 17:49
[#7]
Re: [C] OS, Kick v39 - v36 (v35) Pytania
@asman, post #1
3. Czy aby zamienić AllocBitMap to lepiej użyć AllocRaster czy AllocMem i co zrobić w przypadku bitmapy typu INTERLEAVED (grzebać samemu w structurze BitMap ??? )
No właśnie w przypadku BitMapy typu Interleaved pod V36 jest niewielki problem - w przypadku systemowych funkcji rysujących.
Z tego co zauważyłem, to nawet jak ustawię Planes[0] na początek, a następnie Planes[1], Planes[2], ..., Planes[depth - 1] na kolejne linijki oraz BytesPerRow na wielkość całej linijki, czyli (bajty w wierszu * głębokość), to funkcje rysujące nie biorą pod uwagę, że można rysować jedną operacją.
Jeśli chodzi o wyświetlanie i podpinanie pod ekran, to już ta technika działa - więc tu nie ma problemów.
A funkcje rysujące można zastąpić własnymi.
@Phibrizzo
BMF_INTERLEAVED to flaga, która pojawiła się w systemie V39, więc raczej np. na Amidze 600 z V36 nie zadziała.
Ostatnia aktualizacja: 03.07.2021 17:50:34 przez Hexmage960
05.07.2021 21:53
[#10]
Re: [C] OS, Kick v39 - v36 (v35) Pytania
@asman, post #1
Generalnie to masz:
v33 - 1.2
v34 - 1.3
v36 - wstępne wersje 2.0, niewarte uwagi bo to tylko A500+ w zasadzie
v37 - czyli 37.175+ czyli 2.04 - minimum by pisać cokolwiek
v39 - czyli 3.0, absolutne minimum od lat. Jak ktoś nie ma to pewnie i tak tylko SuperFroga męczy.
v38 to było kilka bibliotek z WB 2.1 - w zasadzie poza locale.library reszta pomijalna
v40 i powyżej to jak już piszesz coś wyraźnie pod 3.1 i następne ale wtedy wiesz czemu
Poniżej v39 nie schodź. Chyba że piszesz na gołą Amigę 500. A wtedy to Forbid() i jedziesz sam po sprzęcie bo jak ktoś tam nie ma v39 to i tak SuperFrog.
v33 - 1.2
v34 - 1.3
v36 - wstępne wersje 2.0, niewarte uwagi bo to tylko A500+ w zasadzie
v37 - czyli 37.175+ czyli 2.04 - minimum by pisać cokolwiek
v39 - czyli 3.0, absolutne minimum od lat. Jak ktoś nie ma to pewnie i tak tylko SuperFroga męczy.
v38 to było kilka bibliotek z WB 2.1 - w zasadzie poza locale.library reszta pomijalna
v40 i powyżej to jak już piszesz coś wyraźnie pod 3.1 i następne ale wtedy wiesz czemu
Poniżej v39 nie schodź. Chyba że piszesz na gołą Amigę 500. A wtedy to Forbid() i jedziesz sam po sprzęcie bo jak ktoś tam nie ma v39 to i tak SuperFrog.
05.07.2021 22:32
[wyróżniony]
[#12]
Re: [C] OS, Kick v39 - v36 (v35) Pytania
@asman, post #9
No i fajnie byłoby ogarnąć przełączanie się między oknem a ekranem w trakcie działania programu, bez konieczności zamykania go. Zawsze mnie w amigowym sofcie irytowało to, że nie dało się tego robić pomimo tego, że to jest do zrobienia. W czasach MOSowego MUI trochę o tym problemie już zapomniałem, bo tam nie istnieje. Ale wcale nie trzeba MUI żeby to ogarnąć.
14.07.2021 15:07
[#13]
Re: [C] OS, Kick v39 - v36 (v35) Pytania
@MDW, post #12
Samo przełączanie nie stanowi problemu. Gorzej z grafiką, która to muszę remapować w przypadku okna. Cały czas poruszam się w V39 (wyżej nie). Jeśli teraz skorzystam z datatypów, to spokojnie sobie zremapuje grafikę. Tyle że przy przełączaniu, będę musiał przeładować wszystkie assety graficzne, bo przecież używam w datatypie DTST_FILE. Przynajmniej tak to rozumiem w teorii, gdyż tego nie sprawdzałem. Jeśli się mylę to byłoby super. Przeładowywanie asetów graficznychw trakcie przełączania będzie męczące dla gracza. A to już mnie boli. Jedyną sensowną drogą jaką w tej chwili widzę to użycie DTST_CLIPBOARD, co nieco komplikuje sprawę. Chyba że ktoś widzi jakieś inne rozwiązanie, to z chęcią usłyszę.
16.09.2021 22:16
[#14]
Re: [C] OS, Kick v39 - v36 (v35) Pytania
@asman, post #13
Wieści z pola walki i kolejne pytanie(a). Udało mi się zaimplementować przełączanie pomiędzy oknem i ekranem i, o dziwo działa. Na tą chwilę olałem clipboard, mimo że ogarnąłem temat w testowym jakimś tam projekciku. Teraz siedzę i myślę co zrobić w przypadku kopiowania klocków (16x16 pikseli) zarówno w przypadku ekranu (podwójny bufor) jak i okna. Ktoś coś robił takiego kiedyś i ma ciekawe przemyślenia ?
17.09.2021 16:24
[#16]
Re: [C] OS, Kick v39 - v36 (v35) Pytania
@Krashan, post #15
Nie szkodzi, podstawy są najważniejsze. Dzięki temu sobie uświadomiłem że podwójny ekran raczej nie będzie potrzebny, zależy jak to będzie wyglądało przy testach (użyje WaitBOVP). Bo i tak wpierw będę kopiował klocek z bitmapy klocków na bitmapę gry (która jest większa niż ekran) a potem będę kopiował kawałek bitmapy gry na ekran. Czyli będę musiał zsynchronizować kopiowanie z wiązką.
Stokrotne dzięki.
Stokrotne dzięki.
24.09.2021 18:53
[#17]
Re: [C] OS, Kick v39 - v36 (v35) Pytania
@asman, post #1
Kolejne pytania, tym razem dotyczą sound datatype i audio device.
Wyczytałem że od wersji v40 sound datatype może umieścić próbkę dzwiękową poza pamięcią CHIP i stąd moje pytanie jak elegancko ujarzmić sound datatype i audio.device. Bo dotychczas robiłem to tak. Za pomocą sound datatype wczytywałem próbkę typu 8svx. Pobierałem sobie niezbędne atrybuty do audio.device i odgrywałem próbkę. Ale jak adres sample nie jest w CHIP to są problemy. Czy w takim razie, używać sound datatype do załadowania próbek i samemu kopiować do CHIP ?
Ostatnia aktualizacja: 24.09.2021 18:53:35 przez asman
Wyczytałem że od wersji v40 sound datatype może umieścić próbkę dzwiękową poza pamięcią CHIP i stąd moje pytanie jak elegancko ujarzmić sound datatype i audio.device. Bo dotychczas robiłem to tak. Za pomocą sound datatype wczytywałem próbkę typu 8svx. Pobierałem sobie niezbędne atrybuty do audio.device i odgrywałem próbkę. Ale jak adres sample nie jest w CHIP to są problemy. Czy w takim razie, używać sound datatype do załadowania próbek i samemu kopiować do CHIP ?
Ostatnia aktualizacja: 24.09.2021 18:53:35 przez asman
26.09.2021 12:19
[#20]
Re: [C] OS, Kick v39 - v36 (v35) Pytania
@asman, post #19
Sprawdziłem i działa. Co najlepsze znakomicie to ułatwia sprawę i zmniejsza ilość kodu. Następne pytania a propos sound datatype (tylko V39 nie wyżej), czy jest możliwe sprawdzenie czy próbka jest w trakcie odgrywania czy już się skończyła ? Z tego co znalazłem link to nie ma takiej możliwości.
26.09.2021 12:41
[#21]
Re: [C] OS, Kick v39 - v36 (v35) Pytania
@asman, post #20
Tak, jest to możliwe. Należy użyć tagów SDTA_SignalTask i SDTA_SignalBit. Dostaniesz wtedy sygnał, kiedy dźwięk skończył odtwarzanie.
Obadaj sobie katalog
REFERENCE/DEVCON/ORLANDO_1993/DEVCON93.2/DATATYPES/SRC
na Amiga Developer CD v2.1.
Przykład:
P.S. Nawiasem mówiąc, sound.datatype jest dosyć okrojony z funkcjonalności. Nie jestem tego pewien, ale być może można tę funkcjonalność rozszerzać za pomocą podklas (np. wybór kanału do odgrywania, operacje STM_STOP, STM_CONTINUE itp.)
Ale fajnie że Ci działa, spełnia Twoje oczekiwania i jesteś zadowolony z kodu.
Ostatnia aktualizacja: 26.09.2021 12:41:50 przez Hexmage960
Obadaj sobie katalog
REFERENCE/DEVCON/ORLANDO_1993/DEVCON93.2/DATATYPES/SRC
na Amiga Developer CD v2.1.
Przykład:
/* We want to be notified when the sound stops playing, so * we provide a signal task and a signal */ SDTA_SignalTask, (ULONG) FindTask (NULL), SDTA_SignalBit, (ULONG) SIGBREAKB_CTRL_F,
P.S. Nawiasem mówiąc, sound.datatype jest dosyć okrojony z funkcjonalności. Nie jestem tego pewien, ale być może można tę funkcjonalność rozszerzać za pomocą podklas (np. wybór kanału do odgrywania, operacje STM_STOP, STM_CONTINUE itp.)
Ale fajnie że Ci działa, spełnia Twoje oczekiwania i jesteś zadowolony z kodu.
Ostatnia aktualizacja: 26.09.2021 12:41:50 przez Hexmage960
27.09.2021 10:40
[#23]
Re: [C] OS, Kick v39 - v36 (v35) Pytania
@asman, post #22
Powinny być, ponieważ w programie przykładowym otwierana jest biblioteka datatypes.library w wersji V39.
EDIT: Przepraszam masz rację. W dokumentacji jest mowa o tym, że te tagi są w wersji V40. Czyli w przykładzie jest mały błąd (a w zasadzie niedokładność, ponieważ program uruchomiony na V39 nie wywoła automatycznie sygnału CTRL+F).
Ostatnia aktualizacja: 27.09.2021 10:45:42 przez Hexmage960
EDIT: Przepraszam masz rację. W dokumentacji jest mowa o tym, że te tagi są w wersji V40. Czyli w przykładzie jest mały błąd (a w zasadzie niedokładność, ponieważ program uruchomiony na V39 nie wywoła automatycznie sygnału CTRL+F).
Ostatnia aktualizacja: 27.09.2021 10:45:42 przez Hexmage960
27.09.2021 10:47
[#24]
Re: [C] OS, Kick v39 - v36 (v35) Pytania
@Hexmage960, post #23
W includach jest napisane
poza tym w komentarzu w tym źródle jest
link
Ostatnia aktualizacja: 27.09.2021 10:48:54 przez asman
... ** $VER: soundclass.h 44.7 (6.6.1999) ** Includes Release 45.1 ... /* The following tags are new for V40 */ ... #define SDTA_SignalTask (SDTA_Dummy + 7) #define SDTA_SignalBit (SDTA_Dummy + 8) ...
poza tym w komentarzu w tym źródle jest
link
/* Let the 8svx sound finish playing. Currently (V39) there is */ /* no programmatic way to find out when it is finished playing. */
Ostatnia aktualizacja: 27.09.2021 10:48:54 przez asman
29.09.2021 13:38
[#25]
Re: [C] OS, Kick v39 - v36 (v35) Pytania
@asman, post #24
Kolejne pytania tym razem picture datatype i okno.
Czy jest możliwe otrzymanie penów (coś w stylu ObtainPen) za pomocą picture datatype ? Chodzi mi o to że chciałbym mieć wsparcie do zmiany kolorów obrazka (kolorów jest mało, 5 bodajże) na oknie. Na ekranie to nie ma problemu dostaje się do kolorów za pomocą taga PDTA_ColorRegisters.
Ktoś coś ? Jakieś pomysły ?
Oczywiście poruszamy się przy V39.
Ostatnia aktualizacja: 29.09.2021 13:39:38 przez asman
Czy jest możliwe otrzymanie penów (coś w stylu ObtainPen) za pomocą picture datatype ? Chodzi mi o to że chciałbym mieć wsparcie do zmiany kolorów obrazka (kolorów jest mało, 5 bodajże) na oknie. Na ekranie to nie ma problemu dostaje się do kolorów za pomocą taga PDTA_ColorRegisters.
Ktoś coś ? Jakieś pomysły ?
Oczywiście poruszamy się przy V39.
Ostatnia aktualizacja: 29.09.2021 13:39:38 przez asman
29.09.2021 21:16
[#27]
Re: [C] OS, Kick v39 - v36 (v35) Pytania
@Krashan, post #26
Jasne, tak też robię, tylko chciałbym mieć możliwość zmiany koloru(ów) w oknie (na ekranie Workbencha). Mogę to osiągnąć bez picture datatype. Poprzez ObtainPen i ręczne zremapowanie danych graficznych i skopiowanie tychże danych za pomocą WritePixelArray8. Oczywiście ObtainPen może się nie powieść wtedy nie ma remapowania i wygląda to słabo. I to jest jeden z minusów. Drugi minus jest taki że dane graficzne trzymam jako chunky - wolałbym jako iff, coby łatwiej można było je modyfikować. Super by było jakby dało się osiągnąć coś takiego za pomocą picture datatype. Wyczytalem że pod V44 jest PDTA_AllocatedPens. Ale ja ograniczam się do V39.
30.09.2021 22:27
[#28]
Re: [C] OS, Kick v39 - v36 (v35) Pytania
@asman, post #27
Na tą chwilę zostawiłem ten problemik, do rozważenia na później... Gdyż w moim podejściu z remapowaniem do ekranu WB zauważyłem dziwną rzecz. A robię to tak
I teraz tak. plik tiles.iff to 8 kolory loresowy obrazek. Ustawiłem sobie do testów WB jako 640x256x1 (dwa kolory). I po zremapowaniu depth wynosi 3. A nie powinien wynosić przypadkiem 1 ? Przecież robiłem remapowanie. A może coś źle robię. Dla zabawy ustawiałem sobie depth na sztywno 1 i kopiowanie kawałka bitmapy do rastportu też działało
Oczywiście i dla detph = 3 kopiowanie kawałka bitmapy do rastportu okna i działa jak trzeba
Tu przykładowy kawałek za pomocą którego kopiuje sobie.
A może to wszystko działa przez jakiś kosmiczny zbieg okoliczności.
//
struct Screen* screen = LockPubScreen(NULL);
Object* o = NewDTObject("tiles.iff", DTA_GroupID, GID_PICTURE,
PDTA_Remap, TRUE, PDTA_Screen, screen TAG_END);
if (NULL != o)
{
DoDTMethod(o, NULL, NULL, DTM_PROCLAYOUT,NULL,TRUE);
result = GfxGetBitmapTiles(o);
DisposeDTObject(o);
}
//...
static int GfxGetBitmapTiles(Object* o)
{
struct BitMap* bm;
GetDTAttrs(o, PDTA_DestBitMap, &bm, TAG_END);
const ULONG width = GetBitMapAttr(bm, BMA_WIDTH);
const ULONG height = GetBitMapAttr(bm, BMA_HEIGHT);
const ULONG depth = GetBitMapAttr(bm, BMA_DEPTH);
const ULONG flags = BMF_DISPLAYABLE|BMF_CLEAR;
bmap = AllocBitMap(width, height, depth, flags, NULL);
if (NULL != bmap)
{
BltBitMap(bm, 0, 0, bmap, 0, 0, width, height,
0xC0, 0xFF, NULL);
return 0;
}
return -1;
}I teraz tak. plik tiles.iff to 8 kolory loresowy obrazek. Ustawiłem sobie do testów WB jako 640x256x1 (dwa kolory). I po zremapowaniu depth wynosi 3. A nie powinien wynosić przypadkiem 1 ? Przecież robiłem remapowanie. A może coś źle robię. Dla zabawy ustawiałem sobie depth na sztywno 1 i kopiowanie kawałka bitmapy do rastportu też działało
Oczywiście i dla detph = 3 kopiowanie kawałka bitmapy do rastportu okna i działa jak trzeba
Tu przykładowy kawałek za pomocą którego kopiuje sobie.
BltBitMapRastPort(bmap, 16, 0, rport, x, y, 16, 16, 0xC0);
A może to wszystko działa przez jakiś kosmiczny zbieg okoliczności.