Відео

Ez egy tündérmese egy Mortal Combathoz, vagy egy Doomhoz képest, és akkor az újabb címekről még nem is beszéltünk :)

köszi!

A Game Engine demó esetében, a GEDemo.ras forrásfájlban minden egyes demóeffekt egy külön eljárásba van, tehát teljesen elkülönülnek forrás szinten is egymástól. Az eljárások pedig végig vannak kommentezve. A Menu eljárásban ott van, hogy az 1, 2, 3, 4, 5, 6, 7 gombokra melyik eljárást hívja meg a demó, ami az adott sorszámú rész eljárása. De az eljárás nevek is elég beszédesek, már abból is ki lehet következtetni, hogy abban a demó melyik része van. Ha a 6. demórész érdekel, akkor a Menu() procedure KEY_6 gomb lenyomására meghívott ImagePutRect() eljárásban lesz annak a forrása, ami az image osztály PutRect eljárását demózza. Egyetlen eljárás, minden abban van. Ennél jobban, hogy szedjem szét? A változó deklarációs rész is elkülönül, mindegyik rész elé oda van írva, hogy azok melyik sorszámú demó rész változói. Ezek pedig sorrendben egymás után vannak. Direkt nagyon elkülönítve tettem mindent a forrásba, hogy akit csak egy rész érdekel, az könnyen megtalálja azt.

Amiben fejlesztek, az nem Turbo Pascal (bár nagyon hasonlít), és nem is PC-re / Mac-re, vagy mobilra / tabletre fejlesztek, hanem egy olyan platformra, ahol sem Unity, sem a C# nem létezik, sem semmilyen ismert játékmotor. Igazából már az is egy ajándék, hogy pár éve létezik egy jó, Pascal-szerű fordító, és nem csak Assembly-ben lehet fejleszteni. Ebben a projektben az elsődleges a számítógép, amire a fejlesztés történik, és ez az, ami igazán retro. Ugyanis a gyerekkori számítógépemre fejlesztek, a Videoton TV-Computerre, ami egy magyar gyártású home computer 1985-ből, aminek egy 8 bites Z80 processzor a lelke. A gépben jó esetben maximum 64 kbyte memória van (de volt 32 kbyte-os modell is), ami Unity-vel semmire sem lenne elég, még ha létezne is rá Unity :) Ez gép a Commodore 64 és a ZX Spectrum időszakában élte fénykorát, 1985 és 1990 között. A videósorozat elsősorban a TV-Computer Facebook csoport tagjainak készül, akik pontosan tudják, hogy mi ez a számítógép, és milyen komoly korlátai vannak mai szemmel, így mekkora kihívás rá valamilyen épkézláb játékot összerakni. Meg persze mindenki másnak is, akiket érdekelnek a 8 bites retro számítógépek, és az ezekre való játékfejlesztés.

??? Ha ez nekem szólt, akkor valószínűleg téves "hívás" :) Sosem voltam Lénárd :)

@@BerySoftTVC Akkor VHS Henrik? vagy VHS Salamon?

@@bencemeitert5146 bocs, de abszolút nem :) Nem is hallottam még ezeket a nickname-eket, és Spectrumom sem volt soha. Bery néven vagyok 1986 óta.

@BerySoftTVC Miért TVC? Retrogamingesként tevékenykedsz?

@@BerySoftTVC Dark Basic-ben fejlesztettél valahán valamit?

