Hát ez fura, lehet van valami a getMetrics-ben ami értéked ad a metrics-nek, de ha így s van akkor az csak véletlen egybe esés szerintem szóval annak a változónak máshogy kéne értéked adni, nem úgy hogy egy result-ot elküldünk a devnull-ba.


EDIT:

Úgy látszik ez így működik, egy ilyet találtam a neten.



Jó volna látni a kódját, mert most már érdekel.


EDIT2:

Viszont nálad még mindig nem stimmel, nem így lenne a helyes?

Röhögni fogsz, de kell az a sor. Most, ahogy be akartam volna nyomni a saját kódomba, jött a szép FC. 'Width and height must be > 0'

A getMetrics() szerintem beállítja a paraméternek átadott DisplayMetrics-t. Mindjárt utánanézek. Milyen jó, hogy egy doksiba összeírogatok mindent!

Na akkor lassan csak beindul az agyműködésem, azt hittem tökre nem értem a kódot.

Egyelőre az bosszant, hogy nem jelentkezik a hiba, amit ezzel kéne kiküszöbölni. De ha hazamentem, akkor megint szétkapom a kódot.

Igen, a GetDPIScaled fgv-k azok sajátok. A DisplayMetrics meg szintén igen, beépített cucc. Az a sor meg nem tudom hogy került oda, elvileg kikommenteltem . Annak úgy tényleg nincs érteme. Viszont kelleni fog a DisplayMetrics, mert abból fogjuk megkapni a DPI arányt.

És igen, pontosan arra van az additionalScale.

Köszi!

Ebben a kódrészletben nem biztos, hogy kiigazodok.

Ha jól értem, akkor a GetDPIScaled() az egy saját függvény, de a DisplayMetrics az valami beépített cucc?

És ez a sor megy a levesbe?



Mintha hiányozna innen egy érték adás.


Az additionalScale meg akkor kell, ha a korrekción felűl még skálázni akarod a képet?

Idézet

---

DMG :
Köszi!

Arányokkla terveztem én is dolgozni, csak a jelenlegi jelenséget nem értem. Most 240d és 120d mellett is ugyan az az eredény, ami bosszantóbb, mintha elnyújtaná 240-en, mert akkor tudnék rajta dolgozni.

Nagyon még nem aklimatizálódtam, így a "nyaralás" után, szóval még nagyon nem merültem bele, talán ma este, már tudok vele érdemben foglalkozni.

---

Én amíg nem tudtam, hogy DPI-ben is van eltérés (mert egy láma vagyok), addig csak a width és a height arányok alapján próbáltam nyújtogatni, ami totál káosz volt. Btw, lehet, hogy nem látod, de updateltem az előző posztom.

Köszi!

Arányokkla terveztem én is dolgozni, csak a jelenlegi jelenséget nem értem. Most 240d és 120d mellett is ugyan az az eredény, ami bosszantóbb, mintha elnyújtaná 240-en, mert akkor tudnék rajta dolgozni.

Nagyon még nem aklimatizálódtam, így a "nyaralás" után, szóval még nagyon nem merültem bele, talán ma este, már tudok vele érdemben foglalkozni.

@DMG

Idézet

---

The conversion of dp units to screen pixels is simple: px = dp * (dpi / 160). For example, on a 240 dpi screen, 1 dp equals 1.5 physical pixels.

---

--nyilván ha 120-as density-re fejlesztessz (mint ahogy én is), akkor a '/ 160' / 120' lesz. akkor úgy kapod meg jól a koordinátákat. Ha a dp 1, akkor láthatod (elemi matek) a két dpi közti arányszámot, amit felhasználva konvertálhatod a képeket.

