>Tanacsot szeretnek kerni grafikus uzemmod hasznalataval kapcsolatban.
>Egy DOS alkalmazasrol volna szo, ahol a lenyeg, hogy minel nagyobb
>felbontasban, nem tulzottan nagy szinmelyseg igennyel, minel gyorsabban
>tudjak grafikus kepernyot kezelni. Tul sok folyamatosan mozgatando adatom
>nincs (nem videolejatszas vagy hasonlo).
>Amit szeretnek: valami olyan uzemmod, aminek a hasznalatahoz nem kell minden
>videokartyara kihegyezni a programot (VESA?), minel nagyobb (mondjuk
>1024x768) felbontas (de az elozo szempont fontosabb), es mondjuk 256 szin
>(esetleg 32k/64k).
>Azt mar tapasztaltam, hogy a BIOS hivasokkal nem erdemes kezelni a
>kepernyot, mert lassu, de hogyan lehet gyotsabban (kozvetlenul)? Ezen a
>teren csak az egyszeru 320x200 felbontast hasznaltam, azt is csak
>probakeppen...
>Megvalosithato ez valahogyan (egyseges vezerles, nagy felbontas, jopar
>szin)? Hol talalok ezzel kapcsolatban valami leirast, utmutatot, peldat?

Hali!

Nekem is szuksegem volt mar hasonlo felbontas/szinmelyseg kezelesere. En
vegul vedett modban irtam meg, BP70 alatt. Hasznaltam az LFB-t (Linear
Frame Buffer), igy kozvetlenul a videomemoriaba irtam, lapozas nem
kellett. Ennek csak az az egy hatranya volt, hogy minimum 2.0-as VESA
BIOS-nak kell lennie a gepben, vagy futtatni kell egy "BIOS frissito
programot", ami lehet pl. egy SciTech DisplayDoctor. Nekem ez a modszer
bevalt. 1024x768 24bites szinmelyseggel baromi gyorsan tudtam rajzolni.
Amugy itt csak arra kell a BIOS, hogy a felbontas beallitasakor
engedelyezni tudd az LFB hasznalatat.

                 Hali
                              Benji

CODER #1112, :
>A proggynak akkor kell menteni, ha a vizsgalt fajl
>megvaltozik. Ezt hogyan lehet megcsinalni (az eredeti
>alkalmazas tudta nelkul)?
>
>A fajl vizsgalatara van vmi okossag vindozeba,
>lehet figyelni kernel obj vagy nezzek ra x mseckent?

Ez a legegyszerubb, es szerintem eleg jo megoldas is.

Udv,
		Hunter				-[HE 1.15beta6]-
"A legrosszabb, amikor a hulyeseg akaraterovel parosul."
MMI MLI

CODER #1112, :
>Egy DOS alkalmazasrol volna szo, ahol a lenyeg, hogy minel nagyobb
>felbontasban, nem tulzottan nagy szinmelyseg igennyel, minel gyorsabban

DOS platform, tehat gondolom Pascal vagy C lenne a programnyelv, igaz?
Ezekhez van BGI, ami tamogat nagyobb felbontast is.

>Amit szeretnek: valami olyan uzemmod, aminek a hasznalatahoz nem kell
minden
>videokartyara kihegyezni a programot (VESA?), minel nagyobb (mondjuk
>1024x768) felbontas (de az elozo szempont fontosabb), es mondjuk 256 szin
>(esetleg 32k/64k).

SVGA256.BGI: max. 1024x768, 256 szin
SVGA16m.BGI: max. 1024x768, 16 szin, eger tamogatassal, HKK.

>Azt mar tapasztaltam, hogy a BIOS hivasokkal nem erdemes kezelni a
>kepernyot, mert lassu, de hogyan lehet gyotsabban (kozvetlenul)? Ezen a
>teren csak az egyszeru 320x200 felbontast hasznaltam, azt is csak
>probakeppen...

320x200-ban egyszeru a dolog, az $A000:0000 cimnel kezdodo szegmens tarolja
a pixeleket.

Nos, a bgi nem tartozik a gyors megoldasok koze, de eleg egyszeruen
kezelheto.

Udv,
		Hunter				-[HE 1.15beta6]-
MMI MLI

CODER #1111, :
>Hasznalhati e az embor 1 kep tomorijjesere?

Nem hinnem, hiszen ez pont mozgokepre van kitalalva, raadasul igencsak
veszteseges...

>Hogyan muxik a DivX algo???
>[...]
>p.s.: A Project Mayo-n mogvan a forrasa

Ha mogvan a forrasa, akkor abbol kiderul, hogyan mukodik, nem?

Udv,
		Hunter				-[HE 1.15beta6]-

hi Coderz!
>amit szeretnek: valami olyan uzemmod, aminek a
>hasznalatahoz nem kell minden
>videokartyara kihegyezni a programot?
ez sajnos nem lehetseges. vesat kell hasznalnod.
viszont c-ben meg asm-ban (mem>64k) hasznalhatsz un.
linear frame buffert, igy a videomem-t linearisan
tudod kezelni, akar a 320x200 modnal, nem kell lapozgatni.
en ebbol nem sokat tudok (nagy pascalos letemre),
de nezd meg a prog.hu-n a cikkekben.
remelem segitettem.
es 1 kerdes: tudom hogy orultseg, de nem tudna valaki
infot dos alol hosszufajlnevek lekerdezeserol?
megkoszonnem.
thSoft

Sziasztok !

Lenne egy kerdesem a parhuzamos programozassal kapcsolatban:

Win32-ben szeretnem megoldani a kovetkezo problemat:

Adott egy szal (thread), ami tobb helyrol is kaphat esemenyt,
amire reagalnia kell. Ezek kozott van event, es van anonymous pipe is.

