Colisão inversa

Queria fazer uma colisão inversa que ao invés do jogador não poder atravessar o sólido, ele não pode atravessar o vazio. Como se estivesse preso dentro dos blocos.



No caso, esses retângulos são formados por diversos blocos.
Como na imagem, se houver interseção entre as formar o jogador pode atravessar pois os blocos podem e vão se movimentar se fundindo um com o outro.

A solução é obvia: checar se não tem colisão e impedir o movimento. Mas na prática não é tão simples pois as funções de colisão do GM são otimizadas para o método oposto e um movimento do tipo plataforma pode resultar em muitos bugs.
Eu consegui resolver esse problema com a famosa técnica da gambiarra métodos nada funcionais que resolvem mas obviamente não são eficientes.

Alguém ai tem uma boa ideia de como fazer isso?

Usando a lógica é só você transformar sólido em vazio, e vazio em sólido... e inverter o que estava fazendo?

Sim mas só por essa lógica a diversos problemas de colisão em terrenos que os blocos não formam retângulos perfeitos como aqui:



Sempre da problema na hora de processar a colisão dos cantos.

Hum!... Entendi! o que vc quer é usar isto como o mapa da fase...

Tentei isso usando um sprite contendo toda a fase (mapa) e mesmo deixando o blackground da imagem invisivel, o player nao entrava nem a pau! entao fui obrigado a botar o tal mapa como background e onde eu nao queria que ele passasse, botei os blocos invisiveis... q chato.

Talvez invertendo o tal place_free e direcionando a situaçao a aquela sprite em particular(mapa) nao sei exatamente como mas algo que detecte colisao com determinada cor! do tipo

se player em cima da sprite so para se topar com a cor.
nao sei se foi voce mas lembra do pedido que fiz de destruir apagando cor?
https://gmbr.forumeiros.com/t22097-resolvido-curiosidade-objeto-se-destuir#166436
Talvez o conceito ajude!

Vou estudar isso mais a fundo qq novidade te falo ou vc nos mostra.

Eu fiz um exemplo aqui, está adaptado para rpg.
http://dl.dropbox.com/u/34803365/engines/movimento%20dentro%20de%20retangulos%20em%20movimento.gmk

Ela funciona assim:
O objeto tem que está dentro do retângulo, caso ele fica fora do retângulo não consegue se mover, usei place_meeting(x, y, obj_retangulo); no caso de ter vários formatos de objetos colocar todos eles com o mesmo parente, e então no place_meeting você usa o pai de todos esses retângulos, então basta verificar antes de mover o objeto, se a posição que ele vai mover ainda está dentro do retângulo, caso esteja ele vai mover o objeto, caso contrario não, fazendo isso você vai conseguir se movimentar livremente dentro dos retângulos, caso eles estejam em movimentos, fazer com que o objeto continue dentro do retângulo, caso ele saia ele fica preso, o exemplo que fiz faz isso, acho que não é tão difícil adaptar para plataforma, se for o seu caso. Veja ae se essa ideia é adequada para oque você está fazendo, caso não seja, podemos pensar em formas diferentes de fazer isso, flw.

fiz um pequeno exemplo simples e funcional, talves ajude

Colisão Inversa.gmk

@Jiraya e Klior
Era esse método que usei no começo, só que é difícil aplicar em um movimento do tipo plataforma porque os cantos/pontas dos blocas em uma fase do tipo da segunda imagem que posto dá muitos bugs sendo que o tipo de colisão que estava usando detectava inclinações (subir rampas e objetos).

@moisesBR
Você me deu uma idéia, eu poderia transforma o espaço vazio em um surface limitando as dimensões ao tamanho da view.
Resolveria o problema com os scripts de colisão com inclinação sem muito esforço mas estou preocupado com a performance porque alguns podem se mexer e eu teria que atualizar a surface sempre que isso acontece-se.

Kabeção escreveu:eu poderia transforma o espaço vazio em um surface limitando as dimensões ao tamanho da view.
Resolveria o problema com os scripts de colisão com inclinação sem muito esforço mas estou preocupado com a performance porque alguns podem se mexer e eu teria que atualizar a surface sempre que isso acontece-se.

É o que eu faria. Isso permite a colisão normal.
De fato é lento, mas pode ser aceitável.
Acredito que os objetos não teriam sua posição atualizada automaticamente (nesses jogos, a atualização da posição das plataformas costuma depender de uma ação - eventual - do jogador). Diminuir as performances SÓ nessas horas pode passar despercebido. O truque é avisar pro computador em que momentos fazer isso. Um "if" deve bastar.
Além disso, pelas screens, o jogo seria um puzzle, certo? Provavelmente terá uma quantidade pequena de objetos em tela, isso te libera pra usar uns códigos mais pesados.

