Snake Ten Liner

[Kiwi]

I had to change the cont2.B0 to cont1.B0 in order to fire.

Very nice game. The laser and the blast reminds me of Space Battle battle scene. Well done.

[freewheel]

Huh, neat thread. Yeah, in my mind using : is a bit like cheating, but still - I broke this down and it's still only about 80 lines of code. Impressive for a very playable game, with animations and everything.

 

What do you guys think about a 100 line limit? I kinda like the idea of a mini contest like this for IntyBASIC. We'd have to come up with some rules - like does a label have to be on its own line, or not? PROC labels obviously have to be but regular ones? I think that level of "cheat" is OK. The only issue I see is that IntyBASIC kinda requires some use of : when it comes to IF statements, but then people could cheat and just use IF 1 THEN command1:command2:command3 etc. You coding syntax experts could probably write up better rules than I.

[+DZ-Jay]

Huh, neat thread. Yeah, in my mind using : is a bit like cheating, but still - I broke this down and it's still only about 80 lines of code. Impressive for a very playable game, with animations and everything.

 

What do you guys think about a 100 line limit? I kinda like the idea of a mini contest like this for IntyBASIC. We'd have to come up with some rules - like does a label have to be on its own line, or not? PROC labels obviously have to be but regular ones? I think that level of "cheat" is OK. The only issue I see is that IntyBASIC kinda requires some use of : when it comes to IF statements, but then people could cheat and just use IF 1 THEN command1:command2:command3 etc. You coding syntax experts could probably write up better rules than I.

 

The thing about rules is that they are defined with context. We're all smart people here, so you write the rules as you see fit, and if anybody attempts to abuse them, you just call them out on it. It's not like "OMG! we forgot to explicitly state that the program has to compile! I guess we're toast: the short but broken program wins. Oh well."

 

-dZ.

[catsfolly]

I had to change the cont2.B0 to cont1.B0 in order to fire.

 

Very nice game. The laser and the blast reminds me of Space Battle battle scene. Well done.

Thanks for the kind words.

 

On my computer keyboard, the arrow keys are cont1 and the left shift key is cont2.b0. So that is how I play the game.

[intvnut]

Huh, neat thread. Yeah, in my mind using : is a bit like cheating, but still - I broke this down and it's still only about 80 lines of code. Impressive for a very playable game, with animations and everything.

 

What do you guys think about a 100 line limit? I kinda like the idea of a mini contest like this for IntyBASIC. We'd have to come up with some rules - like does a label have to be on its own line, or not? PROC labels obviously have to be but regular ones? I think that level of "cheat" is OK. The only issue I see is that IntyBASIC kinda requires some use of : when it comes to IF statements, but then people could cheat and just use IF 1 THEN command1:command2:command3 etc. You coding syntax experts could probably write up better rules than I.

 

How about doing it like the IOCCC does: Total byte count of the source. Use them however you like. Take formatting off the table.

 

Give everyone, say, 2K or 4K bytes of source to work with. To minimize OS differences, measure it with line endings converted to UNIX (LF only, instead of CR+LF), just so everyone's on the same page.

[catsfolly]

Huh, neat thread. Yeah, in my mind using : is a bit like cheating, but still - I broke this down and it's still only about 80 lines of code. Impressive for a very playable game, with animations and everything.

 

What do you guys think about a 100 line limit? I kinda like the idea of a mini contest like this for IntyBASIC. We'd have to come up with some rules - like does a label have to be on its own line, or not? PROC labels obviously have to be but regular ones? I think that level of "cheat" is OK. The only issue I see is that IntyBASIC kinda requires some use of : when it comes to IF statements, but then people could cheat and just use IF 1 THEN command1:command2:command3 etc. You coding syntax experts could probably write up better rules than I.

The contest wasn't my idea - I saw it in the Atari 8 bit forum. They use lots of ":" multicommand "lines" in their 10 line programs. It would be hard to do anything interesting in just 10 lines of basic.

 

With Intybasic it is difficult to put a whole program into one line - once you use an if statement the rest of the line has to be part of the "then" or the "else" side...

 

It is fun to see what you can do with 10 lines of code - it definitely forces you to think outside the box. On the other hand, the resulting code is an almost unreadable jumble of characters.

 

It would be cool to have a contest to write a program that does something useful in 100 lines, and award points for clarity and readability. The resulting programs might be useful for new Intellivision programmers....

 

