Ancient knowledge for free! (sort of)

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

By parallax

Expert (70)

parallax's picture

27-03-2006, 12:09

Oh dear, that would officially make me a dinosaur, wouldn't it ? Wink

By BiFi

Enlighted (4348)

BiFi's picture

27-03-2006, 12:11

Not Cas Crutches already? Wink

By parallax

Expert (70)

parallax's picture

27-03-2006, 12:15

Nah. But if you're right Wolf, then surely you don't need my help in completing Core Dump...

By wolf_

Ambassador_ (9767)

wolf_'s picture

27-03-2006, 12:24

Well I'm not an MSX-coder, so I'm not the right one to ask, I only do music & gfx (and xdev tools like gfx-editors/map-editors, basically anything related to 'art'). Tongue

Apart from that, you stated that the CD sources were old etc. so completing all that would be tedious. Also, coders typically would start such a thing from scratch Tongue
I bet the CD project is dead and burried then. It doesn't mean no-one else should/can make a game like CD, but it would prolly start from scratch.
The major problem in the current scene is the lack of gfx-artists and iirc CD was quite advanced in that department. I could imagine some coders here being able to code CD, but without gfx it would not really 'be' CD.

By Thom

Hero (576)

Thom's picture

27-03-2006, 12:50

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.

By parallax

Expert (70)

parallax's picture

27-03-2006, 12:58

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.

By parallax

Expert (70)

parallax's picture

27-03-2006, 13:18

(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.

By parallax

Expert (70)

parallax's picture

27-03-2006, 13:22

(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.

By Manuel

Ascended (15686)

Manuel's picture

27-03-2006, 13:31

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

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

By parallax

Expert (70)

parallax's picture

27-03-2006, 13:36

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

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