Edit: Se for limitar ao tamanho da view (não sei se existe ganho nisso), ao mover a view, você vai precisar atualizar a sprite criada novamente. Talvez seja mais interessante aumentar um pouco o limite, pra diminuir o número de atualizações da sprite de colisão (você verifica se view_xview < bbox_left - e o mesmo nas outras 3 direções - e só refaz a sprite quando a view fugir da sprite).

E se tirar a cor de dentro das caixas brancas e usar outro objeto pra fazer essa película branca?
Aí só oque fica sólido são as bordas que tem cor, certo?

@Super Maker
Isso não resolve porque será um problema quando os blocos se juntarem.

@saim
Mas só da pra desenhar apartir da posição da view, qualquer coisa fora da view não é capturado pela surface. Tentei até aumentar a view só na hora de atualizar a surface mas também não funciona.

Mas eu fiz uns testes e desenhar só os objetos de colisão em tempo real é bastante rápido no runner mas isso só funciona pra Windows porque o HTML5 não suporta blend mode e ainda não sei como vai ser no Android e iPhone.

Então para fazer uma surface do espaço vario seria assim:

Código:

surface_set_target(surf);
draw_clear(c_red);

draw_set_blend_mode_ext(bm_zero,bm_inv_src_alpha);
with parSolid {
    draw_sprite(sprite_index,image_index,x,y);
}
draw_set_blend_mode(bm_normal);
surface_reset_target();

Kabeção escreveu:Mas só da pra desenhar apartir da posição da view, qualquer coisa fora da view não é capturado pela surface. Tentei até aumentar a view só na hora de atualizar a surface mas também não funciona.

Sério??? Você deve estar desativando as instâncias ou usando algum tipo de screen_redraw. Não faz sentido, os objetos não serem desenhados. Se eles estão ativos, têm que obedecer aos comandos.

Kabeção escreveu:Mas eu fiz uns testes e desenhar só os objetos de colisão em tempo real é bastante rápido no runner mas isso só funciona pra Windows porque o HTML5 não suporta blend mode e ainda não sei como vai ser no Android e iPhone.

Isso explica alguns problemas que estou tendo em outros jogos... Diacho, aprendi a depender dos blend modes!
É, sem usar blends, fica difícil. Aí, o jeito é partir pra gambiarra de verificar collision_lines, bboxes e um MONTE de exceções.

Kabeção escreveu:Então para fazer uma surface do espaço vazio seria assim:

Código:

surface_set_target(surf);
draw_clear(c_red);

draw_set_blend_mode_ext(bm_zero,bm_inv_src_alpha);
with parSolid {
    draw_sprite(sprite_index,image_index,x,y);
}
draw_set_blend_mode(bm_normal);
surface_reset_target();

Eu faria até mais simples, usando bm_subtract, mas isso parte do pré-suposto que o alpha dos "sólidos" é 100% - ou que eles possam ser associados a uma sprite com alpha em 100%.
Pra começar, eu mudaria um paradigma: ao invés de começar com os objetos colidindo com espaços sólidos, eu criaria objetos-espaço, sem serem necessariamente sólidos, só pra lidarem com os blends, e um único objeto pra ser todas as plataformas, com sprite sendo atualizado de tempos em tempos. Esses objetos-espaço seriam controláveis pelo jogador e nesses momentos de mudança de posição, ativariam um trigger no objeto-plataforma que atualizaria a própria sprite (cara, já quero jogar esse jogo...).
Esse trigger seria mais ou menos assim:

Código:

var Surf, borda, oldSprite; //se for testar, note que eu uso a maiúscula em Surf
oldSprite = sprite_index; //note que, pro primeiro step, isso demanda alguma sprite "de verdade". Ou você pode checar se existe uma sprite_index
borda = 20; //20 tá bom?
Surf = surface_create(view_wview[0] + 2 * borda, view_hview[0] + 2 * borda);
surface_set_target(Surf);
draw_clear($ffffff);
draw_set_blend_mode(bm_subtract);
with(objEspaco){
draw_sprite(sprite_index, image_index, x - view_xview[0] + borda, y - view_yview[0] + borda); //ou draw_sprite_ext, se necessário. Estou meio enferrujado, não tenho certeza se é pra somar ou subtrair a "borda"
}
draw_set_blend_mode(bm_normal);
sprite_index = sprite_create_from_surface(); //esqueci os argumentos, aqui. Cria a sprite com origem em (borda, borda)
x = view_xview[0]; y = view_yview[0];
sprite_delete(oldSprite);


Fiz Esbocei esse trigger de forma que ele possa ser usado nos momentos em que a view sair da borda, também. Aí, o objeto que controla a view também pode verificar se a plataforma está toda dentro da view e, em caso contrário, ativar esse trigger.

