thegoodfellas/blogset-br huggingface dataset:
O exercicio era pra fazer um sorvete com flocos de chocolate em cima:Sabor OpenGLE isso ai! XD E x5! Terminando o combo de hoje.O exercicio era bem simples. Fazer um carinha andar pela tela com x e y, declarar um namespace e com o mesmo nome das variaveis, fazer um segundo carinha com x,y e velocidade, e conseguir move-los pela tela sem conflitos (ou seja, gracas a velocidade um vai mover com velocidade diferente do outro).Simples:BITMAP* carinha;int x = 50;int y = 50;namespace cara2{ BITMAP* carinha; int x = 50; int y = 50; int vel = 2;}...carinha = load_bitmap("carinha.bmp",NULL);cara2::carinha = load_bitmap("carinha2.bmp",NULL); ... if (key[KEY_LEFT]) { --x; cara2::x = cara2::x - cara2::vel; }... draw_sprite(frontbuffer,carinha,x,y); draw_sprite(frontbuffer,cara2::carinha,cara2::x,cara2::y);E a magica acontece. Namespace e bom pra usar varias copias de alguma coisa na cena, como um efeito estroboscopico, uma sprite multipla, efeito de luz de camera... Dado o exemplo acima, a forma como eu movo ambos os personagens ao mesmo tempo e bem interessante, lembra um pouco uma dinamica 3D. Daria pra usar em classes, tipo 2 personagens semelhantes na tela, mas e que se voce vai usar classe, use objetos ao inves de namespace...E e isso, em teoria acabei o primeiro semestre do curso. Bom, ainda falta o projeto, mas talvez eu o ponha no blog bem depois.C-C-C-COMBO BREAKER! Pois e. Fazia um tempinho que nao postava nada. Pessoal comecou a reclamar, entao ca estou.(E... Ate que tem bastante gente lendo esse blog no momento. XD) Feriadao de pascoa, "piguic", e afins. Mas voltei.Desafio dest... Da outra semana era fazer o Zero pular de uma plataforma para outra. O desafio nem explicitamente especificava se esta plataforma deveria estar em outra posicao X da inicial, pelo menos a Y. (Que por as duas no mesmo lugar nao tem a menor graca. )Como eu irei usar um sistema de colisao deveras complexo no meu projeto, pensar em gambiarra seria pecado. (Alias, nao postei nada sobre meu projeto, em breve eu vou.)Primeiro comecei analizando o jogo no estado atual. MEUS OLHOS! Eu ate deixo passar o fundo em parallax scrolling fugindo da tela e gerando uma coluna preta a esquerda (e sorte que gera algo, em algumas engines acontecem coisas muito bizarras no caso), mas o pulo realmente estava estranho: Tudo bem que e ate uma mecanica legal de se usar... Mas e um bug.Nao deixei barato: decidi nao somente fazer ele pular para virtualmente qualquer plataforma (e pro caso de estourar a cabeca numa plataforma acima, faze-lo cair com gravidade e tudo mais) como evitar o uso de uma varredura pelas posicoes das plataformas, e sim reconhecer quando achou o chao e parar de cair. Ou seja, uma verdadeira colisao fisica, independente das posicoes das plataformas (Elas ate poderiam estar se movendo! Bem, ia faltar a logica de fazer ele mover conforme a plataforma se move, mas ficaria meia logica pronta e generica.).Para minha infelicidade, essa logica desmonstrou-se alem das minhas capacidades de programador (e nao de PoGramador).Foi meio que o mesmo drama com o Haggar, ele desaprendia a pular. So que nesse teve uma novidade, ele
parou de reconhecer o que e chao e as vezes aparecia voando pela tela.Um dos principais problemas, que o professor havia mencionado na sala, e que gracas ao fator gravidade nao ha mais como prever, em posicao da tela, onde que o personagem vai parar. Entao o que ocorria era o personagem entrar terra adentro e nao conseguir mais sair, ou simplesmente andar la como se fosse o chao. Entao se eu usasse um personagem auxiliar para verificar o chao antes de se enterrar, e por o personagem no lugar certo, ate funcionava. O problema e que dai ele ficava andando flutuando acima da plataforma. Eu sabia fazer o personagem achar o chao, so nao precisamente...Para isso bolei outra logica de colisao, que seria uma varredura do chao. Ele tentaria achar o chao analizando os pixeis do chao. Me chame de suicida, mas usei um "while" para isso! Aparentemente nao causou problemas ja que era um while fazendo calculos inocentes. (So quando programei errado. Ai o bicho pegou. Deu pra sentir o gosto de tela azul.)Olhando assim parece facil programar. E e! Mas nao funcionou. XDEu ainda usava o boundboxing, so que eu fazia uma varredura para ajustar a posicao atual com a que deveria ser.Mas sei la, nao sei onde eu errei, mas nao funcionou. O personagem geralmente nao saia da terra apesar de tudo, e ele nao caia de fato no chao. Nem pulava mais. E andava no ar.Foram quatro horas pra pensar e programar tudo, e nao deu. Daria pra fazer em vinte minutos na gambiarra, mas nao. Me recuso.E isso.
Ca estou eu de volta, rachando a cuia pra resolver um dos exercicios propostos, o de ponteiros, o que se demonstrou mais dificil pra mim, ate o momento.O DESAFIO era instanciar duas classes, classe a e classe b. Na classe a ha uma variavel, e na classe b, eu devo somar a variavel da classe a. A ideia era usar ponteiros pra isso... Bem, depois de muito neuronio queimado durante DUAS horas, resolvi. Aha! Ai depois eu fui reler o exercicio proposto e descobri que nao podia usar heranca nem parametros. A casa caiu.O motivo do exercicio ter sido proposto dessa forma e para poder utilizar ao maximo o recurso de ponteiros num jogo, o que contribui enormemente na perfomance do jogo. (E, estamos no nivel de 2D pra DOS, mas e bom ter tendencia a se fazer assim pra futuramente nao ficar fazendo codeblotch de graca num jogo que vai exigir do pc)O problema e que a nao ser que ao inves de "int variavel" use-se "crystlbll variavel" (crystal ball, bola de cristal), eu nao entendi exatamente como que duas classes que nao se herdam conhecam uma variavel que nao e pertencente a elas. A classe A conhece a sua variavel, mas a B nao. Tudo bem que o main sabe, o problema e que o exercicio especifica para nao usar parametros, entao nao posso mandar o var pra classe B.Se eu usar heranca da, mas ai nao e justo, quando o exercicio foi proposto nao haviamos aprendido heranca.Eu entendi o que e pra fazer, eu entendi o porque de se fazer, mas nao sei como fazer. Nao sem heranca.Trechinhos do quao longe que fui:No main:...classea *numero;classeb *numero2;... numero = new classea(); numero2 = new classeb();... numero->mostra_var(); numero->var = numero2->soma_var();...Classe A:...classea::classea(){ var = 2;}void classea::mostra_var(){ cout << var << endl;}Classe B:...classeb::classeb(){}int classeb::soma_var(){ var++;}Alguem ja deve ter lido e ter pensado "Meu deus onde que esse cara tava com a cabeca pra fazer uma burrada dessas!" e eu respondo: Nao sei, se fiz algo de errado ali em cima eu pelo menos nao percebi.E isso! Sim! Combo! Dois posts num mesmo dia! E nao vai acabar por aqui.O exercicio consistia em pegar uma imagem e redimenciona-la pra aumentar em pelo menos 25%. Isso e ligeiramente mais complicado que diminuir uma imagem, ja que ao diminuir tu so descarta pixeis. Ao aumentar uma imagem voce deve preencher os espacos vazios deixados pelo redimencionamento.Bom... Pelo menos 25%... Ok. Mas sabe, aumentar em 100% e muito mais facil. XDEu fiz o codigo, ficou bunitim, mas meu pc esticou os capacitores e o codigo ficou la. Entao nao vai ter ctrl+c ctrl+v nenhum, vou so explicar.A ideia e que ao aumentar a imagem em mais 100% (200% da imagem original), voce esta simplesmente redimencionando a imagem multiplicando cada dimensao por 2. Isso resulta em uma imagem duas vezes maior ne? NAO!! E quatro vezes maior. Isso porque voce esta aumentando a dimensao x e y, duas vezes pra cada.Se voce so multiplicar o x e y por 2, da certo em teoria. Na pratica voce precisa
especificar o pixel que fica no meio das duas novas posicoes.Como na imagem, temos a imagem original (1). Se voce so multiplicar o x por 2, sendo que a "matriz" da imagem comeca em [0,0], e 0*2 = 0, o primeiro pixel continua o mesmo. Mas ja no proximo valor, [1,0], 1*2 = 2, ficaria como no caso de (2). Nao foi atribuido nada a posicao [1,0] na imagem resultante. O mesmo se fizesse no y primeiro, ficaria como (3). E a imagem resultante seria (4) se feito nos dois. Para resolver, voce ira trabalhar com as dimensoes separadas. Felizmente elas ja estao separadas, pelo for, do codigo original de redimencionar a imagem pra encolher 50%. So recomendo trocar o x e y do for da propria imagem por um int i e int j, pra nao confundir.Com a imagem original (5), voce vai na verdade fazer a mesma coisa que antes, so que vai declarar a mesma variavel que atribui o pixel denovo, -1. Entao vai uma linha pra x*2 e outra pra x*2-1. Vai ficar como no (6).A vantagem de ter feito separado pelos for e que tens agora a linha prontinha pra outra dimensao. Se tu tivesse feito esse calculo depois, como que ficaria como no caso da imagem (4) tu por um pixel na posicao [1,1]? Complicado ne? Por isso eu falei pra trabalhar com as dimencoes separadas.Tendo a (6), so fazer o mesmo pra dimensao y, e pronto (7)!Ah, e nao me pergunte porque, mas tu PRECISAS usar for. Com while nao funciona. Se tu usar while a imagem vai parecer borrada de de cabeca pra baixo.E isso. E o combo nao para.
x3! Esse e outro caso de codigo que ficou la no pc que pifou.Eu confesso que esse deu um pouco de medo, o codigo de pathfinding as vezes faz umas maluquices. Tipo o fato do mesmo programa estar fazendo uma rota em aula e outra em casa... Sem contar o cheating que o codigo do professor fez na sala, visto que ao nao conseguir chegar no local de destino, encurralado no canto usou teleporte e foi parar direto no local de destino!Meio burrinho, eu sei, mas de uma reles decisao empirica pra uma decisao correta vao ai umas 30 linhas de codigo...A questao e que o codigo so enxerga as 8 posicoes adjacentes. Se ele soubesse o trajeto inteiro, ai nao seria mais pathfiding ne...Enfim, o segredo e usar a recursividade. Ja que o proprio path gerado pelo codigo ocupa a area usada pra se mover (ou seja, ele nao vai voltar pra um quadrado no qual ele ja passou uma vez), visto uma posicao onde nao ha saida, e lembrando que as pedras atribuidas meramente tem uma dificuldade pra passar, ao inves de simplesmente ser impossivel passar, ou seja, voce tem que alterar o metodo pra um certo numero de dificuldade ser considerado "impossivel", enfim, dado essa flag "impossivel", a recursividade e feita fazendo a logica de pathfinding ser executada novamente. E como se o programa tivesse comecado denovo, so que agora ele esta em outra posicao no campo.E uma simulacao do meu programa pronto, eu perdi o codigo no outro pc. Mas ele tava se comportando assim. A vantagem da recursividade e que uma vez implementada, tu nao precisa implementar denovo, afinal de contas, se o codigo possui recursividade, ao "recursivar" a parte da recursividade esta implementada. (E se nao tiver entendido, recursive a frase acima. Entendeu agora, ou vai ler denovo?)(Leu denovo nao foi? XD)Ta, deixa eu explicar melhor com codigo (vai ficar algo assim):arv->gerar(); //Gerando a arvore, ou "path"...nd = arv->acha(); //Vai meu filho, vai la achar....Node* Arvore::acha(){...if (impossivel == true){arv->gerar(); //Tenho que bolar outro caminho arv->acha(); //La vou eu}/*Nao pode fazer mais nada depois, porque a recursividade nao vai ler, so o caso de uma logica pra fazer algo quando chegar no destino, porque afinal, se voce chegou no destino a rota nao era impossivel...*/} Sim, voce tem que gerar a arvore denovo pra ele saber pra onde ir. Bom, e se for usar o mouse pra criar outro destino, e basicamente a mesma coisa. Na logica que vai o clique do mouse voce vai usar a recursividade. O coitado para no meio da rota, gera a arvore, e vai em busca do destino denovo.Eu so nao refiz o codigo porque to muito ocupado com o projeto final, e a logica do mouse e meio complicadinha de fazer, e a logica de descobrir pro "impossivel == true" e feita com uma comparacao de dificuldade (ele nao verifica a rota ja feita, e as pedras tem uma dificuldade distinta, da algo como if dentro de if umas 7 vezes), entao perdoem-me se ficar faltando algum detalhezinho que eu
Apos seculos, eu retorno de algum lugar perdido. E bem, perdido mesmo eu estava. Eu decidi por os exercicios na ordem apresentada, entao ja tenho alguns ja prontos, foi so esse que me atrasou mesmo. Eu estou programando o projeto final de semestre, entao os exercicios ficaram pra tras mesmo. Enfim! Com ajuda do professor, vos trago a resposta correta: numero = new ClasseA(); numero2 = new ClasseB(numero);Ou seja, o parametro de ClasseB e o objeto da ClasseA.A ClasseA nao tem misterio, o ClasseB.h ficou assim:...#include "ClasseA.h"class ClasseB{ public: ClasseA *ca; ClasseB(ClasseA*); void soma_var();};...E o ClasseB.cc:...ClasseB::ClasseB(ClasseA *ca_){ ca = ca_;}void ClasseB::soma_var(){ ca->var++;}...(Lembre-se de por o #include "ClasseA.h", senao voce vai deixar a coitada classe orfa e o compilador vai se recusar a ser o tutor.)Pronto. Agora admire e use isso o maximo que puder. Nao se um POGramador javalesco, ponteiro e tua salvacao! Agora va, meu filho, que teu compilador te espera. Pois e. As coisas comecaram a acumular e eu estou fazendo o exercicio da semana passada.O objetivo era fazer o personagem deixar uma nuvenzinha de poeira toda vez que aterriza no solo. Para tanto, envolve o uso de um timer, que era o objetivo do exercicio.Bem, o problema e que como isso era pra semana passada, o professor ja mostrou a resolucao... Entao fica meio estranho eu resolver um exercicio que ja foi resolvido. Bom, pelo menos era um bem facil e de solucao obvia, entao nao ha grandes perdas mesmo. Pelo menos eu ja tinha uma boa nocao de como fazer antes do professor mostrar como era.Entao decidi ir um pouco alem do pedido e fazer algo mais realista, porque a solucao apresentada pelo professor foi eficaz porem nao estava bem solucionada no quesito estetica. A poeirinha acompanhava por onde o personagem andasse ao inves de ficar la no chao. Entao decidi deixar a poeira ter uma aparencia mais realista nesse aspecto. (Se bem que o sprite ta bem feio, parece que o zero andou num campo embarrado.)Confesso que deu vontade de usar "cheat" ja que eu ja aprendi como trabalhar com programacao orientada a objetos em jogos, iria ficar muito mais facil se eu fizesse a poeira como um objeto, mas optei pela programacao sem objeto mesmo.O primeiro problema e que a poeira se movia quando aterrizava, mas so a primeira vez. Depois nunca mais andava, e aparecia sempre na posicao final. Bom, resolucao foi facil ate: if(po_x > 40 && chao == false) { po_x = 0; }Na verdade nao e a solucao ideal, nao funciona la muito bem se o personagem pular constantemente, mas resolve em 90% dos casos.Outro problema e que a poeira nao ficava no chao quando o personagem pulava, ela subia junto. Foi surpreendente que a solucao foi extremamente facil. Quando o professor foi por a linha de codigo pra poeira, ele decidiu evitar problemas e usar a variavel do personagem pra posicao y. Bem, eu so troquei a variavel por uma constante e agora a poeira fica la no chao...: draw_sprite(backbuffer,poeira,px + 20 + po_x,500);Ta la. 500. Ok, nao resolve pro caso
de multiplas plataformas, so no chao, mas ai o programa ja estaria muito diferente pra poder suportar as plataformas.Por ultimo foi a posicao x. A poeira seguia o personagem se ele andasse tambem. Bleh, com o scrolling ficou complicado. Na verdade ficou o suficiente pra eu ter preguica de achar uma solucao ideal. Dai nao fiz. :DFicou assim: if(scrolling == true) { map_move -=10; px -=10; }Nao ficou la muito bom, indo pra direita a poeira fica mesmo no chao, mas pra esquerda a poeira anda um pouquinho. E so funciona no scrolling, quando nao tem a poeira continua andando com o personagem. Enao e uma daquelas solucoes que tu conserta um lado do programa, quebra o outro. Ai tu vai consertar aquele lado quebrado, quebra o lado que tu tinha consertado antes. Geralmente apos dois vais e vens o resultado sao os dois lados quebrados. Mas sao so detalhes, o essencial da logica ta feito.Na verdade eu fiz a parte da poeira ficar no chao sem o scrolling... Mas nao sei mais onde eu corrigi isso. Bom, o importante e renderizar usando uma variavel diferente da variavel do personagem, assim voce garante que a poeira nao vai andar com o personagem, e quando for gerar a poeira voce so vai igualar a posicao x do personagem com a posicao x da poeira, e dali voce trabalha so a variavel da poeira. A ironia e que fui eu quem comeu poeira, fiz o exercicio com 8 dias de atraso.E isso. Essa semana ainda eu posto o exercicio dessa semana. Se e que tera. Senao eu posto sobre meu jogo.
O exercicio proposto para essa semana (e, essa uma semana passada de algum temo remoto distante onde eu deveria ter feito o exercicio mas deixei pra hoje) era de fazer uma classe filho herdar a posicao x e y do pai, e mover com as posicoes do pai.E, nao e muito intuitivo, eu pessoalmente interpretei mal o exercicio e tava tentando fazer umas coisas doidas (pra variar). Mas e simples, e so voce atribuir a heranca la no codigo e usar os mesmos NOMES das variaveis de posicao do pai, nao as mesmas variaveis do pai em si, tipo o exercicio anterior. Faz sentido caso por exemplo tenhas que criar varios personagems com classes diferentes. Embora o guerreiro nao vai usar um arco (exceto no WoW...) e o arqueiro nao vai usar uma espada (denovo, exceto no WoW...), todos eles tem posicao x e y, assim como HP, equips, etc.. Ficaria nao so exaustivo como redundante ficar declarando pra cada classe separada as mesmas variaveis, entao voce usa heranca!Classe pai:class classe{ public: int posx, posy; classe();};Classe filho:class classe2 : public classe{ public: classe2();};O segredo ta ali no : na declaracao da classe. E ali que e feita a heranca, e agora o filho vai herdar as riquezas de variaveis do pai.No codigo do main:per = new classe();pers = new classe2();...draw_sprite(buffer,imagem2,per->posx,per->posy);draw_sprite(buffer,imagem,pers->posx,pers->posy);Pronto! No caso, as posicoes x e y eram movidas conforme o mouse, e como atribui o mesmo pra ambas, ambas moviam junto, como se fosse uma imagem so. Repare que a classe2 por si so nao tem as variaveis posx e poxy, mas por causa da heranca, ela tem!E isso. Um dia ainda melhoro essa minha mania de dar nomes bizarros pras variaveis e classes. Alias, fica a dica, nomear uma classe com o nome "classe" e um tiro no pe. Tu vai acabar querendo usar uma tag de C++ em portugues, fora o fato de ser dificil as vezes reparar o e. Nao complique o nome tambem. E preferivel declarar "variavel_que_controla_o_mindinho_do_pe_esquerdo" que "varctrlmindimpesc". Paciencia, digita mais e se confunde menos, nao reclama. Melhor que passar duas horas pra descobrir que declarou a variavel com o nome errado, e agora ja editasse metade do codigo so pra debugging. Seguindo o mesmo destino do vice-governador Romulo Gouveia (PSD), do deputado Manoel Ludgerio (PSD), mais um ex cassista ratifica a sua decisao de apoiar a reeleicao do governador Ricardo Coutinho (PSB).Trata-se do secretario executivo de obras do PAC, e superintendente da Suplan Ricardo Barbosa. Amigo antigo do cla Cunha Lima, Ricardo deu mostras de que vai deixar a amizade com Cassio de lado, e seguir plantando seus projetos no jardim girassol. Diferente de outros cassistas, como o ex secretario de Estado de Planejamento e Gestao, Gustavo Nogueira, que entregou o cargo atendendo apelo do senador Cassio, Ricardo Barbosa preferiu permanecer no Palacio da Redencao.Deixando a briga politica de lado, ele segue normalmente trabalhando. Nesta quinta-feira, Ricardo Barbosa, explicou os motivos de supostos atrasos nas obras do estadio O Amigao, em Campina Grande. Segundo ele, tanto o Amigao quanto o Almeidao tem muitos problemas estruturais
graves, mas nos ultimos tres meses o andamento da obra esta acelerado, sendo que a parte de urbanizacao do local ja esta sendo concluida. O custo total da construcao sera em torno de R$ 30 milhoes, sendo a maior obra publica em volume de recursos de Campina Grande, conforme Ricardo, que ressaltou tambem que todas as ruas que dao acesso ao estadio serao pavimentadas.Voltando para a politica, Ricardo Barbosa, tem defendido a manutencao da politica de coalizao do senador Cassio Cunha Lima e o Ricardo Coutinho. Em recente entrevista a uma emissora de radio de Campina Grande, ele revelou que a Paraiba sairia perdendo com uma eventual candidatura de Cassio em 2014 ao Palacio da Redencao e com o fim da alianca com Ricardo Coutinho.Para Barbosa so uma coisa justificaria o fim dessa alianca, que seria o nao compromisso de promessas de campanha para com a populacao defendidas por Cassio e Ricardo em palanques.Para o pre-candidato a deputado estadual, um rompimento politico entre as liderancas politicas provocaria prejuizos para os dois. Ricardo Barbosa que ja foi secretario do governo de Cassio em tres pastas destacou ainda a boa relacao pessoal que possui com o senador Cassio Cunha Lima e disse nao haver sentido uma ruptura entre PSB e PSDB na Paraiba. Ricardo e filho da ex vereadora de Campina Grande Maria Lopes Barbosa, uma alada historica da familia Cunha Lima.Fonte: PBAgora
o ex-deputado federal Enivaldo Ribeiro, que vem mantendo uma serie de reunioes com liderancas da legenda para definicao de um nome, que represente a sigla, de forma consensual. De acordo com Enivaldo, o partido tem varios nomes credenciados dentre eles o do ministro das Cidades, Aguinaldo Ribeiro, da deputada Daniella Ribeiro, do presidente da Camara de Joao Pessoa, Durval Ferreira.Fonte: Correiro da Paraiba.
de deputado federal e estadual", completou o dirigente.Alvaro Neto, que foi vereador de Campina Grande, deputado estadual e federal, afirmou que ve com bons olhos o trabalho do governo junto aos municipios que precisam se desenvolver junto com o Estado. "Este e um governo que tem se preocupado com a estruturacao do Estado, se preocupado com as estradas como o anel do Cariri e a rodovia da Reintegracao. Isso e algo muito importante para um Estado que quer se desenvolver economicamente", completou.Fonte: Assessoria do PSB