Configurando bounding box por código - BUG do GM8?

Olá!

Estou carregando imagens por fora do jogo (sprites) para ficar com loading rápido. Então preciso configurar por código o bounding box (caixa de colisão) que quero para cada sprite.

Eu quero um bb simples (sem precise collision), quadrado, em um área pequena na imagem definida por mim.

O comando que achei que faz isso é o

Código:

sprite_collision_mask(ind,sepmasks,bboxmode,bbleft,bbright,bbtop,bbbottom,kind,tolerance)

Estes parâmetros significam o sprite que quer, se usará bb diferentes para cada quadro da animação, o tipo (precise ou não), valores do bb left, right, top, bottom, tipo (quadrado, circulo, etc), tolerância (um tipo de transparência, esquisito mas se colocar 0 funciona).

Então por exemplo, com isto aqui no create do objeto

Código:

sprite_collision_mask(sprite_index,0,2,5,285,15,295,1,0)

diz que quero que o próprio sprite seja afetado, que use o mesmo bb para todos os quadros(se tiver anim), use bb do tipo definido por mim (sem precise), com as coordenadas left=5, right=285, top = 15, bottom=295, tipo quadrado, tolerância normal (encostou=acionou)

Bem, tudo ok, funciona beleza.... porém tem um BUG terrível que está tirando meu sono...

Veja essa imagem de teste:


Se eu coloco o código para o bb deste sprite ficar sobre a bolinha pequena do canto superior esquerdo, funciona. Seria este código:

Código:

sprite_collision_mask(sprite_index,0,2,5,15,5,15,1,0)

Se eu coloco o código para o bb ficar sobre a bolinha pequena do canto inferior direito, funciona. Seria este código:

Código:

sprite_collision_mask(sprite_index,0,2,285,295,285,295,1,0)

Porém se coloco o código para o bb ficar sobre a bolinha pequena do canto inferior esquerdo, não dá certo!!. Seria este código:

Código:

sprite_collision_mask(sprite_index,0,2,5,285,15,295,1,0)

Na realidade quase toda imagem fica com bb, ele fica gigante! Descobri que o que acontece é que o GM troca o valor da coordenada right com a top.... Se eu inverter isso de propósito funciona... Mas não entendo por que só dá bug se eu definir um bb na extremidade inferior esquerda do centro da imagem? Qualquer bb que coloque mais para esquerda e abaixo do centro (não precisa ser tão na extremidade) dá este bug...


E por fim se colocar o bb na bola do canto superior direito, tb dá problema! Seria este código:

Código:

sprite_collision_mask(sprite_index,0,2,285,295,5,15,1,0)

Mas não conseguir entender que bug acontece neste caso pois passo por cima de toda imagem e não colide nunca... não sei onde foi parar o bb........

Para testar isso é só importar esta imagem, criar um objeto para ela, e no create colocar algum código desses para definir o bb a alguma extremidade. Então crie qualquer outro objeto com alguma imagem menor (que possa se locomover) que fará alguma coisa quando colidir com o primeiro objeto (pode ser matar ele). Assim dá para testar se o bb está no lugar que deveria.

Então resumindo, se o bb estiver na extremidade superior esquerda ou inferior direita, funciona tudo blz!
Porém se estiver na extremidade inferior esquerda acontece o bug das coordenadas right e top ficarem invertidas...
Se o bb estivar na extremidade superior direita, tb dá bug, pois não consigo mais colidir com a imagem, não faço idéia onde o bb foi parar.....

Enfim isso não faz sentido, mas já testei milhões de vezes e não chego em alguma conclusão lógica do que está ocorrendo. Preciso de ajuda....

Claro que se definir o bb no editor do sprite do GM tudo funciona, o problema é fazer isso por código.

Valeu gente, só vocês podem me ajudar a sair deste buraco.
Bom ano novo!

tipo, eu acho que é bug na transparencia...
porque o GM, quando voce poe o sprite transparente, ele apaga a cor que esta no canto esquerdo inferior, o que esta dando bug no seu...
altera esse valor e nao inverta right com top e fale o resultado para mim...

FLW

Você esta confundindo as coisas. A BBox não deve ser atribuida dependendo da posição do objeto na room, você deve especificar apenas pelo tamanho da bolinha/sprite.