A TVC is kész volt már 1985-ben is, 1986-1987-ben csak bővítések érkeztek hozzá, mint a memória bővítő a 32k-s géphez, a floppy interface kártya, és a soros - és párhuzamos kártyák. Illetve 1986-ban a 64k-s gép a kezdeti 32k-s után, és valamikor utána a 64k+. Ezekben továbbfejlesztett BASIC is volt, ami azért nem volt egy nagy váltás, és a visszafelé kompatibilitás miatt nem is nagyon használták ki a BASIC játékok sem. De az alap TVC is teljes volt, és a játékok 99%-a az alap TVC-re készült, nem használt semmit a későbbi hardver kiegészítőkből, legfeljebb a 32k-s memóriabővítő jöhetett jól, ha nem 64-k-s gépe volt az embernek. Viszont kevesebb színt kezelt, mint a C-Plus4, és a hangképzése is szegényesebb, amik felróhatóak a szűkösebb tervezési- és fejlesztési lehetőségeknek, aminek egyik fő oka a COCOM-lista jelentette korlát volt. De más tekintetben meg fejlettebb volt a a TVC a VT-DOS által, és a PC kompatibilis lemezkezeléssel, és a 4 bővítő slot által is. Persze, ez inkább az üzleti, vagy professzionálisabb felhasználás szempontjából volt (vagy lehetett volna) előny, amit szintén nem sikerült olyan mértékben kiaknázni, mint amennyi lehetőség lett volna ebben. Egy PC-nél lényegesen olcsóbb üzleti gép lehetett volna a TVC, miközben fájl szinten hordozhatóak lehettek volna az adatok egy PC és a TVC között. De mivel a vállalkozások száma, és ezzel együtt az üzleti szoftverekre való igény inkább a rendszerváltás után ugrott meg, amikorra a PC-k ára is már lényegesen alacsonyabb volt, a TVC támogatása pedig megszűnt, így ez a ziccer is kimaradt. A TRSE pascal-szerű nyelve és a Game Engine unit csak az egyik lehetőség a TVC-re való fejlesztéshez. Ezen kívül még Major Tom kiváló fejlesztőeszköze is rendelkezésre áll, a DevTool, amihez a GameLib biztosít magas szintű támogatást játékok készítéséhez. A DevTool-ban Assembly-ben és C-ben is lehet programozni TVC-re, és még egy beépített pályaszerkesztőt is tartalmaz. A DevTool fejlesztés alatt álló új verziójában pedig nem csak TVC-re, de Enterprise-ra, Primo-ra, és HomeLab 2-3-ra is lehet majd fordítani. A DevTool-hoz is létezik tutorial videósorozat: ua-cam.com/play/PLgiPdks9_cRQR3i--Sn8YwSt6SuoWT9QO.html A DevTool fejlesztőeszköz a tvc.hu weboldal Programfejlesztés menüpontjából tölthető le.

Nem, sajnos nincsenek hardware sprite-ok a TVC-ben, mindent szoftveresen kell megoldani. A VIDEOTON mérnökei a '80-as évek vége felé elkezdtek ugyan fejleszteni egy sprite kártyát, de a prototípus akkora volt, mint egy PC (lásd tvc.hu - Sprite Modul menü), és nem jutott már el abba a fázisba, hogy egy chip-re ültessék át a bonyolult elektronikát, mert az olcsó Commodore Plus/4-ek elárasztották a magyarországi piacot, így nem volt már üzletileg értelme befejezni ezt a fejlesztést. Sajnos. Ahogy a már kártya formában is létező hangkártya prototípus sem került sorozatgyártásra. Kár ezekért, meg hogy nem pár évvel korábban kezdődött a fejlesztésük, ahogy a TVC is valamivel sikeresebb lehetett volna 1-2 évvel korábbi megjelenéssel.

Minden videó leírásában linkelve van az a Game Engine unit, ami a videóban használva van. A Game Engine, ha nem is mindig, de többnyire folyamatosan fejlődik, és én mindig a legújabb verziót használom.

Nem volt leírva a szöveg, így azt nem is olvasta fel senki :)

A videót PC-n, TVC emulárból vettem fel, ezért is akad néha, mert a Windows folyamatok "beleszólnak". Nincs hardware sprite TVC-n, minden sprite szoftveres.

A videó chip típusára vonatkozott a kérdés hogy milyen videó chip van a tvc-ben?

@@gaborm4767 egy CRTC 6845-ös képernyővezérlő van benne, ami tudtommal nem sok mindent csinál, kb. kimásolja a VIDEORAM-ot a beállított képernyő paraméterek alapján. Eredetileg karakteres képernyők vezérlésére tervezték (amilye a TVC-nek egyébként nincs), de a széles paraméterezhetősége miatt kisebb felbontású grafikus képernyőkhöz is használható. CRTC 6845 van az Amstrad CPC-kben is, csak ott még egyéb hardveres lehetőségek egészítik ki, így például függőleges pixeles hardver scroll is megvalósítható vele, ami TVC-n sajnos nem lehetséges. Illetve egy trükkel megvalósítható, szoftveres rásegítéssel, csak éppen azt nem tolerálja a TV-k túlnyomó többsége.

Terveztek hozzá egy ún. "sprite modult" is, de az sajnos nem jutott túl a prototípus fázison

Nem találom most, hogy ki lehet az eredeti előadó, de ez egy '70-es '80-as évekbeli zeneszám, amolyan Vangelis, Mike Oldfield vonal. És igen, nekem is rémlik, hogy használták valamelyik rádiós vagy TV-s műsorban.

Vangelis, Pulstar

@@AppCruiser köszi!

@@BerySoftTVC Köszi a válaszokat!

Yes, I'd like to see the new TVC Game Engine unit and the demo included in the official TRSE release, but I'm still optimizing and improving it daily and want to give you a clean version. I plan to do this in 1-2 weeks. Thanks.