Én így jártam el, és lekopogom, hogy eddig jó minden (bár tesztelni csak emukon 'tudtam'. Egyébként meg általánosságban tudom csak azt tancsolni, hogy textúraskálázásnál ne fix értékekkel, hanem arányokkal dolgozz. Ugyanígy a koordinátáknál (x koordináta legyen a képernyő fele, mínusz a kép szélességének fele) - akkor szerintem sokkal pontosabb eredményt fogsz kapni az eredetihez képest, mintha fix értékkekkel szórakoznál.


Edit: Hát DMG, nem hittem volna, hogy erre fog sorkerülni, de megnéztem a jelenlegi konverzióm, és egy most gyorsan kigondolt konverzió közötti pontosságbeli eltérést, és KÖSZÖNÖM!
Az eddigi módszerem totál más volt. Ez -legalábbis eddig úgy néz ki- pontos eredményt ad. A következőt csinálom a képek betöltésekor:



A displMetrics pedig a következő:


A 'density' meg visszaadja a te képernyőd és a 160dpi közötti arányt.

Ennyire egyszerű nálam. Én meg mindent túlbonyolítottam Vagy lehet, hogy abszolút tévedek, és nem is jó? Nálam eddig jónak tűnik, de majd még írok...

Na jó, lefagytam. A Draw texture csúnya dolgokat művel különböző felbontásokon és Density-n.

Mert ha még csak a méretében lenne eltérés, akkor tiszta lenne a dolog, de hog ya textúrakép "kvázi textúra koordinátái" sem stimmelnek, az már fáj.

120 Density-nél jó de 240-es density-nél még csak véletlenül sem a duplájára nyúlik.

Valakinek valami hasznos ötlete?

LugaidVandroiy: lehet most jól jönne a több felbontásban szerzett tapasztalatod, megosztanád velem?


EDIT:

Most újrafordítottam, a tegnapi szétjuggatás után (szarakodtam kicsit az orto-val aztán visszaálltam az eredeti perspektív nézetre) és működik. Kit verjek álcsúcson?

Idézet

---

LugaidVandroiy :

Idézet

---

DMG :
Nekem szokott használni, ha befrissítem az egész projectet és újraindítom az eclipse-t, engem is rohadtúl bosszant, nem tudom, hogy lehetne rávenni a frissítésre rendesen.

---

Én időközben rájöttem: Project->Clean. Szinte megtláltosodik.

---

Ezt kösz!

Kerstem, hog yhol lehet egy ilyn funkció.

Idézet

---

Pretender :

Idézet

---

LugaidVandroiy :
Thrall:
Köszönöm szépen! Kaphatnék valami felvilágosítást a konstansokról meg arról, hogy a ciklus minek kell (az utóbbit hirtelen nem látom át miért lenne szükséges)? Mindemellett kipróbálom, és majf írok hogyan sikerült

---

mondjuk azért kell a ciklus, hogy ne 1db-ot generálj....

---

Jó, jogos, néha nagyon nem tudom meglátni a nyilvánvalót

Idézet

---

LugaidVandroiy :
Thrall:
Köszönöm szépen! Kaphatnék valami felvilágosítást a konstansokról meg arról, hogy a ciklus minek kell (az utóbbit hirtelen nem látom át miért lenne szükséges)? Mindemellett kipróbálom, és majf írok hogyan sikerült

---

mondjuk azért kell a ciklus, hogy ne 1db-ot generálj....

Idézet

---

DMG :
Nekem szokott használni, ha befrissítem az egész projectet és újraindítom az eclipse-t, engem is rohadtúl bosszant, nem tudom, hogy lehetne rávenni a frissítésre rendesen.

---

Én időközben rájöttem: Project->Clean. Szinte megtláltosodik.

Nekem szokott használni, ha befrissítem az egész projectet és újraindítom az eclipse-t, engem is rohadtúl bosszant, nem tudom, hogy lehetne rávenni a frissítésre rendesen.

Miért van az, ha Eclipse-ben több darab új assetet másolok a a drawable-k közé, akkor összekeverednek? Értem ez alatt, hogy a címzés teljesen felborul, és a kívánt content helyett más contentet lát Rájöttem egy megoldásra: törölni az összes képet, majd egyesével kell hozzáadni. Viszont most 55 darab kép van a projektben, amit egyesével visszaállítani...

Az R.java törlése és újragenerálása nem segít. HELP ME!

Szerk.: kitöröltem egy képet, visszapakoltam, nyomtam egy F5-öt, vártam míg befejezi a "building workspace" cuccost, és minden zsír.

Thrall:
Köszönöm szépen! Kaphatnék valami felvilágosítást a konstansokról meg arról, hogy a ciklus minek kell (az utóbbit hirtelen nem látom át miért lenne szükséges)? Mindemellett kipróbálom, és majf írok hogyan sikerült

LugaidVandroiy:
Nagyon gagyi megoldás:
Úgy generáld, hogy valami rendszer szerint, de mégsem.

Pl.
for (i = 0; i < 100; i ++)
{
ide_x = random(pályaszél)
tüskegenerál(ide_x, -képmagasság - i * 100 - 20 + random(40) );

if (random(20) < 1)
tüskegenerál(pályaszél - ide_x, -képmagasság - i * 100 - 40 + random(80) );
}

Szal így nem teljesen lesz random, de mégis kicsit, és nem csúsznak össze.

A büszkeségem nehezen engedte, de most mégis a véleményetek/segítségeteket szeretném kérni. Van nekünk ez a játékprojektünk, a BalloonAviator. Ebben a játékban vannak random elhelyezett, lefelé hulló tüskék. A generálás a következőképp zajlik (a pálya kezdetekor, illetve, ha a tüske a pálya aljára ér hívódik meg a generálásért felelős függvény):
- generálunk egy random x pozíciót, de úgy, hogy a képernyőn belül maradjon, és ne lógjon ki onnan
- generálunk egy random y pozíciót; a konfigurációs fájlban megadott sűrűségjelző szorozva a canvas magasságával a max.

Az első generáláskor továbbá figyelembe vesszük a többi tüske pozícióját, és ellenőrizzük, hogy van-e ütközés köztük. Gondoskodunk róla, hogy ne legyen.

És itt a kérdés: ez elég? Vagy kellene egy kifinomultabb eljárás a rendezésre? Néha előfordulnak furcsa elrendezések, és nem tűnik folyamatosnak.


Szerintetek ez jó így, vagy ki kell találni valamit? Ez az elrendezés akkor lenne rossz, ha több (4+) ilyen tüskét használnánk egyszerre.

Höhö.

Játszadoztam kicsit a draw texture-el

100 billboard mesh DrawElement-el
átlagban 2.0 FPS

ugyan ez Draw texture-el
átlagban 5.0 FPS

és nem száll el 2000 "részecske számnál" sem.

Én ennek már tudok örülni.

VBO még mindig várat magáta, de felteszem, hogy igazi hatása csak hardveren lesz, ott remélem a DrawTexture is többet hoz, mert elvben az a leggyorsabb megjelenítési forma, csak ügye kicsit korlátozott.

Igen is, egyet értek.

Ezek a témák úgy el tudnak tünni.

Idézet

---

DMG :
[...]
Lesz itt még "Fejlesztés Iphone-ra" Topic.

---

Van ilyen fórum:Iphone, Fejlesztés
Úgyhogy Mac-es témát inkább oda, ne offoljuk ezt szét, köszi.

'vállalkozás szintjén' - ez alatt pontosan mit értesz? Valamelyik nap néztem mennyibe kerülnek a mac ek(ipadra kerestem egyébként, csak aztán legörbült a szám amikor megláttam az árcédulát.), 320 volt a legolcsóbb mac, és jóval gyengébb alkatrészekkel lett megpakolva, mint mondjuk egy 170-180 s pc(win, egér, billentyűzet meg hangszórók nélkül.) A pro meg a maga 680-720 körüli árával mindent elmondott magáról szerintem - és az sem erősebb, mint a fent említett, 170k s pc.

Idézet

---

DMG :
Lesz itt még "Fejlesztés Iphone-ra" Topic.

---

Az jó lesz, bár én is utána néztem és igencsak speckó hardvert kell összerakni ahhoz, hogy egyátalán menjen rajta a rendszer és az is bugos lesz. Vállalkozás szintjén egy PC + legális szoftverek = Mac, amin alapból ott van minden, ami kell, szóval olyan mindegy. Hobbi célra meg minek IPhone.

Hát nem is vennék, ha már ott a wmware, Iphone-t is max azért, hogy terjeszkedjek fejlesztés ügyileg.

Lesz itt még "Fejlesztés Iphone-ra" Topic.

Ja sokan istenítik, mert biztos az Apple templomba járnak imádkozni. És ennek a gyülekezetnek rengeteg tagja van. De hidd el, hogy nem éri meg mac-et venni .

iPhone-t sem éri meg annyi pénzért, de az legalább tényleg jó.

kollégák között akinek van az isteníti, de felteszem nem fejleszt rá játékokat.

Idézet

---

DMG :
Mac-en is lassabb mint a telefonon?

---

Igen. Ha vannak itt Apple fanok, azok most fogják be a fülüket, de a macbook-ra sok mindent lehet mondani, csak azt nem hogy jó . A simáról beszélek, MacBook Pro-hoz még nem volt szerencsém.

Ha elakadok feltétlen szólok majd, ksözi, már gondoltam rá, hogy konzultálok veled ezzel kapcsolatban.

Most ennek a Draw Texture-nak próbálom megfejteni a működését, de még nem látok semmit.


MOD: megint szétlyukgattam a kódot, de legalább már működik a draw texture. GUI-nak meg esetleg részecske rendszernek jó lesz.

VBO meg holnapra marad.

DMG: a felbontással én is sokat küszködtem, ha nagyon kell, megkönnyítem a dolgod, és odaadom a releváns kódrészletet

szerk: pontosabban a canvashoz heggesztettem működőt, OGL-re még nem igazán néztem.

Idézet

---

FZoli :
egy x10 mini pron, galaxy acen, zte bladen, galaxy p1010 tabon, galaxy S-en tudok próbálni, ha nagyon kell.

---

Az zsír.

Nagyon kell.

Felteszem majd csak jövő hónapban lesz aktuális, most elmegyek nyaralni aztán még meg kell csinálni pár apróságok, épp VBO-t Meg Draw_Texture-t implementálok, hogy kihozzam a maximumot. Az a fránya textúra tömörítés még mindig hiányzik. Meg még felbontással is szórakoznom kell,ho gyminden felbontáson azt lássam amit akarok. Szóval még van egy pár apróság, de jó hír, hogy ennyi féle hardveren lesz lehetőség kipróbálni. Köszi!

egy x10 mini pron, galaxy acen, zte bladen, galaxy p1010 tabon, galaxy S-en tudok próbálni, ha nagyon kell.

Idézet

---

Seeting :

Idézet

---

DMG :
[...] bár fejlesztőrendszert már össze tudok reszelni IOS-hez én is, csak telefon nincs amin kipróbáljam.

---

A szimulátor is elég használható, csak arra figyelj, hogy sose hagyatkozz az ott mért eredményekre a teljesítményt illetően. Nekem például szimulátorban sokkal lassabb a játék, mint tényleges device-on. Ami azért érdekes, mert azt várná az ember, hogy fordítva legyen.

Ja és a szimulátor nem küld memory warningokat sem.

---

Ez így van androidon is, ott mondjuk logikus, Mac-en is lassabb mint a telefonon? Az tmég megértem, hog ya hardveres virtualizációval futtatott wmvare-en lassú.

Idézet

---

DMG :
[...] bár fejlesztőrendszert már össze tudok reszelni IOS-hez én is, csak telefon nincs amin kipróbáljam.

---

A szimulátor is elég használható, csak arra figyelj, hogy sose hagyatkozz az ott mért eredményekre a teljesítményt illetően. Nekem például szimulátorban sokkal lassabb a játék, mint tényleges device-on. Ami azért érdekes, mert azt várná az ember, hogy fordítva legyen.

Ja és a szimulátor nem küld memory warningokat sem.

LugaidVandroiy: Köszi! Hamarosan szavadon foglak.

Pretender: OK, de százalékos arányban még mindig sehol nincs a két konkurencia melett, véleményem szerint kicsit elkésett vele a Microsoft, persze még változhat a felállás.

@DMG: igen, láttam már, elég stabilan működik

Bratyómnak van egy samsung galaxy ace-e, azon megy minden vagy vannak durva verziók meg ilyesmik, amitől egyes progik nem működhetnek?

Idézet

---

DMG :
Jut eszembe, ha elkészül egy benchmark, akkor ki az aki ki tudja próbálni?

---

Nekem van egy szerényebb Androidos kütyüm, ha gondolod lefuttatom a benchmarkot.

Hát elvileg lesz update lehetőség, de nem tudom, hog yképzelik el, szervízbe be, aztán gariban megy az upgrade. Még rohadt ritka a hivatalos 2.3-as mobil.

A hackelt cuccok meg általában bugzanak, vagy nem teljesen üzemelnek, de annyira én még nem értek hozzájuk.

Pretender:

Láttál te már stabilan működő WP7-et? én még csak rémhíreket halottam róla, majd talán jövőre, de igen kis százalékot tud véleményem szerint kiharapni a tortából, szóval marad az IOS és az Android. Halandó embereknek meg inkább android, bár fejlesztőrendszert már össze tudok reszelni IOS-hez én is, csak telefon nincs amin kipróbáljam.

minden boldog-boldogtalan androidra fejleszt, a wp7 meg ott áll kihasználatlanul... tény, hogy xna kell hozzá, viszont egy telefonra bőven sok

Izé...a samsung szokta tartani a lépést az androiddal? Mert jelenleg 2.2-es van a cuccomon (galaxy ace), de a neten láttam módszereket hogy hogyan lehet ráhekkelni a 2.3-at; de ha hivatalosan is elérhetö lesz vmikor akkor inkább azt kéne megvárni

Ha valaki csinálna valami kis játékot rá, szívesen rajzolnék hozzá.

Idézet

---

Asylum :
Én nemrég kezdtem el nézegetni az android sdk-t és ndk-t, úgy látom hogy teljesen c++ -ban nem lehet, hanem csak ugy, hogy egy c/c++ libraryt hivogatsz javaból (amihez viszont van nyelvi támogatás a "native" kulcsszó formájában).

---

De lehet teljesen C++-ban, csak a fő XML-nek kell megmondani, hogy Natív activity-t használ a program. Onnantól kezdve egy sort sem kell leírni Java-ban, de ez csak 2.3-as androidtól működik.

Az alatt meg szerintem nem is érdemes a natív kóddal szórakozni, mert csak metódusokat tudsz hívogatni, egy full C++ osztályt nem, tehát az OOP C++ alatt elvész.

Bár most próbálgatom,hogy mennyi kraft van egy OPENGLES motorban tisztán SDK alatt, kerültek már elő furcsa limitációk (vagy csak program kód hiba, még keresem), szóval lehet, hogy bukom ezt a SDK alatt 3D-s dolgot, de egyelőre készül a benchmark.


Az mondjuk érdekelne, ha valakinek van tapasztalata:

Láncolt listában tárolok mondjuk 1000 mesh objektumot, amivel nincs is baj, egy mesht csak egyszer tárolok, csak indexel hivatkozok rá. De mikor kirajzolásra kerül, akkor egy szám felett elszáll hibával, csak még nem építettem bele kivétel kezelést, így nem tudom, hogy hol és mivel.

syam

---

EGL nincs c++ oldalon és ha jól tudom native activity sem.

---

Én már írtam is, futtattam is, csak a 2.3-as limitáció miatt egyelőre kukáztam, majd ha elterjed a 2.3, akkor átállok rá.






MOD:

Jut eszembe, ha elkészül egy benchmark, akkor ki az aki ki tudja próbálni? Vagy itt mindenkinek IPhone-ja van, csak én vagyok vizibicikli?



MOD:

Tudom már sok vagyok.


Egy kis infó:

A júniusiban ha jól láttam van az is.

Idézet

---

Parallax :

Idézet

---

syam :
API level 9-től már lehet tisztán c++ban tolni. Ez alatt NDK / jni kombó kell c++hoz.

---

Ha az ablakkezelés, image kezelés, OpenGL ES, OpenGLSL, Input is elérhető natív libből, akkor a JNI az mihez kell? Mitha úgy olvastam volna valahol, hogy C++ project is van mindenféle hakkelés nélkül.

---

EGL nincs c++ oldalon és ha jól tudom native activity sem.

Idézet

---

syam :
API level 9-től már lehet tisztán c++ban tolni. Ez alatt NDK / jni kombó kell c++hoz.

---

Ha az ablakkezelés, image kezelés, OpenGL ES, OpenGLSL, Input is elérhető natív libből, akkor a JNI az mihez kell? Mitha úgy olvastam volna valahol, hogy C++ project is van mindenféle hakkelés nélkül.

API level 9-től már lehet tisztán c++ban tolni. Ez alatt NDK / jni kombó kell c++hoz.

Igen, ez így van. De ha jól emlékszem ígértek teljesen Java független NDK-t a közeljövőre.

Én nemrég kezdtem el nézegetni az android sdk-t és ndk-t, úgy látom hogy teljesen c++ -ban nem lehet, hanem csak ugy, hogy egy c/c++ libraryt hivogatsz javaból (amihez viszont van nyelvi támogatás a "native" kulcsszó formájában).

Ha valaki esetleg fejleszt a mézeskalácsra C++ ban megoszthatná a tapasztalatait. Mennyi hekkeléssel jár, kell e egyátalán JNI-zni?