Knightmare Gold

Page 6/8
1 | 2 | 3 | 4 | 5 | | 7 | 8

By Sonic_aka_T

Enlighted (4130)

Sonic_aka_T's picture

06-10-2005, 16:13

If I remember correctly, the only modes R#23 doesn't work on are the text modes.It does work, it just doesn't do what you'd expect! Tongue

By marison

Expert (104)

marison's picture

06-10-2005, 16:22

@ BiFi.

Second the information in portugues in the Knightmare Gold site, the 7MHz was neccessary for changing the sprite Y coordinates accordingly to the R#23 value and to maintain the screensplit stable.

I could translate some of the texts below to you understand better.

Quote, from the Knightmare Gold Site http://www.caetano.eng.br/MSXPage/KMG/?p=4&l=br:

Os maiores problemas ficam por conta do V99x8 fazer scroll dos sprites ao mesmo tempo que a tela, e também pelo fato de ele manter a posição de "desligamento" dos sprites fixa na mesma linha, mesmo que ela esteja bem no meio da tela, devido ao scroll vertical.
Estes fatos, somados ao fato de a estrutura interna do jogo não ajudar nem um pouco a implementação (o jogo atualiza posição de sprites nos mais diversos lugares e, mesmo usando delay na plotagem dos sprites, para que eles possam ser impressos no vblank, não há como escapar (totalmente) dos solavancos, já que a plotagem de todos os sprites é mais demorada que o tempo de vblank) fizeram com que a implementação do scroll fino, em princípio, não seja um característica prioritária.
PS: Tudo isso foi feito em micros com 7MHz. Em micros com 3.57MHz o scroll fino é impossível, ao menos usando sprites multicoloridos, pois não está sobrando tempo de CPU suficiente para manter o screen split estável em 3.57Mhz.
PS2: Mesmo em micros com 7MHz existem alguns glitches ao serem utilizados scroll fino simultaneamente com o CD Áudio.

By ro

Guardian (4125)

ro's picture

06-10-2005, 16:52

@ BiFi.
Second the information in portugues in the Knightmare Gold site, the 7MHz was neccessary for changing the sprite Y coordinates accordingly to the R#23 value and to maintain the screensplit stable.

Only for that?!?! wtf!

By wolf_

Ambassador_ (9778)

wolf_'s picture

06-10-2005, 17:05

Space Manbow changes all X and Y sprite-coords in sc4 while scrolling, on 3.58mhz ..

By Sonic_aka_T

Enlighted (4130)

Sonic_aka_T's picture

06-10-2005, 17:14

Don't be so negative/critical people. Try to applaud the effort instead... Smile

By BiFi

Enlighted (4348)

BiFi's picture

06-10-2005, 17:14

pitpan, R#23 does work in SCREEN 4... the only mode it behaves differently is SCREEN 0 (either WIDTH40 or WIDTH80 mode).

@ BiFi.

Second the information in portugues in the Knightmare Gold site, the 7MHz was neccessary for changing the sprite Y coordinates accordingly to the R#23 value and to maintain the screensplit stable.

I could translate some of the texts below to you understand better.Honestly, for some reason I still won't understand even if you would translate it. I still think it's no reason to require 7 MHz just for that. IMHO it only shows bad coding somewhere... and an audio CD track really wouldn't affect it at all, or I must be missing something...

Don't be so negative/critical people. Try to applaud the effort instead... SmileDon't get me wrong here... I can't wait to see (or even have) it. I just can't understand why a smoothscroll in 7 MHz while others have done the same (if not more) in 3.58 MHz.

By Fudeba

Expert (113)

Fudeba's picture

06-10-2005, 18:54

