Data Compaction

[JIM]

Has anybody got any thoughts on mode 2 sprite data compaction?
Arcade adventure screen block data compaction?
One method I have used is just splitting a byte into two nibbles which allows you to have two different screen blocks between 0 and 15 per byte.

[regregex]

I can't say much about sprite and map compression, if your sprites are in MODE 2 and don't have flashing colours in then they can be compacted by 25% and unpacked without much time penalty. There was a program in The Micro User (July 1985, p.102) but this compressed whole screens.

Text adventures tend to use VDU sequences to draw vector graphics, possibly with a little dictionary compression thrown in.

HTH

--Greg

[garfield]

I prefer to keep my sprites as uncompressed as possible, since the overhead of decoding softward sprites can really make things sluggish on the Beeb (no hardware sprite capability, unfortunately). It's inevitably a compromise between space and time.


(Straying off-topic a wee bit: QWAK! has really fast and flicker-free sprites. Nice game too.)

[sorvad]

Arcade adventure screen block data compaction?
One method I have used is just splitting a byte into two nibbles which allows you to have two different screen blocks between 0 and 15 per byte.

Yes, that's the most popular. I've also used that method, on a Mode 2 screen if you're sprite blocks were 16 pixels square it'd only take 128 bytes to represent the entire screen map for any one screen. Then for each screen you can also have a lookup table of which sprites are represented by which value (0-15), so you can easily have more than 16 different graphics between screens.

However that's probably not going to be enough, 30 screens would eat up 3840 bytes and in MODE 2 that's a lot of memory eaten up. So you need an overall compression on top of the normal compression. Which is easily done really by giving each screen an ID, lets say between 0 and 255.

You can then define a overall game map, say 16 x 16 screens in size (256 MODE 2 screens, which is a fair size game map) , which would only take 256 bytes to store. When your displaying say location 3, you look up which screen it is in the game map (say ID 7), then read the 128 bytes of data for that screen at it's location and show the screen. This way you've got a game map of 256 screens for about 4K. It works if you design your game map well, you could have corridors which pretty much all look the same but to the player will make the games seem huge. There's other screens that can also look the same without the player realising it. And you could have special objects that you pick up etc. in different locations not in the normal screen map which leads to greater variety at little memory cost.

[sorvad]

Has anybody got any thoughts on mode 2 sprite data compaction?

Well not compaction as such, but one of my sprite routines used to be able to plot a sprite as either in it's default design or mirrored horizontally or vertically, this gave 4 graphics for every 1. The sprite routine would have been slightly slower but IIRC it wasn't much slower at all. Mostly because the plot routine was quite a bit bigger than it would have been for a normal sprite routine (with optimised bits depending upon orientation) but you saved much more memory than you lost.

[PeterScott]

A sneaky way to increase the number of screens is to have another lookup table with a byte per screen, with a 0-255 number in it. You can then, say, repeat screen 5 (lunar surface) or screen 243 (corridor) as many times as you want. You might see that in my games heheh...

Or if you've got 128 screens, you can use the extra bit in each byte to flag up a change in each screen - ie colour / draw it upside down / different background etc.

The secret is tables to look up tables to look up tables. As long as the data is organised efficiently it won't take too long. In some of my games the screens averaged a hundred bytes or so, despite being complex and varied.

[sorvad]

Heh heh, looks we're both describing the same thing there although you more eloquently

[timmy]

You can then define a overall game map, say 16 x 16 screens in size (256 MODE 2 screens, which is a fair size game map) , *snip*

Is this what Sabre Wulf & Star Drifter and game like that do...? I've often wondered.

[JIM]

Recently i have visually been comparing Citadel and Palace of Magic, I think Citadel is far superior with how much more they crammed in. Any thoughts on the teqniques used in this game ?. The rooms are allot less blocky than in most games of this type. The only game which comes near is Quest.
(Disregarding Exile of course)

[retro_junkie]

(Straying off-topic a wee bit: QWAK! has really fast and flicker-free sprites. Nice game too.)

Yes it is amazing really - hard to believe it's running on an Elk. Just shows what was possible. It would probably be worth contacting the author Jamie Woodhouse - he is proud of Qwak and as well as the 90s Amiga version (the first I saw), he just this year released a new GBA version.

http://www.jamiewoodhouse.co.uk/pages/BBC/Qwak/qwak.htm

http://www.qwak.co.uk/

[sorvad]

You can then define a overall game map, say 16 x 16 screens in size (256 MODE 2 screens, which is a fair size game map) , *snip*

Is this what Sabre Wulf & Star Drifter and game like that do...? I've often wondered.

Probably, although I've never played these games, so would have to have a look.

[sorvad]

Recently i have visually been comparing Citadel and Palace of Magic, I think Citadel is far superior with how much more they crammed in. Any thoughts on the teqniques used in this game ?. The rooms are allot less blocky than in most games of this type. The only game which comes near is Quest.
(Disregarding Exile of course)

Probably something very simile, but again not played Citadel much, will have a look see soon.

[SarahWalker]

Citadel's rooms are vector rather than tile/block based I believe.

[Cybershark]

heheh, there's that exploit in Citadel where if you take a trampoline to the most eastern point on the island you can bounce out of the play area and onto the title screen. from there you can then drop back into the game and it becomes very evident how the screens are arranged

[JIM]

I thought the citadel screens were a combination of tiles and vector to give the screens that bit extra substance. Any examples of a vector room code? (Passed Article)

[retro_junkie]

(Straying off-topic a wee bit: QWAK! has really fast and flicker-free sprites. Nice game too.)

Yes it is amazing really - hard to believe it's running on an Elk. Just shows what was possible. It would probably be worth contacting the author Jamie Woodhouse - he is proud of Qwak and as well as the 90s Amiga version (the first I saw), he just this year released a new GBA version.

