Bem-Vindo, Visitante
Username: Password: Lembrar-me

Pesquisa no Fórum

  • Página:
  • 1

TÓPICO: buildings.tex

buildings.tex 23 Ago 2013 02:19 #200689

Amigos,

Localizei dois arquivos buildings.tex, um na pasta gfx na raiz do Primo (2.4), outra dentro do data.zip (também em uma pasta chamada gfx). Os dois são bem diferentes, tanto em data como em tamanho.

Qual dos dois são utilizados pelo primo? o do data.zip ou da pasta gfx?

Alguém poderia upar este arquivo que dá uma melhor imagem?

[ ]s
  • Capitão Nemo
  • Iniciante
  • Capitão Nemo's Avatar
  • OFFLINE
  • Postagens: 13
  • Registro em: 23/08/2013
    Ult. Visita: 19/11/2013
Última Edição: 23 Ago 2013 02:20 por Capitão Nemo.
O administrador desabilitou o acesso público de escrita.

buildings.tex 23 Ago 2013 13:22 #200716

:id Ambos pois se tira o data .zip não funcionara seu navegador :oks.
Att.:
MC
  • machadocampista
  • Colaborador
  • Não hesite em repassar conhecimento.
  • machadocampista's Avatar
  • OFFLINE
  • Postagens: 1251
  • Agradecimentos: 554
  • Registro em: 31/10/2012
    Ult. Visita: 06/11/2016
