Rod-Land
Ronald Pieket Weeserik's Amiga games were incredibly slick and always had a nifty trick or two tucked away. Rod-Land appeared to be a pretty simple game for the Amiga to handle, and Ron himself admitted that in a magazine article in The One, but he still used the Amiga sprite hardware for a nice effect.
The original arcade machine was only 256 pixels wide. This width would look a little unusual on the Amiga since it can easily handle 320 pixels horizontally. Ron's solution was to fill the 64 pixel gap with a score panel, and it was made completely using sprites. Here's the game with sprites enabled and disabled:
At first glance, this appears to be a very easy and simple trick, since the game screen is static. All 8 sprites are available on each line, and each pair are attached to allow 16 colours (one being transparent). Ron set the data fetch values as thin as possible so that there is more CPU time while the sprite area is being displayed.
Chip Addr: Copper instructions ; Comments -------------------------------------------------- $0002011A: 0100 4200 ; BPLCON0 = 0x4200 - 4 bitplanes $0002011E: 0102 0000 ; BPLCON1 = 0x0000 - No horizontal scroll $00020122: 0104 000F ; BPLCON2 = 0x000F $00020126: 0108 0002 ; BPL1MOD = 0x0002 - 2 bytes between planes $0002012A: 010A 0002 ; BPL2MOD = 0x0002 $0002012E: 008E 3681 ; DIWSTRT = 0x3681 $00020132: 0090 16C1 ; DIWSTOP = 0x16C1 $00020136: 0092 0038 ; DDFSTRT = 0x0038 $0002013A: 0094 00B0 ; DDFSTOP = 0x00B0 $0002013E: 00E2 544A 00E0 0002 ; BPL1PT = 0x0002544A $00020146: 00E6 720A 00E4 0002 ; BPL2PT = 0x0002720A $0002014E: 00EA 8FCA 00E8 0002 ; BPL3PT = 0x00028FCA $00020156: 00EE AD8A 00EC 0002 ; BPL4PT = 0x0002AD8A $0002015E: 0180 0000 ; COLOR00 = 0x0000 - Only 16 colours! $00020162: 0182 0FAA ; COLOR01 = 0x0FAA $00020166: 0184 0F66 ; COLOR02 = 0x0F66 $0002016A: 0186 0C00 ; COLOR03 = 0x0C00 $0002016E: 0188 079F ; COLOR04 = 0x079F $00020172: 018A 046C ; COLOR05 = 0x046C $00020176: 018C 08F6 ; COLOR06 = 0x08F6 $0002017A: 018E 06B4 ; COLOR07 = 0x06B4 $0002017E: 0190 0FF3 ; COLOR08 = 0x0FF3 $00020182: 0192 0DB2 ; COLOR09 = 0x0DB2 $00020186: 0194 0B82 ; COLOR10 = 0x0B82 $0002018A: 0196 0740 ; COLOR11 = 0x0740 $0002018E: 0198 0ABD ; COLOR12 = 0x0ABD $00020192: 019A 0FFF ; COLOR13 = 0x0FFF $00020196: 019C 0483 ; COLOR14 = 0x0483 $0002019A: 019E 0252 ; COLOR15 = 0x0252
As you can see, the game area is only using 16 colours! Ned Langman was a genius at making the game look so good with so few colours at his disposal. The second set of 16 colours are only used by the score panel sprites, as the game area cannot use those colours.
The sprites are manually positioned and the attach bit set (so they appear as 16 colour sprites):
Chip Addr: Copper instructions ; Comments -------------------------------------------------- $0002019E: 3001 FF00 ; Wait for vpos >= 0x30 and hpos >= 0x00 $000201A2: 0140 36C0 ; SPR0POS = 0x36C0 $000201A6: 0142 1602 ; SPR0CTL = 0x1602 $000201AA: 0148 36C0 ; SPR1POS = 0x36C0 $000201AE: 014A 1682 ; SPR1CTL = 0x1682 $000201B2: 0150 36C8 ; SPR2POS = 0x36C8 $000201B6: 0152 1602 ; SPR2CTL = 0x1602 $000201BA: 0158 36C8 ; SPR3POS = 0x36C8 $000201BE: 015A 1682 ; SPR3CTL = 0x1682 $000201C2: 0160 36D0 ; SPR4POS = 0x36D0 $000201C6: 0162 1602 ; SPR4CTL = 0x1602 $000201CA: 0168 36D0 ; SPR5POS = 0x36D0 $000201CE: 016A 1682 ; SPR5CTL = 0x1682 $000201D2: 0170 36D8 ; SPR6POS = 0x36D8 $000201D6: 0172 1602 ; SPR6CTL = 0x1602 $000201DA: 0178 36D8 ; SPR7POS = 0x36D8 $000201DE: 017A 1682 ; SPR7CTL = 0x1682
Then the sprites are pointed to their graphical data and the sprite palette setup:
Chip Addr: Copper instructions ; Comments -------------------------------------------------- $000201E2: 0122 0E2C 0120 0002 ; SPR0PT = 0x00020E2C $000201EA: 0126 11AC 0124 0002 ; SPR1PT = 0x000211AC $000201F2: 012A 152C 0128 0002 ; SPR2PT = 0x0002152C $000201FA: 012E 18AC 012C 0002 ; SPR3PT = 0x000218AC $00020202: 0132 1C2C 0130 0002 ; SPR4PT = 0x00021C2C $0002020A: 0136 1FAC 0134 0002 ; SPR5PT = 0x00021FAC $00020212: 013A 232C 0138 0002 ; SPR6PT = 0x0002232C $0002021A: 013E 26AC 013C 0002 ; SPR7PT = 0x000226AC $00020222: 0096 8120 ; DMACON = 0x8120 $00020226: 01A0 0000 ; COLOR16 = 0x0000 $0002022A: 01A2 0C00 ; COLOR17 = 0x0C00 $0002022E: 01A4 0E55 ; COLOR18 = 0x0E55 $00020232: 01A6 0E99 ; COLOR19 = 0x0E99 $00020236: 01A8 067A ; COLOR20 = 0x067A $0002023A: 01AA 0469 ; COLOR21 = 0x0469 $0002023E: 01AC 0358 ; COLOR22 = 0x0358 $00020242: 01AE 0246 ; COLOR23 = 0x0246 $00020246: 01B0 0135 ; COLOR24 = 0x0135 $0002024A: 01B2 0024 ; COLOR25 = 0x0024 $0002024E: 01B4 0FA4 ; COLOR26 = 0x0FA4 $00020252: 01B6 0000 ; COLOR27 = 0x0000 $00020256: 01B8 0259 ; COLOR28 = 0x0259 $0002025A: 01BA 058A ; COLOR29 = 0x058A $0002025E: 01BC 08CD ; COLOR30 = 0x08CD $00020262: 01BE 0FFF ; COLOR31 = 0x0FFF
Now there appears to be some strange entries that do nothing. These gaps are used by the title screen. More on that later.
Chip Addr: Copper instructions ; Comments -------------------------------------------------- $00020266: 9001 FF00 ; Wait for vpos >= 0x90 and hpos >= 0x00 $0002026A: 0096 0000 ; DMACON = 0x0000 $0002026E: 0096 0000 ; DMACON = 0x0000 $00020272: 0096 0000 ; DMACON = 0x0000 $00020276: 0096 0000 ; DMACON = 0x0000 $0002027A: 0096 0000 ; DMACON = 0x0000 $0002027E: 0096 0000 ; DMACON = 0x0000 $00020282: 0096 0000 ; DMACON = 0x0000 $00020286: 0096 0000 ; DMACON = 0x0000 $0002028A: 0096 0000 ; DMACON = 0x0000 $0002028E: 0096 0000 ; DMACON = 0x0000 $00020292: 0096 0000 ; DMACON = 0x0000 $00020296: A001 FF00 ; Wait for vpos >= 0xA0 and hpos >= 0x00 $0002029A: 0096 0000 ; DMACON = 0x0000 $0002029E: 0096 0000 ; DMACON = 0x0000 $000202A2: B001 FF00 ; Wait for vpos >= 0xB0 and hpos >= 0x00 $000202A6: 0096 0000 ; DMACON = 0x0000 $000202AA: 0096 0000 ; DMACON = 0x0000 $000202AE: 0096 0000 ; DMACON = 0x0000 $000202B2: E001 FF00 ; Wait for vpos >= 0xE0 and hpos >= 0x00 $000202B6: 0096 0000 ; DMACON = 0x0000 $000202BA: 0096 0000 ; DMACON = 0x0000 $000202BE: FFFF FFFE ; End of copperlist ; Wait for vpos >= 0xFF and hpos >= 0xFE
All very simple stuff so far it would seem. However, after each level is complete, the next level scrolls onto the screen. The scrolling is usually vertical (from top to bottom), but for the first level it scrolls horizontally from the right side of the screen to the left. If you are familiar with the Amiga hardware, you will know that when you smooth scroll the display using the register BPLCON1, you lose the 8th sprite in the process. With the 8th sprite removed, you would expect the far right hand side of the score panel to look like this:
So how did the game get around this problem? There are a few ways to attempt this:
- Switch to a different copperlist, manually loading the 8th sprite's data on every line of the display with the copper.
- Change to a 32 colour screen between levels, turn off the final 2 sprites and draw the right hand 16 pixels of the screen with the blitter. You would then only need to blit a thin vertical strip of graphics each frame.
- Change to a 32 colour screen between levels, turn off all 8 sprites and use the blitter to draw the entire status panel with the blitter each frame.
- Copy the correct part of the screen onto the static screen buffer every frame (using the blitter).
Because there are no objects between levels, there was enough DMA time left to use the simplest method and blit the entire game area every frame (method 4). That meant no copperlist tricks or screen mode changes were needed, so Ron took that option. Incidentally, the game scrolls the new level on at 4 pixels per frame between levels.
Title screen
Another neat touch is how slick the title screen is, just by using a few simple palette tricks. Lesser coders wouldn't have bothered, but these little touches really make the difference between a good game and a great one. I find the Amiga palette much easier on the eye than the arcade version:
Here's the copperlist for the title screen:
Chip Addr: Copper instructions ; Comments -------------------------------------------------- $00020688: 9001 FF00 ; Wait for vpos >= 0x90 and hpos >= 0x00 $0002068C: 0182 0793 ; COLOR01 = 0x0793 $00020690: 0184 0A7C ; COLOR02 = 0x0A7C $00020694: 0186 08BF ; COLOR03 = 0x08BF $00020698: 0188 059C ; COLOR04 = 0x059C $0002069C: 018A 0759 ; COLOR05 = 0x0759 $000206A0: 018C 0572 ; COLOR06 = 0x0572 $000206A4: 018E 0D43 ; COLOR07 = 0x0D43 $000206A8: 0190 0DB0 ; COLOR08 = 0x0DB0 $000206AC: 0194 0630 ; COLOR10 = 0x0630 $000206B0: 019A 0DDD ; COLOR13 = 0x0DDD $000206B4: 019E 0520 ; COLOR15 = 0x0520 $000206B8: A001 FF00 ; Wait for vpos >= 0xA0 and hpos >= 0x00 $000206BC: 0186 0F87 ; COLOR03 = 0x0F87 $000206C0: 0188 0F72 ; COLOR04 = 0x0F72 $000206C4: B001 FF00 ; Wait for vpos >= 0xB0 and hpos >= 0x00 $000206C8: 0096 0000 ; DMACON = 0x0000 $000206CC: 0096 0000 ; DMACON = 0x0000 $000206D0: 0096 0000 ; DMACON = 0x0000 $000206D4: E001 FF00 ; Wait for vpos >= 0xE0 and hpos >= 0x00 $000206D8: 0186 08BF ; COLOR03 = 0x08BF $000206DC: 0188 059C ; COLOR04 = 0x059C $000206E0: FFFF FFFE ; End of copperlist ; Wait for vpos >= 0xFF and hpos >= 0xFE
I mentioned earlier the strange writes to DMACON in the copperlist. The title screen uses those gaps to alter the palette down the screen. By doing this, the title screen ends up with 42 unique colours on a 4 bitplane screen! The 7 palette entries that form the Rod-Land writing are colour cycled to add a nice (and free) animation.
Two palette entries were changed from shades of blue (for the font) to pink for the left fairy's hair, then switched back just below it.
Amiga vs Atari ST comparison
The Storm team made some simple enhancements to the Amiga code so that it was better than the Atari ST version. Most of these are pretty simple effects that would allow code-sharing between the platforms, while ensuring the game doesn't look completely awful on the Atari ST:
- The Amiga version features a larger screen (320x224 on the Amiga vs 320x200 on the Atari ST). The least important vertical strips were removed on the Atari ST (16 pixels at the top, 8 pixels at the bottom) which does not affect the gameplay.
- Sprites were utilised for the score panel on the Amiga, and used their own 16 colour palette. The Atari ST has to re-use the shades of blue, so the score panel looks significantly worse.
- The horizontal scrolling transition from level 1 to 2 was dropped on the Atari ST and instead scrolls vertically.
Overall, another fine conversion from Ronald Pieket Weeserik and Ned Langman!
Popular Sprite Tricks
2 sprites are displayed then repositioned horizontally right across the screen to create the colourful static background. The remaining sprites are used for the main character, the status bar and player bullets.
The 16-colour background layer was created by using all 8 hardware sprites and repositioning them across the screen. The same 64 pixel wide graphics are repeated across the entire play area.
One of the first jaw-droppingly beautiful Amiga games that still looks great today. Sprites were heavily re-used on the screen, along with priority changes to make them appear between the playfields.
The amazing tunnel sequence was created with a 6 frame animation sequence made with only 4 colours and mirrored vertically. The asteroid layer sits on top of this, with a status panel and player ship made of sprites sitting on top.
Post your comment
Comments
I am a grown man but I would never ever miss out some Rod-Landing when the opportunity arises. I showed it to my kids and they got hooked immediately as well. This game may be overlooked for its cute theme but it's a masterclass in game design. It has a long-lasting value and an incredibly deep gameplay compared to how small set of rules are defined. It especially shines in 2-player mode. Thumbs up for Jaleco and to the Amiga team as well as their version is SMOOTH!
Peter 04/09/2024 8:36am (3 months ago)
Playing this cute little gem atm, this very version too. The woodland critters may indeed appear cute but they have defeated me more than once!
But Ronald and Ned really did a good job (as they did their predecessors at Jaleco).
Kamjay 30/08/2024 9:05pm (4 months ago)
No one has commented on this page yet.
RSS feed for comments on this page | RSS feed for all comments