Just thinking out loud....

 

 

Catsfolly

[intvnut]

Thanks for the kind words.

 

On my computer keyboard, the arrow keys are cont1 and the left shift key is cont2.b0. So that is how I play the game.

 

If you're using jzIntv, try hitting F6. It rearranges the key board so all the controls are on one controller. I use that layout for games like Beamrider that only scan the controller you start the game with.

[catsfolly]

Here is the (more) readable version. It is 281 lines long. It supports either controller.

 

robotblast_r.bas

 

Catsfolly

 

 

[catsfolly]

 

If you're using jzIntv, try hitting F6. It rearranges the key board so all the controls are on one controller. I use that layout for games like Beamrider that only scan the controller you start the game with.

Yeah, that's a great option. I use it for some games.

 

But, in the middle of my change-build-try cycle, I don't wanna hit F6. I just want to try my program.

 

On my Mac, I have to hold down a function key to access F6. And the "F6" label is written on the lower right corner of the key in gnat sized letters.

 

So I usually code things to use the keys as they come up in jzintv by default.

 

I guess the best answer is to write one player games from the beginning to use either controller.

 

Catsfolly

[intvnut]

Yeah, that's a great option. I use it for some games.

 

But, in the middle of my change-build-try cycle, I don't wanna hit F6. I just want to try my program.

 

On my Mac, I have to hold down a function key to access F6. And the "F6" label is written on the lower right corner of the key in gnat sized letters.

 

So I usually code things to use the keys as they come up in jzintv by default.

 

 

If you're launching from a script, I have a handy shortcut for you: The command line flag -m<#> will bring up jzIntv in the specified map number. -m1 for map 1 (the map selected by F6), for example.

 

 

 

I guess the best answer is to write one player games from the beginning to use either controller.

 

 

Also a great option. :-)

[freewheel]

I guess the best answer is to write one player games from the beginning to use either controller.

 

IntyBASIC has a very easy facility for doing this, too

[dalves]

Catsfolly, I love what you did with Robot Blast. I was trying to use this code you provided to figure out how to do something in a game I'm working on. I'm trying to get a missile to start at a set coordinate (say the center bottom of the screen) and end up at the x,y coordinates of the cursor. In my limited programming experience, I'm previously used For/Next statements achieve this, but found changing value of the variables in a loop is the better way. I'm having a brain cramp because I can't seem to figure out the right way to have the missile start from a specific location but end up at the cursor location. Thanks again for the code. It is incredibly valuable for a newbie like me.

[GroovyBee]

I'm trying to get a missile to start at a set coordinate (say the center bottom of the screen) and end up at the x,y coordinates of the cursor.

You'll need to use Bresenham's line drawing algorithm to move smoothly between two arbitrary points. If you look at ColouredSquares.bas in the contrib folder of the latest IntyBASIC, you'll find an implementation of that algorithm that can be adapted to your needs.

[Mr SQL]

Snake ten-Liner is cool!

 

Awesome Intellivision BASIC supports old-school BASIC programming!

 

It would be great to see the Intellivision enter next years 10 liner contest for vintage computer systems - the Atari VCS participiated in the last contest with 9LineBlitz and there were amazing entries from many vintage microcomputers, scroll down that page to see all of the incredible BASIC screenshots.

 

The contest allows categories of 80, 120 or 256 characters per line which keeps the BASIC programs small, but is enough to accomplish a lot. bitd we also a catetory of just a single line of code.

 

Looking at the posts on this thread, I have to comment that : is the balm; I really like/miss efficient horizontal BASIC structures that make good use of screen real estate:

 

if g=y and r=g*2 and x=5 then r=7:x=25 else r=g*4:v=23

 

Never saw the reason for going vertical, for indenting the code or for adding extra statements - it's just semantics but on a functional level these sprawling structures obfuscate nearby code:

 

if g=y and r=g*2 and x=5 then

r=7

x=25

else

r=g*4

v=23

end if

 

 

[+DZ-Jay]

Never saw the reason for going vertical, for indenting the code or for adding extra statements - it's just semantics but on a functional level these sprawling structures obfuscate nearby code:

 

if g=y and r=g*2 and x=5 then

r=7

x=25

else

r=g*4

v=23

end if

 

 

Horses for courses, I guess. To me the exact opposite is true. I suspect I'm not the only one.

 