Hey, Guys... calm down. You start to blame things withtout propper knowledge of what are you talking about. Tongue
First of all, there is about 8KB of extended routines (data compressed, originaly it was almost 16KB), plus data that is placed on VRAM (about 34KB, uncompressed).
The amount of changes needed for add smooth scroll in Knightmare is simple enormous. The game is *very* optimized and uses every drop of your 3.57MHz to be just like it is on MSX1. To made it an MSX2 it was needed, in first place, cope with the bigger amount of data to be transfered to VRAM. Attibute + Color table on MSX1 / Sprites mode 1 are just 128 bytes (4*32). On MSX2 it is a bit larger: 640 bytes (4*32 plus 16*32). It's "just" 5 five times the size which made a "simple change" to become a nightmare. There was *no* processor time to do it at 3.57Mhz.
The solution was make deeper changes on the graphics code. Since the game was developed to avoid 4 sprites in the same line, I tried to disable the "scrambler" routine, which placed each sprite in a different priority every interrupt (more on that later). This proved to be a wise solution, since the sprites did not flick or disappear anymore (8 sprites per line are much better than 4 sprites per line)... and this change provided me several Z80 machine cicles to work.
But even this way, when many sprites were on the screen, there was slow down... but since now an character sprites was always at the same place on the VRAM (its color data only changed when the character was destroyed), I could add a color cache for the sprites. This proved to be nice, and the game stopped to slowdown when many enemies ware on the screen. But I had spent almost every bit of free cicles per interrupt doing it (yes, everything is optimized).
When I started to think about smooth scroll, the first thing to do was create the screen split. This consumed even more cycles on interrupt, because now I had to test line interrupts, update screen position counters and etc, etc, etc. I tried to optimized as much as possible (the code is even changes itself to speed up things), but those things ate my last Z80 cycle available at 3.57MHz.
Well, then I started to work in the smooth scroll itself. The idea was change things so I could scroll the entire screen (256 lines) and only draw the new lines, like games developed for smooth scroll should work... which would give me some mode Z80 cycles to work with. Well, after some weeks of hardwork, finding everyplace where VRAM addresses were referenced and changing everything (because at that time I had 4 tables for colors, patterns and names) the result was simply... jerky. Many problems appeared because when you scroll the screen, the VDP keep the "disable sprites" at lines D0 and D8, which brought me a terrible headache: I had to TEST the sprite position of each sprite moved, and make little changes in the position to avoid those positions (which made, sometimes, all sprites disappear from the screen... very annoying). Games developed for vertical smooth scroll use special preparation to "delete" sprite lines when need to plot on those positions, so the sprite is plotted one position below and the move is not perceived by the player (Aleste does that). But on Knightmare this is not done, nor I had space for more sprites to use, space to place them in the RAM, VRAM bus to use... so I had to create another solution.
The new solution was add a 8 pixel mask in the top of screen, and only scroll up to 8 pixels, and keep fast updates of sprites so they do not "jump" in the screen when the "back scroll" is made. But now I had to use framebuffer approach and redraw the entire screen (like Space Manbow does, as far as I know). After some more months working, it was almost done. The framebuffer (including the crazy verifications so the "modifiable blocks", like the "?" ones, could be plotted in the correct position... in the actual screen or framebuffer), the screen split was ok... but I was not able to make the "enemy" sprites not to jump. This was very difficult to correct, because the game update the sprites positions in several different places in the game... and the enemies are updated using a table in the RAM, which is sent to VRAM at once (the usual procedure on good games). But the problem was Knightmare doesn't sync this update with the screen update (the update of attribute table on VRAM should happen on VBlank)... I tried to move it to VBlank, but no luck: I had no spare cycles to do it, the game simple became choppy. That time I decided the game would not have smooth scroll and gave up for 2 or 3 months, working on several other things (including the Graphical Menu, some of the manual/box graphics, etc).
Well, even if I had decided to not include smooth scroll on final release, I felt I should try once more. At least to show something and say: "Look people, I tried." But the fact is: I reprogrammed everything, using a new trick, based on some of the game variables, and the enemies started to be scroll as expected...
After I could make the sprites/background scroll in sync, I started to work on other "problems", moving the clocks to the scoreboard (there is no way to keep themn on the screen when using smooth scroll in a tiled mode), correct some glitches in odd situations, adjust the background to push Popolon smoothly with the background, etc, etc, etc.
When I finished (and lots of mods are simply not commented here, I could write a book about Knightmare Gold, but I have no time and believe most people are simply not interested), I noticed one sad thing: the game of course works in 3.57Mhz when using smooth scroll... but there are several problems: 1) It is shoppy. 2) The screen split become unstable, because there are not enough cycles to the game run between interrupts... (mainly when many enemies are on the screen). And worst of all 3) The game simply freezes sometimes.
I'm not happy and I'm trying to optimize several routines for speed (now I know how much space I can use for these optimizations) and trying to make it work on 5MHz (MSX2+ Panasonic computers) too, but I belive it'll be a miracle if I can make it work on 3.57MHz machines.
And... even at 7Mhz, when playing with CD music there are minor glitches with smooth scroll. This is caused because CD routines must verify when a music was finished to start it again and to accomplish this, the game has to exchange atapi packets with CDROM... and sometimes the IDE/CDROM is just too slow... and at these times the screen blinks. Since the problem happens a lot less than a few times per game and the "blank" time is just *one* interrupt (1/60s), it's not annoying... this is why I decided to make smooth scroll + CD default on 7MHz computers (but the user can disable it, if he wants to).
I'll try to use a trick to avoid this problem: with musics longer than the stage time, the verification can be disabled most of time, being enabled only on final bosses, where the CPU is less loaded. I don't know if it will work, but I'll try for sure.
Everything in this text was written to explain to you... that no, it's not only a change on a VDP register. And to colorize sprites it is not just a matter of screen capture and color them in Photoshop. There are *lots* of problems. Also, there is a big difference between "design a game to use smooth scroll" (like Space Manbow) and "adapt a game which *was not* designed to use smooth scroll" so smooth scroll can be used. All in all, most of smooth scroll of Space Manbow is horizontal, where problems like D0/D8 line positions do not happen. And the vertical smooth scroll on Space Manbow is, when it happens, somewhat choppy in 3.57Mhz (IMHO). Also, the design of Space Manbow Screen allows it to use only one line of split screen (of course, it was designed to use smooth scroll, even when using set adjust). Because of the way the screen was designed on Knightmare, I had to create two split lines. The alternative was modify even more the screen layout, which I did not wanted to.
I hope you understand it was never was my intention to make it need 7MHz computers (or 5MHz computers, if I find some more things to speed up) and I'm always doing my best in lowering the system requirements of my softwares. Smile

My kindest regards,
Daniel Caetano
Amusement Factory

By Konamito

Paragon (1028)

Konamito's picture

06-10-2005, 19:43

Keep the your big effort man!!!

It´s worthy!!!

By Manuel

Ascended (15839)

Manuel's picture

06-10-2005, 21:23

Daniel, keep up the great work! Smile

And please try to support Novaxis SCSI CD-ROM Smile

By BiFi

Enlighted (4348)

BiFi's picture

06-10-2005, 21:36

or manuel move to sunrise ide Wink

Page 6/8
1 | 2 | 3 | 4 | 5 | | 7 | 8