játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5443
FZoli:    4892
Kuz:    4455
gaborlabor:    4449
kicsy:    4304
TPG:    3402
monostoria:    3284
DMG:    3172
HomeGnome:    2919
Matzi:    2519

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2188
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1625
syam:    1491
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] > 7 < [8] [9] [10] [15] [20] [25] [30] [35] [40] [45] [46]
kompabt - Tag | 27 hsz       Online status #184173   2012.07.03 20:43 GMT+1 óra  
Időközben megtaláltam az okot, ugyanis beragadt valahol a szál, ezért volt a késleltetés...
Azt jól sejtem, hogy az elsült eventekhez beregisztrált függvények valamiféle sorba kerülnek? Ide lehet valahogy soron kívül (szinkron) üzenetet küldeni, vagy szigorúan FIFO a kiszolgálás?

   
kompabt - Tag | 27 hsz       Online status #184168   2012.07.03 16:53 GMT+1 óra  
sziasztok!

A következővel akadt egy kis gondom: (Windows Formsos témában)
Ha lenyomom az egér gombját a Control.Click event-re beregisztrált esemény nem sül el azonnal, van olyan, hogy fél-egy másodperccel később, és ez rendkívül zavaró.

Hogy miért van ez így, nem tudom, gondolom a WM_CLICK (vagy ilyesmi) esemény bekerül az ablak üzenetsorába, és nem azonnal, hanem csak később dolgozódik fel. (Azt, hogy fél-egy másodpercig hogy a francba nem dolgozódik fel az üzenetsor tartalma, nem értem. )

Az üzenetsor megkerülésével lehet közvetlenül, szinkron módon az ablakkezelőnek ilyen üzenetet küldeni? köszi

   
Parallax - Tag | 575 hsz       Online status #184038   2012.06.29 20:49 GMT+1 óra  
Erőforrások kezeléséhez érdemes írni egy osztályt, már csak azért is, hogyha valamit egyszer betöltesz újra már ne kelljen, tehát valami Singleton és Factory pattern jó ha van ehhez központilag. Extrém esetben valami Dependecy Injection konténert is lehet használni, de ez ehhez szerintem fölösleges.

A fizikai file-okhoz peig egy nagy zip, de az se nagy tragédia, ha csak mappákkal vannak elválasztva.

   
kompabt - Tag | 27 hsz       Online status #184035   2012.06.29 17:16 GMT+1 óra  
Hm, köszi, úgy csináltam (state). Már kezd alakulni

Még annyi lenne, hogy az erőforrásaimnak (képek, hangok) célszerű csinálni egy teljesen külön osztályt, vagy hova kerüljenek? Itt a Visual Studio class diagram nézetben látok valami Resources osztályt, ez arra való?

   
zeller - Törzstag | 464 hsz       Online status #184025   2012.06.29 14:05 GMT+1 óra  
A legjobb, ha state vagy strategy patternt hasznalsz.
Legyen egy osztalyhierarchiad, ami a megfelelo eseteket kezelo paint_fun fuggvennyel rendelkezik, es te az eppen megfelelo osztaly egy peldanyat alkalmazod a paint-ben.
Neten utana tudsz nezni mindket patternnek.

Szinte mindig erdemes if- else-if-else... szornyusegek helyett polimorfizmust alkalmazni, kiveve ha mikrooptimalizaciora van szukseg.

   
kompabt - Tag | 27 hsz       Online status #184024   2012.06.29 13:53 GMT+1 óra  
Köszi

Még lenne egy kérdésem:
MVC architektúra van. Adott a View-m, ami egy WindowsForm, van neki egy paint event -je amire be van regisztrálva egy paint_fun nevű függvény, ami a játéktér kirajzolását végzi.

Azonban a Model állapotától függően mást és mást kellene kirajzolni. Ezt megtehetném úgy, hogy if-eket alkalmazok a paint_fun -on belül (az if belsejében a feltételek, amik a model állapotára vonatkoznak):

Kód:
paint_fun(object sender, PaintEventArgs e){
   if(...){  // kirajzol
}
else if(...){ // kirajzol
}
else{ // kirajzol

}
}


