GoSub for INTV

[catsfolly]

Gee. I got the animated seaweed done by myself, but I know absolutely nothing about the INTV hardware. I wonder how inefficient my code is. But I doubt that it doesn't really matter how much frames I waste since all I'm doing is moving the sub and octopus? But the thing is, IT WORKS (at least in an emulator.) Yes, I'm doing this in INTVBasic. I've attached the latest version and the code here. But now I'm at 8.5 kb, so I doubt I'll have much room for a fancy title screen and the one now will have to do.

Generally it's not bad, but in this case, it's pretty inefficient.

 

The most efficient way to animate the seaweed is not to rewrite the whole screen, but instead to redefine the seaweed gram character.

 

My recommendation would be:

 

1. take out all your seaweed animation code.

 

2. add this line before the wait in mazemain:

	if keynoisetimer>10 then keynoisetimer=10 : sound 0,,0

	GOSUB animate_seaweed   ' <--- add this line

	WAIT

3. Add some seaweed tiles:

tiles:
	BITMAP "....1..."
	BITMAP "...1...1"
	BITMAP "111.111."
	BITMAP "..11...1"

	BITMAP ".1...1.."
	BITMAP "1.111..."
	BITMAP "....111."
	BITMAP "...1...."

tile2:
	BITMAP "...1...."
	BITMAP "...1...1"
	BITMAP "111.111."
	BITMAP "..11...1"

	BITMAP "1...1..."
	BITMAP "1.111..."
	BITMAP "....111."
	BITMAP "...1...."
tile3:
	BITMAP "..1....."
	BITMAP "...1...1"
	BITMAP "111.111."
	BITMAP "..11...1"

	BITMAP "1...1..."
	BITMAP "1.111..."
	BITMAP "....111."
	BITMAP "...1...."

tile4:
	BITMAP "...1...."
	BITMAP "...1...1"
	BITMAP "111.111."
	BITMAP "..11...1"

	BITMAP ".1...1.."
	BITMAP "1.111..."
	BITMAP "....111."
	BITMAP "...1...."
	

4. Finally, add this routine (near the end of gosub.bas) :

animate_seaweed: PROCEDURE
	
	if ((frame AND $1f)> 0) then goto as_done

	temp = frame /16

        temp = (temp/2) AND 3

	if (temp = 0) THEN define 16,1,tiles : goto as_done
	if (temp = 1) THEN define 16,1,tile2 : goto as_done
	if (temp = 2) THEN define 16,1,tile3 : goto as_done
	if (temp = 3) THEN define 16,1,tile4 : goto as_done

as_done:
	
	RETURN
	END

Done. No slowdowns.

 

(The seaweed animation is just a placeholder... )

 

Catsfolly

[+atari2600land]

EDIT: The error is my fault, but now the seaweed won't show up.

Edited September 26, 2014 by atari2600land

[catsfolly]

EDIT: The error is my fault, but now the seaweed won't show up.

You do have to draw the maze initially.

 

Did you put this code back?

       read #line
        for x=0 to 19

        if #line and $8000 then print at y*20+x+2,"\272"
        #line = #line * 2
        next
        next

 

Edited September 26, 2014 by catsfolly

[+atari2600land]

OK, I found the error and I fixed it, but the seaweed won't animate.

[catsfolly]

OK, I found the error and I fixed it, but the seaweed won't animate.

??????

Works for me.

 

If you send me the source code (in a PM?) I'll look at it...

[+atari2600land]

OK, thanks to catsfolly, I have got a new, better code for the seaweed animation that shouldn't slow down. DZ-Jay, are you testing these binaries on a real Intellivision? The previous one didn't slow down in jzintv (the emulator). So I guess this means I can go to 32k without any problems. That should be enough space for a good amount of levels.

Edited May 30, 2015 by atari2600land

[+cmart604]

Its a process that works for us .

Lol! Yep, you need a few more steps, including:

 

How can we get more bacon into this game?

What will Shat think of this?

Briefly consider Rev's ongoing request for an ice level and then summarily dismiss it out of hand.

Ponder how the art on screen will translate to boxes and overlays.

 

[+DZ-Jay]

OK, thanks to catsfolly, I have got a new, better code for the seaweed animation that shouldn't slow down. DZ-Jay, are you testing these binaries on a real Intellivision? The previous one didn't slow down in jzintv (the emulator). So I guess this means I can go to 32k without any problems. That should be enough space for a good amount of levels.

 

No, I was testing on jzIntv. It was indeed pausing for a frame during the animation. In any case, congratulations! It's working fine now. Great work!

 

I will play it some more a bit later and provide some feedback.

 

-dZ.

[+atari2600land]

Here I fixed a bug pertaining to the turning of the sub. If you died during the middle of a turn, the sideways sprite would show up once you reset. This I think has now been fixed.

 

