Cavern Explorer

[DarwinNE]

Name: Cavern Explorer
Author: DarwinNE (D. Bucci)
Released: September 10th, 2018 (v1.0)
Genre: Arcade Game
Requirements: Unexpanded VIC-20, PAL or NTSC
Development system: Textwrangler + ca65 + VICE xVIC + real PAL machine

Description: A spaceship is at your command to explore a vast cavern discovered on planet Zorf.
You control the spaceship with the Z,S and X keys to move it to the left, upwards and to the right, or use joystick.
You can move the ship very fast, but beware of momentum!

Advance as much as you can in the cavern, collect pulsating rings and avoid carnivorous plants shooting deadly slime.

Video: https://www.youtube.com/watch?v=JvhkRBfTAec

Download: https://github.com/DarwinNE/vic20-cavern-exp/releases
Open source GPL v.3, the source code is available.

While writing Alien Invasion a few months ago (http://sleepingelephant.com/ipw-web/bul ... =10&t=9109), I realized how fun it was to work on small games for the unexpanded VIC20 in 6502 assembly language. I continued with this Cavern Explorer that put together some ideas I had for a C64 game back at the beginning of 1990's. The gameplay is not very elaborated and it is based on vertical scrolling. Since I could exploit some of the techniques I employed with Alien Invasion, I could put together Cavern Explorer at a much faster pace. Probably I still need to improve my graphic skills (I am no pixel artist) and learn some techniques for convincing music and sound effects on the VIC-20. Ship momentum makes things more challenging and a friend of mine said it was probably too difficult, but he was not much into arcade games.
I could try the game on my PAL hardware, but I would be happy if someone can give a feedback on a real NTSC machine.

The screen and character editor from Beamrider has been precious for putting together the loader graphics: http://sleepingelephant.com/ipw-web/bul ... =14&t=7133

[LoadError]

Excellent! Keep up the good work! Looking forward to try these.

[DarwinNE]

Many thanks, LoadError! I hope you'll enjoy them!

BTW, I added a link to a youtube video in the first post.

[joshuadenmark]

Great looking game, congratulations with this achievement, looking forward to load this on the real thing.

[DarwinNE]

Thank you very much, joshuadenmark!

[orion70]

+1
I guess I'm gonna revive my VIC soon, even if Real Life (tm) tries to prevent me from playing. Thanks so much for it.

[Gorf]

Name: Cavern Explorer
I could try the game on my PAL hardware, but I would be happy if someone can give a feedback on a real NTSC machine.

I can say that it works nicely on my NTSC VIC.

[DarwinNE]

Thank you orion70.

And thanks to Gorf, too: I was really curious to know if the game was OK on an NTSC machine. It should play a little faster than on the PAL hardware and so it is a little more difficult.

[Gorf]

...
And thanks to Gorf, too: I was really curious to know if the game was OK on an NTSC machine. It should play a little faster than on the PAL hardware and so it is a little more difficult.

You're welcome, I'm glad I could be of assistance.

[AndyH]

This looks great, I shall be having a play with it later.

[vicassembly]

I have been conversing with David about some of the technical details and he suggested I bring a particular question to the group.

The crux of the question was surrounding sprite movement shifts and how to clean up "dirty characters" after shifting 8 bits in any direction.
I think David's choice wound up redrawing the screen each time for Cavern Explorer and a more restrained cleaning for Alien Invasion.

I am in the infancy stages of a new game and am generating sprite routines that are generic enough that can be used for multiple games. (YES! I know about Robert Hurst's sprite stack and don't want to use it. It's the journey that's fun. )
The method I have employed is when a character shift has completed a boundary cross (Delta X = 0) then the screen is scanned for the sprite and anything existing is erased.

My question for the group. Can anyone explain a better heuristic for easily keeping track of the locations of dirty sprites?
For example, sprite 1 may be made of characters:
AC
BD

Sprite 2 made of characters
EG
FH

When either quadrant completely holds the character of the sprite that is when I go and remove all characters and re-draw. For example, sprite 1 I would search the screen for A,B,C, or D and blank that position out.

Perhaps there is a better method. Thanks for reading and helping.



Here was our conversation.

______________________________

Hi!
The code for the "sprite" is very similar for Alien Invasion and for Cavern Explorer. For the first one, I just clear all the area where the aliens are known to be possibly present.
In Cavern Explorer, all the screen is cleared and redrawn at each frame. I am not fond of this, as it requires some time and demanded a certain deal of optimization, especially for NTSC machines.
I first tried to keep track of the "dirty" areas, save and restore them, but it was difficult as basically both the screen and the sprite move at the same time.

Cheers,
D.

P.S. those are technical questions that may interest other people, don't hesitate to put them on the forum. Some interesting discussions may arise with people more experienced than I am.
Re: cc65 template
Sent: Tue Nov 06, 2018 11:23 am
by vicassembly

Question about the DrawSprite routine specifically. I isolated the code out and see how you draw and calculate the AC(ret)BD characters each time.

My question for you is HOW do you erase the characters that are left around the screen? For example, when I shift right one pixel at a time, slowly, I see the image shift. The problem is when it shifts 8 bits and the DeltaX gets back to 0. The prior A remains on the screen and now shows the bits shifting again. How do you clean up after each move of 8 bits? I hope this makes sense

[DarwinNE]

The crux of the question was surrounding sprite movement shifts and how to clean up "dirty characters" after shifting 8 bits in any direction.
I think David's choice wound up redrawing the screen each time for Cavern Explorer and a more restrained cleaning for Alien Invasion.

Those are the strategies I used. In my experience, it is not very difficult to clean the dirty characters around the sprite if you just have to put again the background color (this happens in Alien Invasion). What's difficult is to handle what happens when you "blend" the sprite with a character in the background. With a static screen, you need to keep track of the original characters that are "blended" with the sprite and put them at their place when you move the sprite. In Cavern Explorer, the sprite containing the starship moves and so does the background. I tried to combine the two movements, but the code was not very clean and I did not like it. The code in Cavern Explorer can be improved, of course, but since the screen is continuously scrolling, there was already the need to draw everything very fast, so it is not a big deal to do the redraw more frequently.

[vicassembly]

Did you ever come up with an algorithm to remember what the original character was and keep it around until the 'ORd' condition was finished?

Anyone else... Have you coded something similar that you want to share?

[Mike]

Anyone else... Have you coded something similar that you want to share?

You might take a look at the cursor in MINIPAINT.

It uses 6 characters. Before the cursor is "instated", the routine calculates its address on screen, remembers that address and those 6 characters, copies the character definitions of those underlying 6 characters into the cursor characters (codes 122..127), writes those characters to the screen and then superimposes the cursor data. Before any relevant background change takes place, the original characters are just written back to that place, the background change is done, and then the cursor is re-instated.

The whole thing takes place within an event-oriented framework, so cursor-create and -remove only take place as necessary. The blinking is done without any change to the text screen, just by modifying the mini-bitmap in place!

Here's the part that copies the character definitions of the background characters into the cursor characters:

Code: Select all

.4D9E  A2 00     LDX #$00
.4DA0  86 F9     STX $F9
.4DA2  A9 00     LDA #$00
.4DA4  85 FC     STA $FC
.4DA6  BD 32 4D  LDA $4D32,X  ; a 6-byte buffer containing the background character codes
.4DA9  0A        ASL A
.4DAA  26 FC     ROL $FC
.4DAC  0A        ASL A
.4DAD  26 FC     ROL $FC
.4DAF  0A        ASL A
.4DB0  26 FC     ROL $FC
.4DB2  85 FB     STA $FB
.4DB4  18        CLC
.4DB5  A5 FC     LDA $FC
.4DB7  69 18     ADC #$18
.4DB9  85 FC     STA $FC
.4DBB  8A        TXA
.4DBC  48        PHA
.4DBD  A6 F9     LDX $F9
.4DBF  A0 00     LDY #$00
.4DC1  B1 FB     LDA ($FB),Y
.4DC3  9D D0 1B  STA $1BD0,X  ; "inner" X runs from 0..47 and writes to $1BD0..$1BFF (chars 122..127)
.4DC6  E8        INX
.4DC7  C8        INY
.4DC8  C0 08     CPY #$08
.4DCA  D0 F5     BNE $4DC1
.4DCC  86 F9     STX $F9
.4DCE  68        PLA
.4DCF  AA        TAX
.4DD0  E8        INX
.4DD1  E0 06     CPX #$06
.4DD3  D0 CD     BNE $4DA2

Greetings,

Michael

[DarwinNE]

@vicassembly: In Cavern Explorer, the game reads the four characters that correspond to a "sprite" and blends them with the shape contained in the "sprite". The code of the four characters read are stored in BLENDCHA to BLENDCHD. They are read just before drawing the "sprite", at the moment where collisions are checked. The BlendSprite routine then blends BLENDCHA to BLENDCHD with the "sprites" and SPRITE1A to SPRITE1D contain the characters with the results and are written back to the screen.
If you want to erase the "sprite", you just have to write back on the screen BLENDCHA to BLENDCHD.

@Mike: neat stuff!