Ezt így szokás?? Nem tetszik benne, hogy minden egyes paint_fun híváskor "feleslegesen" lekérdezi a feltételeket, továbbá kevésbé átlátható.
Amire gondoltam még, hogy a feltétel teljesülése esetén kiregisztrálom a "régi" paint_fun() függvényt, és beteszek helyére egy újat. Ennek viszont az lenne a hátránya h. az eventekre ki-be regisztrálni kéne függvényeket, könnyebb eltéveszteni, nehezebb átlátni h. aktuálisan mi is van beregisztrálva.
Hogy szokás ezt megoldani?

   
Matzi - Szerkesztő | 2519 hsz       Online status #183991   2012.06.28 14:24 GMT+1 óra  
Annyit hozzátennék, hogy a view lehetőleg csak nagyon felügyelt módon nyúlhasson adatokhoz, mert a controller tartalmazza a logikát.
Az adatok mindig ilyen irányban mozogjanak: M <-> C <-> V
Annyi bele szokott férni, hogy a View lekérdezhet a Modellből adatokat, hogy ne kelljen mindennek átvándorolnia a Controlleren.

Játékban én konkrétan úgy csinálnám (csináltam) meg, hogy van egy játéklogia osztály, és van egy vetület. A kettő hasonló modellen dolgozik, amik között az irányító osztály szinkronizál. Vagyis lényegében van egy Model, van a Controller, és a Controller módosít egy megjelenítő Modelt, amit meg a megjelenítő osztály már fel tud használni.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Pretender - Törzstag | 2498 hsz       Online status #183987   2012.06.28 13:56 GMT+1 óra  
Az a jó, ha nem tudsz hozzáférni az adattagjaihoz, az úgy csúnya megoldás is lenne. De jól látod a helyzetet, így érdemes megcsinálni.

   
kompabt - Tag | 27 hsz       Online status #183985   2012.06.28 13:26 GMT+1 óra  
Azt hiszem értem, köszi az útmutatást.
Kicsit utánanéztem/ utánagondoltam közben a dolgoknak.
Ugye windows forms esetén a View-Controller egyben van, tehát lényegében a Document-View architektúráról van szó.
Ha jól értem azt mondod, hogy a View a Document adatait, csak a Document (publikus) interfészén keresztül módosíthatja. És így nem is merül fel a lenti probléma, tehát a Document minden tagváltozója nyugodtan lehet privát, (az interfész nyilván publikus.) Persze ekkor nem tudok közvetlen módon hozzáférni az adattagokhoz, és az interfész megírása egy kis többletmunkát is jelent, de nyilván ezzel együtt is megéri így megcsinálni, mert így lesz szép objektumorientált (nem gány) megoldás .

   
Matzi - Szerkesztő | 2519 hsz       Online status #183963   2012.06.28 09:51 GMT+1 óra  
kompabt:
Nem egészen igy van. MVC paradigma. A view szól a controllernek, ha történik valami, és a controller adatokat biztosit a view-nak. De nem függenek össze szorosan, nem férnek egymás belső állapotaihoz, amennyire csak lehet, szeparáltak. Szóval definiálsz egy interface-t a kettő között, és függvényhivásokkal kommunikálhatnak. Ha ez 5-10 függvénynél több lenne oldalanként, akkor valami tervezési hiba van.

Amúgy nem az a gond, ha sokszor hivjak egymást, hanem ha túl sokat tudnak egymásról. De tegyél fel konkrét példát és segitünk.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Pretender - Törzstag | 2498 hsz       Online status #183958   2012.06.28 09:34 GMT+1 óra  
A form elemeire nyugodtan írhatsz egy getter propertyt, abból baj nem lesz. Azoknak pedig van pl. ChangeText, vagy ilyesmi függvénye, amivel tudod az állapotait módosítani. Ugyan ez lehet a logika elemeire is. Gondolj csak bele, az enginet valahogy vezérelni kell, így például lennie kellene egy olyan függvénynek, hogy SetEntityPosition(0, 100, 150, 200); Ha ilyen nincs, akkor valahogy máshogy kell megoldani. A lényeg az, hogy ne félj a public dolgoktól, főleg, ha csak getterről van szó, az elég biztonságos

   
kompabt - Tag | 27 hsz       Online status #183951   2012.06.27 23:53 GMT+1 óra  
heló!