Edited May 30, 2015 by atari2600land

[+atari2600land]

New level 13.

Edited May 30, 2015 by atari2600land

[Cybearg]

Maybe I'm mistaken, but doesn't IntyBasic support Tiled for designing your screens? I'm not sure exactly how it works, but I thought I recalled reading that somewhere...

 

If so, that might help you speed along the design process, if you're not already using it for levels.

 

Also, for testing purposes, maybe there could be some way to key in the level one wants and directly jump to it as a debug mode feature, rather than having to play through the full game?

[+atari2600land]

For designing levels, I am using Paint. I made a blank board template then I black out the squares I want in and then using my chart I made of binary sets, I type in the data in data statements. Pretty crude, I guess, but it gets the job done.

[Cybearg]

New level 13.

Beat it, though it took me probably 30 tries at least.

 

I haven't played it for the other levels to be honest, but the level design seems solid. As long as you keep getting good ideas, keep cranking 'em out, I guess.

 

Does the entire game need to be completed in just those 2 lives, or is there a way to get more?

[+Tarzilla]

Gee. I got the animated seaweed done by myself, but I know absolutely nothing about the INTV hardware. I wonder how inefficient my code is. But I doubt that it doesn't really matter how much frames I waste since all I'm doing is moving the sub and octopus? But the thing is, IT WORKS (at least in an emulator.) Yes, I'm doing this in INTVBasic. I've attached the latest version and the code here. But now I'm at 8.5 kb, so I doubt I'll have much room for a fancy title screen and the one now will have to do.

 

I've had a chance to have a look at your code, you might make things easier on yourself if you used the GOSUB command in your code, kind of ironic that you don't, considering the name of your game...

 

For instance, where you have this:

    if room=1 then goto maze2
    if room=2 then goto maze3
    if room=3 then goto maze4
    if room=4 then goto maze5
    if room=5 then goto maze6
    if room=6 then goto maze7
    if room=7 then goto maze8
    if room=8 then goto maze9
    if room=9 then goto maze10
    if room=10 then goto maze11
    if room=11 then goto maze12

I'd replace it with

GOSUB DRAWMAZES

and create a PROCEDURE to isolate the IF statements

DRAWMAZES: Procedure

    if room=1 then goto maze2
    if room=2 then goto maze3
    if room=3 then goto maze4
    if room=4 then goto maze5
    if room=5 then goto maze6
    if room=6 then goto maze7
    if room=7 then goto maze8
    if room=8 then goto maze9
    if room=9 then goto maze10
    if room=10 then goto maze11
    if room=11 then goto maze12
End

You'll have to make maze2, maze3 etc Gosubs as well.

 

Using GOSUB to isolate logical blocks of code will make seeing your game loop and basic flow easier to follow. It will also make it easier when your game is bigger in order to move Procedures into the next available ROM space.

Edited September 26, 2014 by Tarzilla

[+atari2600land]

 

Does the entire game need to be completed in just those 2 lives, or is there a way to get more?

You get three chances per maze. So even if you complete the maze on your third chance, you still get three chances on the new maze.

[+nanochess]

 

I've had a chance to have a look at your code, you might make things easier on yourself if you used the GOSUB command in your code, kind of ironic that you don't, considering the name of your game...

 

For instance, where you have this:

    if room=1 then goto maze2
    if room=2 then goto maze3
    if room=3 then goto maze4
    if room=4 then goto maze5
    if room=5 then goto maze6
    if room=6 then goto maze7
    if room=7 then goto maze8
    if room=8 then goto maze9
    if room=9 then goto maze10
    if room=10 then goto maze11
    if room=11 then goto maze12

I'd replace it with

GOSUB DRAWMAZES

and create a PROCEDURE to isolate the IF statements

DRAWMAZES: Procedure

    if room=1 then goto maze2
    if room=2 then goto maze3
    if room=3 then goto maze4
    if room=4 then goto maze5
    if room=5 then goto maze6
    if room=6 then goto maze7
    if room=7 then goto maze8
    if room=8 then goto maze9
    if room=9 then goto maze10
    if room=10 then goto maze11
    if room=11 then goto maze12
End

You'll have to make maze2, maze3 etc Gosubs as well.

 

Using GOSUB to isolate logical blocks of code will make seeing your game loop and basic flow easier to follow. It will also make it easier when your game is bigger in order to move Procedures into the next available ROM space.

 

I would suggest to use GOSUB also instead of GOTO, and put a RETURN at end of PROCEDURE. Otherwise the stack would grow little by little until the ultimate failure.

[+Tarzilla]

 

I would suggest to use GOSUB also instead of GOTO, and put a RETURN at end of PROCEDURE. Otherwise the stack would grow little by little until the ultimate failure.

 

