játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5440
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:    2185
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]
Marcsello - Tag | 228 hsz       Online status #196545   2013.08.03 22:08 GMT+1 óra  
Hát, ha mindenképpen Android telefon, akkor egy Caterpillar B15, de csak mert a legutóbbi Okos telefonom pár hónap után így nézett ki: http://ww1.prweb.com/prfiles/2012/05/16/9510753/iphone-broken.jpg. De amíg én sem állok jobban maradok a Nokia 100-nál. De táblából én is a Nexus 7-re szavazok.
Az élet szép, csak tele van Bugokkal
http://marcsello.com/
   
DMG - Szerkesztő | 3172 hsz       Online status #196441   2013.07.31 06:03 GMT+1 óra  
Na akkor fussunk neki még egyszer.
Mint ha láttam volna syam-től valami hozzászólást, csak SQL server nyűgje miatt nem tudtam megnézni, most meg nincs sehol.
-----------------------------------------
Dont Listen to the Naysayers
   
DMG - Szerkesztő | 3172 hsz       Online status #196374   2013.07.26 19:29 GMT+1 óra  
Még nem raktam fel a 4.3-at a telóra, szóval még várok vele, de meglesem.

Jah és ma eldöntöttam, hogy ha Android akkor Nexus, ha lesz rá keretem veszek is egy új nexus 7-eta tabletem helyett.
-----------------------------------------
Dont Listen to the Naysayers
   
syam - Törzstag | 1491 hsz       Online status #196363   2013.07.26 14:46 GMT+1 óra  
Tudomásom szerint elérhető Androidra az GL ES3.0 SDK.
alias aalberik
   
Ronnin - Tag | 6 hsz       Online status #194500   2013.06.04 02:31 GMT+1 óra  
Üdv!

Androidos alkalmazások fejlesztéséhez a következőket keresünk:

- Grafikust
- Openglben jártas programozó
- Java programozót

Akit érdekel az írjon a varmol8@gmail.com email címre és megbeszéljük a részleteket.

   
__z - Tag | 69 hsz       Online status #193945   2013.05.13 02:27 GMT+1 óra  
kernel_panic - Tag | 117 hsz       Online status #192663   2013.03.23 16:54 GMT+1 óra  
dvorgaz - Törzstag | 575 hsz       Online status #191936   2013.03.06 17:03 GMT+1 óra  
Csak az android projektben vannak asseteim, máshol nincsenek is.
   
gopher - Törzstag | 491 hsz       Online status #191935   2013.03.06 16:56 GMT+1 óra  
@dvorgaz: tuti 100%, hogy az Android projekt mappájába is bemásoltál minden assetet? (Csak azért kérdem, mert nálam akkor fordult elő ilyen, mikor elfelejtettem)
   
dvorgaz - Törzstag | 575 hsz       Online status #191918   2013.03.05 22:40 GMT+1 óra  
Idézet
LugaidVandroiy :
Hülye kérdés, de egyáltalán betöltődnek a textúrák Androidon?


Gondolom hogy igen, mivel ugyanolyan png textúrák mint amit egy modellre ráhúztam, és az meg látszik rendesen.

Idézet
kernel_panic :
@dvorgaz:
A "semmi nem látszik" konkrétan mit jelent, fehér/fekete felület látszik helyette, stb. ?


A clearcolor látszik helyette meg egy modell. Illetve ha a skybox shader-ében kiveszem a samplert és csak fehér színt adok vissza, akkor látszik a fehér háttér.
   
LugaidVandroiy - Törzstag | 504 hsz       Online status #191917   2013.03.05 22:04 GMT+1 óra  
Hülye kérdés, de egyáltalán betöltődnek a textúrák Androidon?

   
kernel_panic - Tag | 117 hsz       Online status #191916   2013.03.05 22:00 GMT+1 óra  
@dvorgaz:
A "semmi nem látszik" konkrétan mit jelent, fehér/fekete felület látszik helyette, stb. ?

   
dvorgaz - Törzstag | 575 hsz       Online status #191913   2013.03.05 20:20 GMT+1 óra  
Nem atlaszt használok hanem 6 db 256x256-os textúrát, és nem emulátoron, hanem a libgdx-nek a Desktop projectjéval teszteltem pc-n. Tableten viszont semmi nem látszik a skyboxból, ha samplerCube-ból próbálok olvasni, meg semmi hibaüzenet sincs (vagy legalábbis nem látok egyet se).
   