Miért? A grafika használja a logikát, ez trivi. A fordított irány talán hülyeség lenne?

A WindowsForm klikk eseménye megváltoztatja az adatok állapotát. Ez az egyik irány
más esetben:
Az adatok változása megváltoztatja a Form kinézetét. Ez a másik irány. (konkrét példa: a megváltozott adatok megváltoztatnak egy Text-et a Form-on)

Ez így miért ne lenne jó? És akkor hogy kéne helyette?

   
Kuz - Törzstag | 4455 hsz       Online status #183948   2012.06.27 21:40 GMT+1 óra  
Ha a grafika és a logika használja egymást, akkor tervezd újra az alkalmazást (nyilván, ha ez felmerült, akkor eleve nem nagyon volt tervezés, ami pedig igen fontos része lenne a fejlesztésnek). Ne rossz tervezésre akarj megoldást találni, inkább jó tervet készíts és azt implementáld.
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???

   
Pretender - Törzstag | 2498 hsz       Online status #183934   2012.06.27 13:46 GMT+1 óra  
Ha jól tudom C#-ban erre nem nagyon van lehetőség. Projekten belül lehet olyasfajta friendséget kialakítani, de azt mindenkivel.
Szóval ha van egy dll-ed mondjuk, amibe fordul az Engine, akkor azon belül ami internal, azt abból a programból, amiből hívják a dll-t nem lehet látni, csak az Engine projekten belül. De ez nem az igazi.

   
kompabt - Tag | 27 hsz       Online status #183933   2012.06.27 13:40 GMT+1 óra  
Sziasztok!

A következő kérdésem lenne:
- van egy Form osztályom, legyen a neve mainForm, amiben az elkészítendő játék grafikusan megjelenne.
- van egy GamePlayManager nevű osztályom, ami a játékmenet logikáját tartalmazná (tehát minden logikát, ami a grafika mögött van).

A fenti kettő osztályt nem szeretném keverni, élesen el szeretném különíteni a grafikát, és a logikát egymástól. A két osztály azonban kölcsönösen, intenzíven használná egymást.

