Alguem pode me informa se eh BUG GRAFICO ou erro de PROGRAMAÇAO?

Tipo... o y do personagem BUGA... pq? msm tando sempre no msm Y... soh q quando ta .50 .... pq? ninguem viu isso?

deve ter algum desencontro no seu código.
salve o seu codigo e tente faze-lo denovo e veja se vai bugar.

ass eu to criando um game do MARIO... ta ficando bom pakas... soh q ta ferrando em uma coisa... com o eu estou fazendo um sistema de pulo q se vc segurar vc pula mais alto... quando o char cai, as vezes ele fica 1 pixel acima da plataforma... pq?... olha como eu to fazendo...:

y += global.player_yspeed;
global.player_yspeed += grav;



//para nao ficar ficar 1 pixel ou mais abaixo do chao
if global.player_yspeed > 0 {
while collision_rectangle(bbox_left,bbox_top,bbox_right,bbox_bottom,obj_platform,1,1)
{y -= grav;}}

// colisao perfeita
if collision_rectangle(bbox_left,bbox_top,bbox_right,bbox_bottom+1,obj_platform,1,1)
{
if global.player_yspeed > 0 {
global.player_yspeed = 0;
grav = 0;
phase = 0;}
}
else{
if !keyboard_check_pressed(vk_space)
{grav = 0.2;} else {grav = 0.1;}}


quando eu vejo o y do heroi... na msm plataforma, quando eu pulo... ele ta 183.50 as vezes 183.80... as vezes 183.30... PQ ALTERNA TANTO??? o.O

se alguem poder me ajudar ficaria GRATO!!!

Olha cara, isso já me aconteceu diverssas vezes, o jeito que eu resolvi isso, é sempre fazer o movimentos verticais com vspeed e os horizontais com hspeed, aí na colisão com o chão colocar move_contact_solid(direction,270) e o vspeed ficar igual á zero, assim ele não fica um pixel para cima, mas se você usar essa função com os movimentos por "X" e "Y" o player da uns saltos loucos para os lados ou até para fora da room !

serio? nossa... mas e ta... eu to usando funçao porntas certo?... e se eu fosse programa e C ou ACTIONSCRIPT... ou qualquer outro... n eh todos q tem essas funçoes... certo? Como eu faria?

Amigo se voce quer saber porque ele alterna a resposta é matemátca. Quado você pula ele joga um certo valor no vspeed, conforme ele vai subindo já vai agindo sobre ele a forca da gravidade ou seja o vspeed é somado a cada step pelo valor gravity que no caso é integral pois gravity_direction deve estar setada para 270. Isso faz com que o valor de vspeed varie. Supondo que o bloco do chão esteja na posição 400 e o seu y esteja na posicao (400 - 35) e o seu sprite seja 32 x 32 ou seja ele esta a 3 pixels de encostar no chão. Se o vspeed estiver com o valor 4 ele vai ficar 1 pixel acima pois vai dar colisão com SOLID e o GM colocar o char na posicão anterior quando há colisao. Basicamente é isso, ou seja como o vspeed varia muito ele pode estar exatamente colado ao solo ou variar em posiçoes acima dele.
Como o nosso amigo citou acima, a funcão move_contact_solid() resolve esse problema pois ela vai testando a colisão com incrementos minimos até que ele fique exatamente a 1 pixel do pixel de colisão.
Voce pode fazer essa função em GML usando o place_free() mais não é aconselhavel que voce use a que ja tem pronta para isso. Mais se voce quizer realmente fazer na unha pra aprender, com certeza poderemos lhe ajudar.
Valeu!

so mais fazer na unha... mas amigo...

1° VALEW PELA EXPLICAÇAO

2° sobre alternaçao de pixel eu ja arrumei como WHILE assim

while collision_rectangle(bbox_left,bbox_bottom,bbox_right,bbox_bottom,obj_platform,1,1) and global.player_yspeed >= 0
{y -= grav;}

// colisao perfeita
if collision_rectangle(bbox_left,bbox_bottom+1,bbox_right,bbox_bottom+1,obj_platform,1,1) and global.player_yspeed >= 0
{
global.player_yspeed = 0;
grav = 0;
phase = 0;
can_run = true;
}
else
{grav = 0.2;}



ele sempre colide no 180 (por exemplo).... mas o problema... eh q alterna... 180.10; 180.20; 180;30 e assim vai... e quando xega no 180;90... volta.. pro 180;00... ateh aki perfeito!!! mas o q buga eh no 180.50 (sempre no .50) buga a imagem... n eh erro do GAME MAKER? e otra n tem como ele sempre cair no 180 perfeito (sem variaçao do .__)?

vinians escreveu:Amigo se voce quer saber porque ele alterna a resposta é matemátca. Quado você pula ele joga um certo valor no vspeed, conforme ele vai subindo já vai agindo sobre ele a forca da gravidade ou seja o vspeed é somado a cada step pelo valor gravity que no caso é integral pois gravity_direction deve estar setada para 270. Isso faz com que o valor de vspeed varie. Supondo que o bloco do chão esteja na posição 400 e o seu y esteja na posicao (400 - 35) e o seu sprite seja 32 x 32 ou seja ele esta a 3 pixels de encostar no chão. Se o vspeed estiver com o valor 4 ele vai ficar 1 pixel acima pois vai dar colisão com SOLID e o GM colocar o char na posicão anterior quando há colisao. Basicamente é isso, ou seja como o vspeed varia muito ele pode estar exatamente colado ao solo ou variar em posiçoes acima dele.
Como o nosso amigo citou acima, a funcão move_contact_solid() resolve esse problema pois ela vai testando a colisão com incrementos minimos até que ele fique exatamente a 1 pixel do pixel de colisão.
Voce pode fazer essa função em GML usando o place_free() mais não é aconselhavel que voce use a que ja tem pronta para isso. Mais se voce quizer realmente fazer na unha pra aprender, com certeza poderemos lhe ajudar.
Valeu!

