carregando...

Semana passada eu descobri que a SDL foi portada para o Nintendo DS, então eu pensei que seria legal portar o Rockbot para ele - eu adoraria recriar o Rockman 0 e 10 para jogar no meu DS já que a Capcom decidiu não portá-lo. Na verdade, a primeira razão para eu decidir criar todo o projeto Rockbot foi por estar brabo com a Capcom que decidiu não portar um jogo que parece de NES para plataformas antigas como o Playstation, e eu não tenho dinheiro ou desejo de comprar um console de nova geração.
Mas bem, uma vez assentada a idéia, eu tinha que construir todo o SDK do DS e as bibliotecas SDL, o que se mostrou um desafio, porque a SDL foi baseada em uma evrsão antiga do kit de desenvolvimento e tive que corrigir alguns bugs antes de ter um ambiente funcional para compilar alguns testes. Uma vez terminado, eu teria que diminuir o uso de memória de 46MB para menos de 4MB, que é o limite do Nintedno DS.

Aí vem a parte divertida, a maioria dos programadores de hoje são simplesmente preguiçosos de otimizar o código e usam o quanto de memória conseguirem, e frequentemente as pessoas acham que os jogos mais legais são os que as obrigam a comprar um computador inteiro novo, então podem ter um PC super modificado com luzes de laser interno e resfriamento a água e outras tolices frescas. Felizmente, os videogames não estão infestados por essa moda de atualizações frequentes. Então, a primeira coisa a fazer é usar variáveis menores, já que estou lidando com valores abaixo de 64 mil, todos os inteiros foram convertidos para short. O próximo passo foi limitar o uso de cores a 256, usando paleta web-safe, o que no fim das contas é legal, por parecer mais com os jogos antigos de NES. Finalmente, não dá para carregar toda uma fase na memória de uma vez, pois é isso o que mais usa memória, já que o núcleo em sí é bem pequeno. Então, eu reduzi o tamanho do mapa, e agora o jogo usa cerca de 5.1MB de RAM!

Mas nós precisamos de mais, por isso eu planjeo usar os mesmos truques que jogos de NES antigos usavam: quebranco a fase em partes. Lembram-se como era lenta a transição de tela quando você estava em uma escadaria, ou alguns jogos tinham uma sala de chefe no meio? A razão é que, neste momento, vocês está liberando um mapa e carregando outro. Assim, acredito que será possível reduzir o uso de memória para 3MB.

O passo seguinte é aprender a editor os makefiles dos exemplos de SDL para DS para recompilar o Rockbot para o Nintendo DS e testar. Mas como o fim de ano está próximo, por enquanto planejo trabalhar em gráficos.

Outras notícias:
- você pode sair da introdução pressionanto start
- começado trabalho em um teileset para montar um cenário
- feito um build teste para PS2, funciona bem, mas ainda tem problemas com delay/waiters.
- O PS2 precisa de ajustes para carregar os drivers necessários de acordo com a unidade de onde o programa está rodando, e também setar o FILEPATH com ela
- precisa ser refeito o sistema de tempo para frame de animação- por alguma razão eu perdi parte do código
- devemos implementar escadarias e "teleporte" de um mapa para outro
- implementar som usando SDL_mixer e doomsdl_mixer (PS2)

loading...

Last week I found that SDL was ported to Nintendo DS, so I tought that it would be a great thing to port Rockbot to it - I would love to recreate Rockman 9 and 10 to play on my DS once Capcom do not port it. Actually, the first reason I decided to create the whole Rockbot project was because I was angry Capcom did not wanted to port a game that is NES like to old platforms such as Playstation 2 and I do not have money, nor desire, to buy a new generation console.
But well, once settled the idea, I had to build all the DS SDK and SDL libraries, that showed to be a chalenge, because the SDL port was to an old version of the devkit and I had to fix some bugs before having an working dev enviroenment to build some tests. Once it was done, phase two started, I have to diminish memory usage from 46 MB to less than 4MB, that is Nintendo DS limit.

Now comes the fun part, most programmers today are just lazy to optimize code and take as much memory as he can get, and often people find that the good games are the ones that need a complete upgrade on your system, so you can have and ultra modded PC with internal lazer lights, water cooling and other pimp foolishes. Gladly videogames are not plagued by this upgrade-often fashionism. So, first thing is to use smaller variables, as I'm dealing with values under 64k, all integers were converted to short. Next step is to limit color usage to 256 colors, using web-safe palette, that is nice because looks more like old NES 8 bits style. Finally, we can't load the whole stage in memory, because it is the thing that uses more space, as the program core footset by itself is very small. So, I've lowered the size of the map, and now the game uses only just around 5.1 MB in RAM!
But we need more, so I plan to use the same tricks old NES games used: breacking the stage in parts. Remember how slow was the scrolling when you changed screens on a starircase? Always wondered why some games had a middle-boss room? This is why, in that moment, you just freed one map, and loaded a new one. So, I believe soon, we'll be able to reduce the memory usage to 3MB.

