BAZZ 0.7 Windows és DOS kompatibilitás egyszerre Visual C és DJGPP-vel vagy Watcommal.

hi. Folytatván az előző részt most is WINMÓkrol lesz szó azzal a különbséggel, hogy a mostani változat lefordul DOS-ban is. Erre még sok fejlesztés fér rá.Mert most a neve BAZZ 0.7
Természetessen ajánlom ezt win alatt gyengén programozóknak vagy teljesen kezdőknek.
Egy 3d engine íráskor hatrároztam el, hogy megcsinalom ezt az egyszerű, de hasznos enginet. Azért nem használok kettösbuffert, mert a 3d enginemben rögton a framebuffer után helyezkedik el a Z buffa.(az ami a távolság reciptrokát tárolja 32-bites egészként minden képponthoz) Meg azert sem, mert DOS alatt VBE 1.2-vel nincs lfb, meg LINUX-ban sincs. természetessen GUI supportot is lehetne bele adni a késöbbiekben, meg a LINUX support is vissza van.De utobbiakat nem biztos, hogy megcsinálom. Ja GUI support alatt azt értem, hogy win alatt ablakba megy.

Hogy miert jó ez ?
Mert például, ha közösen fejlesztetek és egymásnak mutogatni akarjátok, akkor a win95-ben lazán lehet futtatni rövid kis programokat anélkül, hogy fagynál. Ezt DOS-os programok esetében nem mindig sikerül az embereknek megcsinalni. Fagyni szoktak win95 alatt. Meg egy csomó ember nem is hallott VBE-röl, és 2.0-ról meg főleg nem.

Ezért csináltam egy olyan c-ben és asm-ban irt programrészt, amit megcsináltam win és dos alá is. Ezen keresztül lehet demokat írni. Hang kezelés ugyan nincs benne, de ezt már sokan megoldottál oprendszer és fordító függetlente. pédául: MIDAS (szar mert GUS-on nincs hardware mix, de jól syncronizál) SEAL (Ez tök jó, egyszerű, de nincs docolva, hogy kell syncronizálni, bugosan játsza le a module fileokat)

Hogy mit tud ez ?

Álltalánosan	DOS	WIN
Programozási rendszer: Arra kell odafigyelni, hogy ha WATCOM-ot választassz DOS-os compilernek, akkor a lib és include environment variablékat mindig át kell állítani. DJGPP-nél ez már csak annyi, hogy set djgpp=c:\djgpp\djgpp.env és akkor mindössze egy változót használ és most sem zavar minket, mint WATCOM-nál. Mert a Visual C is lib es include env variableban tárolja a pathokat. És össze szoktak akadni.	DOS alatt a DJGPP-t kell használni, WATCOM compatibilitás is van. A DJGPP free, és kurva jól optimalizál. De ezt most nem részletezem.	WIN alatt az MS visual C kompatibilitást csináltam meg. Ez kényelmes, kis binárikat csinál.
VIDEO engine: Meg kell adni neki a felbontást, a mód mindenképpen TRUE color. ha a kártya nem supportálja a 32-bites true colort, akkor 16 bitesre convertál le. Vagy 15 bitesre, ha az a mode áll be windows alatt.	VBE 2.0 és VBE 1.2 van használva. Megpróbálja beállítani előszőr VBE 2.0-val a módot, ha nem jön össze, akkor pedig VBE 1.2-vel. Ha azzal sem, akkor kilép hibaüzenettel. Szóval lehetőleg ne állítsad fel hamarabb az sound systemedet, ha az erre fagyással tud reagálni. Nincs kettősbuffer lehetőség az enginében, de így is elég jó példa.(összetettebb demóknál néhány helyen még gyorsabb is)	Win alatt a DIRECTX 5.0 DirectDraw-ját használja a mód beállítására. Itt használ kettösbuffert, de képfrissittéssel dolgozik. Frissíti a képet, aztán vált. Ha nincs 32-bites mód, akkor 16 vagy 15 bitesre konvertál attól függően hogy az adott video kártyához a seggfej hogyan írta meg a DX drivert.(itt nincs egységesség) A képfrissítési mód viszont jobb képet adhat, mint a sima képfrissítés.
KEYBOARD handler: Demo írásnál szerintem jó módszer az, ha az ember a billentyűkre teszi be a 3d demóknál a jeleneteket például a kameramozgatást, és azt veszi fel, hogy hogyan nyomta el. Én ezt imádom. Ezert csináltam bele a billentyű kezelést. Felállít egy tömböt charokból és abban van az, hogy éppen melyik billentyű van lenyomva a scan kódok alapján. Egy másik tömbben csak a billentyűlenyomások kerülnek bele, szóval neked kell nullázni. Ez például kilépéskor kell. Például akkor, ha a felhasználó 5ös frame-sec mellett csak 100 msec-ig tehénkedik az ESC-en akkor így mindenképpen érzékeped, holott ritkán checkolod, mert benne marad.	IRQ-t állít fel használva a biztonságos de lassú _go32_dpmi_allocate_iret_wrapper() funkcióját. Ez lebassza az eredeti BIOS vagy szarmagyarkeyboard kezelőt onnan, szóval ne getch() meg ilyenek, azért sem, mert win alatt az nem megy úgy.	Normál windoz billentyű kezelést használ. Nem állít fel sajátot, mert windozban a default is elég jó. Arra figyelj, hogy win alatt lehet, hogy úgy is megy, ha nem hívod meg az inicializálót. Ezért hívd meg, mert DOS-ban nem megy külnben.
timer: Át lehet adni neki, hogy mekkora freqvenciában növeljen egy belső egészet, amit procokkal lehet módosítani, lekérdezni. Ha közben akarsz freqvenciát váltani, akkor utána állítsd be a timer értékét. A settimerrel kell állítani a freqvenciát, egy egészet kell neki átadni, hogy secenként mennyi növelés legyen.	Csinál egy timer IRQ-t, átállítja a timert, hogy a megadott freqvencián hívogassa azt, ami növeli azt a bizonyos értéket.	A winfos GetTickCount() utasítását használja, ami ms-ben adja meg, hogy a winfos elővevésétől számolva hány ms-t sikerült számolnia a winfosnak. természetessen nem azt jelenti, hogy mindenképpen egész szám az a szám, ami a belső timer érték növelései között eltelt időintervallum MS-ben mérve. Mert rendessen megszorozza azt a kért freqvenciával aztán elosztja 1000-el. Nem állít fel timercallback-ot, mert az lassabb windoze alatt.

