Billy Ball and Bobby Ball!

[Retrospect]

BILLY2 < Compiled program runs in XB

 

BILLY BALL DEMO 2.txt < Source code in XB256

 

This is a little demo showing the scrolling in XB256 for anyone who hasn't seen it yet.  Also you can have the documented source code and play around with it.

Study the code and you'll find the lines where you can alter values to make Billy bounce faster, or make Bobby fire more often etc.

 

There's a comment in there about turning line 1100 into a commented line to make Billy move faster. Don't do that, it was a mitsake.  Just alter the value in line 16100 to a small one or even zero to make him move quicker!

 

Edited November 1, 2021 by Retrospect

[Retrospect]

BILLY3-X  < XB compiled program

billy ball demo 3.txt < The source code to play with.  

 

Here we start to push the TI a little in regards all the things that are happening.  The program works down a list of Gosub's ... we have 3 layers of scrolling for the ground, twinkling starfield that scrolls on a timer, leftwards, 2 balls that not only bounce up and down they spin round now with faces, they fire a missile each that doesn't use auto-motion (but you can rework the code if you like to do that?) and just for chuckles we have the word "BALLS" bouncing up and down in massive letters.  Also when Bobby Ball (the blue one) dies, he goes through a proper death sequence whilst everything else continues to move.  It's all in the source code documented for new-starters, I aren't the best documenter in the world but I tried my best. You'll get the gist of what's going on. 
 

[+TheBF]

These are really great demos. Thanks for doing them.

I have used one of your designs to improve my graphics language in the past.

You have raised the bar very high with these ones. As time permits I have to see how I would do this kind of thing.

The way you have laid out the source code makes it very clear to understand.

[unhuman]

This does 5 things:

1. Inspires me to write again.  I have got to get back to my game... 
2. Really optimizes development process.  One could save the effects for later in the development process, speeding up the development cycle (since regular XB is so slow), yet easy to add later.  Really cool.
3. Highlights how little code is actually needed to do very cool things.
4. We could wind up with a reusable library of tricks just like this.  Or a website with a list of snippets?
5. I mentioned how I'm inspired, right?  But, then frustrated by time, or my challenges managing it.

 

[Retrospect]

Here's another little example, this is more of a game.  But it's an easy one, for now. We can work with it!

 

Documented source code , for you to play with and alter to your will.  You'll need to use XB256 and compile it for it to run as intended.

 

BILLY4  < -- the compiled program

BILLY BALL AND THE ASTEROIDS.txt < --- Documented source code.

 

[Retrospect]

This time we use CALL MOTION for billy instead of incrementing a variable for his position.  This is indeed faster.  

However, his missile is still incremented on a variable, for a very good reason.  Each time the missile sprite re-locates on the incremented variable, it checks all four asteroids for collision.  I believe this to be far more accurate and reliable than CALL COINC would be if the missile was using CALL MOTION.

 

Billy is currently using CALL MOTION value of 32, you could try changing it to a higher value if you want to attempt more speed.

 

BILLY5-X << XB compiled program

BILLY BALL AND THE ASTEROIDS REV 2.txt << Revised source code with call motion.

[Retrospect]

3 hours ago, unhuman said:

This does 5 things:

1. Inspires me to write again.  I have got to get back to my game... 
2. Really optimizes development process.  One could save the effects for later in the development process, speeding up the development cycle (since regular XB is so slow), yet easy to add later.  Really cool.
3. Highlights how little code is actually needed to do very cool things.
4. We could wind up with a reusable library of tricks just like this.  Or a website with a list of snippets?
5. I mentioned how I'm inspired, right?  But, then frustrated by time, or my challenges managing it.

 

its great that this has inspired you to get back into it , unhuman.   Inspiring creativity is my goal here.  And of course having fun.

[+TheBF]

1 hour ago, Retrospect said:

Here's another little example, this is more of a game.  But it's an easy one, for now. We can work with it!

 

Documented source code , for you to play with and alter to your will.  You'll need to use XB256 and compile it for it to run as intended.

 

BILLY4  < -- the compiled program

BILLY BALL AND THE ASTEROIDS.txt < --- Documented source code.

 

 

Oh man now I have to really work harder!

 

[SteveB]

Why the CALL LINK("WINDOW"...) here?