Pelos dados que você postou ai, as bolinhas devem ser 10x10, certo?
Então nas bounding box você deve deixar:
left: 0
right: 10
top: 0
bottom: 10

Criando um quadrado do mesmo tamanho da bolinha. A posição do BBox é atualizado pelo GM automaticamente na posição da sprite (Acho que o ponto de apoio não vai influenciar, o BBox vai continuar na sprite).

O que você está fazendo é criar um BBox gigante! No 3º exemplo:
5,285,15,295
Essas são as cordenadas usadas, tente fazer um draw_rectangle para você ver como ele fica na room!
Vai ser um retângulo muito maior do que a bolinha! (Ou a sua intenção era cobrir parte da tela assim? O_o)

Quanto a transparência não faz diferença a princípio, pois estou usando png com alpha... será que muda algo? Não deveria...

Quanto as coordenadas, tem que contar a partir do lado esquerdo superior do sprite, não é? Se eu fizer um draw_rectangle com as coord que tinha dito fica certo, um quadrado pequeno... Se fosse só 0,10,0,10 deveria haver outro valor para posicionar isso em algum lugar... senão como diria onde quero que fique o quadrado?

Pelo que sei é isso. Ex:


Não está certo?

Se entrar com estes valores no editor de sprite do GM para setar a bb, funciona...
(na figura exagerei o desenho do quadrado, pois fiz na mão como exemplo, seria mais perto da bola pequena)

Calma, isso é uma sprite só? Ou cada bolinha é um sprite/objeto separado?
Qual o tamanho do sprite da bolinha (caso ela seja separada do resto)?

O BBox é para decidir o tamanho da caixa e a posição RELATIVA a posição atual da sprite. Da forma que você está fazendo está correta CASO isso seja um sprite só, ou seja, a sua sprite é um quadrado de 300,300 (ou o tamanho que você usou..) e a bolinha está no canto e você quer que apenas ela tenha a BBox.

Se fosse só 0,10,0,10 deveria haver outro valor para posicionar isso em algum lugar...

A BBox é posicionada em "Relative" a sprite, então seria:
x1 = 0+x;
x2 = 10+x;
y1 = 0+y;
y2 = 10+y;

A BBox é fixa em relação a sprite, mas não em relação a TELA.

Sim exatamente. Isso é uma sprite só...

Veja, fiz um teste, criei um "jogo" com este sprite (png com alpha) e outro objeto que segue o cursor. Quando ele colide com o primeiro sprite, destroi ele.

Setei o bb direto pelo GM, no meio do sprite. Passando o cursor lá mata ele, Ok.
Se apertar barra espaço reinicia tudo.

Se apertar Q, coloquei o código que falei para bb ficar sobre a bolinha sup esq.
Se apertar W, vai para sup dir.
Se apertar A, vai para inf esq
Se apertar S, vai para inf dir

Ou seja, para definir um canto basta acionar um destes:

QW
AS

Estranho que agora testei e não colide mais quando aciono as teclas... cadê o bb????

Bizarro não func mais nada... o que será?
Pode baixar o "jogo" aqui:
http://dl.dropbox.com/u/15200241/teste.gmk

Realmente, testei aqui e o GM está com problema. Mas é apenas na descrição da função.
Ela diz para você usar:
bbox left, bbox right, bbox top, bbox bottom

Use nessa ordem:
bbox left, bbox top, bbox right, bbox bottom

Testei aqui e funcionou!

Então a função funciona, e é só um erro de texto do GM?

Estranho... troquei aqui e ainda não funcionou....

Por exemplo troquei da tecla Q (canto de cima esq) e não ficou o bb lá. E agora mesmo reiniciando a sala o bb original que era no meio não está mais lá...

Tá muito estranho isso... Te importa em pegar o projeto que funcionou p/ ti e mandar p/ mim ? Se não funcionar aqui é macumba braba...

Eu mexi agora no editor de sprite, liguei e desliguei o precise e tal... e então funcionou trocando o código.

MAS na bola da baixo a esq tem que deixar as coord como no original !!!! Para as outras precisa inverter.......?!??!??! Não entendo mais nada....

Essa função tá toda bugada?? Não coloca os atributos certos, as vezes func às vezes não...... estou perdido.... Preciso arrumar isso em dezenas de sprites e sem entender 100% do que está ocorrendo, como irei fazer??

