glezmen:

Csak az elméletileg biztonságoshoz írtam valamit, ami kijátszhatatlan lenne. Ha akarnák... Hogy van-e ami ilyesmi elveket használ, azt nem tudom.

Idézet

---

ddbwo :
Egy oprendszer, ami a programnak nem enged kilépni a saját könyvtárán és az installerek is csak saját könyvtáron belül csomagolhatnak, már szuper safe lenne.

---

ha valaki normalis user account managementet hasznal, akkor ez tobbe-kevesbe mar megvan (persze a legtobben kapasbol rendszergazdai jogokkal hasznaljak a gepet, hiszen "ugy egyszerubb", plane windowson...)

Az installerekkel kapcsolatban nem egeszen ertem hogy mire gondoltal, de ha arra amire szerintem (a user sajat konyvtaraba menjen a telepites), akkor az OSX pl. alapbol ezt szorgalmazza

Először is a kőbevésett oprendszer feltelepítése után már semmi nem rakhat semmit sehova.

Néhány kivétel csak lehet, például a Paint, de kivételeket power userként lehetne hozzáadni, csak meghatározott mappákat megadni nekik. Ha nincs hozzáférés, hack sem indulhat el. Az installereknek szintén power userként megadjuk a könyvtárat, de csak ahhoz férhet hozzá. power userként run installer, akármi, kijelöl könyvtár. Oda telepít. A lényeg, hogy egy program se férhessen hozzá semmilyen file-hoz.

Persze a rendszer frissítéseket ha töltögetik innen onnan, az már az egészet bonthatja. De mivel a programoknan nincs joguk semmit módosítani és nincs joguk jogot adni maguknak, nem terjedhetnek a vírusok. Esetleg könyvtáron belül olvashatna és küldhetne infót egy trójai.

A paintnél maradva ha berakja valaki a dokumentumokat, akkor máris nyomkodhat bármit. Ennek nem kell bonyolultnak lennie sem. Az ember csak felismeri, hogy a dokumentumok a dokumentumok. Ha meg nem, legalább fejlődik logikailag.
---
Azért másolgatni tud az, akinek kell valami.

akkor a paint csak a /windows könyvtárban működjön, az nfs installere meg csomagolja ki a játékot a dvd-re, vagy ez úgy mégis honnan jött?

Egy oprendszer, ami a programnak nem enged kilépni a saját könyvtárán és az installerek is csak saját könyvtáron belül csomagolhatnak, már szuper safe lenne.

Idézet

---

M4 :
Gondolkoztam a programok biztonságosságáról. Vagyis hogy lehet-e egy számítógép teljesen védett az ártó programokkal szemben. Olyasmi oprendszer, vagy inkább virtuális gép jutott eszembe, hogy abba csak byte-kódos programokat tölthetnénk, amit könnyen ellenőrizhetne, nem akar-e hozzáférni valami tiltott erőforráshoz stb. Illetve, ha egy fejlesztő védeni akarja a kódját, akkor valami központi "megbízható" fordítóval le lehetne fordíttatni és aláírni, így a letöltő tudja, hogy biztonságos.

Az elméletileg biztonságos kód okozhat-e a processzorban (vagy más hardverban) valami nem várt hibát? És ezzel károsíthatja-e a saját programján kívül más programok futását?

---

ez nem így megy. most is az apin keresztül érjük el az operációs rendszert, az meg olyan szabályrendszer alapján működik, amilyenen keresztül akar. a védett mód lehetőséget biztosít számunkra arra, hogy a felhasználói módú programok csakis pontosan azokhoz az erőforrásokhoz férhessenek hozzá, amikhez az oprendszer úgy akarja.

nem ezen múlik.

"audio frequency spectrum analysis visualization" kérdésem lenne. Nem tudom hogy keressek rá.

Elkészül a spectrum analízis, de a magnitude-k a hz-el egyre kisebbek lesznek. Az ellensúlyozásra kitaláltam valamit, most így néz ki: 0-15000 Hz, eredetileg a mély hangoknak van a legnagyobb súlya.

Van valahol leírás, hogy pontosan mit szoktak csinálni a spectrummal? Mert kicsit eltérő képet kapok, mint amit a winamp ad pl.