As far as I know, the only reason we used to cram things like that in the old days was because it conserved memory in some BASIC interpreters, by dispensing of additional line pointers.

 

Horses for courses, like I said.

 

dZ.

[GroovyBee]

Given the choice, whitespace and comments are where its at for me. As an example of code compression, look at the Elite video game source code from BITD :-

 5280LDX#15:JSRPLS3:CLC:ADCK3:STAK3:TYA:ADCK3+1:STAK3+1:JSRPLS3:STAP:LDAK4:SEC:SBCP:STAK4:STYP:LDAK4+1:SBCP:STAK4+1
 5300LDX#9:JSRPLS1:LSRA:STAK2:STYXX16:JSRPLS1:LSRA:STAK2+1:STYXX16+1
 5310LDX#21:JSRPLS1:LSRA:STAK2+2:STYXX16+2:JSRPLS1:LSRA:STAK2+3:STYXX16+3
 5320LDA#64:STATGT:LDA#0:STACNT2:JMPPLS22
 5330.PLS1 LDAINWK,X:STAP:LDAINWK+1,X:AND#127:STAP+1:LDAINWK+1,X:AND#128
 5340JSRDVID3B2:LDAK:LDYK+1:BEQP%+4:LDA#&FE:LDYK+3:INX:INX:RTS

Taken from the file ELITEE.TXT in http://www.iancgbell.clara.net/elite/archive/a/a4080610.zip

 

Its not very readable like that.

[Mr SQL]

Given the choice, whitespace and comments are where its at for me. As an example of code compression, look at the Elite video game source code from BITD :-

 5280LDX#15:JSRPLS3:CLC:ADCK3:STAK3:TYA:ADCK3+1:STAK3+1:JSRPLS3:STAP:LDAK4:SEC:SBCP:STAK4:STYP:LDAK4+1:SBCP:STAK4+1
 5300LDX#9:JSRPLS1:LSRA:STAK2:STYXX16:JSRPLS1:LSRA:STAK2+1:STYXX16+1
 5310LDX#21:JSRPLS1:LSRA:STAK2+2:STYXX16+2:JSRPLS1:LSRA:STAK2+3:STYXX16+3
 5320LDA#64:STATGT:LDA#0:STACNT2:JMPPLS22
 5330.PLS1 LDAINWK,X:STAP:LDAINWK+1,X:AND#127:STAP+1:LDAINWK+1,X:AND#128
 5340JSRDVID3B2:LDAK:LDYK+1:BEQP%+4:LDA#&FE:LDYK+3:INX:INX:RTS

Taken from the file ELITEE.TXT in http://www.iancgbell.clara.net/elite/archive/a/a4080610.zip

 

Its not very readable like that.

 

Wow GroovyBee that's a great Assembler they must have been using - I always wished for the concatenator operator in Assembly because it's ridiculously vertical in the extreme.

 

vwBASIC also supports : for embedded asm.

 

 

Horses for courses, I guess. To me the exact opposite is true. I suspect I'm not the only one.

 

As far as I know, the only reason we used to cram things like that in the old days was because it conserved memory in some BASIC interpreters, by dispensing of additional line pointers.

 

Horses for courses, like I said.

 

dZ.

 

Great point dZ, older systems definitely benefit from conserving memory.

 

I agree it's preference; in a group programming environment I once wrote a plug-in to (re)indent all the code in the IDE for other programmers in the group who needed to see a nice sign wave instead of my left aligned code.

 

Some other programmers still didn't like ":" because there was no way to make a sign wave.

 

Next was next, for the same reason:

 

Next x,y,z

 

Oh no!

Next x

Next y

Next z

 

Then undeclared variables were bad and even using shorthand for data types was bad:

 

dim a$, b#

 

Oh no what are those strange characters?!

 

dim a as string, b as integer

 

Wait, still wrong (remember next):

 

dim a as string

dim b as integer

 

Then BASIC intrinsics became bad too because the language was verbose and not everyone could know all the words, so command.item.othercommand with drop downs programmers could painstakingly scroll through became fashionable.

 

Having seen all these changes it seems a lot of programmers learned how to write c in BASIC.

[+DZ-Jay]

Having seen all these changes it seems a lot of programmers learned how to write c in BASIC.

I don't agree. If you take the (rather reasonable) position that a line should represent a single logical and functional statement (in the general meaning of the word "statement"), then it is also reasonable to break blocks of code "vertically," as you call it.

 