Calma! você fez 3 posts em menos de 10 minutos! USE o botão EDITAR!
Você deveria receber um alerta por isso!
Leia as regras!

Esqueci de falar uma coisa, depois que você troca os BBox, você precisa redefinir a sprite. Achei muito estranho, mas funciona.
Em baixo de cada codigo que muda a BBox, adicione:
sprite_index = sprite_index;

Eu sei, parece um código sem sentido, mas teste você mesmo. Funciona. Não intendi porque, mas aposto que muita gente vai ficar ainda mais confusa sobre o funcionamento do GM! haha
É como se fosse criada outra sprite com as novas BBox, e o ID é guardado no valor ind, ou seja, no sprite_index que nós passamos para a função. Então é criada outra sprite com o mesmo valor só que "atualizada", setando novamente você muda para a nova sprite! O_o

Não sei, o código não faz sentido quando você lê. Mas para o GM é assim! ._.

[Aqui funcionou]

Ups, sorry pelo post rápido, não sabia do botão editar...

Testei tanto o sprite_index = sprite_index;

quanto o screen_redraw()
screen_refresh()

E ficou na mesma aqui...
Só funciona do jeito que já estava antes, virando as coord menos no canto inf esq.
O estranho que às vezes funciona, então dou um restart na sala e não funciona mais, nem na colisão default não pega mais, ai faço mais um restart e então funciona... não tem lógica, o negócio está instável.

O que me parece é que este comando deveria fazer parte de um conjunto de coisas que modifica a estrutura interna do sprite. Talvez falte mesmo algum outro comendo "irmão" que arrume tudo... mas qual seria?

O comando não pode simplesmente estar "quebrado" deve haver uma forma de validar o sprite... existe alguma biblia GM que fale sobre estas operações internas, como é feito o tratamento dos elementos etc? Enfim, como debugar isso?

Ok, mas no canto inf esquerdo continua tendo que usar a coordenada normal, em todos outros tem que inverter right por top, né?

Qual seria a moral disso?

Se o problema do comando fosse estar virado, era sempre inverter e deu. Mas um canto só não aceitar isso... não consigo entender a lógica do problema...

Não, está tudo igual.
na ordem:
bbox esquerdo, bbox de cima, bbox da direita, bbox de baixo.

Todos estão funcionando normalmente (seguindo essa ordem).
Verifique se você usou as coordenadas corretas.

Desculpe minha intromissão. Mas o q é essa bounding box? Por favor peço q me expliquem.

Ah sim, conferi, todos estão com as coordenadas invertidas pelo right = top. Sem exceções ....
Então realmente havia um bug na descrição da função... alguém avise a YoYoGames

