Autor Wątek: Ładowanie assetów z ekranem loading na platformie która eventuje onDraw (C++)  (Przeczytany 3865 razy)

Offline skoti

  • Użytkownik

  • +1
# Lipiec 26, 2012, 18:48:54
Nie możesz, bo w Androidzie nie masz swap buffers. Robi to za Ciebie system a Ty musisz tylko narysować ramkę na żądanie.
Nie system, a implementacja GLSurfaceView w SDK - jeśli robisz kontekst w NDK to musisz użyć eglSwapBuffers.

Pod Androidem i tak masz wszystkie assety w zipie, więc siłą rzeczy masz VFS. ;)
Niekoniecznie wszystko masz w zipie - możesz również czytać z karty pamięci w postaci plików z OBB (Opaque Binary Blob) rozszerzających 50MB na aplikacje (w zipie) do 4GB na aplikacje http://android-developers.blogspot.com/2012/03/android-apps-break-50mb-barrier.html ale to też jest VFS

PS. Tak, tak nie wspominasz o tym, bo siedzisz dalej na  API Level: 8, a ani OBB, ani natywne aplikacje nie są dla Ciebie dostępne (obie rzeczy weszły z Androidem 2.3 i API lvl 9)
« Ostatnia zmiana: Lipiec 26, 2012, 18:50:29 wysłana przez skoti »

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Lipiec 26, 2012, 18:53:54
Cytuj
PS. Tak, tak nie wspominasz o tym, bo siedzisz dalej na  API Level: 8, a ani OBB, ani natywne aplikacje nie są dla Ciebie dostępne (obie rzeczy weszły z Androidem 2.3 i API lvl 9)
Natywne aplikacje są dla mnie jak najbardziej dostępne, tylko musiałem zadbać o to sam ("natywne" aplikacje i tak są odpalane z kodu java, tyle że ten kod jest w SDK). Poza tym póki co powyżej API Level 8 featurów żadnych nie potrzebowałem, tak więc moje aplikacje będą mogły działać nawet na tabletach z Carrefoura. ;)

Offline skoti

  • Użytkownik

# Lipiec 26, 2012, 19:29:50
Natywne aplikacje są dla mnie jak najbardziej dostępne, tylko musiałem zadbać o to sam ("natywne" aplikacje i tak są odpalane z kodu java, tyle że ten kod jest w SDK).
Jasne - pisałem o całkowicie pozbawionych kodu Javy i wykorzystujących native-activity.

Poza tym póki co powyżej API Level 8 featurów żadnych nie potrzebowałem, tak więc moje aplikacje będą mogły działać nawet na tabletach z Carrefoura. ;)
Tanie tablety z Carrefoura czy Biedronki mają wersje 2.3 z możliwością aktualizacji do 4.x (przykładowo Tracer Ovo czy Goclever Tab A73), ale też tańsze poniżej 200zł jak Apollo Quicki 701 (arch ARMv6) mają 2.3 (jedyne tablety z 2.2 jakie udało mi się wyszukać mają procki ARM11 600MHz - na takich prockach to nawet Angry Birds nie chce działać).
« Ostatnia zmiana: Lipiec 26, 2012, 19:34:25 wysłana przez skoti »

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Lipiec 26, 2012, 19:42:54
Cytuj
Jasne - pisałem o całkowicie pozbawionych kodu Javy i wykorzystujących native-activity.
Też o tym pisałem. To, że cały kod Javy jest przerzucony i ukryty w runtime w SDK nie zmienia faktu, że nadal jest w aplikacji. ;)

Cytuj
(jedyne tablety z 2.2 jakie udało mi się wyszukać mają procki ARM11 600MHz - na takich prockach to nawet Angry Birds nie chce działać)
No bez jaj. Do Wolfensteina 3D wystarczyło 30MHz i antyczna architektura, a Ty chcesz mulić przy 600MHz? ;)

Offline Dab

  • Redaktor
    • blog

  • +2
# Lipiec 26, 2012, 20:24:25
Olej pasek postępu (trudno jest zrobić go dobrze, tzn. żeby dostarczał sensowną informację). Jeżeli wczytywanie trwa długo to je skróć* i nie chcesz żeby user myślał, że aplikacja się zawiesiła to dorzuć na czas wczytywania jakąś natywną kontrolkę typu Activity Indicator. UI ma własny wątek więc masz jeden problem na głowie mniej.

* ale i tak skróć :)

Offline Shelim

  • Użytkownik
    • Homepage

# Lipiec 26, 2012, 23:25:57
Na trzeźwo (czyt. na wyspanie się) doszedłem do podobnego wniosku :D

Offline Kos

  • Użytkownik
    • kos.gd

  • +3
# Lipiec 28, 2012, 20:15:25
No bez jaj. Do Wolfensteina 3D wystarczyło 30MHz i antyczna architektura, a Ty chcesz mulić przy 600MHz? ;)
Mi na 600MHz mulą nawet SMS-y. :-)