DMG - Szerkesztő | 3172 hsz       Online status #191912   2013.03.05 20:15 GMT+1 óra  
Emulátoron látszik OpenglES alatt? és HW-meg nem? Az emulátor textúrázásával én is szívtam amíg próbálkoztam vele, én azt hiszem a Blend és Alpha kezelés környékén szívtam, ott kezel valamit fordítva az emu.
-----------------------------------------
Dont Listen to the Naysayers
   
LBandy - Tag | 271 hsz       Online status #191911   2013.03.05 20:13 GMT+1 óra  
dvorgaz - Törzstag | 575 hsz       Online status #191910   2013.03.05 20:12 GMT+1 óra  
Libgdx-szel csináltam cubemap-es skyboxot, ami PC-n faszán látszik, de tableten nem akaródzik megjelenni, van valami ötletetek, ez miért lehet?
   
kernel_panic - Tag | 117 hsz       Online status #191500   2013.02.23 13:05 GMT+1 óra  
Ha már úgyis a témánál vagyunk, íme két screenshot:
HVGA (320x480)
WVGA (480x800)
...a natív felbontás 320x532, szerintetek mennyire zavaró a torzítás (főleg, ha valaki csak a HVGA-t látja) ?

szerk: a natív magasságot elírtam, 532 a pontos érték...

Ezt a hozzászólást kernel_panic módosította (2013.02.23 14:06 GMT+1 óra, ---)

   
mandyedi - Tag | 32 hsz       Online status #191497   2013.02.23 11:46 GMT+1 óra  
Igen, de a képernyő is kisebb, szóval megmarad az arány. Ja és a pöttyök mérete is százalékos, szóval kisebb képernyő, kisebb objektumok, kisebb távolság. Kb ugyanaz mintha képszerkesztőben lekicsinyíteném a pályát. Ha jó az elméletem.

   
DMG - Szerkesztő | 3172 hsz       Online status #191491   2013.02.23 09:27 GMT+1 óra  
H ajól értem, akkor ezzel kvázi egy torzítást érsz el, ha kisebb a képernyő magassága, akkor közelebb kerülnek egymáshoz a pontok. Vagy nem értem jól?
-----------------------------------------
Dont Listen to the Naysayers
   
mandyedi - Tag | 32 hsz       Online status #191490   2013.02.23 09:00 GMT+1 óra  
Én kicsit máshonnan közelítettem meg. Én a pálya elemeinek (ami az én esetemben egy gráf csúcsai) a koordinátáit százalékos értékben tárolom és attól függően, hogy milyen a felbontása az adott készüléknek, úgy helyezem el a képernyőn a pontokat. Pl x = 0.3; y = 0.4; A koordinátákat pedig így számolom: posX = width * x; posY = height * y;

   
DMG - Szerkesztő | 3172 hsz       Online status #191489   2013.02.23 08:35 GMT+1 óra  
amezing alex is így oldotta meg, én is így tervezem, vagy úgy hogy kiterjesztem a játékteret, de ügyelek rá, hogy ott akció ne történjen. Most egyelőre örülök, ha már az alfa elkészül végre. majd utána szórakozok ezzel.
-----------------------------------------
Dont Listen to the Naysayers
   
Bacce - Bacce | 1783 hsz       Online status #191488   2013.02.23 03:50 GMT+1 óra  
Na igen, a fekete sáv nekem se szívem csücske, de pl jetpack joyride-ban úgy oldották meg a fejleszők hogy ahol a fekete sáv lett volna fent és lent ott falat rajzoltak, szóval nem egy zavaró üresség de nem is a játéktér része lett, ezzel szerintem egy jó arany középutat válaszottak.
Making the world a better place, one line of code at a time.
http://bacce.uw.hu
   
DMG - Szerkesztő | 3172 hsz       Online status #191482   2013.02.22 21:20 GMT+1 óra  
Én úgy csinálom, hogy kvázi méterben számolok, nálam most egy képernyő 10x15 méteres, ezt osztom el az aktuális felbontással és így jön ki, hogy méter az hány pixel valójában (de aránynak is lehet nevezni ). Aránykezelés még nálam sincs, de az én szememet bántja a trozulás, szóval valami megoldást keresek majd rá, az AngryBirds megoldása a szép, de teszem azt a mi játékunknál az arányos kitöltés és az ezáltal nagyobb teret megjelenítő széles vásznú gépek előnyhöz juttatnák az azzal játszókat, mert nagyobb teret látnak be a térből, de ez még tesztelésre szorúl, a fekete sávot nem csípem, de valahogy meg kell oldani. Plusz ICS-en a fix virtuális gombsor csökkenti az y tengely hosszát, a kis mocsok.
-----------------------------------------
Dont Listen to the Naysayers
   