Next step is learn how to edit the makefiles from SDL+DS examples to compile Rockbot to Nintendo DS and test. But as holidays are near, for now I've work on intro and graphics.

In other news:
- you can skip intro by pressing enter
- started to work on a tileset to build a scenary
- made a build to test PS2, works OK but still have bugs with delay/waiters
- PS2 needs adjustments to load necessary drivers according to the unity is is running from, also, set the FILEPATH with it.
- needs to re-work the animation frame delay - for some reason I've lost part of code
- must implement staircase and map "teleport" to another map
- implement sound using SDL_mixer and doomsdl_mixer (PS2)

Editor Update

Iniciei o trabalho na ferramenta de edição de NPC. Ela será mais complexa no futuro, já que o usuário terá que adicionar cada frame gráfico, mas atualmente é bastante fácil pois não possui suporte a animação de NPCs.

Started to work on the NPC editing tool. It will be kind of complex in the future, as the user will have to add each frame, but currently it is fair simple as it does not support animation for NPCs.

[editing a NPC]

Editando

Durante o fim de semana, foram feitos os últimos retoques no editor básico, que já conta com boa parte das funcionalidades do editor antigo e no motor do jogo para suportar o novo formato de mapas.

Uma desvantagem do novo formato, é ao contrário de idéia inicial de termos um arquivo por mapa, que decidimos por ter um número fixo de estágios e tamanho de mapas unificado em um único arquivo, para simplificar a programação do sistema. O problema reside exatamente no tamanho, um arquivo de jogo possui 34 Mega bytes, o que não é exatamente um problema hoje em dia, mas ainda desejamos diminuir, se possível, este valor, usando compressão via zlib ou outras alternativas.

O que está faltando são ferramentas como desenhar uma linha ou fazer preenchimento com um tile, para o usuário não cansar de clicar o botão do mouse. Além disso temos que começar a organizar e implementar suporte a objetos mais complexos como NPCs, objetos móveis (implementando um segundo nível de tiles) e outras características para poder finalmente produzir um pequeno jogo na versão 1.0.

Editing

During the last weekend, some retouchs were made into the basic editor tool, that already have a good part of the functionalities from the old editor, and in the game engine to support the new maps format.

One disavantage of the new format is that, contrary to the initial idea of have one file for each map, that we decided to have a fixed number of stages and unified map size in just one file, to make the system programming simpler. The problem is that the size of the file containing the game is now 32 mega bytes, that is not a big problem nowadays, but we still want to lower this value, if possible, using compression with zlib or by using some other alternative.

What is missing are tools like drawing a line or filling with a tile, so the user does not get tired of clicking the mouse button. Besides that, we have to start to organize and implement support to more complex objects like NPCs, movable objects (implementing a second tile level) and other characteristics in order to be able to, at last, create a small game on version 1.0.

Editor Update

Uma figura vale mais que mil palavras.
A picture is worth more than a thousand words.

Editor

I finally learned what I needed to use Qt Creator + Qt Developer to create the editor UI in a easy way, so the plan to drop the Qt editor in favor of the SDL one is no-more. This weekend I plan to have an editor with the same functionalities of the SDL one, and then start improving until it is simular to the one in RPG Maker XP.

Eu finalmente aprendi o que precisava para usar o Qt Creator com o Qt Developer para criar a UI do editor de forma fácil, então o plano de abandonar o editor em Qt em favor do em SDL deixou de existir. Este fim de semana, espero deixar o editor em Qt par a par com o atual, em SDL, e daí em diante incrementá-lo até ficar semelhante ao existente no RPG  Maker XP.

Pixels

I am no good ate creating pixel art, but slowly we get there:
Eu não sou muito bom em criar arte em pixels, mas devagar chego lá:

[Ape Bot and Seahorse Bot]

In other news, I'm rethinking the editor plans. Ideally it should be written in C++ with Qt to be like a normal Desktop app, but more and more I'm kind of thunking the task ahead is too big to fit our needs. So I'm back to think about developing the editor also using SDL as it is simpler and keeps the dependencies low for the whole project. We lose some ease of use, but gain in not loosing time with something that is not the focus of the first release.

Em outro tópico, eu estou repensando os planos para o editor. Idealmente ele deveria ser escrito em C++ com Qt para parecer um programa desktop normal, mas estou pensando cada vez mais que a tarefa pela frente é muito grande para caber em nossas necessidades. Então, volto a pensar em desenvolver também o editor em SDL, já que é mais simples e mantém as dependências do projeto como um todo, baixas. Perderemos alguma facilidade de uso, mas ganhamos em não perder tempo com algo que não é o foco do primeiro lançamento.