Is it really impossible to retrieve any data from that crashed HD? Did it crash that badly? Too bad.

Telling us a bit about the scrolling technique in Core Dump would be a good on-topic question I guess.

Core dump has four effective layers (top to bottom):

1. Overlay (any fences, walls which sprites can move behind, etc)
2. Sprites
3. Background (the normal stuff that scrolls)
4. Static parallax layer

Layers 1 and 3 move at the same speed. Layer 4 doesn't move at all. Layer 2 is a collection of stuff that can go anywhere on the map.

There are a few key techniques:

- Hardly any 'weird' tricks are used. A bit of self-modifying code for faster table lookups, and VDP statusregister #2 is made the default (the interrupt handler switches to #0 to read, and sets it back to #2 at the end)

- The multiple camera views all shared the same static background (the deepest parallax layer): this *never* moves, and is printed relative to the screen, not to the camera window, which is a hack to make it work.

- All block sets are scanned and each block is given a status flag: fully transparent/partially transparent/no transparent pixel. This is hugely important for the efficiency.

- The topmost layer (which goes over the software sprites) is duplicated in the background layer. Hmmm, how to explain this. Well, it means that if there are no sprites on top of the background, there is no need to additionally print the topmost layer: this is needed only after a sprite is printed there.

When updating the screen on the alternate page, the code starts by printing any sprites and then afterwards completes the rest of the background.

(part 2):

Thus, in sequence: given that each swap page has its own buffer that says which block was where on the last go:

1. Print all sprites.
2. Print any needed overlay blocks (topmost layer)
3. Print any remaining blocks that have changed (high-speed copies)

Step 1:
When printing a sprite block, the status flags come in:
If the topmost layer has no transparent pixels, the sprite block will never be visible, so it is simply skipped.
If the sprite block has no transparent pixels, the background beneath it can never be visible, so we use a high speed copy.
If the sprite block has transparent pixels, but is not fully transparent, we first print the background (using the same code as in step [3]), and then using a logical copy overlay the sprite, and mark the buffer with 'sprite'. This will cause step [2] to print any overlay stuff later, if needed.

Step 2:
Fairly simple. Wherever we printed a sprite block we now logical copy any overlay stuff on top, if it is partially transparent.

Step 3:
When printing a background block, we again split cases. If the block was already there (according to the buffer) or is fully transparent, we skip it. If it is partially transparent, we print the bottom (static) parallax layer using a high-speed copy, and logical copy the background on to it. If it has no transparent pixels, we high-speed copy the block.
The buffer is updated to reflect the current contents.

Roughly, this optimizes the printing significantly: it decreases the number of copies significantly, and uses the 'right' (logical/high-speed) one whereever possible.

(part 3):

Because the buffer is relative to the screen, as is the static lowest layer, having more cameras introduces very little overhead. Of course it takes some administration, but this is fairly small in computing terms.

It also means, that if the screen does not scroll, only the sprites are re-printed for blocks where they are visible: having more stuff in the topmost layer often speeds up the scroll! Also, the static background does not need to be re-printed unless something moves over it, so having 'open' areas with much depth allows for bigger sprites.

Hey Cas! Nice to see you here indeed!
It was nice meeting you at the ICT Kenniscongres back in 2002 (If it was 2002 indeed...)

What are you doing nowadays? I guess you finished your PhD in the mean time.

(Hi! I'm writing my thesis as we speak.)

(ah, cool! Oh, by the way, maybe your vast amount of knowledge could come in handy on some of the other technical/programming topics that can be found somewhere in this Development forum!)

Well, erm, I browsed through them and indeed, most of them seem to have been answered already.

Hey how are you cas?
I heard much about you, even back in the old days (Im from Geleen)
Im a newby, and started develloping Spacemanbow 2 about 1.5 years ago.
I was wondering how you programmed your games back then.

What assembler, what tools, cross assembling???
Did you work in a team, who designed grapx etc. (I heard Pat from DP even helped you out graphwise, thats cewl !!)

Anyway, it seems that people here in holland think you're a legend or sometin,

well to be honest, not much dutch people back then created really impressive games for the msx!!!
I saw a bit of coredump and blade lords, and another game you made....

Yes, looks really cool !!

Norakomi: Thanks for the kind words. Much information and team info can also be found at parallax.shape9.nl/ , especially in the programmer's diary.

But for a brief answer: for the first game (Vectron) I only used a hex editor, and no assembler. After that I used wbasm for a bit and later gen80. No cross assembling, as I only had my NMS 8250 and no other computer. We used DD-graph. Other tools were simply developed in-house (music/sfx editors, map editors, erm anything really)

Team: me & pat. We both did gfx & music, and I did whatever else was needed. And put in many hours

Ey Cas, by the way, any idea why your Parallax logo animation (from Blade Lords, e.g.) is messed up in openMSX?

As was already said earlier in this topic, nowadays there are a lot of crossdev tools that can make MSX development much easier or more efficient at least. openMSX (of which I'm one of the codevelopers) is meant to be one of these tools.

Dunnoh about the logo, it works on my real MSX, so you should ask the openMSX people! Ow, that's you then
In reality, I have a hard time remembering how that was done. I mean, it was supposed to be nothing too special, just a simple trick. Hmmm. I forgot

cool,

Hey, another question. Could you tell me a bit about the feeling you have this day (being here, typing these words, being nostalgic etc..)

Erm... well nostalgic sort of sums it up.

It was a nice time. New stuff has come along and I am also very glad I moved on, otherwise I would've felt stuck. Being here for now is nice, maybe shift some knowledge before I really forget it.

Eh yeah, the next question was: what does it do, that trick? Probably it's just very tightly timed, which means openMSX is a bit off timing, which we know already...