Quote:

Yes, only if the entire screen is static, which for games it never is. Background scroll, foreground scroll and nonsprite objects moving leaves you in the cold quickly Nor would there be any visible changes for a timespan of 16 frames.

I could be wrong but I believe that for old beat em up games (at least the home versions) most of the backgrounds are static images. Sure, some of them use parallax too or a one colour special cloud effect. I am not sure how good a flipping screen with a white cloud would look on Screen 5, does anyone know if a "light and shadow" effect would turn to be a good thing on MSX2 home computers !?

i really would like a shooter in the vain of HYDEFOS.
(the best msx2 game for me)

To bad that I only got one disk of HYDEFOS, but there was a nice poster of PSYCHO WORLD with it ...

hydefos is trully psycho hardcore. 3 finals and tons of secrets.... =\
never reached more thant 88% in stage 2 or the third final.

a great horizontal shooter.

What strikes me the most, is the great BGM in the first stage. I really love that piece of music

Quote:

What strikes me the most, is the great BGM in the first stage. I really love that piece of music

Yeah, me too.
http://www.msx.org/modules.php?op=modload&name=Downloads&file=index&req=visit&lid=876

Quote:

hydefos is trully psycho hardcore. 3 finals and tons of secrets.... =\

Please tell me how to get a different ending.

Must have finished the game over 10 times, but always got the same one.
Judging from the BGM test there should at least be a wedding?
Is this correct?

About VDP command speed: this page has detailed information about the VDP command speeds in various circumstances (sprites on/off, screen height)

Quote:

The nice thing about coloursplits is that you hardly notice them if they're done in the right way so indeed I probably missed them if they are so common. Can you give some examples of where they're used?

Bombaman uses colorsplits in the titlescreen, don't know any other game which uses a colorsplit in the titlescreen.

IIRC, (the promo of) the "Incredible Micro Mirror Men" by NOP also used color splits. In the game itself.

I added the "differential" rendering to the TP engine and there are quite a lot of savings...
http://totalparodyrebirth.googlecode.com/files/TPengine.rar

The non black area in borders is the one used in code execution and in waiting for VDP command execution.
The black area is spare time.

Interesting; when I looked at the original TP demo last week I guessed it wouldn't as much benefit from differential copying as the patterns aren't distinctly 32-px repetitive. How large (in %) is the saving with this version? Obviously when keeping this in mind in level design the savings could be far greater.

Your demo (which already looked very good BTW) also shows that parallax is not really an option. With an X-px difference only effective every pageswap (16px I assume) it looks more like a copying glitch than an intended effect. I guess parallax scrolling can only be done in pattern-based modes.

Another interesting question: when only precalculated copies are stored to build up the levels when scrolling, how does this compare memory-wise to the original way of storing the levelmap? (But I guess this depends heavily on whether scrolling is fixed or flexible according to the user's movements, and if the player can also move backwards.)

Quote:

Interesting; when I looked at the original TP demo last week I guessed it wouldn't as much benefit from differential copying as the patterns aren't distinctly 32-px repetitive. How large (in %) is the saving with this version? Obviously when keeping this in mind in level design the savings could be far greater.

Well the saving is large. Consider that now I copy a column each frame. Column 0 due to the border cannot take advantage of the differential coping (its rendering corresponds to the longest blue flash). To have an idea of the saving compare the length of the longest blue flash with the average length of the blue border.

Quote:

Your demo (which already looked very good BTW) also shows that parallax is not really an option. With an X-px difference only effective every pageswap (16px I assume) it looks more like a copying glitch than an intended effect. I guess parallax scrolling can only be done in pattern-based modes.

I would not be so negative. Maybe rather than a sky (that being far should have a sensible parallax speed) it could be used for the back of a cavern or of a forest. In this case a low parallax speed is OK.
The real problems are two:
1) the background tiles cannot take advantage from the differential drawing (as they change at each step)
2) two pass blocks: they have to be copied as background (High speed) and and foreground (Low speed). The number of two pass blocks per columns is very limited and they cannot take advantage from the differential drawing.

Quote:

Another interesting question: when only precalculated copies are stored to build up the levels when scrolling, how does this compare memory-wise to the original way of storing the levelmap? (But I guess this depends heavily on whether scrolling is fixed or flexible according to the user's movements, and if the player can also move backwards.)

As now the screen is build per column I do not store precalculated commands.
Actually precalculating could be interesting for load balance...
If, thanks to differential rendering, I gain some time in a frame, now that time goes lost even if I know that the successive frame will be critical...
I'll think about it. The advantage of C is flexibility. (Yes this TP rebirth is in C for HTC v7.8) ;-)

Something about IE0 and IE1 bits is not clear to me...
Any expert here ?

yukio: please send me HQ scans of your hydefos box and manual. i'll try to translate it.

DemonSeed: i'm trying too. but in this weekend, i'll try it again.

if you are interested to talk about...

magicspellbr AT hotmail PT com

Hrothgar

I'm exploring you idea about pre-computing the data to feed the VDP for screen drawing....

I tried to compute at each scroll position the command to build the next frame, in order to balance the number of copies
among the 16 steps in witch the screen is build.

The problem is that the best code I can do takes one frame or more to compute the data of the next page.

void   scanpage (uchar * window, tileinfo todo[])
{
  if    (currpage) 
    buff = shadow1;
  else
    buff = shadow0;

  p = todo+1;

  for (i=14;i>0;i--)
  {
    wy = window+i;
    if (i)
        for (j=0;j>11;j++)
        {
          if  ((*wy)!=(*buff))
          {
            *buff = *wy;
            p->s = *wy;
            p->d = j*16+i;
            p++;
          }
          buff++;
          wy += map_w;
        }
    else
      for (j=0;j>11;j++)
      {
        p->s = *wy;
        p->d = j*16+i;
        p++;
        wy += map_w;
      }
  }

  n_item = p - todo;
  
  fairld = n_item/16 + 1;

  p->s = n_item;
  p->d = fairld;
}

Another possibility is computing off-line the data for any scroll position.
It takes too much memory.

If a command can be driven by just two bytes, (source tile destination square), a page takes up to 15x12 commands, as 15x11 if you want room for scorebar.

if a page is 15x11x2 bytes assuming a room large 64x16 = 1024 pixels we need 64-15 = 49 scroll positions the total room in RAM is 49*15*11*2 = 16K !!

This for one direction!
The other direction needs other 16K