Jump to content
  • entries
    34
  • comments
    88
  • views
    26,008

bBasic - PF Height Animation


Robert M

490 views

 Share

Goals:

-> Try to create an animation of pf graphics using the pfheight kernel option.

-> Gain more experience with bBasic syntax

-> Still no user interation.

 

Design:

-> Base on the HelloWorld program.

-> Turn on the pfheights kernel option.

-> Create an on...goto statement that maps to a 16 frame circular animation that bounces and stretches "HelloWorld".

-> the code for each frame will set the pfheights.

 

Implementation:

PFanimation.txt

PFanimation.txt.bin

 

Lessons learned:

-> RTFM! The syntax for an ON...GOTO does not include commas (I was still thinking of the C64 basic :P) Putting commas into an ON...GOTO statement makes for some wild compiler errors.

-> Also, if-statements do not like parenthesis on the condition side.

 

Recommendations for improving bBasic:

-> The language really needs an ON...GOSUB statement in addition to the ON...GOTO. I was forced to use a clumsy system of gotos to get back to the mainloop of code from the frame setup routines. The resulting code is brittle and harder to read. Plus I can't reuse my frame routines in a different on...goto statement.

 

Up Next:

-> Exercising the multisprite multiplexing algorithm.

 Share

6 Comments


Recommended Comments

Recommendations for improving bBasic:

-> The language really needs an ON...GOSUB statement in addition to the ON...GOTO. I was forced to use a clumsy system of gotos to get back to the mainloop of code from the frame setup routines. The resulting code is brittle and harder to read. Plus I can't reuse my frame routines in a different on...goto statement.

I think Fred/batari is going to have "on...gosub" in the next version, because it turns out that it's easy to implement. However, in the meantime there *is* a way to reuse your routines in other "on...goto" statements. First, put your "on...goto" statements in their own subroutines, so you can "gosub" to the one you want. But you do *not* need to put a "return" after each "on...goto" statement. (On the other hand, putting a "return" after each one *would* keep you from falling through if none of the "goto" branches are taken.) Then end each *frame* subroutine with "return":

 

   rem * Example 1
loop
  rem * some stuff
  if this then gosub here else gosub there
  drawscreen
  goto loop
here
  on something goto frame1 frame2 frame3
  return : rem * just to prevent unwanted fall-through
there
  on somethingelse goto frame1 frame2 frame3
  return
frame1
  rem * some stuff
  return
frame2
  rem * some stuff
  return
frame3
  rem * some stuff
  return

 

   rem * Example 2
loop1
  rem * some stuff
  gosub here
  drawscreen
  if this then goto loop2
  goto loop1
loop2
  rem * some stuff
  gosub here
  drawscreen
  if that then goto loop1
  goto loop2
here
  on something goto frame1 frame2 frame3
  return : rem * just to prevent unwanted fall-through
frame1
  rem * some stuff
  return
frame2
  rem * some stuff
  return
frame3
  rem * some stuff
  return

 

By the way, I concur with SpiceWare-- neato!

 

Michael

Link to comment
I think Fred/batari is going to have "on...gosub" in the next version, because it turns out that it's easy to implement.

Yeah, the code is in place and working, though not officially released yet. I remember making a DOS/Windows build with this functionality and sent it to someone in a PM but I may have posted it to the forum as well.

Link to comment
I think Fred/batari is going to have "on...gosub" in the next version, because it turns out that it's easy to implement.

Yeah, the code is in place and working, though not officially released yet. I remember making a DOS/Windows build with this functionality and sent it to someone in a PM but I may have posted it to the forum as well.

 

 

That's great news. I think ON...GOSUB will prove very useful. Do you have a planned release date?

Link to comment
I think Fred/batari is going to have "on...gosub" in the next version, because it turns out that it's easy to implement.

Yeah, the code is in place and working, though not officially released yet. I remember making a DOS/Windows build with this functionality and sent it to someone in a PM but I may have posted it to the forum as well.

 

 

That's great news. I think ON...GOSUB will prove very useful. Do you have a planned release date?

I quit planning release dates when I found I always underestimated how long everything took :)

 

That said, I've been meaning to release a 1.01 version that includes the changes since 1.0, which mostly consist of bugfixes and minor additions. The only thing stopping me is laziness at this point, as it will probably just take a couple of evenings to put all of the files together, modify the web site and write documentation for the new commands (there are 3 of them, I think.)

 

I also saw what you wrote in another entry about using custom kernels with bB. I think that's great and I wish more people would do that. bB can work well witg a custom kernel, allowing you to fill out the game logic with bB code. Compiled code will almost certainly be larger and slower than pure assembly, but I don't think it's that bad, and as long as you have the space and enough cycles in your overscan and vblank areas, it should work quite well.

 

Using custom kernels in bB isn't necessarily difficult. The easiest way is to simply paste one in as inline asm, but this is the least efficient way to do it and it probably isn't as useful as modularizing an existing kernel to be called with drawscreen by making your own includesfile, and use your own headers but modify them just enough so bB will build.

 

Doing so may require adding some variable equates or changing some to match those that bB expects. I can't think of all that is needed offhand, but bB will let you know if it tries to access an equate that doesn't exist (by failing in the assembly stage.) You don't need a-z, as bB can use any equate you specify, but you will probably want, at the very least, the score variables and pointers, temp variables (temp1-temp7, though not all are strictly needed) and maybe the random number variable, rand (and rand16 to use a 16-bit LFSR.))

Link to comment
First, put your "on...goto" statements in their own subroutines, so you can "gosub" to the one you want. But you do *not* need to put a "return" after each "on...goto" statement. (On the other hand, putting a "return" after each one *would* keep you from falling through if none of the "goto" branches are taken.) Then end each *frame* subroutine with "return"

 

That's a good work around. Thanks!

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...