Bacce - Bacce | 1783 hsz       Online status #191467   2013.02.22 15:34 GMT+1 óra  
Végülis az nem lenne probléma, ahol nem fér arányosan a képernyőre ott maximális kitöltés és "fekete sáv", bár a filmnézős tapasztalatok alapján megszokja a szem a 4:3-ast szélesvásznúra nyújtva is, játékban mondjuk nem tudom hogy mutatna, de 16:9 és 16:10 között tényleg nem sok a különbség. Majd utánanézek az ogl-nek, bár esélyesen hatékonyabb lenne javascriptben megoldani akkor ezt is.
Akkor végeredményben két lehetőség van, vagy egyenként méretezni előre mindent és az egész játékot úgy megírni hogy ne pixelekkel számoljon hanem arányokkal, vagy 480x800 (gondolom ez egy átlag középérték) és azt akkorára nyújtani vagy zsugorítani amekkorára kell. Ez az utóbbi egyszerűbbnek hangzik, de erőforrásigényesebbnek is.
Ok, köszi a segítséget.
Making the world a better place, one line of code at a time.
http://bacce.uw.hu
   
kernel_panic - Tag | 117 hsz       Online status #191463   2013.02.22 12:53 GMT+1 óra  
Idézet
DMG :
Ez a megoldás viszont képarányok eltérésére nem nyújt megoldást, mert torzítani fog a kép eltérő képarány esetén.


Ez igaz, de egyrészt szerintem pl. landscape módban nem feltűnő, ha a natív felbontás horizontálisan 1/10-nyit nyúlik, másrészt a "feketesávos" megoldást itt is lehet alkalmazni. Persze abban igazad van, hogy ez létező probléma, de szerintem igazán jó megoldás (legalábbis univerzálisan) nem létezik rá.

   
DMG - Szerkesztő | 3172 hsz       Online status #191459   2013.02.22 12:43 GMT+1 óra  
Idézet
kernel_panic :
@Bacce:
Szerintem az opengl használata alap, bár nem tudom, ez mennyire nehezíti meg a html5-ről való portolást. Amúgy a legegyszerűbb, ha a glViewport-al a grafika natív felbontását "ráhúzod" a képernyő felbontására (legalábbis én ezt a megoldást használom). Natív felbontásnak szerintem a 480x800 a legjobb kiindulási alap (ha jól tudom, a Google Play-en "HD"-nek titulált verziók is ezt használják), bár ha mondjuk oldschool pixelgrafikát használsz, akkor felesleges ilyen "magas" felbontás...



Ez a megoldás viszont képarányok eltérésére nem nyújt megoldást, mert torzítani fog a kép eltérő képarány esetén.
-----------------------------------------
Dont Listen to the Naysayers
   
kernel_panic - Tag | 117 hsz       Online status #191456   2013.02.22 12:01 GMT+1 óra  
@Bacce:
Szerintem az opengl használata alap, bár nem tudom, ez mennyire nehezíti meg a html5-ről való portolást. Amúgy a legegyszerűbb, ha a glViewport-al a grafika natív felbontását "ráhúzod" a képernyő felbontására (legalábbis én ezt a megoldást használom). Natív felbontásnak szerintem a 480x800 a legjobb kiindulási alap (ha jól tudom, a Google Play-en "HD"-nek titulált verziók is ezt használják), bár ha mondjuk oldschool pixelgrafikát használsz, akkor felesleges ilyen "magas" felbontás...

   
LugaidVandroiy - Törzstag | 504 hsz       Online status #191452   2013.02.22 10:21 GMT+1 óra  
Én amikor betöltöm a bitmapokat, akkor a képarányt figyelembe véve fel-vagy leskálázom a képeket. mindez persze igényel egy design resolutiont is. általában a tabletem felbontása az. densitit meg ha nagyon muszáj, tudsz állítani canvason.

   
Bacce - Bacce | 1783 hsz       Online status #191450   2013.02.22 10:13 GMT+1 óra  
Csinálgatok egy játékot playbookra és mivel html5 így nem tartana sokból portolni androidra sem, és akkor szöget ütött a fejembe hogy mégis hogy kéne kezelni azt a millió felbontást amin android fut. Mivel playbook egy méret így nem is foglalkoztam a kérdéssel, nem is figyeltem rá a fejlesztés közben hogy nyitott maradjak más felbontásra/képarányra is.