Pra começar, eu mudaria um paradigma: ao invés de começar com os objetos colidindo com espaços sólidos, eu criaria objetos-espaço, sem serem necessariamente sólidos, só pra lidarem com os blends, e um único objeto pra ser todas as plataformas, com sprite sendo atualizado de tempos em tempos. Esses objetos-espaço seriam controláveis pelo jogador e nesses momentos de mudança de posição, ativariam um trigger no objeto-plataforma que atualizaria a própria sprite (cara, já quero jogar esse jogo...).

Bem pensado saim.
Mas a fato disso não funcionar em HTML5 desanima.

Queria pensar em uma solução multiplataforma.

Tem algo que funcionaria até mesmo para nova engine de física do Box2D do GMS.
A solução seria construir "paredes" dinamicamente em volta dos blocos, se houver interseção apagar os partes juntas.
Temos a opção de criar fixtures do tipo wall no sistema de física, seria como criar uma parede mesmo.

No editor de room eu monto os blocos:

Depois eu fundo os objetos, é um script simples que sempre uso pra apagar os objetos próximos e transforma-los em um só só aumentando a escala do objeto que sobrar.

Agora na teoria eu crio as paredes:

Checo as interseções

e mudo o tamanho os linhas


Ilustrar é fácil mas o problema é fazer isso considerando as diversas formas que podem acontecer.

Poxa to curioso pra ver o resultado disso.
Qual código vc usa na colisão de um obj com outro e para transforma-lo em um só ?

ou é isso que vc qer o_O ?

Eu cheguei a pensar nisso, criando centenas de pequenos blocos 1x1. Mudaria um pouco a jogabilidade - os personagens teriam que estar congelados ao mover as plataformas - e, num loop após as movimentações, cada plataforma eliminaria e recriaria esses pequenos blocos nas partes de seu contorno que não colidem com alguma instância igual a elas.
Mas não consegui fazer isso com plataformas inclinadas. Você DISSE que quer rampas. Além disso, você falou em unir os objetos, o que não é recomendável, caso queira voltar algum objeto pra posição inicial. Lascou.

[almoço]Conversei com uma amiga minha, um verdadeiro gênio. Pena que ela só curta programar pra coisas de gênio, não quer nem saber de jogos.
Ela me deu uma idéia.[/almoço]

E se usássemos uma grid? Vou apresentar a idéia aos poucos, por enquanto, esqueça qualquer preocupação com performance. É uma mudança meio radical no paradigma de colisão.

E se houvesse uma grid, do tamanho da tela, com cada célula correspondendo a um pixel? Daí, poderíamos atualizar a cada step, em função dos pixels dos objetos-janela (vou chamar os espaços disponíveis pra movimentação assim), cada célula da grid em termos de "true" e "false". Se está livre pro jogador andar, true, senão, false. Daí, preveríamos a posição seguinte do objeto-personagem em função das entradas do jogador e, num loop, verificaríamos se algum pixel do jogador estaria numa posição correspondente a algum pixel com valor false. Funciona? Funciona.
Agora, vamos falar em termos de performance. Os loops seriam muito longos. Poxa, definir os valores da grid pra tela inteira, a cada step? Pesado!
A solução, então, seria diminuir a grid. Nós não precisamos da tela inteira, precisamos de uma região em volta do personagem! Leve em conta a velocidade máxima em cada direção, mais o tamanho da sprite do personagem e pronto, esse é o tamanho da grid que precisamos. Acelera um bocado, né? Com uma transposição de eixos simples, é como se o jogo se movesse e a grid ficasse quieta, permitindo a ela manter o valor constante.

Pois bem. Nessa grid, pra verificar se o valor da célula deve ser true ou false, podemos usar collision_point. Pra reduzir o número de objetos-janela a entrar nesse loop dos collision_point, podemos usar "if (collision_rectangle){ //entra no loop;}. Depois, num segundo loop, verificamos (novamente com collision_point, dessa vez testando o objeto-personagem) se a posição seguinte representa algum sprite colidindo com alguma célula cujo valor é false.

Viajei muito? Não garanto que isso dê performance, mas acho que vale o risco. Não tenho como desenhar o que imaginei, mas posso tentar criar algo pra ilustrar (códigos), caso eu não tenha sido claro.

Edit:

Outro rascunho...

create

Código:

velMaxHor = ???; //velocidade máxima horizontal
velMaxVer = ???; //velocidade máxima vertical
larGrid = sprite_width + 2 * velMaxHor;
altGrid = sprite_height + 2 * velMaxVer;
gridColisao = ds_grid_create(larGrid, altGrid);
ds_grid_set_region(gridColisao, 0, 0, larGrid, altGrid, false);

movimentação ou step

Código:

var i, j, xTela, yTela;
//calcula o deslocamento
dx = ???; dy = ???; //deslocamento em x e y
//zera a grid
for(i = 0; i < larGrid; i += 1){
   for(j = 0; j < altGrid; j += 1){
      ds_grid_set_region(gridColisao, 0, 0, larGrid, altGrid, false);
      }
   }
