Szevasztok, Szevasz Bagoj!

>Felado :  [Hungary]
> adott: class class1{int var1; class class2{...}; class2 myClass2;}; Nos
azt hogyan tudom elerni hogy myClass2 (vagy egyaltalan egy class2 ami class
1 peldanya) lassa var1-et? >
>Ezekszerint mindenkeppen muszaly a class2 konstuktoranak class2(class1*
pParent) formajunak lenni, ahol atadom a szulo (vagy micsoda) cimet? Ja es
akkor arrol nem is beszelve hogy utana indirekcioval kell pParent->var1
modon megcimezni azt a csorikam valtozot. >

Igen, pontosabban a parameter erteket atadod egy osztalyon beluli class1*
tipusu valtozonak:

// a constructor-ban
Par = pParent;

// egy tagfuggvenyben
valami = Par->var1;

//egy masik "lepcson" levo osztaly valtozojanak hasznalata
valami2 = Par->myClass5->barmi;

> de ha mar 15-16 lepcsom van akkor nem valami takarekos modszer >

Az alsobb "lepcsokre" is az elso lepcsore mutato mutatot adsz tovabb, igy
barmelyik lepcsore tudsz hivatkozni barmelyik lepcsorol. Ez az irasmod
raadasul tukrozi, hogy valojaban mely osztalyokrol van szo. Azt is
megtehetned, hogy

Rovid = &Par->myClass2->myClass3->myClass4->myClass5;
valami3 = Rovid->barmi;
// erre nem eskuszom meg, hogy helyesen irtam le

Ez az irasmod rovideb, csak eppen az nem derul ki belole, hogy mi is
*barmi*.
Egy szemleletesebb pelda:

ClEmber* Jozsi, Bela, Mari;

Hagyomanyos modon:
Jozsi->Lab->Ujj->Nagyujj
// tudom mirol van szo!

Rovid = &Jozsi->Lab->Ujj;
valami3 = Rovid->Nagyujj;
// nem tudom mirol van szo, kinek az ujja, lab vagy kez ujj, esetleg ruha
ujja?!

> raadasul debugolhatatlan etc. >

CBuilderben nem okoz semmilyen problemat, gondolom mashol sem.

(Ment listara es maganba.)
Cap
http://web.axelero.hu/torszoft/  (Szovegesinformacio-kezeles)

Kedves Starters és Mindenki !
> cel az volt, hogy a 8085-osre irt programok a szegmens beallitasa
> utan futtathatok legyenek. Ez igy is van, ilyenkor a szegmens fix,
> a program pedig max. 64kB
Jo, de hat attol, hogy ketszer 16 bitet egymas melle' teszunk,
me'g megmeradhatott volna ez a kompatibilitas.

>en sem ertem, hogy miert nem csinaltak a processzort olyanra,
>hogy 8 bittel tolja el a cimet es a szegmens felso 4 bitjet eldobja.
Nem ertelek. Ez gyakorlatilag ugyanaz lenne. Tologatas.
De miert nem teszik egymas melle a ketszer 16 bitet??
             ---