Szóval azt szeretném kérdezni hogy ti hogy oldjátok meg hogy különböző felbontásokon is ugyan úgy nézzen ki komolyabb grafikai romlás és vagy brutális erőbefektetés nélkül. Mi erre a leg célravezetőbb mód? Vagy az android market hagy lehetőséget különböző verziók feltöltésére és azt adja a usernek ami neki optimális? Lehet megadni küszöbszintet ami alatt nem mutatja az adott készüléknek a play-ben? Hogy is megy ez az egész?
Még nem néztem utána, bocs ha trivi a kérdésem.
Making the world a better place, one line of code at a time.
http://bacce.uw.hu
   
Germo - Tag | 40 hsz       Online status #191235   2013.02.11 07:19 GMT+1 óra  
Tud valaki megoldást arra, hogy flash + away3d kombóval hogyan kell aplikációt írni androidra?
A végtelenbe és tovább!
   
DMG - Szerkesztő | 3172 hsz       Online status #191196   2013.02.09 18:22 GMT+1 óra  
Idézet
LugaidVandroiy :
Én ezt használom videó felvételre. Szerintem megéri a pénzét. https://play.google.com/store/apps/details?id=com.ms.screencast
(root szükséges hozzá sajna)



Szintén zenész. Jó cucc.
-----------------------------------------
Dont Listen to the Naysayers
   
kernel_panic - Tag | 117 hsz       Online status #191192   2013.02.09 17:25 GMT+1 óra  
@Thrall:
Az android-os sdk-ban lévő "monitor" (régebben ddms) alkalmazással tudsz screenshot-ot csinálni, akár usb-n keresztül csatlakoztatott eszközről is...

   
M4 - Tag | 187 hsz       Online status #191188   2013.02.09 13:11 GMT+1 óra  
Screenshot (htc-n): kikapcsoló gomb + home

   
LugaidVandroiy - Törzstag | 504 hsz       Online status #191187   2013.02.09 13:01 GMT+1 óra  
Én ezt használom videó felvételre. Szerintem megéri a pénzét. https://play.google.com/store/apps/details?id=com.ms.screencast
(root szükséges hozzá sajna)

   
Thrall - Törzstag | 609 hsz       Online status #191184   2013.02.09 12:57 GMT+1 óra  
Sziasztok,
mégegy kérdésem lenne:
Hogyan screenshotolok/videózokmobilról android esetén?
Valakinek ezzel kapcsolatban tapasztalata/tuti tippje?
Jatekfejlesztes.hu közös projekt: próbálunk összerakni egy olyan csapatot, akik együtt el tudnak készíteni egy komolyabb játékot megfelelő minőségben. Érdekel?
Link:
JF.hu közös projekt
http://frogbonegame.uw.hu/
   
kernel_panic - Tag | 117 hsz       Online status #190815   2013.01.27 00:42 GMT+1 óra  
DMG - Szerkesztő | 3172 hsz       Online status #190774   2013.01.25 16:48 GMT+1 óra  
Idézet
Thrall :
Idézet
DMG :
Ha már így szóvakerült, elvileg teljes értékű már az emu androidra, valaki próbálta már? Mert én hiába indítok emut, ugyan úgy csak GL ES 1.x és lassú mint a teve.


Múltkor valami - szerintem nagyon komoly androidos 3d-s játék - készítője mondta, hogy emulátoron nekik is pár FPS-el ment, pedig a játékuk arról tanúskodott, hogy nagyon profik.
Szóval szerintem az emu sajnos ilyen lassú...
LugaidVandroiy - köszi a választ, megkeresem.
Amúgy mégegy dolog: Olyat meg lehet valahogy oldani, hogy nem használok különböző képeket, de mégis működik minden felbontáson (csak lowres lesz mondjuk nagyob kjelzőn)?