//atualiza a grid
for(i = 0; i < larGrid; i += 1){
   for(j = 0; j < altGrid; j += 1){
      if(ds_grid_get(gridColisao, i, j) == false){ //pra evitar fazer a mesma coisa
         //acha, na tela, a posição correspondente ao valor da grid
         xTela = bbox_left - velMaxHor + i; yTela = bbox_top - velMaxVer + j;
         if (collision_point(xTela, yTela, objJanela, 1, 1){
            ds_grid_set(gridColisao, i, j, true);
            }
         }
      }
   }
//move
x += dx; y += dy;
//finalmente, checa a colisão
for(i = 0; i < larGrid; i += 1){
   for(j = 0; j < altGrid; j += 1){
      if(ds_grid_get(gridColisao, i, j) == true){
         if (collision_point(bbox_left - velMaxHor + i, bbox_top - velMaxVer + j, id, 1, 0){
            //colidiu
            }
         }
      }
   }

HTML5 é que vai te atrapalhar um pouco porque essa ideia da surface é muito boa. Eu só não sei se ficaria muito rápido usar uma grid muito grande. Um dos exemplos de melhor performance que eu já vi pra GM usando grids foi um de flood fill, e mesmo assim ele não é tão rápido... Mas vale a pena tentar! Um jogo com um cenário e um quebra-cabeças assim ficaria legal demais.

É bem complexo mesmo justamente por causa do movimento dos blocos, porque se fossem parados ou alinhados rigorosamente à uma grade, acho que daria pra usar esse método do Jiraya e colocar umas arestas em cada objeto em volta, acho que ficaria mais rápido.

Eu fiz um exemplo aqui seguindo mais ou menos essa ideia (do Jiraya, só que com as arestas ao invés dos blocos, e com triângulos), mas não sei se vai ajudar:

http://dl.dropbox.com/u/77818756/Cen%C3%A1rio%20arestas.rar

Talvez, uma ideia legal fosse você fazer o conceito normal da programação, mas tentar passar pro jogador a ideia de que o cenário está invertido. Talvez desse pra fazer isso, mas sinceramente, não tenho ideia.

saim escreveu:Você DISSE que quer rampas. Além disso, você falou em unir os objetos, o que não é recomendável, caso queira voltar algum objeto pra posição inicial. Lascou.

As rampas não são um problema, posso até descarta-las.
O essencial pra mim seria construir um poligono em tempo real marcando as paredes.
A fusão que me refiro não é em tempo real, é so no evento room start pra simplificar os objeto e diminuir o numero de instancias.


Os blocos que se movem eu não fundo.

Então saim é esse método mesmo que usara no exemplo de jogo de plataforma que vem junto com o GMS: http://yoyogames.com/tech_blog/7

É a melhor maneira para conseguir performance se for um grid em que cada ponto representa 32x32 ou 16x16.

Na hora de mover o jogador junto com a plataforma é mesmo melhor trava-lo que ai pode ter muitos bugs.

FlyAway escreveu:Poxa to curioso pra ver o resultado disso.
Qual código vc usa na colisão de um obj com outro e para transforma-lo em um só ?

ou é isso que vc qer o_O ?

O script é esse:

Código:

// fundir_objetos(obj)

var merge;

do {
    merge = false;
    with argument0 {
        if object_index != argument1 {
            if x=other.x+other.sw and y=other.y and sh=other.sh {
                other.sw += sw;
                merge = true;
                instance_destroy();
            }
        }
    }
} until merge=false;
do {
    merge = false;
    with argument0 {
        if object_index != argument1 {
            if y=other.y+other.sh and x=other.x and sw=other.sw {
                other.sh += sh;
                merge = true;
                instance_destroy();
            }
        }
    }
} until merge=false;

with(argument0) {
    image_xscale = sw/sprite_width;
    image_yscale = sh/sprite_height;
}

Eu defino no create do objeto uma variável sw e sh com o valor do tamanho e largura dos blocos.
Ai fundi os tamanhos como mostrar esse ultima imagem.


@Ninja8086
Legal esse exemplo.
Me deu uma ideia de como resolver isso sem usar surface.
Ou passo criar os objetos contornando, como são blocos juntos, se o contorno estiver sobre outro bloco eu o apago na inicialização da room.
Posso sacrificar o movimento livre das plataformas (encaixando uma na outra sem atravessar) e desativar os contorno que colidem com os blocos em tempo real.
Acho que é a solução mais prática.

Vou tentar reproduzir e postar mais tarde.


Então cheguei a essa solução:
http://dl.dropbox.com/u/60691076/colisao.gmk
É bem prático e na hora de construir as paredes eu posso transferir as características dos blocos pra elas e destruí-los para diminuir o número de instências.