Cavern Explorer
Moderator: Moderators
-
- Vic 20 Devotee
- Posts: 231
- Joined: Tue Sep 04, 2018 2:40 am
- Website: http://davbucci.chez-alice.fr
- Location: Grenoble - France
Cavern Explorer
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
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
Last edited by DarwinNE on Wed Sep 12, 2018 4:21 pm, edited 1 time in total.
- LoadError
- Vic 20 Hobbyist
- Posts: 120
- Joined: Sat Feb 17, 2007 2:44 pm
- Website: http://digilander.libero.it/pyrotech/
- Location: Italy
- Occupation: FG Soft
Re: Cavern Explorer
Excellent! Keep up the good work! Looking forward to try these.
Commodore VIC-20 n. WG-C-275517 - manufactured in Western Germany in 1983
-
- Vic 20 Devotee
- Posts: 231
- Joined: Tue Sep 04, 2018 2:40 am
- Website: http://davbucci.chez-alice.fr
- Location: Grenoble - France
Re: Cavern Explorer
Many thanks, LoadError! I hope you'll enjoy them!
BTW, I added a link to a youtube video in the first post.
BTW, I added a link to a youtube video in the first post.
- joshuadenmark
- Big Mover
- Posts: 1178
- Joined: Sat Oct 23, 2010 11:32 am
- Location: Fr-Havn, Denmark
- Occupation: Service engineer
Re: Cavern Explorer
Great looking game, congratulations with this achievement, looking forward to load this on the real thing.
Kind regards, Peter.
____________________________________________________
In need of a wiki logon - PM me
____________________________________________________
In need of a wiki logon - PM me
-
- Vic 20 Devotee
- Posts: 231
- Joined: Tue Sep 04, 2018 2:40 am
- Website: http://davbucci.chez-alice.fr
- Location: Grenoble - France
Re: Cavern Explorer
Thank you very much, joshuadenmark!
- orion70
- VICtalian
- Posts: 4272
- Joined: Thu Feb 02, 2006 4:45 am
- Location: Piacenza, Italy
- Occupation: Biologist
Re: Cavern Explorer
+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.
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
- Vic 20 Dabbler
- Posts: 92
- Joined: Tue Feb 09, 2016 6:55 pm
- Website: http://home.macintosh.garden/~europa/
- Location: United States
- Occupation: Eccentric Musician
Re: Cavern Explorer
I can say that it works nicely on my NTSC VIC.DarwinNE wrote: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.
She/Her
SoundCloud: https://soundcloud.com/user-385492180
YouTube: https://www.youtube.com/channel/UC3uSQ5 ... AJkFHzReqw
SoundCloud: https://soundcloud.com/user-385492180
YouTube: https://www.youtube.com/channel/UC3uSQ5 ... AJkFHzReqw
-
- Vic 20 Devotee
- Posts: 231
- Joined: Tue Sep 04, 2018 2:40 am
- Website: http://davbucci.chez-alice.fr
- Location: Grenoble - France
Re: Cavern Explorer
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.
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
- Vic 20 Dabbler
- Posts: 92
- Joined: Tue Feb 09, 2016 6:55 pm
- Website: http://home.macintosh.garden/~europa/
- Location: United States
- Occupation: Eccentric Musician
Re: Cavern Explorer
You're welcome, I'm glad I could be of assistance.DarwinNE wrote: ...
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.
She/Her
SoundCloud: https://soundcloud.com/user-385492180
YouTube: https://www.youtube.com/channel/UC3uSQ5 ... AJkFHzReqw
SoundCloud: https://soundcloud.com/user-385492180
YouTube: https://www.youtube.com/channel/UC3uSQ5 ... AJkFHzReqw
- AndyH
- Vic 20 Afficionado
- Posts: 410
- Joined: Thu Jun 17, 2004 5:51 am
- Website: https://www.hewco.uk
- Location: UK
- Occupation: Developer
Re: Cavern Explorer
This looks great, I shall be having a play with it later.
-
- Vic 20 Devotee
- Posts: 253
- Joined: Fri Mar 19, 2010 1:40 pm
Re: Cavern Explorer
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
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
-
- Vic 20 Devotee
- Posts: 231
- Joined: Tue Sep 04, 2018 2:40 am
- Website: http://davbucci.chez-alice.fr
- Location: Grenoble - France
Re: Cavern Explorer
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 wrote: 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.
-
- Vic 20 Devotee
- Posts: 253
- Joined: Fri Mar 19, 2010 1:40 pm
Re: Cavern Explorer
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?
Anyone else... Have you coded something similar that you want to share?
- Mike
- Herr VC
- Posts: 4976
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Cavern Explorer
You might take a look at the cursor in MINIPAINT.vicassembly wrote:Anyone else... Have you coded something similar that you want to share?
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
Michael
-
- Vic 20 Devotee
- Posts: 231
- Joined: Tue Sep 04, 2018 2:40 am
- Website: http://davbucci.chez-alice.fr
- Location: Grenoble - France
Re: Cavern Explorer
@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!
If you want to erase the "sprite", you just have to write back on the screen BLENDCHA to BLENDCHD.
@Mike: neat stuff!