persze hogy lassú, de volt a google hírcsatornán egy hír miszerint hardvergyorsítást kapot megg rendesen tudja emulálni a 2.0-át, de még nem sikerölt kipróbálnom, de már le is tettem róla, bővítem a gépparkot inkább.
-----------------------------------------
Dont Listen to the Naysayers
   
LugaidVandroiy - Törzstag | 504 hsz       Online status #190770   2013.01.25 10:25 GMT+1 óra  
Ha egy méretű assetnél akarsz maradni, akkor csinálj egy drawable mappát (csak így simán) a többi mellé. Ez viszont azt jelenti, hogy neked kell trükköznöd a felbontásoknál (vagy betöltéskor, vagy futásidőben méretezed). Én a betöltést szoktam válaszani, aspect ratiot figyelembe véve.

   
Thrall - Törzstag | 609 hsz       Online status #190769   2013.01.25 09:28 GMT+1 óra  
Idézet
DMG :
Ha már így szóvakerült, elvileg teljes értékű már az emu androidra, valaki próbálta már? Mert én hiába indítok emut, ugyan úgy csak GL ES 1.x és lassú mint a teve.


Múltkor valami - szerintem nagyon komoly androidos 3d-s játék - készítője mondta, hogy emulátoron nekik is pár FPS-el ment, pedig a játékuk arról tanúskodott, hogy nagyon profik.
Szóval szerintem az emu sajnos ilyen lassú...
LugaidVandroiy - köszi a választ, megkeresem.
Amúgy mégegy dolog: Olyat meg lehet valahogy oldani, hogy nem használok különböző képeket, de mégis működik minden felbontáson (csak lowres lesz mondjuk nagyob kjelzőn)?
Jatekfejlesztes.hu közös projekt: próbálunk összerakni egy olyan csapatot, akik együtt el tudnak készíteni egy komolyabb játékot megfelelő minőségben. Érdekel?
Link:
JF.hu közös projekt
http://frogbonegame.uw.hu/
   
DMG - Szerkesztő | 3172 hsz       Online status #190712   2013.01.23 13:20 GMT+1 óra  
Köszi!

Sebaj, növelem a gépparkot.
-----------------------------------------
Dont Listen to the Naysayers
   
LugaidVandroiy - Törzstag | 504 hsz       Online status #190710   2013.01.23 12:32 GMT+1 óra  
Szerintem még mindig használhatatlan, ha pl bekapcsolom a hardveres gyorsítást, akkor vagy el sem indul az emu, vagy fekete képernyő lesz az appomból.

   
DMG - Szerkesztő | 3172 hsz       Online status #190708   2013.01.23 12:25 GMT+1 óra  
Ha már így szóvakerült, elvileg teljes értékű már az emu androidra, valaki próbálta már? Mert én hiába indítok emut, ugyan úgy csak GL ES 1.x és lassú mint a teve.
-----------------------------------------
Dont Listen to the Naysayers
   
LugaidVandroiy - Törzstag | 504 hsz       Online status #190704   2013.01.23 10:47 GMT+1 óra  
A beállítások között (mármint az emulátor managerben) kellene egy resolution résynek lennie. Ott predefiniált értékek vannak (qvga, stb), azzal játszhadozhatsz.

   
Thrall - Törzstag | 609 hsz       Online status #190699   2013.01.22 23:16 GMT+1 óra  
Sziasztok, egy olyan kérdésem lenne, hogy Eclipse-ben az android emulátort hogyan tudom átállítani úgy, hogy más legyen a méretezése?
Ugye vannak a mappák,drawable-mdpi, drawable-ldpi, ilyesmi.
Nálam a cuccok a drawable-mdpi - ben vannak, telón jó is, de emulátoron nem, mert a képeknek csak egy része látszik.
Jatekfejlesztes.hu közös projekt: próbálunk összerakni egy olyan csapatot, akik együtt el tudnak készíteni egy komolyabb játékot megfelelő minőségben. Érdekel?
Link:
JF.hu közös projekt
http://frogbonegame.uw.hu/
   
lezli01 - Tag | 190 hsz       Online status #189201   2012.12.01 18:37 GMT+1 óra  
Örülök, hogy sikerült megoldani.
Ezzel most én is sokat tanultam!
   
LugaidVandroiy - Törzstag | 504 hsz       Online status #188982   2012.11.22 10:53 GMT+1 óra  
Idézet
LugaidVandroiy :
De a probléma továbbra is fenáll: egy 48 megás heapbe szeretném ezt a közel harminc megát beletuszkolni, nem megy, OutOfMemory. A 24-es heappel rendelkezőn tökéletesen megy, ott nincs probléma. Ugyanazokkal a képadatokkal működne mindegyik eszközön.