So END to close a Procedure isn't automatically a RETURN?

 

So this is wrong?

DoSomething: Procedure

X=1

END

 

This is correct?

DoSomething: Procedure

X=1

 

RETURN

END

[+atari2600land]

can I do this?

on room goto maze2 maze3 maze4 maze5 ...

[+nanochess]

 

So END to close a Procedure isn't automatically a RETURN?

 

So this is wrong?

DoSomething: Procedure

X=1

END

 

This is correct?

DoSomething: Procedure

X=1

 

RETURN

END

 

You're right. END implicitly includes RETURN

 

can I do this?

on room goto maze2 maze3 maze4 maze5 ...

 

I want to put it in next version of IntyBASIC and also the ON expr GOSUB, it would be very useful

[+atari2600land]

OK, so I put in the gosub drawmazes thing Tarzilla suggested. It will stop working after level 13 because I haven't designed level 14 yet. And since there will be a special end of game screen, I don't need to put a goto statement to go to the title screen. So this will work. I just don't understand, though, why this is better than what I had before.

Edited May 30, 2015 by atari2600land

[+Tarzilla]

OK, so I put in the gosub drawmazes thing Tarzilla suggested. It will stop working after level 13 because I haven't designed level 14 yet. And since there will be a special end of game screen, I don't need to put a goto statement to go to the title screen. So this will work. I just don't understand, though, why this is better than what I had before.

GoSub vs GoTo is all about program Flow Control and readability. Constant GOTOing around makes debugging a pain for large projects. It isn't a case of only use one or the other, you still will have some GoTos but use GoSub to isolate logical blocks of code together.

 

ResetGame:

Gosub DrawTitleScreen

Gosub InitializeVariables

titleloop:

Gosub UpdateAnimationCounters

gosub updatetitleframe

gosub CheckTitleScreenForKeys

GOTO titleloop

'GameStart:

' GoSub SetupGame

'GameLoop:

' Gosub CheckKeys

' GoSub MovePlayer

' GoSub MoveEnemy

' GoSub Check Collisions

' GoSub UpdateAnimations

' Goto GameLoop

This method Is way easier to debug and read vs if all the code that would normally be isolated in a Procedure was just in one long block with constant GOTO jumping around. I can see my program flow on one screen instead of 10 or 20 screens.

If the Procedure for InitializeVariable contains 50 lines of code, I shouldn't need to see all 50 lines, just the Gosub command.

The example of Gosub Maze2 etc above may not have been the best example to use when encouraging Gosubs, try the attached file for a real example.

sampletitleanimated.bas

sampletitleanimated.bin

Edited September 26, 2014 by Tarzilla

[+Tarzilla]

 

You're right. END implicitly includes RETURN

 

 

I want to put it in next version of IntyBASIC and also the ON expr GOSUB, it would be very useful

Include Files directives would be MORE useful

[Cybearg]

What is the cycle cost of those extra GOSUBs? Is it essentially insignificant?

 

By the way, what is a cycle exactly? Is it 1hz? The CPU that Inty uses is technically a good couple hundred thousand hertz slower than the 2600's 6507, yet Inty strikes me as having more processing power. Why is that, or am I just mistaken?

[catsfolly]

 

GoSub vs GoTo is all about program Flow Control and readability. Constant GOTOing around makes debugging a pain for large projects. It isn't a case of only use one or the other, you still will have some GoTos but use GoSub to isolate logical blocks of code together.

 

ResetGame:

Gosub DrawTitleScreen

Gosub InitializeVariables

titleloop:

Gosub UpdateAnimationCounters

gosub updatetitleframe

gosub CheckTitleScreenForKeys

GOTO titleloop

'GameStart:

' GoSub SetupGame

'GameLoop:

' Gosub CheckKeys

' GoSub MovePlayer

' GoSub MoveEnemy

' GoSub Check Collisions

' GoSub UpdateAnimations

' Goto GameLoop

This method Is way easier to debug and read vs if all the code that would normally be isolated in a Procedure was just in one long block with constant GOTO jumping around. I can see my program flow on one screen instead of 10 or 20 screens.

If the Procedure for InitializeVariable contains 50 lines of code, I shouldn't need to see all 50 lines, just the Gosub command.

The example of Gosub Maze2 etc above may not have been the best example to use when encouraging Gosubs, try the attached file for a real example.

sampletitleanimated.bas

sampletitleanimated.bin

 

Cool!

 

[+atari2600land]

Cool as well! I can use this in my game, right? Here's what it would look like. I worked on a level 14 and made it before I saw that. When I put that in there, I saw that I can switch back and forth from using mode 0 and mode 1. Not only that, it used only 1.5 k!

Edited May 30, 2015 by atari2600land