Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
  You are not logged in - nap
Ghosts'n Goblins Demo   [2018]

Ghosts'n Goblins Demo Released by :
Rastah Bar

Release Date :
10 October 2018

Type :
C64 One-File Demo

User rating:awaiting 8 votes (5 left)   See votestatistics

Credits :
Code .... Rastah Bar
Music .... Reyn Ouwehand of Paradize, Scoop
  Steve Barrett
Graphics .... Gollum
  Ste Pickford


SIDs used in this release :
Knightmare(/MUSICIANS/B/Barrett_Steve/Knightmare.sid)
Knights(/MUSICIANS/O/Ouwehand_Reyn/Knights.sid)

Download :

Look for downloads on external sites:
 Pokefinder.org


Production Info
Submitted by Digger on 14 October 2018
That's a great write up. I wish more coders would share such insights. Thanks RB!
Production Info
Submitted by Rastah Bar on 14 October 2018
Although it is not very difficult to figure out the basic idea of how it works, here are some remarks about the code.
Also for my own future reference because I often don't fully understand anymore the mess I call code after just a few weeks :-)

I have been playing with linecrunch before and now with FLD. Plain FLD shows the ghostbyte (no pun intended) in between character rows.

I watched some recent demos with cool layered gfx.
Many demos end with a sprite scroller showing greetings, notes, or credits on top of a picture.
This gave me the idea to attempt to create some impression of layered gfx, with a picture on top of sprites.

It was harder than I thought it would be, because the multiplexed background sprites are moving upwards so the lines where sprite image pointers (SIPs)
have to be changed and the badlines are at arbitrary positions (and I'm not a very good coder).

The SIPs are changed by a single $d018 write (different screen RAM locations). The background sprite multiplexing requires six screen RAM locations and
two are used for double buffering the ghost sprites on the GnG picture.

The $d018 and $d011 FLD writes are all done in raster IRQs. This is done to save raster time for updating the scroller and ghost sprite data,
sprite movements and play music. There are different IRQs depending on the number of rasterlines left until the next $d018 or $d011 write. For example, there is
an IRQ that postpones a badline by six rasterlines, there is an IRQ that always occurs 1 line before a badline ("char row" IRQ), there are IRQs that subdivide a six line stretch
into two when a $d018 write must be done in that range. During a "six line" or a "char row" IRQ there is (sometimes just) enough time to do multiplexing and
preparing IRQs for the next screen section. Sometimes a $d018 write is needed two lines before a badline and again on the line before the badline.
In this case there is not enough time for an RTI, so the code jumps directly from one IRQ into another.

The ghost sprites are plotted into memory. Double buffering is used to clear and plot the sprites (with EOR for the 2nd one).
They are multicolor in the middle section of the screen. Turning MC on and off happens during the display of the rightmost sprite of a row of multiplexed sprites.
I had to change the display order of the last two sprites (that is, place sprite 7 to the left of sprite 6, such that the higher priority of sprite 6 hides
a glitch that occurs when MC is set. If I understand it correctly this glitch is used in Krestage 3 to create 50 pixel wide sprites!

The dragon that moves on the scroller gave me a bit of a headache since almost all $d018 writes don't occur right after the dragon's head. I solved
that with a transition sprite that consists of part of the dragon's body and part of its head. This transition sprite is refreshed every frame.

When the multiplexer has moved upwards by 42 lines, the sprite gfx are updated in Main for the (then invisible) last sprite row.

An IRQ starting in the lower border handles sprite movements, changing FLD distance, updating the dragon transition sprite, playing music, and
clearing and plotting the ghost sprites. This is far too much to fit into the border, so I put an CLI somewhere and it is interrupted by the other raster IRQs.
First I made the obvious mistake of using the same ZP addresses for storing and retrieving the registers as in the other IRQs. That bug took way too long to find.

I'm happy with the result, but there are probably better and more efficient methods to do these kind of things. I would appreciate your
suggestions, since I'm always eager to learn.
Search CSDb
Advanced
Navigate
Prev - Random - Next
Detailed Info
· Summaries
· User Comments (20)
· Production Notes (2)
Fun Stuff
· Goofs
· Hidden Parts
· Trivia
Forum
· Discuss this release
Support CSDb
Help keep CSDb running:



Funding status:




About this site:
CSDb (Commodore 64 Scene Database) is a website which goal is to gather as much information and material about the scene around the commodore 64 computer - the worlds most popular home computer throughout time. Here you can find almost anything which was ever made for the commodore 64, and more is being added every day. As this website is scene related, you can mostly find demos, music and graphics made by the people who made the scene (the sceners), but you can also find a lot of the old classic games here. Try out the search box in the top right corner, or check out the CSDb main page for the latest additions.
Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.091 sec.