1) Megvan a probléma oka. HoneyComb alatt a bitmapok pixeladatai a natív memóriába kerülnek. E felett viszont a VM Heapet gazdagítják. Ezt azért csinálták így, hogy gyorsabb legyen a garbage collector... Viszont 11-es api felett meg lehet neki határozni manifestben a következőt:
Kód:
android:largeHeap="true"
ami annyit tesz, hogy egy jóval nagyobb szeletet kapunk a memóriából a heap számára.

2) Ugyanakkor ha az ember a Bitmap.createScaledBitmap fgv-t használja, számítson memory leakre. Helyette a BitmapFactory.Options classal lehet hatékonyabban optimalizálni a betöltést.

3) Ha van felesleges Bitmap objektumunk, akkor ne legyünk restek megívni a recycle() fgvjét, mert a GC nem fogja magától megtenni (illetve eléggé későn)

   
kernel_panic - Tag | 117 hsz       Online status #188963   2012.11.21 15:33 GMT+1 óra  
Idézet
Parallax :
Igen, csak a Dead-nél 100 ezres nagyságrendről a másik ratyiság esetében pedig ezres nagyságrendről lehet beszélni. Már mobilon se a fingó app a menő, fejlődik a hardver, igényesebbek a felhasználók. Ezt nehéz elfogadni egy garázsfejlesztőnek, de ez van.


Akkor az eladások miért nem ezt támasztják alá?

   
Parallax - Tag | 574 hsz       Online status #188962   2012.11.21 07:19 GMT+1 óra  
Idézet
kernel_panic :
A linkelt cikkhez is hozzászólva: én eddig se értettem, hogy mobil eszközökre mi értelme van ilyen játékokat kiadni, mint ez a Dead Trigger? Szerintem az ehhez hasonlókkal inkább konzolon/pc-n játszanak az emberek (ahol ráadásul jobb nevek is vannak), mobilon meg inkább az egyszerű, könnyed és egyedi vizuális stílusú (vagy a bevalottan casual) játékok mennek, mint pl. ez...


Igen, csak a Dead-nél 100 ezres nagyságrendről a másik ratyiság esetében pedig ezres nagyságrendről lehet beszélni. Már mobilon se a fingó app a menő, fejlődik a hardver, igényesebbek a felhasználók. Ezt nehéz elfogadni egy garázsfejlesztőnek, de ez van.

Idézet
DMG :
Blabal...

Szoftverkalózok miatt szidják a Windows Phone 8-at


Azért van a store, meg azért wp8-on nem mindenki azt berhel szét, amit akar, ez nem linux.

   
LugaidVandroiy - Törzstag | 504 hsz       Online status #188960   2012.11.21 00:20 GMT+1 óra  
Hogy mire használnám, teljesen lényegtelen, mivel a 30 mega meg abszolút nem sok. Mivel nem tömörített formában tárolja a pixeladatokat a Bitmap, ezért w * h * 4 a kép mérete byteban (igen, kell az alfa csatorna is). Így jött ki a 30 mega.

De a probléma továbbra is fenáll: egy 48 megás heapbe szeretném ezt a közel harminc megát beletuszkolni, nem megy, OutOfMemory. A 24-es heappel rendelkezőn tökéletesen megy, ott nincs probléma. Ugyanazokkal a képadatokkal működne mindegyik eszközön.

Azt hiszem, hogy inkább megpróbálom betuszkolni a képadatokat egy spritesheetbe, mert lehetséges, hogy az sem tetszik neki, hogy van vagy 40 betöltendő fájl.

   
lezli01 - Tag | 190 hsz       Online status #188956   2012.11.20 21:07 GMT+1 óra  
This is wrong in so many ways...

Egyetlen megoldásként azt látom, hogy dinamikusan, az adott eszkösz heap méretének megfelelő képet tartasz bent és ezeket folyamatosan cseréled...

Understanding heap sizes
Detect heap size

Viszont nagyon kíváncsi lennék mit csinálsz amihez ennyi adat kell, valami infót szórj már hátha segít! :
   
Frissebbek | Korábbi postok
[1] [2] [3] [4] > 5 < [6] [7] [8] [9] [10] [15]