kérdésem:
Hogyan tudom ezt megtenni?
Hogyan érhetem el, hogy a két osztály lássa egymást, ha nem szeretném publikussá tenni az osztályaimat, és getter, setterekkel sem akarok bajlódni? ( C++ ban a friend adná magát, de ugye az C#-ban nincs. ) Olvasgattam még, hogy a C++ -os friend helyett a beágyazott osztályt ajánlják, de nekem ez nem tetszik, nem akarom egyiket se a másikba ágyazni, azt akarom, hogy teljesen különüljenek el, továbbá a beágyazással az is a baj, hogy - ha jól tudom- csak a belső osztály látja a külsőt, fordítva viszont nem.

Előre is köszi a válaszokat.

   
ddbwo - Tag | 1625 hsz       Online status #183813   2012.06.23 21:44 GMT+1 óra  
Ha fél reális a fizika, akkor is meg kell maradnia az össz energiának, nem lehet több. max ugyan annyi lesz, de a surlódás miatt ez is csökken.

Ha jól vettem ki, vmi ilyesmit szeretnél:

pl.:2D ütközés, jégszerű talaj minimális tapadással, nulla rugalmasság a dobozokon.
// a megjelenítés GLEW-es, elvileg 256fps-el akar menni a logic miatt
2503-nyuszka.zip

Egyszerűen az energiamegmaradás törvényével össze lehet hozni.
A párosítást pedig meg lehet csinálni matekkal h mindenki csak egyszer cseréljen a másikkal.

4 tag esetén:

[0] + [1]; [0] + [2]; [0] + [3]
[1] + [2]; [1] + [3]
[2] + [3]

Mivel ha az 1. ütközik a 2.-al, a 2. is biztos h ütközött az 1.-vel. Mindig az n től felfelé kell venni a tagokat. Csak így tudom elmagyarázni...

Ne űberelési kísérletnek vegyétek, nem annak szánom...
---

u.i.:
Általában ha pont úgy működik, ahogy kell a cucchoz, és elég gyors, akkor tökéletes megoldás. Ez a legjobb válasz... xD

Ezt a hozzászólást ddbwo módosította (2012.06.23 22:38 GMT+1 óra, ---)
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
Pixi - Tag | 205 hsz       Online status #183809   2012.06.23 19:12 GMT+1 óra  
Kuz:
Értem én mire gondolsz, ennyire azért nem vok már hülye. Hogy ez nem reális ütközés, az akkor volna, ha visszapattannának a kockák egymástól, de ennek a kódnak pont az a lényege, hogy dominánsá tenni az egyiket a másik felett, ami aztán vezérli az összes többit (összeragadás). Szerintem ez némely játékoknál még használatos is. Mostmár működik, lehet látni mit akartam elérni vele.

http://data.hu/get/5266504/V2_Rectangle_collision_and_move.zip

Matzi:
Kösz a tömör és érthető magyarázatot, be kellett iktatni plusz tagváltozókat. Működni működik, csak nem tudom ez mennyire jó megoldás. Azt csináltam, hogy az x és y mozgás változókon kívül betettem egy plusz x és y számlálót. Ha megindul egy kocka mozgása (megérintem a kis kijelölő négyzettel), akkor ez az érték átvált egy nullától nagyobb értékre vagyis akkorára mint a mozgás tehát 1.5f, és lassan számol visszafele párhuzamban az xy mozgásával. Ha egy másik kockának ütközik, akkor az előző lesz a dominánsabb, mert leellenőrzi, hogy az ő számláló értéke nagyobb-e mint a másiké. Ezután a másik kockának átállítja a számláló változóját és sebességét. Így amikor már mindegyik összeragadt a másikkal, akkor akármelyiknek adom a lökést, vele együtt az egész képes mozogni.

Kód:
...
...
...

            foreach (Kocka k in kockak)
             {
                if (k.X_szamlalo > 0)
                    k.X_szamlalo -= 0.01f;
                if (k.Y_szamlalo > 0)
                    k.Y_szamlalo -= 0.01f;

                 k.pozicio.X += k.X_sebesseg;
                 k.pozicio.Y += k.Y_sebesseg;
             }

            foreach (Kocka k1 in kockak)
             {
                 foreach (Kocka k2 in kockak)
                 {
                    if (k1 != k2 && k1.forras_negyzet.Intersects(k2.forras_negyzet))
                    {
                        if (k1.X_szamlalo > k2.X_szamlalo)
                        {
                            k2.X_sebesseg = k1.X_sebesseg;
                            k2.X_szamlalo = k1.X_szamlalo;
                        }
                        if (k1.Y_szamlalo > k2.Y_szamlalo)
                        {
                            k2.Y_sebesseg = k1.Y_sebesseg;
                            k2.Y_szamlalo = k1.Y_szamlalo;
                        }
                    }
                 }
             }
...
...
...

   
Matzi - Szerkesztő | 2519 hsz       Online status #183804   2012.06.23 16:28 GMT+1 óra  
Elsöprő erejű.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Kuz - Törzstag | 4455 hsz       Online status #183801   2012.06.23 15:33 GMT+1 óra  
Miféle ütközés az, ahol a k2 átveszi k1 mozgását?
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???

   
Matzi - Szerkesztő | 2519 hsz       Online status #183779   2012.06.22 22:41 GMT+1 óra  
Pixi:
Az a gond, hogy bár minden párt kétszer vizsgálsz meg, de az, hogy melyik a k1 és a k2, az tök véletlen. Vagyis lényegében a sorrend határozza meg, hogy melyik "győz". Ezért kéne a feltételbe valami egyébvizsgálatot is beletenni, vagy ütközésnél mindkét elemre ütközési választ vizsgálni.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Pixi - Tag | 205 hsz       Online status #183778   2012.06.22 22:17 GMT+1 óra  
Nos elméletben nem nagyon tudom megfogalmazni, hogy pontosan mi is a gond. Amikor megadok egy feltételt a két önmagával nem egyenlő kockára (k1 != k2), akkor azt mondom neki, hogy ha ütközés történik, a k2 XY mozgása legyen egyenlő a k1-vel. Ez csak félig működik, egyszerűen nem mindegy a lista melyik elemét ütköztetem egy másik elemmel. Egyik ütközik a másiknak, akkor mozog vele együtt azonos sebességgel a másik is, viszont ha a másikat ütköztetem az előzővel, akkor megáll fixen. Magyarul talán úgy fogalmaznék, hogy nem tudom megoldani, melyik elem legyen dominánsabb a másik felett mozgás alapján. De itt van a kód és a projekt is:

http://data.hu/get/5263916/Rectangle_collision_and_move.zip

Kód:
...
...
...

            foreach (Kocka k in kockak)
            {
                k.pozicio.X += k.X_sebesseg;
                k.pozicio.Y += k.Y_sebesseg;
            }

            foreach (Kocka k1 in kockak)
            {
                foreach (Kocka k2 in kockak)
                {
                    if (k1 != k2 && k1.forras_negyzet.Intersects(k2.forras_negyzet))
                    {
                        k2.X_sebesseg = k1.X_sebesseg;
                        k2.Y_sebesseg = k1.Y_sebesseg;
                    }
                }
            }
...
...
...

   
Parallax - Tag | 575 hsz       Online status #183436   2012.06.18 12:18 GMT+1 óra  
Szerintem érdemes megismerkedni minél több nyelvvel, akár csak pár nap erejéig is. Már csak azért is, mert játékhoz is, ha csak tesztelési céllal, de célszerű valamilyen kliens oldali scriptet használni.

   
Tibsy - Tag | 307 hsz       Online status #183435   2012.06.18 12:10 GMT+1 óra  
PHP-ban és javascript-ben nem tervezek magamnak nagy jövőt . nem nagyon vonz aza két nyelv + ahogy nekem tűnt túlsókat kell ahhoz gépelni hogy legyen valami belőle szó ha tehetem inkább el kerülöm őket
   
Parallax - Tag | 575 hsz       Online status #183434   2012.06.18 12:04 GMT+1 óra  
tibsy: PHP-ban és javascript-ben is vannak vezérlési szerkezetek, mert script nyelvek. html-ben css-ben nincs, mert azok leíró nyelvek. Ha nem találkoztál velük ott vannak a 24 óra alatt könyvek pár órán belül tudni fogsz PHP-ul, meg javascript-ül. Programozni talán javascript-ben lehet legegyszerűbben kezdeni, mert nem kell hozzá semmi különleges fejlesztői eszköz, meg futtatási környezet és módosítás után azonnal látszik az eredmény.

   
Tibsy - Tag | 307 hsz       Online status #183423   2012.06.18 07:12 GMT+1 óra  
Idézet
Pretender :
Azért lett visszaküldve az alapokhoz, mert látszik róla, hogy fogalma sincs, hogy mi hogy működik - különben nem hagyta volna ki az else-t.
De legalább megtudtam, hogy nem csak c++ban lehet ilyen blokkokat írni, hanem c#-ban is


mivel a C-böl let C++ és C# ez a minimum hogy 90% ba ugyan úgy épül fel egy kód
( csak tudnám h neked minek írom hisz te is tudsz programozni nem is kicsit ,,, )
akk mit szolnál ha azt írnám még flash-ben is lehet ?! meg szinte minden progi nyelvbe van if ,else, for , continue,break, while , enum, legaláb is azokba amiket sűrűn használnak nagy kár h pl: webes progi nyelvekbe :php. html -be nincs vagy legalább is én nem találkoztam vele .
   
Kuz - Törzstag | 4455 hsz       Online status #183422   2012.06.18 06:38 GMT+1 óra  
Azt én sem értem, hogy mit szeretnél ebből kihozni. Ha 3 objektumod lesz, akkor 3 foreach-et írsz, vagy mi? Ha itt ütközésekről van szó, lehet kényelmesebb egy adott objektumon belül kezelni az ütközést, ami annyit tesz, hogy végig iterálsz minden ojjektumon, meghívod az üzközés kezelő metódusát, ha van olyan más objektum, amivel ütközött, akkor mindenkinek beállítod az érétkét, majd veszed a következő objektumod, arra is meghívod ezeket, blabla, egészen az utolsó elemig. Nem tudom erre gondoltál-e?

Maga az ütközés megvalósítás működhet úgy is, hogy van egy általános metódus, ami paraméterül vár egy objektumot és egy olyan objektum listát, ami azon dolgokat tartalmazza, ami az első objektummal ütközött, így egy külső metódusban tudsz állapotot kezelni, ami szebb, mintha egy objektum egy másikat módosítana saját magában.
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???

   
LBandy - Tag | 271 hsz       Online status #183421   2012.06.18 06:08 GMT+1 óra  
Persze, hogy 9-et ad hozzá, mivel egy 3 elemű tömbön lépsz végig két alkalommal, magyarul hatványozod... Az aktuális feladatodban nem látom, hogy mit szeretnél megoldani, de annyit nem árt tudnod, hogy a for az egy lineáris ciklus tehát útközben tudtommal az irányát nem tudod megváltoztatni, amire szükséged van, az inkább egy do ... while, amiben csak annyit tesztelsz, hogy ütköztek-e már, és ha nem, akkor mozgatod őket éppen neked szimpatikus irányban és sebességgel.
   
Pixi - Tag | 205 hsz       Online status #183418   2012.06.18 01:17 GMT+1 óra  
Hali mindenki.

Bár a problémám konkrétan XNA-hoz kötődik, úgy gondolom, hogy ez egy általános C# kérdés lesz. Amikor van egy listánk, és annak elemeit lekezeljük egy darab foreach-el, akkor az adott elem adattagjával, ami pl. int változó vagy float, probléma mentesen tudunk számolni (növelni, csökkenteni az értékét, szorozni, osztani...). De ha már dupla foreach-ot használunk, akkor problémás, mert az aktuális értéket beszorozza a lista összes elemével. De hogy konkrét példát mondjak:

Kód:
//legyen a listában 3 darab kocka

foreach (Kocka k in kockak)
{
      k.poz.X += 3;  // így hármat ad hozzá ez ok
}

foreach (Kocka k1 in kockak)
{
     foreach (Kocka k2 in kockak)
            {
                  k1.poz.X += 3;  // így már nem jó, mert 3x3 vagyis 9-et ad hozzá
            }
}


A kérdésem, hogy ezt milyen módon lehet megoldani dupla foreach-en belül? Csak ez olyan macerásnak tűnik, mert tegyük fel ha nem arra kell ez az egész, hogy ha a k1 nem egyenlő k2-vel, akkor törölje k1-et k2-őt vagy mindkettőt, hanem teszem fel valami bonyolultabb, hogy ha k1 halad jobbra, k2 pedig balra, és ütköznek, akkor k1 haladjon balra egy adott sebességgel, és k2 pedig jobbra ugyanígy...vagyis valami bonyolultabb fizika amelyben összetettebb számítások és mozgások vannak, na akkor ezt hogyan szokás megvalósítani? Tudtommal a for ciklusnál is ugyanez a probléma.

Ezt a hozzászólást Pixi módosította (2012.06.18 03:49 GMT+1 óra, ---)

   
Bukta - Tag | 308 hsz       Online status #182522   2012.06.06 12:08 GMT+1 óra  
Jah hát lehet ilyen üres blokkokat írni, mondjuk nem tom mi értelme...
Am az én non-reális elképzelésem az volt hogy azért hagyta ki az else-t mert azt gondolta hogy az itteni fórumozók nagy tudásúak és maguktól rájönnek hogy oda egy else kell. Így Anakin megmenekült 4 billentyű lenyomásától .
De mikor lentebb nézegelődtem rájöttem hogy eme elgondolás kudarcot vall. És szerkesztettem a hozzászólásom. Tényleg alapoznia kéne.
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
   
Pretender - Törzstag | 2498 hsz       Online status #182520   2012.06.06 12:01 GMT+1 óra  
Azért lett visszaküldve az alapokhoz, mert látszik róla, hogy fogalma sincs, hogy mi hogy működik - különben nem hagyta volna ki az else-t. De legalább megtudtam, hogy nem csak c++ban lehet ilyen blokkokat írni, hanem c#-ban is

   
Matzi - Szerkesztő | 2519 hsz       Online status #182519   2012.06.06 11:57 GMT+1 óra  
Sajnos hibás is, mert a második elágazásban kihagyta az else-t. Gondolom nem kell ecsetelni, hogy az miért nem jó úgy.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Bukta - Tag | 308 hsz       Online status #182518   2012.06.06 11:52 GMT+1 óra  
Matzi: Anakin megoldása nem hibás, csak pazarló, de az ilyenektől még nem kell visszaküldeni a változókhoz. Ha megvan a nyelvi tudása akkor már csak gyakorolnia kell és idővel észre fogja venni, hogy jé ezt ide felesleges leírni mert 20 sor helyett 2 sorral is működik. De azért jó, hogy szóltál neki, hogy ezt inkább máshogy csinálja.

Habár ha nem ismeri a { } jeleket akkor a "nyelvi tudása" nem elégséges ...
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
   
Tibsy - Tag | 307 hsz       Online status #182454   2012.06.05 21:30 GMT+1 óra  
Idézet
DMG :
És én arra a kódra gondoltam, amit beszúrt képként, azt láttad?

most már igen
   
Matzi - Szerkesztő | 2519 hsz       Online status #182423   2012.06.05 17:45 GMT+1 óra  
Anakin:
Szerintem rugaszkodj neki az alapoknak, mert ez így sok jóra nem fog vezetni. Ugyanis az alábbi szösszenetet sikerült lényegesen hosszabban, és hibásan leírnod.
Kód:
   
        public Form1()
        {
            InitializeComponent();
            backbutton.Enabled = webBrowser1.CanGoBack;
            forwbutton.Enabled = webBrowser1.CanGoForward;
        }
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Anakin12 - Tag | 19 hsz       Online status #182421   2012.06.05 17:29 GMT+1 óra  
Üdv!
Köszönöm a válaszotokat!
Sikerült ki javítanom a problémát. Igazából újra írtam ezt a részt és utána működött!
Kód:
        public Form1()
        {
            InitializeComponent();
            if (this.webBrowser1.CanGoBack == true)
            {
                this.backbutton.Enabled = true;
            }
            else
            {
                this.backbutton.Enabled = false;
            }
            if (this.webBrowser1.CanGoForward == true)
            {
                this.forwbutton.Enabled = true;
            }
            {
                this.forwbutton.Enabled = false;
            }
        }

   
LugaidVandroiy - Törzstag | 504 hsz       Online status #182376   2012.06.05 09:21 GMT+1 óra  
Nyugi, ezt csak ő tudja dekódolni Már feltéve persze, ha tudja

Anakin: hogy legyen valami konstruktív is a hozzászólásomban. A C# egy olyan nyelv, amiben a fordítónak úgy mondod meg, hogy egy-egy kódblokk mettől meddig tart, hogy { és } használsz. Ezek néhány esetben elhagyhatóak. Majd mindjárt. A { nyitja a blokkot a } pedig zárja.

Kód:
public static void foo(){
....
}


itt egyértelmű, hogy a függvény {-tól }-ig tart.

Kód:
if (feltetel){
...
}
else {
...
}


Itt is látszódik, hogy meg kell valahogy mutatni, hogy meddig tart a feltétel egyik és másik ága.

De vegyünk egy ellenpéldát.

Kód:
if (feltetel){
...
}
foo();


nem ugyanaz, mint

Kód:
if (feltetel){
...
foo();
}


Az első esetben a foo() fgv. minden esetben meghívódik, a második esetben pedig csak ha a feltétel igaz.


Mikor hagyható el? Akkor, ha a feltételed, ciklusod, vagy akármi, csak egy sor. Akkor viszont nyitni sem kell a blokkot.

Kód:
if (feltetel)
foo();



De ajánlom, hogy nézegess a neten tutorialokat/könyveket, egyértelműen el van magyarázva az első fejezetben. Én annak idején a 21 napos könyvből tanultam meg, csak ajánlani tudom.

   
DMG - Szerkesztő | 3172 hsz       Online status #182375   2012.06.05 08:33 GMT+1 óra  
Idézet
Tibsy :
Idézet
DMG :
Köszönjük!
És a kódot, azt láttad?


szívesen ,
nem ,mert csak részlet és ok nem kezdő ,ez egyértelmű
csak a véleményemet osztottam meg,,,,



Mi van?

"csak részlet és ok nem kezdő"



És én arra a kódra gondoltam, amit beszúrt képként, azt láttad?
-----------------------------------------
Dont Listen to the Naysayers
   
LugaidVandroiy - Törzstag | 504 hsz       Online status #182372   2012.06.05 06:07 GMT+1 óra  
Köszönjük Emese!

   
Tibsy - Tag | 307 hsz       Online status #182368   2012.06.05 02:01 GMT+1 óra  
Idézet
DMG :
Köszönjük!
És a kódot, azt láttad?


szívesen ,
nem ,mert csak részlet és ok nem kezdő ,ez egyértelmű
csak a véleményemet osztottam meg,,,,
   
Parallax - Tag | 575 hsz       Online status #182337   2012.06.04 16:39 GMT+1 óra  
Tibsy : Minden else ág lezárója meg van fordítva, aztán sportszerű nehezítésként a konstruktor bezáró is. Aztán, ami nem látszik még ki tudja mi minden. Ennél talán még a bugyuta állásinterjún "na mi a hiba" című feladatok szándékos hülyeségei sem jobbak, egyszerűen zseniális. Utoljára delphiben volt ilyesmi felling, mikor valami kódot kellett átkonvertálni. Ott 10-12 end egymás alatt mindeféle behúzás nélkül notepadban emberes volt.

Ezt a hozzászólást Parallax módosította (2012.06.04 16:45 GMT+1 óra, ---)

   
LBandy - Tag | 271 hsz       Online status #182335   2012.06.04 16:34 GMT+1 óra  
Amúgy a shoton nagyon szépen megfigyelhető, hogy melyek azok a részek amik nyilvánvalóan a ctrlcv mágikus billentyűkombináció eredményei, és melyek azok a karakterek, amik ugyan formailag nem megfelelően, de mégis saját ötlettől vezérelten átírásra kerültek.
   
DMG - Szerkesztő | 3172 hsz       Online status #182306   2012.06.04 14:00 GMT+1 óra  
Idézet
Tibsy :
és valszeg nem volt le zárva az a blokk {} vagy egyel töb volt akkor is alá huza



Köszönjük!

És a kódot, azt láttad?
-----------------------------------------
Dont Listen to the Naysayers
   
Tibsy - Tag | 307 hsz       Online status #182302   2012.06.04 12:48 GMT+1 óra  
nya azért a vc# se olyan rossz , egy hozáértö kezében de egy kezdőnek még sok tapasztalatra van szűksége mire kérdések nélkül is buldogul.. és valszeg nem volt le zárva az a blokk {} vagy egyel töb volt akkor is alá huza
   
Parallax - Tag | 575 hsz       Online status #182300   2012.06.04 12:24 GMT+1 óra  
Rájöttem, ezért szeretik a kezdők a vizuális béziket és mondják, hogy az könnyű. Ott ilyen gond nincs, mert valami end akármicsoda a vége éppen attól függően mi volt az eleje a blokknak.

   
LugaidVandroiy - Törzstag | 504 hsz       Online status #182298   2012.06.04 12:06 GMT+1 óra  
Maaaaaaaatttzzzzzziiiiii, neeeee

   
Matzi - Szerkesztő | 2519 hsz       Online status #182297   2012.06.04 11:56 GMT+1 óra  
Nem az ilyen feladatokra van a "fordító"?
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
DMG - Szerkesztő | 3172 hsz       Online status #182284   2012.06.04 08:39 GMT+1 óra  
meg még a többit is, ami még rossz irányba mutat.

Amúgy meg, ha nem képet töltesz fel, ahnem a kódot másolod ide, akkor hamarabb korrigálni tudnánk.
-----------------------------------------
Dont Listen to the Naysayers
   
Kuz - Törzstag | 4455 hsz       Online status #182283   2012.06.04 08:13 GMT+1 óra  
Idézet
Anakin12 :
Már megfordítottam a } jelet és úgy se akar működni.


Én csak megpróbálnám még egyszer megfordítani.
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???

   
DMG - Szerkesztő | 3172 hsz       Online status #182260   2012.06.03 20:59 GMT+1 óra  
Ez most fájt.

Anakin12 azt tudod, hogy a "{ }" pár mire jó és mit csinál?
-----------------------------------------
Dont Listen to the Naysayers
   
sirpalee - Tag | 1282 hsz       Online status #182257   2012.06.03 20:36 GMT+1 óra  
Ó máj gád.
raytraceisten és übermedic
   
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] > 7 < [8] [9] [10] [15] [20] [25] [30] [35] [40] [45] [46]