The indentation buys you visual delineation of blocks of functionally related statements, and in some cases, highlights language-specific scope of local objects (although I would argue that scope rules are intended to delimit functional use of objects, which follows the cognitive separation of said blocks; so one is equivalent to the other).

 

This leads normally to certain patterns and idioms that become common in any language.

 

Code separated into multiple lines, each doing a single and specific thing, is therefore not a "BASIC" thing, but a common human way of coping with complexity within the constraints of a system.

 

(For a non-obvious but just as relevant example, consider how we organize prose into paragraphs with indented first lines, spaces after punctuation, and even how we break passages into sentences paragraphs, chapters, volumes, etc. If you want to get pedantic, the content would remain the same if you just smooshed it into a single stream of text; although many would argue it wouldn't be as intelligible.)

 

So, yeah, there are some stylistic preferences (and a dose of some cargo-cultism, I'm sure), but it's reasonable to appreciate how universal it is across disciplines and media, especially when dealing with complex or high-volume content. It's just how we're wired.

 

dZ.

Edited September 7, 2016 by DZ-Jay

[Mr SQL]

I don't agree. If you take the (rather reasonable) position that a line should represent a single logical and functional statement (in the general meaning of the word "statement"), then it is also reasonable to break blocks of code "vertically," as you call it.

 

The indentation buys you visual delineation of blocks of functionally related statements, and in some cases, highlights language-specific scope of local objects (although I would argue that scope rules are intended to delimit functional use of objects, which follows the cognitive separation of said blocks; so one is equivalent to the other).

 

This leads normally to certain patterns and idioms that become common in any language.

 

Code separated into multiple lines, each doing a single and specific thing, is therefore not a "BASIC" thing, but a common human way of coping with complexity within the constraints of a system.

 

(For a non-obvious but just as relevant example, consider how we organize prose into paragraphs with indented first lines, spaces after punctuation, and even how we break passages into sentences paragraphs, chapters, volumes, etc. If you want to get pedantic, the content would remain the same if you just smooshed it into a single stream of text; although many would argue it wouldn't be as intelligible.)

 

So, yeah, there are some stylistic preferences (and a dose of some cargo-cultism, I'm sure), but it's reasonable to appreciate how universal it is across disciplines and media, especially when dealing with complex or high-volume content. It's just how we're wired.

 

dZ.

 

All good points. Looking at the entries in a BASIC 10 liner contest where the lines are 256 or even 120 characters can indeed be difficult to read because every line is indeed a very long stream.

 

But I find a small vertical strip of single commands at the opposite end of the spectrum because it's so sparse.

 

We read left to right accross the page/screen and we look at sentences and paragraphs like you pointed out; I think BASIC is more like simple English than any other language except Structured English Query Language (SQL) and I like reading sentences and paragraphs in both languages the same way I do reading English.

 

Code readability for me breaks down like your analogy; reasonably sized lines coupled with a few small lines and a few long lines (if blocks are good candidates).

 

Other languages don't feel natural or easy to use to the extent of comparing them to English; and they require far more code for being lower level - so far no one is writing Video Games in 10 lines in anything else but BASIC and that hasn't changed since the 70's.

 

Fwiw I like writing BASIC in c dialects as much as some programmers like writing c in BASIC.

[+DZ-Jay]

 

All good points. Looking at the entries in a BASIC 10 liner contest where the lines are 256 or even 120 characters can indeed be difficult to read because every line is indeed a very long stream.

 

But I find a small vertical strip of single commands at the opposite end of the spectrum because it's so sparse.

 

We read left to right accross the page/screen and we look at sentences and paragraphs like you pointed out; I think BASIC is more like simple English than any other language except Structured English Query Language (SQL) and I like reading sentences and paragraphs in both languages the same way I do reading English.

 

Code readability for me breaks down like your analogy; reasonably sized lines coupled with a few small lines and a few long lines (if blocks are good candidates).

 

Other languages don't feel natural or easy to use to the extent of comparing them to English; and they require far more code for being lower level - so far no one is writing Video Games in 10 lines in anything else but BASIC and that hasn't changed since the 70's.

 

Fwiw I like writing BASIC in c dialects as much as some programmers like writing c in BASIC.

 

Like I said, horses for courses.

 

Anyway, I agree that it would be cool to see IntyBASIC represented in the 10 Liners Contest.

 

So... Mr. SQL, will you be picking up IntyBASIC soon?

 

-dZ.

[Mr SQL]

 

Like I said, horses for courses.

 

Anyway, I agree that it would be cool to see IntyBASIC represented in the 10 Liners Contest.

 

So... Mr. SQL, will you be picking up IntyBASIC soon?

 

-dZ.

 

Yes, this BASIC looks awesome I will definitely try it out!

[carlsson]

Wow GroovyBee that's a great Assembler they must have been using - I always wished for the concatenator operator in Assembly because it's ridiculously vertical in the extreme.

That happens to be BBC BASIC that supports inline assembly code with the colon separator between each instruction, just like with other BASIC commands. Thus you have both line numbers for the BASIC listing and assembler labels at the beginning on some lines for JSR/JMP/branch within the assembly code.

Edited September 8, 2016 by carlsson

[+DZ-Jay]

Given the choice, whitespace and comments are where its at for me. As an example of code compression, look at the Elite video game source code from BITD :-

 5280LDX#15:JSRPLS3:CLC:ADCK3:STAK3:TYA:ADCK3+1:STAK3+1:JSRPLS3:STAP:LDAK4:SEC:SBCP:STAK4:STYP:LDAK4+1:SBCP:STAK4+1
 5300LDX#9:JSRPLS1:LSRA:STAK2:STYXX16:JSRPLS1:LSRA:STAK2+1:STYXX16+1
 5310LDX#21:JSRPLS1:LSRA:STAK2+2:STYXX16+2:JSRPLS1:LSRA:STAK2+3:STYXX16+3
 5320LDA#64:STATGT:LDA#0:STACNT2:JMPPLS22
 5330.PLS1 LDAINWK,X:STAP:LDAINWK+1,X:AND#127:STAP+1:LDAINWK+1,X:AND#128
 5340JSRDVID3B2:LDAK:LDYK+1:BEQP%+4:LDA#&FE:LDYK+3:INX:INX:RTS

Taken from the file ELITEE.TXT in http://www.iancgbell.clara.net/elite/archive/a/a4080610.zip

 

Its not very readable like that.

 

I, on the other hand, am insanely obsessive about organizing and commenting my code. I have to, since I have the memory retention of a retarded goldfish (and the attention span to match!), and will likely forget whatever clever thing I was doing 15 minutes from now.

 

Here's an excerpt of the code on which I was working today. This was written four or five years ago, and I am infinitely thankful to my Past DZ Self for being so helpful and forthcoming in leaving me all those notes.

                ; -------------------------------------------------
                ; NOTE: When the sprite is on the center of the
                ;       virtual tile and the exit it is facing is
                ;       closed, it will stop.
                ;
                ;       This is our only special case; all other
                ;       movement possibilities are accounted for in
                ;       our delta look-up table.
                ; -------------------------------------------------
                CMPI    #$01,   R0                      ; \
                BNEQ    @@__mve_do_mv                   ;  |_ Check for special case, stop if at center
                CMPI    #$02,   R1                      ;  |
                BEQ     @@__mve_stop                    ; /

@@__mve_do_mv:  MOVR    R4,     R2                      ; \
                SARC    R2,     1                       ;  | Compose delta table index:
                RLC     R3,     1                       ;  |           6   5   4   3   2   1   0
                                                        ;  |    ..//-+---+---+---+---+---+---+---+
                SARC    R0,     2                       ;   >        | D | D | P | X | X | Y | Y |
                RLC     R3,     2                       ;  |    ..//-+---+---+---+---+---+---+---+
                                                        ;  |          \_____/ \_/ \_____/ \_____/
                SARC    R1,     2                       ;  |             |     |     |       |
                RLC     R3,     2                       ; /             Dir   Dist   X       Y

                ADDI    #ELF_DELTA,             R3
                MVI@    R3,     R0

                MVII    #ELF_OBJ.sX,            R4      ; Point back to @@sX
                SDBD                                    ; \_ Update screen coordinates: @@sX += dx; @@sY += dy
                ADD@    R4,     R0                      ; /     (Double-byte data)

                ; -------------------------------------------------
                ; NOTE: When the Elf is inside the tunnel and he
                ;       reaches the outer boundary of the maze, he
                ;       needs to rollover to the other side.
                ; -------------------------------------------------
@@__mve_chk_bl: SWAP    R0
                CMPI    #MAZE_INFO.x_bnd_lo,    R0      ; \_ Check left tunnel boundary
                BNC     @@__mve_chk_br                  ; /
                ADDI    #.roll_adj_l,           R0      ; Rollover to the right
                B       @@__mve_update

@@__mve_chk_br: CMPI    #MAZE_INFO.x_bnd_hi,    R0      ; \_ Check right tunnel boundary
                BNC     @@__mve_update                  ; /
                SUBI    #.roll_adj_r,           R0      ; Rollover to the left

                ; --------------------------------------
                ; Update sprite position based on the
                ; new coordinates.
                ; --------------------------------------
@@__mve_update: MVO     R0,     ELF_OBJ.sY              ; \
                SWAP    R0                              ;  > Update screen coordinates
                MVO     R0,     ELF_OBJ.sX              ; /

Thank you, Past DZ Self! You're my hero! Now get back to work in fixing what I plan to break next...

 

-dZ.

[Mr SQL]

That happens to be BBC BASIC that supports inline assembly code with the colon separator between each instruction, just like with other BASIC commands. Thus you have both line numbers for the BASIC listing and assembler labels at the beginning on some lines for JSR/JMP/branch within the assembly code.

 

Really cool there was a classic BASIC with that functionality (let alone an Assembler) built right in bitd, I wish the BBC Micro had been popular in the US!

 

I thought I had done something original adding that to vwBASIC

 

10 asm "asm_loop; assembly loop: inc g: lda g: cmp #50: bne asm_loop"

 

[catsfolly]

Catsfolly, I love what you did with Robot Blast. I was trying to use this code you provided to figure out how to do something in a game I'm working on. I'm trying to get a missile to start at a set coordinate (say the center bottom of the screen) and end up at the x,y coordinates of the cursor. In my limited programming experience, I'm previously used For/Next statements achieve this, but found changing value of the variables in a loop is the better way. I'm having a brain cramp because I can't seem to figure out the right way to have the missile start from a specific location but end up at the cursor location. Thanks again for the code. It is incredibly valuable for a newbie like me.

There's no RIGHT way to do it, but there are different approaches you could try.

If we had floating point numbers, we could do it like this (pseudocode);

// compute the distances we need to move in x and y

dx  = cursor_x - start_pos_x

dy  = cursor_y - start_pos_y

// then divide these distances by the number of frames we want to take to get to the destination.

// these are our x and y velocities

SHOTSTEPS = 20

vx = dx/ SHOTSTEPS

vy = dy/SHOTSTEPS

shottimer = SHOTSTEPS

// and initialize the shot position

sdx = start_pos_x

sdy = start_pos_y

// then add this code to the game loop

if shottimer > 0 then

   shottimer = shottimer -1

   sdx = sdx + vx

   sdy = sdy + vy

end if

Of course, we don't have floating point numbers on the intellivision. But if we use 16 bit numbers for the positions and velocities, and scale them by a factor, then we can achieve smooth motion. I used a scale factor of 64, which gives us 6 bits of fractional position.

 

So the basic code looks like this:

        CONST SHOTSTEPS = 20
	CONST SHOT_START_X = 80
	CONST SHOT_START_Y = 96
	CONST POS_SCALE = 64


if shottimer = 0 then 
             if (cont1.B0 + cont2.B0) then 
                      shottimer = SHOTSTEPS : #sdx = SHOT_START_X * POS_SCALE : #sdy = SHOT_START_Y * POS_SCALE 
                      #vx = ((X- SHOT_START_X) * POS_SCALE)
                      if #vx > 0 then #vx = #vx/SHOTSTEPS else #vx = -#vx : #vx = #vx/SHOTSTEPS : #vx = -#vx  
                      #vy = ((Y - SHOT_START_Y)  * POS_SCALE)  
                      if #vy > 0 then #vy = #vy/SHOTSTEPS else #vy = -#vy : #vy = #vy/SHOTSTEPS : #vy = -#vy  
              else #sdy= 120 * POS_SCALE : goto nohit
	      end if
         end if

rem handle shot animation
	shottimer = shottimer -1 
	#sdx = #sdx + #vx
	#sdy = #sdy + #vy 

Here is a variant of RobotBlast with this code added. It is hard to shoot things because of the minimalist collision code, but you can try it out:

 

rbv1.rom

 

robotblast_rv1.bas

 

Catsfolly

 

Edit: Here's a gif for gif fans...

<-- click to animate

 

 

 

 

Edited September 9, 2016 by catsfolly