Elso latasra egyszeru lehet a problema, egy
WaitForMultipleObject - be beadom neki az elobbiek handlejet, es
akkor eszre fogja venni, barmelyik iranybol szolnak hozza.
Ez tokeletesen mukodik ha csak eventekre kell varakozni, de
a pipeokkal baj van.
Azt olvastam hogy az anonymous pipe nem tud aszinkron i/o modban mukodni,
ez pedig azt is jelenti hogy nem varakozhatok ra WaitForMultipleObject-el.
Ezek utan merul fel bennem a kerdes, hogyan lehet egyszerre tobb pipe-bol
olvasni ugyanabban a szalban?

Konkretan arrol van szo, hogy egy program elindit ket konzol
modu programot, azok stdout-jat beleiranyitom 1-1 pipeba,
es az ezeken erkezo adatokkal kell dolgoznia az indito programnak.

- Tamas -

Ui.:
Valaki kerdezte, hogyan tudja eszrevenni, ha egy file megvaltozott.
(file automatikus mentese celjabol)

A WaitForSingleObject vagy WaitForMultipleObject fuggvennyel varakoztathatod
a szalat "Change notification" esemenyre.
Ezt az eventet FindFirstChangeNotification fuggvennyel inicializalhatod.

Hali!


>Van valakinek leirasa a Blinkerrol?
Norton Guide van ha kell.

>Elsosorban a SwpRunCmd fuggveny parameterezese, es a
swpruncmd('mit',0) kell neked, akkor minden memoriat oda ad neki
elotte az swpuseems(.f.) swpusexms(.f.) ajanlott,
van valami kornyezeti valtozo ertek a set clipper-hez, hogy
ez EMS memoriat ne kavarja ossze, talan BADCACHE ?
ez sem art (Ezek nelkul megesik, hogy nem ter
vissza a progi futtatas utan...)
ez EMM386 NOEMS marhasag. Definialj neki EMS-t
akko gyorsbanna fut! (Javaslom inkabb a QEMM-et, haDOSos a gep)
de! Smartdrv ne fusson, mert azzal osszeakad... :-((
az swpruncmd-nek megadhatnad, hogy hova swappelejen, de
az nem muxik jol :-((


>C modulok beszerkesztese erdekelne.
linekelesnel csak megadod az obj file nevet, csak ne ez legyen az elso
a C forditasakor csak x86os utasitasokat hasznlahatsz, kapcsolj ki minden
optimalizalast (register variables-t is!)


>Fut nalunk egy Clipper 5.2-vel forditott program.
>Rendszeresen leall "Conventional memeory exhausted"
a megodlas :QEMM 7xx K free memory-t tud dos alatt :-)
De ha az EMS-t bekapcsolod, akkor mar javulni fog a helyzet,
mert a Clipper szereti ha van :-)
Ha nagy tablat kell indexelni, akkor is megeshet... :-((
Azon meg egy ido utan nem tudsz segiteni ...


>uzenettel. A keszitoje szerint a config.sys-ben
>az emm386-hoz a noems parametert kell megadni. Ekkor
RAM es legyen neki EMS :-) (A QEMM meg mindig jobb :-))

>A keszito szerint az egesz oka a beszerkesztett portkezelo
>es egyeb C fuggvenyek (merlegadatokat olvasunk be). Ezek
>miatt nem tudja a Blinker kulonbozo lehetosegeit kihasznalni.
ez butasag. Ha csak nem valami nagyon spac allat
C progit irt, direkt memoria kezelesekkel ...
Nekem Portolasok meg "sima" memory kezelesek mennek
mint a szel!

>A C fuggvenyeket mi irtuk, ugy, ahogy az _eredeti_ Clipper
>kezikonyv eloirta (MSC 5, large model, stb.). Nehany evig
>hasznaltuk is mas Clipper programokban (persze Rtlink-kel
>szerkesztve), es nem volt veluk gond.
akkor itt sem lesz.

Potyos

Hello!

>Toth Peter:
>A clipperrel kapcsolatban nekem az a tapasztalatom, hogy az
>rtlink kisebb memoriaigenyu es gyorsabban futo kodot general.
mint a Blinker? RTlink melyik verzioja a Blinker melyik verziojahoz kepest?
:-))

>Ahhoz, hogy kulso programot, pl. pkzipet tudj futtatni 590-610
>kozotti memoria kell. A pkzipnek erdemes az 1.x valtozatat
BLinker 3.0 tol mar tudja az SwpRunCmd-t ahol a teljes progidat
kiswapolja igy eleg nagy memoriad marad a futtatasra :-))

>hasznalni, mert annak roppant kicsi a memoria igenye. A programot
>is erdemes szetdarabolni belso overlayre, ezzel is lehet csokkenteni
Blinker nel nem kell, mert minden egyes proc ot es func-ot kepes
egyenkent overlayolni, nem kell semmit beallitanod hozza...

Potyos

Hello!

Az az igazsag, hogy mar nagyon regen foglalkoztam ilyenekkel, de a neten a
programmers paradise-ban biztosan talalsz jo sok peldat.
Ne eld bele magad nagy eredmenyekbe, mert annak idejen (gondolom tobbnyire
ma is) minden videokartya egeszen sajatosan volt kedves kezelni a nem
standard uzemmodokat. Arrol pedig, hogy milyen videokartya van bedugva
megint eleg szabvanytalanul tudtunk infot nyerni. Az egyiknel hol ide kellet
beirni egy erteket, masik kettot visszaolvasni, stb... Esely sem volt egy
altalanos driver, vagy detector irasara.

Azert sok sikert.

Robi
---
E-mail: 
ICQ: 96586562
Egyszer volt, hol nem volt, az operacios rendszeren is tul...
---