Realtime modification of the charset is used for paralax scrolling. A part of all the game scenery characters is then reserved for far distance backgrounds. While the whole screen is soft scrolling with a speed of one pixel per frame, the reserved chars are bit shifted in the opposite direction of the overall scrolling. This way they look like moving at another speed or not moving at all." ->link<-
Gonzo: dlaczego uważasz, że na c-64 jest to proste do zrealizowania, a na Atari niewykonalne ? Wydaje mi się, że na obu platformach efekt ten może być zrealizowany w podobny, programowy, sposób. Weź pod uwagę to, że może to zajmować trochę cykli procesora. W Jumpie na Atari np. oprócz tego efektu renderowane są tylko sprajty sprzętowe.
it is :), tak jak pisze Rastan, wszystko się odbywa kosztem cykli, zauważ, że w takim Flimbo`s Quest jest dużo czasu wolnego bo wszystkie obiekty to duchy sprzętowe. Wszystko robi się tak samo na obu platformach, a kluczem do tego jest oprócz przesuwania bitów także dynamiczne rozmieszczanie przesuwanych znaków w pamięci ekranu i tyle
Gonzo: masz już odpowiedź od gorgha. oprócz cykli, które należy wykorzystać na paralax, potrzeba jeszcze cykli żeby narysować sprajty programowe na Atari, a to może być bardzo trudne do zrobienia (aczkolwiek nie niemożliwe). w takim Flimbo's Quest na C-64 procesor rysuje programowo scrolla + nakłada duchy sprzętowe. I to jest szybkie. Dodatkowo na Atari mógłby być problem z 5 kolorem w tym zastosowaniu (więc zostają 4) - tak jak w przykładzie, który podałeś.
- zwykły, uproszczony - gdzie warstwy/tła o różnych prędkościach scrollingu nie nachodzą na siebie (guard, demo shadow of the beast, itp), - wypasiony - gdzie pierwszy plan nachodzi na drugie, trzeci i tak w głąb - prawdę mówiąc tylko crownland pokazuje ten typ parallaxu, a na c64 filmbo quest i zapewne wiele, wiele innych tytułów.
W przypadku tego pierwszego typu, szczerze mówiąc tu nie ma się czym podniecać. Za pomocą manuala do nauki programowania atarowskiego scrolla każdy taki efekt zrobi bez problemu. Wyzwanie to ten drugi typ, tak skrupulatnie omijany przez atarowskich twórców :)
Drugi typ robi się najczęściej skrolując zawartość zestawu znaków. Widać to dobrze np. w grze Turrican na C64. Trudność polega na tym, że oni mają 2x większy zestaw znaków niż my więc mogą szaleć. Zresztą w przykładzie Gonzo to widać równie dobrze.
dokładnie, mono dotarł do sedna. mały zestaw znaków = więcej problemów i więcej zajętej pamięci. dwa razy mniejszy zestaw = circa dwa razy trudniejszy efekt do uzyskania.
128 znakow w zestawie i 12bitowy licznik to najwieksze problemy antica. co ciekawe nawet vbxe nie naprawia problemu 256 zestawu znakow dla standardowej rozdzielczosci :/
Author of the Flimbo's can you say me how you deal with Chars/Charsets?
Did you get all the Lines/Gfxs. into just 1Charset/128Chars or manage it into 3Lines/1Charset.
How much Chars uses the C64 on this Level?
Another thing, a bit off (or not) this Topic: How do you get the Chars? Did you place the C64 Level map .bmp into a Program and get the Chars (like G2F when we import a Picture)?
This is because I want to get a Program where I can simply drop Level Maps and it Rips the Chars. Like just Load an image into G2F, but here it's A8 specific and saves in steps of 128Chars. I want a Program that do this but gets the Chars whatever number they are... Hope you understand what why want and can help me.
I'll try to answer but my English is very bad. ;-( So it's only a short answer. Sorry about this.
>>>Did you get all the Lines/Gfxs. into just 1Charset/128Chars no >>>or manage it into 3Lines/1Charset.
There are 2(3) Areas. One with and 2 without parallax scrolling. I put both areas without parallax scrolling into one font (103 chars). The parallax area is split into 4 fonts: font 1: front chars & background chars for lines 6,10,14 (background 0,4,8) => 117 chars font 2: front chars & background chars for lines 7,11,15 (background 1,5,9) => 113 chars font 3: front chars & background chars for lines 8,12 (background 2,6) => 106 chars font 4: front chars & background chars for lines 9,13 (background 3,7) => 93 chars
Yes, very stupid for next steps of programming (for instance soft-sprites and so on) but o.k for this flimbo demo.
>>>How much Chars uses the C64 on this Level? 233
>>Another thing, a bit off (or not) this Topic: >>How do you get the Chars? >>Did you place the C64 Level map .bmp into a Program and get the Chars (like G2F when we import a Picture)?
no. I've used the charset/datas from the c64 game. (address 0xe000 to 0xe7ff, 0xe800 to 0xefff etc) No detours.
CharLine27&28: Hi-Resol. Bottom StatusArea: Again Charset0
CharLine29: Not used
I get by now 80Chars, more or less, and 48 will probably be enough for SoftSprites (includ.) shifting. Flimbo's seems to be like this, probably if you Scroll the Map you can have Line that have Gfxs. that aren't on the others. A bit like you did, but perhaps different CharLines combinations into Charsets numbers and you will probably reduce, like me, into 80 or so Chars and space for SoftSprites and Shifting.
I always spent many time just Scrolling and see Game Maps first.
Greetings and thanks to take your Time. José Pereira.
+ for the non parallax area ... max 1024 Bytes + for the parallax scrolling area: 4 charsets with max 1024 bytes, every 4 times pre-shifted by atari (shifted 0 bytes, 2 bytes, 4 bytes and 6 Bytes9) 16384 bytes
total 17408 for the complete char set (c64 .... 4*2048 = 8192 ;-( )
I'm sure, with better char sets / an other front and/or background layer you'll need less memory.
I forgot ... 7200 Bytes for layer 0 (front), 2200 Bytes for layer 1 (background) and only some bytes for main programm
@bob_er - to nie mój engine a znaleziony na youtube. Prawdopodobnie także jest stworzony przez piszącego tutaj Alexandra, więc pytanie o zajętość pamięci pewnie do niego.
@gonzo, ja używałem envision, i to zarówno do tworzenia zestawów znaków, jak i map :) Mapy do starballa właśnie powstały w envision. Było tam kilkadziesiąt różnych możliwych kwadracików 2x2, więc zrobiłem ręcznie dwukrotnie mniejszy zestaw do celów rysowania mapy.
A z tym parallaksem w starball, to pomysł przyszedł tak w locie, pewnie w wyniku tego, co na amigę powstawało. Puste pole, byłoby niesamowicie nudne, a cokolwiek tam wstawionego jeszcze gorzej by wyglądało.
@gonzo no problem: front-layer on 0xa250 (18 lines, 0x190 Bytes per line) , background-layer on 0x9990 (10 lines, 0x0dc Bytes per line)
@irwin yes ;-), it's my "child" too ;-)
@bob_er not easy to say, because of my dayly try to optimize it. Code (including player for the music etc too), datas (fonts, music, playeranimations, tables (many tables) etc) ... all in all 20-30k ? +/-5k