Brigado pela explicação Vinians, eu também tinha dúvidas sobre isso, mas você sabe porque que seu eu fazer os movimentos com "X" e com "Y" e usar a função move_contact_solid(direction,270) o player salta 270 pixeis para a direção em que vai certo, mas se usar os movimentos por hspeed e vspeed, ele para no mesmo local e não salta os 270 pixeis, ou será que é só comigo que acontece isso ?

Na verdade 270 é muito pra ser usando com move_contact_solid(), eu geramente uso maximo quinze. Pois se ele realmente for usado no local certo ele raramente vai chegar a esse valor. Quando usar essa funcão temos que usa-la em um local onde o char esteja colisão, pois como diz o nosso amigo Mark, quando a uma colisão com solidos, o char no evento de colisão imediatamente ANTERIOR ao evento de colisão ter surgido. Isso exatamente nos favorece pois podemos justar y, x, vspeed e hspeed de acordo que ele não fique em colisão no próximo step. A funcao move_contact_solid() faz exatamente isso ele vai somando o y com valores minimos até que ele colida então ele volta um para traz e sai. O segundo parametro diz exatamente quantos pontos ele deve ir "procurando" a colisão. Se colocar um valor muito alto ela vai dar saltos gigantescos enquanto não encontrar alguma colisão.

Ainda ninguem respondeu meu topico xP!

esse seu codigo ta muito esquisito...
tenta esse:
Na colisao com chao

vspeed=0

No step:

if !place_meeting(x,y+1,obj_chao) then vspeed+=0.3;
if keyboard_check_pressed(vk_up) then vspeed-=12

AFFE.. gente n tem nenhum programador q n seja soh de FUNÇOES??? gente programa n eh soh fica usando funçao de 1 programa soh... vcs axam q em C existe place_meeting ??? claro q nao... essa funçao eh CRIADA... ninguem aki sabe fazer um sistema de GRAVIDADE... q seja LOGICA??? q n seja por funçao de 1 programa soh?! (ou eh soh eu q programo C e ACTIONCRIPT)?

and.kenobi escreveu:AFFE.. gente n tem nenhum programador q n seja soh de FUNÇOES??? gente programa n eh soh fica usando funçao de 1 programa soh... vcs axam q em C existe place_meeting ??? claro q nao... essa funçao eh CRIADA... ninguem aki sabe fazer um sistema de GRAVIDADE... q seja LOGICA??? q n seja por funçao de 1 programa soh?! (ou eh soh eu q programo C e ACTIONCRIPT)?

Amigo acho que é voce que não esta entendendo. O GML é uma linguagem interpretada. Quando você chama uma função como place_meeting() voce esta usando uma função previamente programada em Delphi que é a linguagem que o GM foi criado. É claro que muita gente aqui sabe fazer tudo a unha, mais se voce esta usando uma linguagem interpretada tem que evitar reiventar a roda, pois voce so vai conseguir lentidão, pois vai fazer com um script de 20 linhas oque poderia ser feito chamando uma função de uma linha e já depurada.
Eu entendo que você queira fazer a sua própria função, mais analise antes o ganho que terá com isso.
Se for aprendisado, então faça você mesmo, com certeza você vai coneguir aprender GML, já que voce programa em C e Action Script GML será uma moleza!!

Eu por exemplo curto muito fazer jogo em C, Pascal, Assembly, QuickBasic, FreeBasic e já fiz alguns testes em Blitz e Dark Basic, mais o GM é dentro do que ele se propoe um ótimo framework para criação de jogos em 2D.

Se quizer ver algo em C tudo feito a unha, clique no site da minha assinatura que la tem
muita coisa feita na unha.

Abração!

conclusao... vo ter de usa funçao pronta... eh isso? pra roda melhor...

otra coisa q eu queria pergunta.... eh normal sempre, por eu mexe com aceleraçao... eu usar... 1.2 ou 0.5... (usar numeros quebrados) para o X oy Y?

Mas que complicação em.
Porque você simplesmente não arredonda o valor da posição depois/durante colidir?

if global.player_yspeed > 0
{
while collision_rectangle(bbox_left,bbox_top,bbox_right,bbox_bottom,obj_platform,1,1)
{
y -= grav;
y = floor(y);
}
}

otra coisa q eu queria pergunta.... eh normal sempre, por eu mexe com aceleraçao... eu usar... 1.2 ou 0.5... (usar numeros quebrados) para o X oy Y?

Sim se você quiser causar um efeito de acelerar e não simplesmente saltar de uma posição arredonda para outra.

NOSSA!!! ADOREI!!! ARREDONDA MSM o.O mas como se define esse tal de FLOOR? (pra q serve exatamente?)

Retira as casas decimais.
Não é arredondar exatamente mas apenas retirar os números depois do ponto.

NOSSA... valew msm... mas assim... como eu programo em ACTIONSCRIPT tbm... gostaria de saber como tira esses decimais em qualquer otra lingaguem... eh usando FLOOR tbm?

(soh pra consta... bugo mais usando isso... hauha... mas valew pela ajuda)... Gostaria q tivesse algo q ao colidir ao chao... o Y do personagem ficasse PERFEITO entende?