Természetessen teszteld le mindkét oprendszerben, hogy biztossan menjen mindkettőben. Mert lehetséges, hogy tévedésből nem tartottad be a specifikációkat, és kialakul akkor az oprendszerfüggőség.(ha például elkezdessz DOS funkciókat hívogatni int-el, akkor már szoptál (dos-ban is, mert azt DPMI-vel kell megtenni, hogy biztonságos legyen) vagy éppen olvasgatsz portokat vagy írogatsz a code segmentbe)

Egy fontos táblázat:

WATCOM	OMF 32 bit obj	NASM,TASM	externalproc_
DJGPP	COFF object format	NASM, as, JAS, djasm	_externalproc
Visual C 5.0	COFF object és OMF is	NASM, as, JAS, TASM, djasm	_externalproc
LINUX(még nincs)	COFF object	NASM(portplja már át valaki), as, jas	_externalproc

Annak ellenére, hogy a Visual C coff objecteket használ, meg a DJGPP is ne próbáld meg keverni őket, mert fagysz.Legalábbis akkor, ha a DJGPP objectját Visual C-vel linkeled. Még akkor sem, ha nagyon vonzó, hogy a DJGPP mennyire jól optimalizál. Majd RSXDJNT-vel.

Download version 0.7 (97Kb)

Figyelni kell a NASM kódnál, hogy a datasegmenten legyenek a változók, azaz a section .data után. HA -fobj vel fordítod le, akkor ki kell írni a section .code után az USE32-t. És watcom alatt így kell lefordítani. Ezeket azért mondom, mert ezek nem minden fordítónál jelentenek problémát.

Valamint a WATCOM esetében az externprocokat így csináld (tasm esetében is):

GLOBAL proc_ GLOBAL _proc proc_: _proc:

Egy példaprogram: Kitesz a képernyőre egy true color 2d efektet, és azt animálja. A 2d efekt egy paramétere secenként 140 szer nő.Ez az időzítést mutatja be. Annyi framet rak ki 140 helyett, amennyit a gép sebessége enged. Billentyűzet kezelést is mutat be.ESC-el kell kilépni, a többi gomb, pedig egy kis fehér négyzetet jelentet meg a képernyőn a scan códtól fühhő helyen. A példaprogram lefordul a 3 C rendszer mindegyikében, hogy az is megtalálja benne a helpet, aki WATCOMMAL, meg az is aki DJGPPVEL nyomja a DOS-os változatot. A NASM-ot használtam asm-nak, hogy mennyen DJGPP-vel is, meg mert támogatom. A 2d efekt NASM-ban lett írva. Az efektnek a cuccost (framebuffer címe, etc..) A DATA segmenten adtam át. Vigyázz, mert a WATCOM register calling conversationt használ, a DJGPP meg a VISAUL C pedig stackt. Borland C-vel is működhet az enginém, abban meg lehet állítani. A példa lefordíthatóan bele van inclúdolva az egészbe. Így kell lefordítani: Visaul C: nmake -f makefile.vc Watcom C: wmake -f makefile.wc DJGPP: make -f makefile.dj

Ha valami BUG jelentés, kritizálás, vagy javaslat, vagy ha nem értessz valamit, akkor irjál nyugottan. Lehetőleg az összes címemre, ahogy a link ezt engedi, hogy minél gyorsabb választ tudjak adni. -- Archee/CoNTRACT coder 01dsolt@vpg.hu,soltesz@hotmail.com,archee@sobieski.ml.org