http://www.jamiewoodhouse.co.uk/pages/BBC/Qwak/qwak.htm

http://www.qwak.co.uk/

Interesting... so who did contact Jamie?! Even more OT... has anyone got the GBA version of Qwak? It does look good but the youtube video is a bit jittery - I assume that's just the video but it would give you a headache if it played like that on the GBA! Anyone recommend it? I guess it won't be around for long. Oh and sadly that jamiewoodhouse.co.uk site is down now (the one that went into detail about beeb Qwak). Is it somewhere else now?

[timmy]

Is this what Sabre Wulf & Star Drifter and game like that do...? I've often wondered.

Probably, although I've never played these games, so would have to have a look.[/quote]

What?! you never played... *faints*

[timmy]

Citadel's rooms are vector rather than tile/block based I believe.

Are you sure? how would this work? wouldn't you see some drawing process as you enter a room? unless the palette is all black... but wouldn't all the fancy fill-patterns take forever to render...?

[SarahWalker]

Citadel's rooms are vector rather than tile/block based I believe.

Are you sure? how would this work? wouldn't you see some drawing process as you enter a room? unless the palette is all black... but wouldn't all the fancy fill-patterns take forever to render...?

The palette is all black when entering a room. From memory, the entire screen is filled with a tile/pattern, then vectors specify the bits that are 'cut out' from that. Mostly it's rectangles which can be filled quickly, but there's also some (bad) approximation of curves, as seen on the first screen.

[Dave Footitt]

Yep it's pretty nicely done, and probably gets away with a lot more space for level data as a result.

I didn't think it was that badly done tbh

[Rich Talbot-Watkins]

yeah... and certain screens like the Pyramid and the Witch's House are obviously constructed largely from filled triangles. In Witch's House, I think they even got the coordinates slightly off and the roof looks wonky.

I didn't know that the other more conventional looking screens were 'cut out' from an initially block-filled screen though.

[SarahWalker]

Just double-checked this with a hacked B-em and you can quite clearly see the screen filled and then triangles cut out of the blocks (using the OS VDU routines?). Some of the results are slightly surprising, for example the screen The Beach is filled with the brick wall at the left, and then has almost all of it cut out. The grass (which occupies more of the screen) is plotted afterwards, again initially as a big chunk with triangles cut out of it.

[timmy]

Oh yeah - i see now fascinating! The first room - the main hall - is a good example of the rough arcs.
But it's only the basic shape of the room, ie. where's the walls & floors etc, and where there isn't that's vector based. The patterns and other furniture are all bitmaps right?

[BeebInC]

Some citadel stuff for you, I did disassemble it somewhere in the past...

citadel sprite decoding routine is at &30ad, with the compressed sprites stored at &0955-&139f

The display room X code is at &3423
The compressed room data is stored at &13a0-&23ff
Some common room name words are at &2400-&2500


The demo room numbers are stored at &750-&76f

DEMO ROOM NUMBERS (displays 3 then skips 4th (title screen instead) in a loop

0750 CA 1C 80 95 17 C4 6E 6A ......nj 202 028 128 149 023 196 110 106
0758 71 01 A3 D5 92 5D 47 ED q....]G. 113 001 163 213 146 093 071 237
0760 94 30 CB 9D 1A 4A 68 72 .0...Jhr 148 048 203 157 026 074 104 114
0768 6B 5A B7 65 97 15 91 5C kZ.e...\ 107 090 183 101 151 021 145 092

Room 202 (CA) Address 2209 The Temple contents 220B
Room 28 (1C) Address 153E West Tower contents 1540
Room 128 (80) Address 1BBA West Wing contents 1BBC
Room 149 (95) Address 1E61 The Cellar contents 1E63
Room 23 (17) Address 1471 The Palace contents 1473
Room 196 (C4) Address 21B2 The lab contents 21B4
Room 110 (6E) Address 1A32 FrEeZeR contents 1A34
Room 106 (6A) Address 196F The Wasteland contents 1971
Room 113 (71) Address 1AE8 The Well Wheel contents 1AEA
Room 1 (01) Address 13A7 The Pyramid contents 13A9
Room 163 (A3) Address 1FB9 Star Port contents 1FBB
Room 213 (D5) Address 230B The Well contents 230D
Room 146 (92) Address 1E1B Witch's House contents 1E1D
Room 93 (5D) Address 1876 East Fireplace *UNIQUE* contents 1885
Room 71 (47) Address 16B9 Central Tower contents 16BB
Room 237 (ED) Address 23B9 The Pyramid contents 23BB
Room 148 (94) Address 1E4E contents 1E50
Room 48 (30) Address 15C6 West Tower contents 15C8
Room 203 (CB) Address 2246 The Temple contents 2248
Room 157 (9D) Address 1F5E The Ocean contents 1F60
Room 26 (1A) Address 1500 The Palace contents 1502
Room 74 (4A) Address 1727 East Tower contents 1729
Room 104 (68) Address 1945 Witch's House contents 1947
Room 114 (72) Address 1B44 East Wing contents 1B46
Room 107 (6B) Address 1990 West Gate *UNIQUE* contents 199A
Room 90 (5A) Address 17C1 The Kitchen contents 17C3
Room 183 (B7) Address 20D3 Star Port contents 20D5
Room 101 (65) Address 190F Stonehenge contents 1911
Room 151 (97) Address 1ED2 The Cellar contents 1ED4
Room 21 (15) Address 1429 The Pyramid contents 142B
Room 145 (91) Address 1DDF Witch's House contents 1DE1
Room 92 (5C) Address 1851 West Wing contents 1853