Ott tartottam, hogy a papirra iro periferiat lecserelte'k kepernyosre,
aminek mindenkeppen kellett egy kulon memoria.
VideoRAM tartalma = kepernyotartalom, 1bit = 1pixel. (kezdetben...)
Ezt a RAMot a helyi HW csak azert olvassa, hogy az elektronsugarat
vezerelje vele (egyelore ki/be es monokrom).
Ahogy a papiros irogep is IO-n at kommunkialt, kezdetben a videoRAM
is IO-n at kerult frissitesre. Unix volt ilyen. (Starters mondta :-))
A masik modja a kepernyotartalom frissitesenek, hogy a videoRAMot
nem IO-n at irogatja a szgep, hanem beilleszti a sajat RAMjaba,
marmint a cime szerint. Ilyenkor a valodi RAM azonos cimu reszet
nem hasznaljak (vagy atcimzik de ezt me'g hagyjuk).
A videoRAM viszont fizikailag a videokartyan van. A kartya HW
(+ a szinten beillesztett ROM rutin?) intezi, hogy a normal RAM
reszenek tunjon, na meg az analog videojel eloallitasat.
A keptartalmat sokfele keppen lehet ta'rolni, ezert a kartya HWnek
a videojel eloallitasahoz mindenkeppen tudnia kell, hogy hogyan
ertelmezze a biteket, bajtokat. Azaz hany bit vagy hany bajt hataroz
meg egy pixelt. Es hogy hogyan. A videoRAM ertelmes feltoltesehez
szinten kell egy BIOS rutin, hogy a felhasznalo ne a videoRAM
cimeivel vacakoljon, hanem eleg legyen megadni a kirajzolando
pixel helyet es szinet. Meg ugy altalaban a kep tulajdonsagait.
A videoszabvanyok eltero felbontast es szinszamot jelentenek,
de nem feltetlenul kolcsonosen egymas rovasara. Emiatt eltero
szabvanyu kepek eltero mennyisegu memoriat igenyelnek.
A szininfo mellett villogasra vonatkozo bit is lehet.
Ha 1 pixelt csak 1 bit jelol, akkor a tinta es hatter szinet
mint a kep egeszere vonatkozo infot kell megadni.
De legalabbis karakterenkent megadhato.  Starters irja:
> CGA: szines, grafikus (max. 320*200*4 szin - de nem akarmelyik 4,
> hanem ket keszletbol valaszthato <egy szin szabadon valaszthato, de
> szinte mindig fekete kell, hogy legyen, mert gr. modban ez a keretszin is>
> = 16kB - C8000-tol)
320*200*2 = 128 000bit = 16 000bajt = 16kB = 15,625KB. Stimmel.
De mi az, hogy keretszin egy PC-n? Mint a Spectrumon a border volt?
Es miert van ez a ket keszletbol valo valaszhatosag?
Az egesz kepernyo vagy a-b-c-d szinekbol vagy e-f-g-h szinekbol all?
(kizaro vagy) Hogyhogy 1 szin szabadon valaszhato? Miert csak 1?
Nem egeszen ertem.

>CGA-tol folfele letezik egy 160*100*16 szinu felbontas is,
160*100*4bit = 64000bit = 8000 bajt = 7,8125KB. Stimmel.
> nincs belole ket lap, pedig a felbontasbol kijonne
Tenyleg pont kijonne.
Na most jon az a kerdes, hogy mitol fugg, hogy egy kartya nem
CGA hanem pl. EGA? Nagyobb memoria es egyre tobbfele keppen
ertelmezhetok a videoRAMban tarolt bajtok?
Hiszen a feltoltes csak a (szinten beillesztett?) BIOS rutin dolga.

>Herc: monografikus (kb. 720*350 egyszinu, 64KB)
720*350*1bit= 31500bajt = nem tul kerek szam...  :-((
> 2 lap: az elso kezdete C0000, a masodike C8000.
A kulonbseguk valoban 32KB. Belefer.
> SW trukkel megoldhato ugyanez a felbontas, 2 szinarnyalattal
> - de 25 Hz frekvencival, es mindket lap kell hozza
> + egy rezidens program.
1 helyett 2 arnyalat, cserebe mindket lap kell hozza, ez OK.
De hogyan jon ide a 25Hz? Gondolom ez a kiolvasas sebessege,
de hat annak mi koze a felbontashoz vagy a szinarnyalathoz?
Egyebkent talan 50Hz lenne? Egy monitor megsem TV.

> Az MDA ugyanez, de csak 80*25 karakteres, 4kB RAM-mal.
MDArol toled hallottam eloszor.  4000bajt / (80*25chr) = 2 bajt / chr.
Itt talan ascii kodokat ir a szgep "videoramba"?
A kartyan van karaktergenerator, ami feltolti az igazi,
folyamatos kiolvasas alatt allo videoramot? Hogy van ez?

>EGA: itt mar programozhatoak a szinek: egyszerre 16 szin lathato a
>lehetseges 64-bol, max. 256KB RAM. Kegyetlenul bonyolult a kezelese.
Hogyhogy itt mar proghato'k a szinek? Mit ertesz azon, hogy proghato'?
Beallithato? A CGA-nal talan nem voltak azok??

>VGA (nem SuperVGA): mindharom szinosszetevo 8 biten programozhato,
>igy gyakorlatilag barmilyen szin beallithato - egyszerre max. 256 latszik.
Miert is van ez az egyszerre-max.256 megkotes? Egy pixelre ezek szerint
itt is csak 1 bajt jut, es elore kell szinhalmazt valasztani??

>> Odaig oke, hogy nincs procija, de akkor minek neki sajat BIOS?
>Azert, hogy a gep intelligensen tudja kezelni a kartyat (a nem
>szabvanyos reszeit is - a videomemoriak fizikai megvalositasa nagyon
>elvetemult) es legyen rajta egy rutingyujtemeny a kiiratashoz. A fo BIOS
>csak CGA/Herc. kezelo rutinokat tartalmaz.
Ertem! A sok foRAMba "beillesztett" kulso RAM es ROMrol jut eszembe,
ennyi erovel nem is ertem, hogy minek kellenek driver progik a
legkulonbozo kutyukhoz, amiket a PChez kapni.
Mindegyikbe tehetnenek egy ROMot, amint minden rajta van. Nem?
Ismet csak megkoszonni tudom, hogy oltod, oltjatok tudasszomjamat.
BM

>Nezegettem az uj DirectX leirasat, es a 8-as verzio ota 
>egybeolvasztottak a Direct3D-t, es a DirectDraw-t.

Ha-ha. "Egybeolvasztottak", vagyis teljesen kiszedtek a DD-t.
Nagyon nem tetszett ez nekem akkoriban.
D3D8 mar elegge eroforrasigenyes, tenyleg ujabb gepekre
talatak ki. Tobb regebbi videokartyat mar fel sem ismer, mint
hardveres eszkozt! Orulhetsz, ha TNT v. TNT2-vel egyidos
kartyak mennek vele. A szoftveres renderelest meg total elfelejtettek!
(RGB, Ramp device)
2D muveletekre nem is igazan alkalmas. D3D9-ben mar
visszahoztak egy-ket 2D dolgot, de az sem az igazi.

> A kerdesem az lenne, 
>hogy ha pusztan, es szigoruan 2D alkalmazast szeretnek irni, akkor 
>melyik az elonyosebb: hogy az uj Direct3D-t hasznalom, vagy a regi 
>DirectDraw7-et?

Termeszetesen ilyenkor csak a DD johet szamitasba. Aki 2D programot akar,
az DD7-et hasznaljon. (Ez egyebkent a MS hivatalos allaspontja is.)
DX8 es 9 mar eleg gepigenyes, es eleg gazdasagtalan es felesleges
lenne 3D feluleten 2D muveleteket vegezni.

Es ha mondjuk a 3D programodban nem akarsz shadereket,
akkor meg a D3D7-hez is nyugodtan visszaterhetsz!
Tehat regi gepeken is megy a jatekod!
Szerencsere a DX visszafele kompatibilis, ugyhogy szerintem 50 ev mulva
is futnak majd a programok :)

Irtam egy csevegoprogramot DPlay8-ban, de iszonyu sok memoriat foglalt
es meg prociidot is evett. Tehat visszaestem DPlay7-re, ami kicsi,
gyors, kevesebb eroforrast hasznal. Eros a gyanum, hogy az
optimalizalassal mar nem sokat torodnek a 2GHzes procik es
gigabajt memoriak idejeben. Szep jovo...


LutheR

Itt design kerdes lesz a gond.

Egy lehetseges megvalositas (arra amit te szeretnel): 
http://emil.alarmix.org/tejfel/files/main.cpp

Amugy en valsz mashogy csinalnam. A move-nak inkabb parametere lenne valamilyen
 formaban az elvegzendo mozgas parametere.

(webes bekuldes, a bekuldo gepe: adsl66.226.axelero.hu)

>From: 
[...]
>>Mindeddig maga a szamitogep nem foglalkozott semmit se a
>>kepalkotassal, azt a konzol hardvere, vagy a kesobbiekben az abban
>>levo mikroprocesszor vegezte. Aztan a tomegcikk PC-khez ez tul draga
>>dolog lett volna, es hat vegulis a fo CPU is meg tud csinalni
>>mindent, ugyhogy onnantol kezdve kezdtek kihalni a specializalt
>>konzolok, es jottek be a monitorvezerlo aramkorok illetve kesobb
>>kartyak.
>
>Pillanat. Volt ez az okos konzol, ami akar vonalat rajzolni is tud,
>es csak meg kell mondani neki (IO-n at), hogy mit rajzoljon.
>Ha ebbol alakultak aki a kartyak, az OK, de akkor most mi is az a
>feladat, amit megis visszavett a fo CPU? Ertsem ugy, hogy a kartya
>feladata maradt a regi (ami a konzole' volt) csak eppen gyakorlatilag
>ezt nem sajat procival szamolja, hanem megszakitasok utjan
>"idonkent kolcsonkeri" a fo CPUt, hogy majd az pakolgassa a kartya
>memoriajaban a keppontokat jelento biteket?
>Innen ered az, hogy manapsag a videokartyakra megis rakerul
>egy izmosabb sajat proci, hogy ne terjelje a fo"CPUt?

Pl. egy konzol tudott vonalat rajzolni. Aztán ezt a logikát kivették
belőle, hogy olcsóbb legyen, így sima monitort kaptunk, ahol a CPU
rajzolta a vonalat. Eltelt 15 év, és eljutottunk oda, hogy a CPU már nem
simán vonalat rajzol, hanem textúrázott poligont árnyékol (pl. Forma-1
szimulátorban kiszámolja, hogy nézzen ki a pálya). Ez viszonylag
speciális feladat, ezért kitalálták, hogy csinálja meg egy célprocesszor
(ezt tették rá a 3D-s gyorsító kártyákra), hogy közben a főprocesszor
tudjon Schumachert játszani ellened, meg figyeljen az ütközésekre, stb.
Ez persze plusz költség, de úgy látszik, hajlandóak megfizetni a
felhasználók.

[...]
>Megsem ertem. Az intelligens konzolnak, ami egy monitort
>hajtott meg, annak is kellett birnia egy sajat kepernyomemoriaval,
>amit kiolvasva vezereltek az elektronsugarat.
>Azt hittem, hogy az intelligens konzol a CPU felol kapott bajtok
>alapjan rajzolgat ebben a sajat kepernyomemoriaban. Nem igy volt?
>Vagy igen? Ketsegtelen, hogy ha a CPU uzen, majd ezek
>alapjan a kartya megszakit, a CPU bekeri a kartyamemoriabol
>kvazi azokat az adatokat, amiket az iment kuldott ki, szamol veluk,
>majd visszakuldi a kartyamemoriaba, akkor ez nem tul gazdasagos.
>Valoban okosabbnak hangzik a videoramot a rendes RAMbol
>levagni, de hat akkor vegul az "intelligens konzol" fizikailag lassan
>megszunik letezni, mert csak megszakitaskero programrutinkobol all.
>A vegeredmeny megiscsak az, hogy a video celra levalasztott RAMot
>rendszeresen ki kell olvasni (dual port), ebbol egy csip bitsorozatot
>csinal,
>es azzal modulalni az elektronsugarat. Vagy nagyon eltevedtem?

Ezért szoktak "dual-buffering"-et használni: a CPU kiszámolja a képet a
főmemóriában, aztán átmasolja a videókártya memóriájába, a következő
képet megint a főmemóriában számolja ki, ...

>>> A CPU adat es cimvezetekeinek egyuttese lenne??
>>Eredetileg az volt, kis kiegeszitessel. [...]
>>Aztan ahogy a processzor sebessege nott (>8 illetve >12 MHz),
>>mar nem lehetett direktben a CPU vezetekeit ratenni,
>>mert az IO eszkozok nem birtak azt a sebesseget,
>Illetve a CPU eppen varhatott volna a Ready jelekre, de az
>nagyon lelassitotta volna?

Igen. Ma már 2GHz körüli processzorok vannak, de pl. a PCI busz
sebessége még mindig csak 33 MHz (ha jól tudom). 

				Bye,NAR

From: 
[...]
>De akkor egy HDD-t soros portra is lehetne csatlakoztatni, nem?

Azt hiszem, parhuzamos portra lehet kötni (a soros nagyon lassú (persze
a párhuzamos sem gyors)). Legalábbis Linux kernelfordításkor szokott
lenni egy ilyen kérdés. Persze biztos kell hozzá valami vezérlő a
párhuzamos kábel túlsó végén is.

				Bye,NAR

From: 
[...]
>Tudtommal ilyen sehol sincs - ill. PC-n irhatsz olyan programot, amelyik
>kozvetlenul a videomemoriabol dolgozik. Nekem van ilyen, de gyors gepen
>nem celszeru igy irni, mert SOKKAL lassubb, mint a fo memoria.

Egyszer olvastam egy olyan linux kernel patch-ről, ami lehetővé tette a
grafikus kártya memóriájának használatát swap céljára :-)

				Bye,NAR

szia,

> > Figyelmébe ajánlanám az olvasóknak egy a C# programozással kapcsolatos 
> > nemrég indult magyar websiteot: www.csharp.hu
> Csak a freeweb logo lathato, magabol az oldalbol semmi nem latszik. A
forras alapjan gondolom, hogy valami automatikus atiranyitast hasznal, > de
az nem mukodik. Kaphatnank kozvetlen mutatot?
Meglepődtem, mert nekem így mükszik és még sok más embernek is, de próbáld
meg esetleg így:
http://www.csharp.hu/index.php v.
http://www.csharp.hu/index.html

ha nem megy így sem, akkor próbáld ki más gépen is,
esetleg éppen akkor nem volt szolgáltatás ...

???

[-DJ-]

> Kell 20 bit, ertem. Azt, hogy ehhez miert nem fert el +4 vezetek,
> azt nem, de am legyen. Ha +4 nem fert el, akkor +16 plane
Takarekossag. Akkoriban ez nagyon megdragitotta volna a processzort -
pont az olcsosaga miatt terjedt el akkor, amikor ennel sokkal jobb
processzorok voltak (pl. a Motorola, ahol folyamatos a cimzes, nincs ez
a trukk) - dragabban.

> nem ferhetett el, ezek szerint marad 16 cimvezetek es a
> cimzes ketfordulos. Ha ketfordulos, akkor ennyi erovel
> a 32bites cim is elferhetett volna, legfeljebb az elso 12 bit
> par evig me'g nulla marad. Na mindegy.
Ez a kompatibilitas miatt keszult igy. A cel az volt, hogy a 8085-osre
irt programok a szegmens beallitasa utan futtathatok legyenek. Ez igy is
van, ilyenkor a szegmens fix, a program pedig max. 64kB - mas kerdes,
hogy a 286-oson mar a kutya nem hasznal 8085-os programot, ezzel a hulye
es kis cimtartomanyu cimzessel viszont azota is kuzdunk... en sem ertem,
hogy miert nem csinaltak a processzort olyanra, hogy 8 bittel tolja el a
cimet es a szegmens felso 4 bitjet eldobja. Na bumm, nem 16 byte-onkent,
hanem 256 byte-onkent lenne egy szegmens... Tipikus rovidtavu
gondolkodas (akkor es ott hasznosabbnak tunt, ha a szegmensregiszter
minden bitjet kihasznaljak, hiszen mire 1MB-nal tobbet kell cimezni, ez
a processzortipus mar "biztos" kihal).
 
> A videokartyas levelig addig is osszefoglalom, mi volt eddig.
Bocs', egyet elrontottam. Az EGA kartya max. 256KB (kulonben beferne a
64KB-ba es nem kellene lapozgatni).

hello!

a ddraw tenyleg eltunt a dx8-tol folfele. ha 2d-s igenyeid vannak,
lehet, hogy eleg neked a ddraw, de d3d-vel lehet par olyan effektet
csinalni, amit ddraw-val nem. pl alpha blending, textura modulacio.  az
alpha blendingel joval teccetosebb dolgokat lehet csinalni, mint sima
colorkeyinggel, modulaciot meg asszem egyaltalan nem lehet ddrawban, igy
pl szines fontokrol szo sem lehet (hacsak nem tarolod le az osszes
szukseges szinben a fontot).
 ezeket meg lehet ugyis csinalni, hogy teglalap alaku polygonokkal
dolgozol plusz texturazol, de sokkal egyszerubb, ha spriteokat
hasznalsz. ez pont erre lett kitalalva, es nagyon szepen mukodik, a
kezeles egyszerubb, de uazt el lehet erni vele, mint ha polygonokkal
csinalnad. igy pl lehet nagyitani/kicsinyiteni is a kepeket. szoval
nekem legalabbis bevalt.

						udv, petschy