Resumindo: para funcionar além de cuidar a ordem das coord, precisa remarcar o index...
O melhor caminho é usar o sprite_collision_mask(nome_sprite, ...
Depois remarcar o index com

sprite_index = nome_sprite

É como se uma função ajustasse o bb mas não aplica ao objeto atual, fica só marcado no sprite...
Ai por fim com o sprite_index recebendo o "novo" sprite, o bb fica atualizado. Seria isso?

Quanta bizarrice hein? Valeu a ajuda, jamais iria progredir nisso sozinho.

Respondendo: o bounding box é a caixa de colisão usada no sprite. Se ele tiver o precise collision checking ligado, irá usar todos os pixels visíveis do sprite, se não usa o bb. Mas no GM8 isso pode ser ajustado para ser não só box, pode ser também círculo ou losango.
Outra forma de substituir o bb por um desenho mais complexo e que não tenha ligação com o sprite atual é usando uma mascara (outro sprite que define a colisão pela sua forma, tom escuro = não colide, tom claro = colide).
Se não me engano é isso.

Por fim pergunto: que solução vocês usam para ler sprites em disco?
Pois tem que gerenciar a memória (descarregar coisas que não são mais úteis), definir se o sprite é ou não animado, não deixar ele aberto em disco (criptografado ou não), além da definir a forma de colisão.

Qualquer jogo que não seja muito pequeno precisa disso para ter um loading decente... Grande decepção a versão 8 do GM não trazer uma solução para isso.

Eu uso o Resource System do Kalnoj Aleksander. Tem todas as soluções para estes problemas, funciona muito bem, porém só no GM7. No 8 ele não adaptou o sistema, só fez funcionar na marra sem re-escrever o que era preciso (relativo ao novo sistema de png com alpha etc). Entrei em contato com o autor ele disse que não mexe mais com GM, então o sistema não será mais atualizado. Até mandou os códigos fonte da extensão se quisesse arrumar no braço, mas é muito complicado, não tenho a mínima chance de entender aquilo (o cara é russo só para ter uma idéia).
Enfim uso este sistema dele no GM8 mesmo assim, porém descobri agora que alguns dos problemas dele não fazer uma versão 100% compatível é que a definição do bb feita no programa dele (há um .exe externo para definir os sprites que serão carregados depois) não funciona. Por isso precisei setar os bb na mão, e tive este problema todo.

Mesmo com tudo isso é a melhor forma de carregar sprites do disco que vi até agora. Alguém tem outro plugin para indicar?
Valeu.

eu li um topico seu que voce fez faz tempo sobre esse assunto...
entao vi as postagens doo brendam e pesquisei sobre o assunto, ai eu peguei e achei o tuto de loading feito pelo brendan ("loading" no buscar)...
eu acho uma solucao boa fazer o seguinte:

- Adicionar os sprites necessarios no room start (sprite_add) ...
- Quando nao usar exlcuir ele.
- pode ser com qualquer recurso.

FLW

Só uma observação, pelo que eu entendi o argumento tolerance indica o nível de alpha que deve ser considerado pelo precise colision checking.

Nós sabemos que o formato PNG suporta alpha entre 0 e 255, né?
Então nós iremos colocar nesse argumento um valor como: 1/alpha tolerado, onde alpha tolerado é o menor valor de alpha que o precise colision checking vai considerar na colisão.

Se você colocar 1, 1 é igual a 255 nesse caso, então todo pixel que tiver um alpha igual ou inferior a esse (ou seja, todos), serão ignorados pela mascara, se você colocar 0.008 que é o mesmo que 125, então todo pixel com alpha inferior a 125 será ignorado pelo precise colision checking e os com alpha superior a 125 formarão a mascara.

Lembrando que esse parametro só afeta o precise colision checking, e creio que só é util com png mesmo.

Hmmm, veja que tem agora um sprite_add_sprite que é muito promissor!!!

Fiz um teste rápido e funcionou muito bem, acho que essa é a saída...
Basta gerar um sprite normalmente configurando tudo que quer (pivot, bb, animação,etc), então vai nas propriedades dele e salva em disco como .gmspr

Então apaga ele do projeto (ou use um projeto secundário para fazer isso)

No jogo que irá carregar essa imagem, no objeto referente a ele basta no create usar

sprite_index = sprite_add_sprite("nome_arquivo.gmspr")

E pronto está carregado com todas as configurações do sprite prontas!!


Quando passar de fase e quiser descarregar da memória, só usar o tradicional sprite_delete...

Claro para isso funcionar deveria carregar o sprite em uma variável para poder apagar depois...
meu_sprite = sprite_add_sprite("nome_arquivo.gmspr")
sprite_index = meu_sprite

depois
sprite_delete(meu_sprite)

Há tb o background_add_background que funciona da mesma forma!
Para o som tem usar o sound_add normal... não há como puxar com formato próprio do GM.

Então com estas funções parece que todos os problemas estão resolvidos... temos como configurar tudo previamente, usar um formato de arquivo que esconde a arte, etc. Só o sistema de liberar memória tem que ser feito na mão.

Há algum comando que faça "apagar todos os sprites" ? Se tivesse bastava rodar isso a cada início de fase, e então carregar só o que quer usar.
Se não tiver isso tem que fazer uma lista de sprite_delete para cada coisa que foi carregada antes, bem mais chato.

Mas enfim, agora dá para encarar esses tipos de operações sem precisar de plugin! No meu próximo projeto testei isso.

ponha num evento que quer que delete os sprites, um evento que não se repita:
i=0
repeat(100)
{
if sprite_exists(i)
sprite_delete(i)
i+=1
}

Sim pode ser.
Mas se houver alguma variável interna que guarde o num total de sprites na memória, poderia usá-la (no repeat) ao invés de algum valor arbitrário para processar só o necessário.
Mas pelo que sei isso não existe...