Technical Curiosities:

The greatest technical issue was, without a doubt, the Smooth Scrolling. However, the one that really stressed me out - by means of "laborial", in fact - wasn't the Smooth Scrolling, but a non-technical, hence practical step instead: the preparation and assembly of the manuals.
This step was, certainly, the most stressfull and time consuming step of the entire work.

The hardware used to play music can be any of them. All Knightmare music from Konami Game Collection (where the SCC data came from) were composed to be played on normal SCC. If your sound board is a SCC+, the first thing the sound engine will do is configure it in "normal SCC" mode.

It may sound crazy, but making the SCC replayer and data to the existing Knightmare Gold was a lot of hardwork. Adriano Cunha had already isolated the replayer and data and relocated it to the 0000h~3FFFh region, but the original routines used as temporary variable data exaclty the same space I had used to place KMG's video routines.
The only solution was disassembly the entire SCC replayer and data structures and relocate all temporary tables and variables used by SCC replayer.
But the worst thing was finding space to place these tables and variables; Adriano Cunha had never told me the SCC replayer used so much memory to store state varibles. After a lot of research, I noticed the region F400h~FA00h could be used since I avoided some BIOS functions (not used by the game).

YES, the game now has Smooth Scrolling!! After trying 3 different ways to implement it, without any practical results, I managed to implement it by a 4th way, but only at 7MHz for now. This is due to the fact that the Smooth Scrolling needs a very precise synchrony for the screen split and, in the event of the screen redrawing, in computers working at 3.57Mhz, this synchrony is lost.
Nevertheless, some small glitches happen during the game running in Smooth Scroll, specially with the usage of the CD, but these are only small and quick blinks and there is nothing else that can be done, as they are related to CD-access time, which sometimes takes longer than needed.
There will still be some temptives to allow Smooth Scrolling in machines running at 3.57MHz, but there is no guarantee that the tricks I intend to use are going to work.

I always used to ask myself this same question and, when performing changes to the game I verified that my original thoughts were right. Konami uses a method in the dynamic construction of the attributes table of the enemies that, combined with a randonly table, changes which enemy is using which priority of sprite every moment. This way, whenever there are 4 sprites within the same line, we believe that they blink (as at each moment one different enemy is being "erased"). It's also important to say that most of the Z80 processing time in the original Knightmare was spent in this process.
Due to several technical reasons (specially: processing requirements), this rotation of sprites was removed from the MSX2 version. With luck, however, the game was designed to avoid more than 4 sprites at the same line...and in MSX2 we can have up to 8 sprites per line, which makes the sprite blinking a very ocasional event in MSX2 version.

The main character and its shots (almost) ever use sprites 0 to 7, i.e, the highest priority ones, and these are not subject to the rotation scheme. Thus, these sprites will never blink.

Konami has used a resource that if 5 sprites happen to be in the same line, the line related to the 5th sprinte onwards will not be shown on screen. This is the only moment during the game that the sprites of the main character are moved from the 0 - 7 position to 8 - 15. The sprites from 0 - 7 are put in the upper left corner of the screen, resulting in 4 or more sprites for all pixels above the door line...consequently, the character, that now is using the lowest priority slots, disapear from the moment it enters the same line as those.
This detail in special lead to a huge effort during the patch work, as it resulted in changing a great portion of pixels to allow putting sprites 0 - 15 in the upper left corner of the screen, as in MSX2 the 9th sprite (and not the 5th) is the one which disapears.

Não. Alguns inimigos de fim de fase são shapes misturados com sprites (fases 1, 5, 6, e 8), mas outros são totalmente compostos por sprites (fases 2, 3, 4 e 7). Os inimigos de sprites do Knightmare são alguns dos maiores que o MSX1 já viu, sendo alguns deles de até 9 sprites.
Alguns dos inimigos de sprites ganharam colorização totalmente nova na versão MSX2, possível através de um remapeamento das cores dos sprites utilizados nos mesmos.

Na versão original o personagem do Popolon usa para si 3 sprites, sendo o escudo um quarto. Se o sprite do escudo ficasse colado ao Popolon, teríamos quatro sprites na mesma linha o que faria com que todos os inimigos que entrassem na mesma linha que o herói sumisse. Desta forma, a Konami optou por distanciar o escudo de Popolon, eliminando o problema.
Na versão MSX2 não temos mais o problema dos quatro sprites, entretanto não existe mais o rotacionamento dos sprites. Desta forma, para evitar problemas de sumiço de sprites, optei por deixar o escudo ainda longe de Popolon.

Existem 2 armas programadas mas não disponíveis no jogo: elas são a flecha simples com dupla velocidade e a flecha dupla com velocidade simples. A razão da Konami optar por não ligar estar armas vem de um fato: a flecha simples com dupla velocidade e a flecha dupla com velocidade simples não representavam uma real vantagem sobre quaisquer das outras armas.

Sim, é verdade. Como muitos jogos da Konami, Knightmare tem uma proteção contra cópias, mesmo que banal. O mecanismo é que em alguns instantes na inicialização do jogo ele tenta sobreescrever regiões do código do próprio jogo. Se o jogo estiver rodando em uma ROM, nada acontece e o jogo funciona normalmente. Por outro lado, se ele estiver funcionando em RAM (tendo sido carregado da fita ou disco, por exemplo), a parte do jogo sobreescrita faz com que ele congele na tela azul, pouco antes de aparecer o logotipo da Konami. Nada que uns 3 ou 4 NOPs não resolvam. (^=

Ao observar o código da versão SCC do Knightmare, é possível sugerir que a Konami não mais tinha o código do Knightmare original quando fez a versão SCC do mesmo, embora isso não seja uma certeza.
O que nos leva a crer isso é o fato de a alteração do jogo para que as músicas sejam tocadas do SCC é muito semelhante áquelas alterações realizadas por terceiros, inserindo um "JumP" no meio de uma função e testando alguma coisa. Caso verdadeiro, desvia para uma nova função. Caso contrário, volta para a função antiga.
Outra característica deste tipo de "patch" é que, apesar de o jogo não usar as músicas PSG, os dados para que elas sejam tocadas a partir do PSG estão todos lá.

Curiosidades Não-Técnicas:

Bem, este nome apareceu por sugestão do amigo Felipe Bergo (Yopparai). A origem do nome é a lenda do Rei Midas, que havia sido amaldiçoado, de forma que tudo que ele tocava virava ouro. Como o carregador do jogo pega a ROM original e a tranforma na versão "gold" (ouro), o nome acabou encaixando como uma luva. (^=

Eu ouvi, como sempre, os mais diversos tipos de música, de Mozart a Testament, incluindo aí as músicas do próprio jogo (originais e Parn). Entretanto, confesso que Metallica foi a banda que mais tocou no meu CD Player durante o desenvolvimento, em especial o álbum St.Anger.

I normally don't eat while programming, but when I do have something it's usually sausage and provolone cheese.

Bohemia, of course! (*) (*) Bohemia is one of the most tradicional (and oldest) beers ever produced in Brazil.

Visitante #196150 desta página