16410 T4=0::CALL LINK("WINDOW",14,1,14,32)::CALL LINK("SCPXLF",152,4,1)

I thought the SCPXLF works on the CHAR 152 to 155, independent on their placement on the screen? In contrast to the CALL LINK("SCRLLF”[,number]) which scrolls full characters within the currently defined window.

 

Otherwise great demos ... I just spent 3 evenings just to figure out that my approach is flawed ... and you publish 3 beautiful demos in less than that.

[+TheBF]

2 hours ago, SteveB said:

Why the CALL LINK("WINDOW"...) here?

16410 T4=0::CALL LINK("WINDOW",14,1,14,32)::CALL LINK("SCPXLF",152,4,1)

I thought the SCPXLF works on the CHAR 152 to 155, independent on their placement on the screen? In contrast to the CALL LINK("SCRLLF”[,number]) which scrolls full characters within the currently defined window.

 

I was just looking at that myself and wondering how to make that happen in Forth. Pixel level scrolling... very clever!

[Retrospect]

2 hours ago, SteveB said:

Why the CALL LINK("WINDOW"...) here?

I may be wrong, but I thought they needed separate window boundaries.  

[Retrospect]

Here's another example for us.  This one certainly needs improvement.  These are for you guys to tear your hair out with though, no me, I'm on with a larger project at the moment!   You'll like this one though.  A space shoot-em-up demo with player ship, player missile, enemy ship, enemy missile, and 2-layer scrolling background.  

 

Use Joystick to control player ship up and down and fire to, well, fire ...

 

Study the code and alter it , add to it, improve it .... 

 

SPACE-X < Compiled XB256 program

SPACE DEMO.txt < Source code 

 

[Retrospect]

I've hacked-in a second enemy into the space demo, it's a UFO that creeps up from behind the player.

As a consequence, I've made the player able to move left and right now, as well as up and down.

The UFO will kill the player should it hit him/her.   So they have to be avoided or better still, shot.

When you shoot one, it will fall to the ground.  The main enemy has another trick up it's sleeve now, also.  

When it comes on, it has 3 speeds and it chooses them at random.  Have fun.  

 

SPACE2-X < XB Compiled code (xb256)

SPACE DEMO 2.txt < XB256 documented source

 

[+Vorticon]

Awesome work. You've really mastered the use of Senior Falcon's XB enhancements and compiler. 

Just imagine the kind of software we would have had by now if these tools had been available in the 80's...

[Retrospect]

11 minutes ago, Vorticon said:

Awesome work. You've really mastered the use of Senior Falcon's XB enhancements and compiler. 

Just imagine the kind of software we would have had by now if these tools had been available in the 80's...

Thanks Vorticon.  There's much more to explore too, there's the sprite-early clock, the in-game music that uses assembly space, all these things i have to learn myself yet

Oh if we'd had things like this in the 80s it would have been a game-changer.  TI themselves should have brought stuff like this out instead of being so closed down.  At least for those with 32K and disk systems it would be very different with all this.  

[Retrospect]

Now the player has lives.  Yesterday I was tired and forgot to have the UFO actually use the array that it was meant to for it's movement.  It uses it now, it's the same array that the main enemy uses, except the UFO uses it for it's left/right movement.   The player also has a proper death sequence.

 

This is as far as I'm going with this particular example.  

 

SPACESHIP < Load this into XB and get ready to get shot a lot.

SPACE DEMO 2A.txt < Documented sauce.

 

My painful attempt at playing it.

 

[Retrospect]

Now the player has lives.  Yesterday I was tired and forgot to have the UFO actually use the array that it was meant to for it's movement.  It uses it now, it's the same array that the main enemy uses, except the UFO uses it for it's left/right movement.   The player also has a proper death sequence.

 

This is as far as I'm going with this particular example.  

 

SPACESHIP < Load this into XB and get ready to get shot a lot.

SPACE DEMO 2A.txt < Documented sauce.

 

My painful attempt at playing it.

 

[Retrospect]

For some reason the above example uploaded twice?

 

Right ... back to the balls.  This example is again pushing the TI in regards of speed of execution.  It has 8 balls, each one has a face that spins and each is at a different pattern to start with.  The user is asked for two things in an input parser, the incrementation number, meaning how many pixels to increment each ball, and the ball spin number, meaning how many patterns it should skip.  If you type 1 and 1 , then you'll get 1 pixel incrementation and no pattern skips.

To note; the program execution is slow because the patterns for the balls are all done by CALL CHAR since there are 23 patterns.  If we had less patterns we could get away with CALL PATTERN and use character numbers such as 96,100,104,108 etc , and that would be a lot quicker.  

OH BALLS!.txt < Documented, but rather badly written, source code
OHBALLS < The XB program

OH BALLS!.txt OH BALLS!.txt

Edited November 3, 2021 by Retrospect

[Retrospect]

This demo comes with no source code.  As it's a possible future project of mine. Point is, this one's using simple character-scrolling on timers, for the ground and "roof" and for the star scroll.  It really is possible to make a Gradius style game in XB256 and the Compiler.  Okay I've pushed it enough now, so folks, if you are interested and you have the time, please use the 256 extension and compiler it will provide you with so much fun and satisfaction.  

 

[+TheBF]

18 hours ago, Retrospect said:

To note; the program execution is slow because the patterns for the balls are all done by CALL CHAR since there are 23 patterns.  If we had less patterns we could get away with CALL PATTERN and use character numbers such as 96,100,104,108 etc , and that would be a lot quicker.  

Another intriguing demo.  I am still noodling on how to best pixel scroll the grass.  :) 

XB265 is a monster to try and match.

 

I don't understand the limitations on CALL PATTERN().

Please explain.

[Retrospect]

52 minutes ago, TheBF said:

limitations on CALL PATTERN()

Hi BF

If I didn't want to redefine a pattern from an array, and wanted it to be faster (and less memory consuming) I would want to use CALL PATTERN.
Here's the difference;
CALL PATTERN needs a number like 92,96,100, and so on, that are already defined .... so we might have a quick animation using this;
100 FOR A=92 TO 128 STEP 4 :: CALL PATTERN(#1,A) :: NEXT A
That would redo the pattern of sprite 1 to whatever is defined in 92,96,100,104,108,112,116,120,124 and 128.

You can see the issue I might have with billy ball's patterns.  There's 23 of the buggers.  And we already need patterns for the different sprites.  So I have to "upload" patterns "on the fly" from an array instead.

DIM A$(23) :: FOR L=1 TO 23 :: READ X$ :: A$(L)=X$ :: NEXT L
101010101241g31g10341414134135015013,124023502302302300520350230520322352352
etc etc etc

And then I would do this;
100 FOR L=1 TO 23 :: CALL CHAR(92,A$(L)) :: NEXT L

That alone will animate Billy with all 23 patterns but it is my belief that not only is this method a life-saver, it's a little slower on the access time as it isn't an instantly defined character it has to "draw" from fresh each time, and it takes up quite a bit of "stack space".   

[+TheBF]

Thanks for the explanation.

 

I am wondering if the fact that you are keeping the data twice in the program why the stack space gets consumed. (no nothing about XB256 internals) 

By that I mean you have it in DATA statements and then you copy the data into an array so it exists in two places in the computers memory.

The only way I know of avoiding that in BASIC it to read the data from a file. 

 

Anyway you have given me no end of homework. 

I am going to try creating your OHBALLS demo where each of the 8 sprites is its own TASK and see how much performance degrades on my system.

These are great ways for me to see if my Graphics code works as intended.  

 

 

 

[Retrospect]

Good luck with the balls!  

 

One thing I could do, and I suppose you too if you wanted, would be to halve the amount of definitions we have for the ball.

For example delete one in every two.  You'd probably have enough characters to define them all without using an array that way.

Plus then , the execution speed would step up a little. Saying that, the demo I did with the 8 balls effectively does that for us by giving us the choice of Steps to have.  

Edited November 4, 2021 by Retrospect

[+TheBF]

Well... 

I don't actually have that limitation in Forth because I can define the data in place in memory when I compile the program.

Then I write a little piece of code (ie: a sub-routine) that makes that block of memory look like an array for me.

 

It's more like how it's handled in Assembly Language.

 

However I don't have all the magic functions that you can use in your XB256 box of tricks ?

[Retrospect]

1 hour ago, TheBF said:

XB256 box of tricks

Senior Falcon wrote the routines in Assembly, that perform these tricks.  Ask him, for some source, he may be able to provide, so that you could do the equivalent in Forth?