Os ignorantes que acham que sabem tudo privam-se de um dos melhores prazeres da VIDA, que é APRENDER.
Se minha resposta foi útil a você, clique no botão 'agradecer'.
GPS FOSTON FS707DC:
Download: Menu 320x240 (3.5") 3 Navegadores
Download: Menu 480x272 (4.3" e 5.0") 3 Navegadores
Download: Menu 800x480 (7") 3 Navegadores
Clique Aqui ajudando a manter o GPSPoint no ar
O administrador desabilitou o acesso público de escrita.
Os seguintes usuários disseram Obrigado: Thoth

buildings.tex 23 Ago 2013 17:00 #200741

Machadocampista,

Tenho interesse nessa resposta.

Sei que o navegador não funciona sem o arquivo data.zip, isso é óbvio até. hehehe

Minha pergunta é quanto às pastas gfx, já que tenho duas. Uma na raiz do Primo, outra no interior do data.zip.

Não se poderia, por exemplo, excluir a pasta gfx que há no interior do arquivo data.zip e se manter apenas a que está na raiz, já descompactada? ou mesmo o contrário?

Mantendo duas pastas iguais, acredito que o navegador utilize apenas uma delas, no caso ignorando a que está no interior do data.zip, ou não?
  • Thoth
  • Usuário Platinum
  • Thoth's Avatar
  • OFFLINE
  • Postagens: 316
  • Agradecimentos: 280
  • Registro em: 26/09/2012
    Ult. Visita: 09/12/2016
Última Edição: 23 Ago 2013 17:02 por Thoth.
O administrador desabilitou o acesso público de escrita.

buildings.tex 23 Ago 2013 18:50 #200751

Peeoal

Por gentileza, leiam estes posts:
www.gpspoint.com.br/...013?start=200#200250
e
www.gpspoint.com.br/...it=30&start=30#87207

Sobre as pastas duplicadas, pode deixar somente a do DATA, lembrando que algumas schemes usam alguns arquivos adicionais na pasta gfx "solta" no pacote, ou seja, para evitar incompatibilidade, copie todos para a mesma pasta ao invés de simplesmente deletar uma delas (a prioridade tem que ser o do DATA), segundo os meus testes o buildings.tex de tamanho 156 KB tem mais dados e mais textura.

Abraços.
  • d780
  • Colaborador
  • d780's Avatar
  • OFFLINE
  • Postagens: 542
  • Agradecimentos: 558
  • Registro em: 15/01/2011
    Ult. Visita: 02/12/2016
O administrador desabilitou o acesso público de escrita.
Os seguintes usuários disseram Obrigado: BOCANNERA, Thoth

buildings.tex 23 Ago 2013 18:52 #200752

Só uma curiosidade:

Como um tópico criado hoje tem, mais de 26800 visualizações?

Mistério, rsrsrsrs
  • d780
  • Colaborador
  • d780's Avatar
  • OFFLINE
  • Postagens: 542
  • Agradecimentos: 558
  • Registro em: 15/01/2011
    Ult. Visita: 02/12/2016
O administrador desabilitou o acesso público de escrita.

buildings.tex 23 Ago 2013 18:57 #200753

d780

A mensagem estava no tópico de download do Primo 2.4 e foi movida para fora, criando um novo tópico que "herdou" as características do tópico original: 26.800 visualizações ...
É mole ? rs

Sk
  • Sherlock
  • Gerente
  • Sherlock's Avatar
  • OFFLINE
  • Postagens: 5958
  • Agradecimentos: 8101
  • Registro em: 04/09/2010
    Ult. Visita: 28/11/2016
Faça uma doação de qualquer valor e ajude a manter o GPSPoint no ar!
O administrador desabilitou o acesso público de escrita.

buildings.tex 23 Ago 2013 19:31 #200754

Tentando ajudar sobre a questão inicial do tópico...

O conceito básico da NQ é manter tudo dentro do data.zip, um arquivo que tem que existir em qualquer pacote baseado em Primo (por exemplo). Parece óbvio, mas não é. Aos corajosos, que se tente extrair todo o conteúdo do data.zip para a pasta raiz do pacote e que se tente executar o navegador: não funcionará.

Por outro lado, todas as pastas que estão no interior do data.zip são descompactada ao iniciar o navegador, onde as mesmas são colocadas temporariamente na raiz do pacote. Só que existe um comando/rotina interna no executável que impede que os arquivos preexistentes sejam sobrescritos na descompactação. Exemplo: suponha que exista uma pasta GFX na raiz do pacote e suponha que uma pasta com o mesmo nome esteja também no data.zip. Os arquivos que já estiverem na gfx na raiz do pacote não serão sobrescritos, mas aqueles que existirem na gfx do data.zip e que não estiverem na gfx/raiz serão adicionados, como se lá estivessem desde o início.

Resumindo. os arquivos das pastas externas ao data.zip (que são colocadas por alguns na raiz do pacote) tem preferências em seus arquivos, não importando o tamanho e nem a data do mesmo, se mais ou menos antigo.

Quando se trata de arquivos de texturas (.tex), então o tamanho passa a ser mais importante, ou seja, deve-se dar prioridade pelo maior, mesmo que apresente uma data anterior. Um exemplo clássico é aquele dado pelo d780 em post mais acima: o building.tex. Este arquivo é o responsável pelas texturas das construções (leia-se prédios). Existem pacotes da NQ que atualizam este arquivo no data.zip, com datas mais recentes, mas não passando de 2 KB em tamanho. Porém existe um arquivo de mesmo nome com tamanho de 156 KB. Que se dê preferência a este arquivo; o mesmo procedimento para os demais arquivos tex.

No que tange às schemes, algo mais importante deve ser levado em conta: os arquivos .bmp e .spr. As schemes, em seus arquivos color.ini, indicam qual ou quais arquivo(s) devem ser buscados na pasta gfx (não importa se na raiz do pacote ou no data.zip), a ausência de um ou mais destes arquivos impede o correto funcionamento da scheme. Os problemas apresentados podem ser de várias ordens, desde um erro por falta de arquivo até mesmo um reboot, passando por algo que considero o pior: você escolher uma scheme e achar que ela está exibindo tudo corretamente, pois nenhum erro foi apresentado (e nem sempre isso ocorre).

No momento estou trabalhando em uma pasta gfx que tenha condições mínimas para exibir, pelo menos, os arquivos "solicitados" pelas schemes mais comuns e conhecidas, até mesmo algumas mais "exóticas", como as realistics e Capulleto. O que tem de pasta gfx "errada" rodando por aí, não está no gibi! Arquivos inexistentes, .spr mal configurados, "sol" sem transparência (sim, o sol nunca aparecerá no céu, como a lua, ele apenas é usado para mudar a iluminação na tela de mapa, simulando os raios de sol, de acordo com o horário, sobre as ruas e morros/montanhas), entre outras coisas.

Não prometo A solução, mas uma solução; que outros tentem aperfeiçoá-la a partir de um ponto diferente de zero. Em breve, aqui neste fórum. ;)


[]'s

Xamanian
  • Xamanian
  • Usuário Platinum
  • Xamanian's Avatar
  • OFFLINE
  • Postagens: 1159
  • Agradecimentos: 1872
  • Registro em: 05/02/2013
    Ult. Visita: 08/12/2016
O administrador desabilitou o acesso público de escrita.
Os seguintes usuários disseram Obrigado: Capitão Nemo

buildings.tex 23 Ago 2013 20:36 #200764

Xamanian,

Considerando que o primo descompacta temporariamente os arquivos internos do data.zip para a raiz do cartão, não seria interessante deixar algumas pastas já na raiz e retirá-las do data.zip? Isso não implicaria em ganho de performance?

[ ]s
  • Capitão Nemo
  • Iniciante
  • Capitão Nemo's Avatar
  • OFFLINE
  • Postagens: 13
  • Registro em: 23/08/2013
    Ult. Visita: 19/11/2013
O administrador desabilitou o acesso público de escrita.

buildings.tex 23 Ago 2013 20:59 #200770

Nemo, já fiz este tipo de teste, confesso que não percebi diferença de performance que pudesse ser classificada como vantajosa. O maior ganho em desempenho ocorre quando o data.zip contém apenas as pastas referentes à resolução usada pelo aparelho. Exemplo: dar suporte para as resoluções 320x240, 480x234, 480x272 e 800x480 em um único pacote, sabendo-se que apenas uma única resolução será usada em cada tipo de aparelho, é comprometer enormemente o desempenho geral. Isto deveria ser evitado a todo custo pelos "pacoteiros", sendo mais viável disponibilizar vários pacotes específicos para cada resolução (tá, sei, dá muito mais trabalho, mas os ganhos são muito expressivos e deveriam ser considerados).

No caso específico da pasta gfx, opto por ter toda ela externa ao data.zip, não há ganho em mantê-la no data.zip, seja no que diz respeito à performance, seja no que diz respeito às possibilidades de personalizações de arquivos (em particular, dos bmp's para céu, sol, lua, etc.).

Já a pasta ui_igo9 deveria ser mantida no data.zip, pois ela é vital e não pode estar totalmente fora deste arquivo (data). Porém é interessante ter esta pasta colocada na raiz do pacote para personalização de alguns arquivos, como aqueles de abertura e encerramento do navegador, bem como alguns arquivos de áudio (e pouca coisa a mais). Veja, não é necessário ter a pasta ui_igo9 externamente, é só interessante mesmo (para não ter que ficar recompactando as telas de abertura/encerramento a cada mudança).

Outra pasta que não pode deixar de existir no data.zip é a scheme, a pasta que contém a scheme padrão dia e noite. Além do mais, se não for algo que nasce para ser diferente, deve-se usar, a todo custo, as schemes padrão originais no data.zip, para evitar-se erros expressivos, colocando-se novas schemes na pasta content\schemes (da mesma forma que faz a própria NQ).

Nemo, pode parecer estranho ou até mesmo inconsistente, mas o certo é que o navegador Primo "precisa" de alguns arquivos do data.zip compactados mesmo; se ele não encontrar este arquivo, mesmo que de tamanho mínimo, nada dá certo. Motivo: o executável tem uma ordem de busca e de prioridades, se não houver algo para ser trabalhado, tudo dá errado. Um exemplo singelo para não ir longe: não adianta colocar o arquivo igo9.ini na pasta raiz ao lado do sys.txt, o igo9.ini tem que estar na pasta correta, e compactada, no data.zip. Vai entender, mas...


[]'s

Xamanian
  • Xamanian
  • Usuário Platinum
  • Xamanian's Avatar
  • OFFLINE
  • Postagens: 1159
  • Agradecimentos: 1872
  • Registro em: 05/02/2013
    Ult. Visita: 08/12/2016
O administrador desabilitou o acesso público de escrita.
Os seguintes usuários disseram Obrigado: Capitão Nemo

buildings.tex 23 Ago 2013 21:07 #200773

obrigado por esta verdadeira aula, Xamanian!

[ ]s
  • Capitão Nemo
  • Iniciante
  • Capitão Nemo's Avatar
  • OFFLINE
  • Postagens: 13
  • Registro em: 23/08/2013
    Ult. Visita: 19/11/2013
Última Edição: 24 Ago 2013 00:07 por Fábio M..
O administrador desabilitou o acesso público de escrita.

buildings.tex 24 Ago 2013 00:20 #200788

Capitão Nemo escreveu:
Considerando que o primo descompacta temporariamente os arquivos internos do data.zip para a raiz do cartão, não seria interessante deixar algumas pastas já na raiz e retirá-las do data.zip? Isso não implicaria em ganho de performance?

Sempre me questionei sobre essa questão até que achei a resposta. O hardware do GPS é um equipamento relativamente limitado se comparado a outros equipamentos disponíveis hoje em dia. Então como tirar mais do menos? O tempo de leitura do cartão microSD é lento, então é mais vantajoso um tempo menor de leitura do cartão e descompactar na memória RAM* que é extremamente veloz do que ler um arquivo maior já descompactado no cartão.



* Agradecimento ao Thoth.
  • Fábio M.
  • Moderador
  • Fábio M.'s Avatar
  • OFFLINE
  • Postagens: 3372
  • Agradecimentos: 1247
  • Registro em: 20/10/2011
    Ult. Visita: 10/12/2016
Pesquise sempre! O fórum tem um acervo enorme com dúvidas respondidas. Evite abrir novos tópicos, utilize os tópicos já existentes.
Não crie uma nova mensagem para agradecer, clique apenas em 'Agradecimento' se a resposta lhe foi útil.
Última Edição: 24 Ago 2013 01:15 por Fábio M..
O administrador desabilitou o acesso público de escrita.

buildings.tex 24 Ago 2013 00:53 #200792

Fábio,

Quando você diz que os arquivos descompactados durante a abertura do navegador vão para a memória, você quer dizer memória RAM? Porque se for memória RAM, até entendo que haveria um ganho em velocidade, mas sobraria menos memória para o funcionamento do navegador, o que resultaria em lentidão.

Seguindo as dicas do Xamanian excluí do arquivo data.zip a pasta gfx, deixando apenas a que estava na raiz do Primo. Excluí também o arquivos referentes à resolução que não são utilizadas pelo aparelho.... Estou testando, fiz uma viagem curta (30km)... até o momento não percebi muita diferença, mas ainda é cedo.

Muito interessante a discussão tratada neste tópico.

Abs
  • Thoth
  • Usuário Platinum
  • Thoth's Avatar
  • OFFLINE
  • Postagens: 316
  • Agradecimentos: 280
  • Registro em: 26/09/2012
    Ult. Visita: 09/12/2016
O administrador desabilitou o acesso público de escrita.

buildings.tex 24 Ago 2013 01:25 #200795

Thoth

Agradeço o questionamento e a possível melhora do texto.

A memória seria ocupada de qualquer maneira porque você pode eliminar o processo da descompactação da memória e aí não teria diferença em termos de ocupação de memória de como o arquivo foi parar lá. Mas no sentido que você citou, exatamente por isso os equipamentos com mais memória - não só GPS's - trabalham com mais folga, pois conseguem armazenar mais processos sem recorrer a uma memória virtual física (disco rígido, cartão etc).
  • Fábio M.
  • Moderador
  • Fábio M.'s Avatar
  • OFFLINE
  • Postagens: 3372
  • Agradecimentos: 1247
  • Registro em: 20/10/2011
    Ult. Visita: 10/12/2016
Pesquise sempre! O fórum tem um acervo enorme com dúvidas respondidas. Evite abrir novos tópicos, utilize os tópicos já existentes.
Não crie uma nova mensagem para agradecer, clique apenas em 'Agradecimento' se a resposta lhe foi útil.
O administrador desabilitou o acesso público de escrita.

buildings.tex 24 Ago 2013 09:39 #200801

Fábio,

compreendo o que você disse sobre as velocidades do cartão de memória e da memória RAM; você está correto quanto a isto, realmente a velocidade da RAM é muito superior a de um cartão SD, de um HD, etc. Porém não procede a sua ideia de que os arquivos descompactados (sejam do data.zip, scheme, skin, branding, etc.) ficam, após o processo, na memória RAM.

Vou justificar a minha afirmação através de um exemplo: coloque um arquivo bmp no data.zip e outro fora, mais especificamente o loading.bmp, um em uma pasta na raiz do pacote (ui_igo9\xxx_yyy, onde xxx_yyy é a resolução) e outro no data.zip\ui_igo9\xxx_yyy. É fácil notar que o arquivo escolhido durante o carregamento do navegador é aquele que se encontra na pasta raiz, fora do data.zip.

Existe uma ordem de busca, praticamente universal, feita pelos processadores, que é: memória cache, memória ram, memória virtual, "disco rígido"/cartão SD. Se os arquivos descompactados, presentes no data.zip, fossem para a memória ram, então eles teriam prioridades de leitura em relação a quaisquer outros; e isto não acontece na prática. De outra maneira: o que você disse não ocorre.

Além do mais, como bem lembrado por você mesmo, o hardware dos dispositivos de gps são extremamente limitados. Tipicamente a quantidade de memória ram fica limitada a 128 MB, muito pouco para os dias atuais. Um aparelho com resolução de 800x480 precisa renderizar todo o mapa em 3D ("aramado"), precisa alocar as texturas nestas telas renderizadas, precisa iluminar os objetos 3D, precisa fazer transformações nos objetos (rotação, translação, etc.), precisa gerenciar os demais mecanismos do próprio navegador (vozes, comandos, posições, etc.). Como, em geral, os dispositivos de gps não possuem uma aceleradora gráfica 3D dedicada (GPU), acaba sobrando para a CPU.

Porém todo cálculo realizado pela CPU precisa ser guardado temporariamente na memória ram para que possa ser lida em qualquer instante. Então na memória ram guarda-se os cálculos realizados pela CPU (renderização, iluminação, transformação, etc.) e o mais pesados (tamanho) dos arquivos, as texturas que serão "coladas" em cada posição. Como a tela do mapa é apresentada em 3D (mesmo sendo possível o 2D) e envolve movimento constante da tela (mudança de frame, o "quadro a quadro"), então é preciso processar e alocar as telas futuras. Sim, este procedimento de preparo e alocação de telas futuras é necessário para que o movimento contínuo seja o mais natural possível.

Um fato "curioso" ocorre quando o sinal do gps é perdido e/ou quando o condutor resolve seguir outro trajeto que seja diferente daquele previsto na rota calculada: a tela de mapa perde toda a qualidade gráfica, podendo girar para um lado ou outro (ou para cima ou para baixo), as texturas de preenchimentos ficam "feias", etc. Isto dura poucos segundos, em geral. Por que isso ocorre? Simples, as telas futuras previamente calculadas não correspondem àquilo que se esperava e as mesmas são imediatamente descartadas da memória ram, mas exigindo um novo cálculo pela CPU, e nova realocação na ram, na renderização, texturização, iluminação, transformação, etc.. Como a CPU tem baixo clock, a quantidade de ram é baixa, não há GPU, etc., então um delay (atraso) ocorre neste momento e é visível a olhos nus.

Uma resolução de 800x480 gera uma imagem de aproximadamente 6,7 x 4 cm2; para que um movimento seja considerado natural é preciso que o número de quadros por segundos (fps, frames por segundos) varie entre 24 (fps padrão cinema) a 30 (padrão TV se não entrelaçado, que exigiria, neste caso, 60). Mas além destas 24-30 figuras por segundo, é preciso ter aquelas "telas futuras", os cálculos prévios para "as próximas exibições". Quantas figuras precisam ser alocadas na memória ram? Uma quantidade enorme e que consomem muito espaço (na ram). Sem falar da necessidade de alocação dos cálculos na própria ram, pois a CPU lê e escreve na ram o tempo todo.

Resumindo: a quantidade de memória ram em dispositivos de gps é tão diminuta que se torna impossível alocar na mesma outras coisas que não sejam os cálculos realizados pela CPU, além de texturas, figuras renderizadas, etc. Todo o resto é lido diretamente do cartão SD (interno ou externo), prejudicando ainda mais o desempenho do sistema. Assim sendo, os arquivos após descompactação não ficam temporariamente na memória ram, ficam temporariamente no cartão SD, onde os mesmos são lidos diretamente ou alocados temporariamente na memória ram e descartado imediatamente após o seu uso. O exemplo clássico é o arquivo loading.bmp, ele é alocado na ram logo no início, é exibido na tela e após isso o mesmo é retirado da mesma.

E só falei da parte gráfica, mas poderia ir bem além, pois tudo que está no igo9.ini e no sys.txt é lido pelo processador, guardado na memória ram, ficando lá até o encerramento da navegação. Este tipo de coisa ocorre com vários arquivos internos, sem falar do próprio executável principal, que fica o tempo todo guardado na própria ram (não o arquivo em si, mas as suas instruções). Assim sendo, não há "folga" na memória ram para "se dar ao luxo" de guardar arquivos descompactados, ainda mais se não usados. Exemplo: imagine um data.zip com várias resoluções (e com grande quantidade de arquivos) descompactando tudo e deixando na memória ram, onde apenas uma delas seria utilizada, seria uma loucura sem igual!


Grande abraço,

Xamanian
  • Xamanian
  • Usuário Platinum
  • Xamanian's Avatar
  • OFFLINE
  • Postagens: 1159
  • Agradecimentos: 1872
  • Registro em: 05/02/2013
    Ult. Visita: 08/12/2016
O administrador desabilitou o acesso público de escrita.
Os seguintes usuários disseram Obrigado: BOCANNERA, Thoth
  • Página:
  • 1
Time to create page: 0.285 seconds