Az első teszt így néz ki, nagyjából jó is, csak kicsit máshogy néz ki:

( full lefedettségű zene tesztnek )

Sziasztok!

Szeretnék megtanulni programozni, lényegébe teljesen kezdő vagyok és ehhez szeretnék magántanárt keresni Pest környékén, természetesen megfelelő juttatásokért cserébe.Akinek van kedve hozzá az írjon ide v privibe!

Le lehet a kódot fordítani pl. installáláskor, ellenőrzés után. Ritkán szoktam új programokat telepíteni.

Keylogger: ezt meg lehetne úgy oldani, hogy csak az aktuális program/ablak kapná meg a begépelt szöveget; illetve lennének speciális billentyűk (mint pl. a windows billentyű amire csak a VM reagálhat.

És a sebességen gondolkoztál? Ha mindig ellenőrzöd a byte kódot, hogy nem nyúl-e olyanhoz, amihez nem kéne (egyáltalán tudod ellenőrizni?), akkor az lehet, hogy egy bottleneck lesz a rendszeren.

Ráadásul mi van a keyloggerekkel? Mindkét része elfogadható egy programtól: figyeli az inputot (egy játék is), illetve használja az internet kapcsolatot (szintén játék is lehet)

Gondolkoztam a programok biztonságosságáról. Vagyis hogy lehet-e egy számítógép teljesen védett az ártó programokkal szemben. Olyasmi oprendszer, vagy inkább virtuális gép jutott eszembe, hogy abba csak byte-kódos programokat tölthetnénk, amit könnyen ellenőrizhetne, nem akar-e hozzáférni valami tiltott erőforráshoz stb. Illetve, ha egy fejlesztő védeni akarja a kódját, akkor valami központi "megbízható" fordítóval le lehetne fordíttatni és aláírni, így a letöltő tudja, hogy biztonságos.

Az elméletileg biztonságos kód okozhat-e a processzorban (vagy más hardverban) valami nem várt hibát? És ezzel károsíthatja-e a saját programján kívül más programok futását?

Idézet

---

Geri :
gprof <- na megnéztem, hát ez nevetségesen bárgyú

---

a 'nevetsegesen bargyu' egy szokasos Geri-fele tulzas nem egy professzionalis profilozo, de mindenhol van/fut, es egyszeruen hasznalhato, amire kitalaltak arra teljesen jo

multithreadhez probald esetleg az oprofile-t (bar azt meg nem hasznaltam)

gprof <- na megnéztem, hát ez nevetségesen bárgyú

nekem is van saját ,,profilozó'' a kódomban (ez abból áll, hogy a részek futásidejét printf-el kiírja). viszont a threadok eloszlásának hatékonyságát így nem tudom vizsgálni, ezért kellene egy ilyen profilozó, ami gondolom kicsit komolyabb, és ami erre képes.

ha csak a -pg kapcsoló kell a fordításnál, az még rendben van, csak speciális direktívákat ne kelljen beleírkálni. a gprofot még nem próbáltam, tegnapig nem is hallottam róla, hogy van ilyen. ezt az amd féle szart akartam először, ez nagyon jónak tűnik, de ha hibás, akkor ezvan.

Idézet

---

Geri :
tud valaki linux alá processz profiler toolt? olyat, amit NEM fordításkor kell hozzáadni, hanem a futó processzt képes profilozni.

---

eleg trivialis valasztas a gprof, nem probaltad? igaz, forditasnal kell a -pg kapcsolo a gcc-nek, szoval ha mar kesz binarist akarnal profilozni, akkor ez nem biztos hogy menni fog
mondjuk en csinaltam sajatot, ami sokkal kevesebbet tud mint a gprof, viszont amire nekem kell arra megfelel, es nem lassitja nagyon a programfutast

amd codeanalyst - ez jó lenne, csak lefordíthatatlan. (hiányzik egy fájlja)

tud valaki linux alá processz profiler toolt? olyat, amit NEM fordításkor kell hozzáadni, hanem a futó processzt képes profilozni.

Vágósíkoknál is kell cache. Elég dinamikus a menete, úgyhogy nem biztos hogy jó lesz akkor, ha a cache elkerülése a cél.
A mozgásirányból és az aabb egdekből (itt pontokból) megkapott síkokkal minden edge-ből ki kell vágni a pontokat az összes polygonból, ami esélyes hogy útba esik. Ezt a mozgás sebességével lehet szűrni, csak azt kell listára rakni, ami útba esik.

Aztán a pontok bekerülnek szintén listába. Ezekből visszamarad mindkét tengelyre a két legközelebbi, amik meghatározzák a normal-t is. A legközelebbi tengely aránya a mozgás irányából kiadja mennyit mehet az aabb.

Csúszni akkor kell, ha egyenletesen rajta van már a síkon.

Tehát van egy "hova akar menni" irány és hossz, aztán kiderül valójában mennyit szabad mennie az aabb-nek, Silányul megfogalmazva és gyorsan ledarálva.

Én úgy csinálnám, hogy amikor a dombnak ütközik, eltárolnám, hogy a jobb alsó sarok a dombon megy, és a középpontra is fel lehet írni egy képletet (domb egyenese + konstans). Amikor a plafonnak megy, elmented, hogy a plafonnak ment. Majd kiszámolod hol kell lennie a középpontnak (y értéke). Majd kiszámolod a dombon hol lesz ez az y érték.

Jobb megoldás nincs. Szerencsére az esetek többségében nem lesz több iteráció, de ilyen esetekben megtörténhet. De ha kicsit lopsz az energiából, akkor nem lesz feltűnő és elég hamar el fog fogyni, így nem kell sok iteráció.

Pretender : A SAT-ot már sikeresen implementáltam , azt használom forgó objektumok és a CharaterControllerBox között (Super Mario vs forgó tüzes rudak)

Matzi : Szóval akkor mégis jól gondoltam hogy több iteráció kell... Akkor megpróbálom addig "tologatni" a box-ot amíg nem ér hozzá semmihez... ÉS CSAK UTÁNNA rajzolom ki.

ddbwo : Kifejtenéd bővebben is ? A vágósíkos verzió érdekelne . A Manifold viszont annyira nem nyerő mert cache-elni kell minden pontot hogy a végén kiszámold a végleges poziciót ahoz pedig megint csak futtatni kell a Matzi által említett loopot akkor meg már mindegy hogy melyiket használom (valójában mind a kettő ugyan azt csinálja csak másként)

Manifold rendszer vagy vágósíkok vannak.
Vágósíkoknál itt csak két tengelyt kell figyelembe venni, mivel csak 2D.

Gyakorlásnak vágósíkok a top, annál úgyse jöhet nehezebb.

Dookle:
Nem vészes a dolog, csak minden ilyen ütközés és velocity irány változás után ráereszted az egész ütközéses mizériát még egyszer. Minden alkalommal egy kicsit le kell csípni a megmaradt energiából, és akkor nem is lesz végtelen ciklus.

Anno nézegettem olyasmit, hogy SAT (alias separating axis theorem - gamedeven is van róla valami írás).
Annak érdemes utána nézni, az valami olyasmit csinál, hogy kiszámolja, hogy mennyivel kell "visszatolni", hogy ne ütközzön.

Heló. Egy kis problémába futottam.Egy 2d side scroller -t csinálok (újabb gyakorló project) . A lényege :

1 saját qudtree alapú rendering
2 saját ütközés vizsgálat (vektor alapú)

a 2. pont az ami megizzaszt... Az előző projectembe nagyon egyszerű volt megoldani mert sima swept AABB to AABB -t használt.Ebbe az új projectbe viszont szeretnék mindenféle dombokat meg lejtőket is tenni.(alapjába véve megoldottam , de van pár szituáció amivel nem tudok mit kezdeni .Itt egy kép




1. kép
Szóval a box halad előre míg egy dombhoz ér .Ekkor a velocity megvváltozik(a domb normaljaból kiszámítva) és a box elkezd felfelé "csúszni" .IGENÁM !!! de mivel a velocity változott , ezért fenn áll az esélye hogy egy másik ponton is keltkezik ütközés (2. kép) .Így az újonnan keletkezett pont lejebb tolja a box-ot ami azt eredményezi hogy megint alul fog ütközni.... és így tovább és így tovább...

Nemtok semmi ésszerű ötlettel előállni... Az egyetlen ötletem az ilyen esetekre hogy addig kell folyamatosan újra és újra ellenőrizni AZ ÖSSZES POTENCIÁLIS obstacle-t míg a kontakt pontok száma nem lesz 0. Tehát ha velocity iránya megváltozik akkor újra kell kezdeni az egész vizsgálatot .
De szerintem ez nem a járható út , de más ötletem nincs... Esetleg valami pszeudó kód jól jönne ha van valakinek ötlete...

PS : még mielőtt valaki ajánlaná a Box2d-t : ne tegye ! Ennek aprojectnek pont az a célja hogy tanuljak belőle.Nem sok kihívás látok benne ha valami külső libet használok ...előre is köszi

Elvileg mindegyik az összes pontba megkeresi, ha hagyod végigfutni. A mapban benne lesz, különben nem lehetne visszakeresni a kiindulási pontot és az útvonalat.
Max ha eleve a teljes feltérképezés a cél, akkor csak ki kell hagyni a mintavétel választásának az értékelését.

Az esetek többségében még az általam gravitációsnak nevezett mintavétel haladás is jobb, ha nem túl bonyolult a pálya.

A Dijkstra valóban lassabb, optimalizálás nélkül ha jól rémlik O(n^2). Viszont szerintem egy elég jól megérthető szélességi gráfbejárás. Az egy adott pontból az ÖSSZES pontba meghatározza a legrövidebb utat. Én 2 éve egy ilyet írtam a versenyre, illetve nem túl rég újra implementáltam egy dijkstra-t. Szerintem érdemes azt megnézni, tényleg elég rövid kóddal megoldható.

@Eldor:
Köszi, utánanézek. Mondjuk az A* ránézésre jobbnak tűnik futásidő szempontjából.

Én a legeslegoptimálisabbat szoktam választani. A legeslegrövidebb út elég könnyű, csak egy hullámot kell indítani, amíg meg nem találja, aztán a legkisebb értékekből megkapjuk a legeslegrövidebb, lehető legpontosabb utat. Amivel már azt lehet csinálni, amit akarunk.
Természetesen ddbwo algoritmust használok rá.

bolyzsolt:
Pár dolgot hozzátennék a dologhoz. Először is olyan nincs, hogy "legoptimálisabb". Valami vagy optimális, vagy nem.
Másodszor pedig az A* egy heurisztikán alapul. Ennek a heurisztikának a lényege az, hogy viszonylag nagy pályákon is gyorsan talál egy viszonylag rövid útvonalat. Ha tényleg a legrövidebb utat akarod megkeresni, akkor használd a Dijkstra-algoritmust. Először picit nehéz megérteni, de igazából nagyon egyszerű, az implementációja. Pont tegnap implementáltam valami miatt, összesen 60 sor lett a forráskód.

Értem, köszönöm. A versenyfeladatban nincs ilyen megkötés, ott bármelyik szabad mezőre lehet lépni, úgyhogy kicsit módosítok akkor az algoritmuson.

bolyzsolt:
A logikai hiba ott van, hogy átlósan ugyan lehet lépni, de ha egy akadály sarka mellett kellene így elhaladni, akkor mégsem. Ez afféle fizikai korlát, hogy férjél el. Különben ad abszurdum előfordulhatna, hogy két akadály csak átlósan érintkezik, de te ennek ellenére átlépsz az összeérő sarkakon a túloldalra.

Gondolom ha átlósan menne a fal végénél a kocka, nekimenne a falnak. Írja az elején, hogy a négyzetrács csak a keresés miatt lett megrajzolva, hogy lekorlátozzák a lehetséges mozgásokat. Ha úgy mozogna átlósan, hogy a fal csücskével érintkezzen a kocka csücske, akkor még rövidebb lenne az út. Te megírhatod úgy az algoritmust, hogy átlósan is mehet, ahogy akarod.

Egy versenyfeladat kapcsán felmerült, hogy implementálnom kéne egy útkereső algoritmust. Egy sima négyzetrácsos pályáról van szó, ahol minden minden irányba (tehát átlósan is) pontosan egyet lehet lépni körönként. Az A* algoritmussal kapcsolatban elolvastam ezt a cikket. Na most elméletileg az A* a legoptimálisabb utat adja vissza minden esetben (öö, ugye?), ennek ellenére a cikkben látható megoldás 68 "költségű" és 6 kör alatt lehetne megtenni, viszont pl. ha az útvonal egy "V" betű lenne (2 lépés átlósan jobbra le, aztán 2 lépés átlósan jobbra fel), akkor 56 lenne a "költség" és 4 kör lenne csak az út.

Kérdés: mit néztem el?

Rendben, köszönöm.

Én is a napokban fogom megcsinálni a parallax háttérkezelést a HTML5 enginemhez, szóval lehet összedobok valami kis szösszenetet róla.

Ennek a végén van néhány nagyon jó magyarázat: Ibm-es cikk
Másik ,amit találtam ahhoz még demo is van ,habár az is canvashoz: megoldás a lényeg
Wikipedian is volt egy cikk: Parallax Scrolling

Tudna nekem valaki adni valamilyen leírást, vagy linket, amiben elmagyarázzák egy 2ds scrolling engine működési elvét?

Találtam egy ilyen példát de ez as3 -om az meg nem igazán érdekel. http://www.hobbygamedev.com/beg/everyones-platformer-editor-and-3-level-demo/

Elméleti része érdekelne nem a programozási, mert azt megoldom.

Idézet

---

Katalin :
Sziasztok!

Hol lehet idehaza LUA scriptet tanulni?

---

http://thor.4242.hu/scripting/manual_hu.html

Sziasztok!

Hol lehet idehaza LUA scriptet tanulni?

ebook

Hát pedig egyszerűbb könyvből olvasni. Könnyebben oda tudok figyelni. A számítógépen olvasás/tanulás könnyen internetezésbe fulladhat .

van benne kereső és ugy hívják, hogy tartalomjegyzék. meg hát ha sok hasznos dolog van benne akkor ugyis végigolvasom, ha meg semmit sem ér akkor nem veszem meg. pdf-ből meg googleből nem érdemes mindent megtanulni. kisül az ember szeme mire 100 oldalt végigrág. nem ér annyit. kiegészítésnek, meg elakadáskor jó a google ja 20 percre kb.

nem erdemes mar konyvet venni, elavult a fenebe, mar egy szakacskonyvet sem birok vegiglapozni, hianyzik belole a kereso

Ez nem rossz, nem tűnik annak, de amilyen ára van jobb lenne ha előbb meglenne pdf-be aztán ha tényleg tetszik akkor mondjuk megvenném. Egyebek valaki?
Meg még egy kérdés: Nem akarja vki megvenni nekem? xD

Nekem ez van, nagyon vastag és sok minden van benne:

http://www.scolar.hu/index.php?site=bookDetails&bookId=57

csőőőő
Algoritmusokat tanulok. Ilyen alapalgoritmusok gondoltam összeszedek egypárat.. Tudtok ajánlani néhány könyvet, weboldalakat amik jók?

Crysis deferred lightingol es eleg jol megy. Es amugy igen, a geometriat gyorsabb kirajzolni (a fwd render eleve gyorsabb mint a deferred).

Tudom, összeszedted a honlapon, de azért továbbra sem teljes ez a performancia dolog nekem.
- ezzel a stenciles deferred shading technikával ugye a memória a nagyobb gond
- a deferred lightingos technikával pedig az, hogy az adott jelenetet még egyszer ki kell rajzolni. Ami esetenként nem is lehet túl kevés, ha mondjuk valami nagyobb, nyitott terepen vagyunk (és például talajt is renderelni kell, stb.)

Nem is beszélve a mindkettőnél előforduló shadow map generálásról, ami még egy geometry passt jelent.

Az a kérdéses, hogy a geometriát azt vajon gyorsabba kirajzolja, mint amekkora hátrányt jelent a + memória sávszélesség + fillrate a deferred shading esetében? Ez függ ugye a geometria komplexitásától, ami a deferred lightingot jobban függővé teszi a geometriától.

SSS szerintem az utolso dolog ami egy jatekba kell.