Nem, ezt még 2022-ben készítettem, amikor még nem volt a TRSE-nek TVC támogatása. Ezt, ebben a sebességben nem lehetne a TRSE / Game Engine-nel megcsinálni, mivel abban általános rutinok vannak, itt pedig speciálisan a játékban levő sprite-okra van megírva a kirakó rutin, ami csak ezt a méretet tudja, de emiatt gyorsabban. Persze, ezt speciálisan meg lehetne írni saját assembly betétekkel TRSE-ben is, és akkor a sprite kirakás hasonló sebességű lenne, csak a vezérlés Rascal kódja lassítana rajta valamennyit a videóban látottakhoz képest. Majd ha lesz egy kis időm, készítek egy tesztet, hogy TRSE / Game Engine-nel hány sprite férne bele egy ugyanilyen játékban, ugyanezekkel a sprite-okkal.

@@BerySoftTVC igen, túl szép lett volna a Trse-ben ez. Köszi a loop-al kapcsolatos segítséget délután. Azóta már 8 sprite-ot definiáltam, próbálkozom az @ tvc rutinokkal is. Csakhát egy megoldott feladat 5 kérdést szül. De nem bombázlak vele, várom a videósorozat további részeit. Üdv:András

Itt a lehetőség, az oktatóvideók alapján le tudod fejleszteni magadnak (meg másoknak) :)

Nem. És, jelentett ez bármi problémát a videóban? :) Simán lehet így is kezelni 2 dimenziósként egy 1 dimenziós tömböt. De egyébként egy saját típus definiálásával még közelebbi megoldást is össze lehet hozni a 2 dimenziós tömbhöz, ha szükség van rá. De a memóriában egyébként minden tömb 1 dimenziós, csak egyes nyelvek ezt elfedik elöled. Ez viszont plusz utasításokba, és proci időbe kerül mindig. De ahogy fentebb is írtam, nem nehéz ehhez közeli megoldást alkalmazni TRSE-ben sem, ha szükséges. De az mindig lassulással jár (a BASIC-ben is, más nyelvekben is), szóval ha lehet, nem árt kerülni a több dimenziós tömböket.

Közben megnéztem az 5-dik részt is. :D

Sajnos a TRSE Rascal nem kezel előjeles számokat. Gondolom a pozitív egészek egyszerűbb kezelhetősége miatti jobb sebesség lehet az oka, mivel első nekifutásra kifejezetten demók fejlesztésére készült a nyelv. De emiatt valóban szerencsésebb lett volna az integer típust word-nek elnevezni, de valamiért nem így döntött a fejlesztő.

Bennem is ez fogalmazódott meg, hogy nem látok negatív, illetve tört szám kezelést. A negatív még meg is oldható eltolással, de a lebegő pontos hiánya már érdekesebb. @@BerySoftTVC

@@ATLAB az alap Rascal nyelvben nincsenek lebegőpontos számok, de van mellékelve egy "smallfloat" unit, amiben ez meg van valósítva. A unitban levő eljárás segítségével létre lehet hozni 16 bites foat változókat byte, integer és string változókból. Ebben a unitban vannak még eljárások float to float értékadásra, összeadásra, kivonásra, szorzásra, osztásra és összehasonlításra. A unit assembly-ben van megírva, így elméletileg relatív gyors, bár én még nem próbáltam. A unit leírása szerint: SmallFloat provides 16-bits (2 bytes) floating point numbers. They have 1 bit for sign, 8 bits for exponent and 7 bits for mantissa.

Köszi! Ez egy első, részben kísérleti videó volt, amiből én is tanultam. Az extra nagyítások többsége valóban felesleges volt. Köszi az észrevételt! A forrásszövegeknél azonban valószínűleg alkalmazni fogom a következő videókban is azt, a kb. 150%-os nagyítást, ami talán fel sem tűnt. Monitoron nézve talán szükségtelen, de ha valaki TV-n nézi, több méterről, ott lehet, hogy nem árt :)

I looked at the Wiki article, and yes, they write about how this scroll works. Two registers in the CRTC 6845 can be used to determine which line of the VIDEORAM to start the screen drawing. If the address of the start row is changed, it will cause a scroll. This can be varied by logical character, so it can also be used for horizontal scroll. Scrolling a whole row of logical characters will result in a vertical scroll. On the VIDEOTON TV-Computer, a logical character is 4 pixels high, so that scrolled vertically by 4 pixels. Unfortunately, it is not suitable for smooth one-pixel scrolling.

Egyelőre teszt, meg erre az évre megvan már a projekt, de aztán úgy se bírom ki, hogy ne készüljön majd ebből egy játék TVC-re :)