Is There A Sample Code Set For Inty Running Man?

[blainelocklair]

Hello everyone!

 

Is there a sample code set in the .bas files somewhere for the classic Inty running man? I've been through nearly all of the samples but the use of the code to generate the animated running man isn't completely clear to me.

 

Thanks!
Blaine

[+DZ-Jay]

Hello everyone!

 

Is there a sample code set in the .bas files somewhere for the classic Inty running man? I've been through nearly all of the samples but the use of the code to generate the animated running man isn't completely clear to me.

 

Thanks!

Blaine

 

The Running Man animation is not in ROM. Whichever game uses it, has its own copy of the animation graphic cards.

 

Those old Mattel games utilized the EXEC operating system of the Intellivision, which allows you to give it a pointer to an array of animation cards, and it would animate them for you automatically. Nowadays, with IntyBASIC, you will have to write your own animation routine to do so.

 

There are two common techniques for animation: card cycling and GRAM cycling.

• Card Cycling: You load all your animation cards into GRAM contiguously, and on every animation frame, you update the card number on the sprite to point to the next card, recycling back to the first one at the end.
• GRAM Cycling: You point your sprite to a single GRAM card, then on every animation frame, you upload a new card into that same spot on GRAM, replacing the previous one.

Both are effective: the first one is faster, but requires a big chunk of GRAM at once for all animation cards to be pre-loaded. Since there are only 64 slots available in GRAM, some prefer to conserve them for other sprites or additional details. I know I do.

 

The second one requires you to update GRAM during the vertical blanking, which can be costly if you have many animations to perform at once. The upside is that each animated sprite or background card only takes a single slot in GRAM at a time, allowing you to maximize its use.

 

Take a look at some of the examples with sprites. They should show how to load cards into GRAM and animate them.

 

-dZ.

Edited November 27, 2018 by DZ-Jay

[carlsson]

Also remember that if you use GRAM cycling and the character is moving in either direction, you need to use at least 2 GRAM cards to cover the case the character overlaps to the next square, up to 4 cards if the character would be moving in two directions. Obviously you can store each frame pre-shifted as 2 cards to load, otherwise you need to both shift graphics data and redefine the GRAM characters you are reusing. I'm in the middle of evaluating various methods of implementing soft sprites, when it is more expense than gain compared to using a MOB (sprite).

 

Of course if the running man (or any other animation) stays in place, the GRAM cycling is a more obvious alternative to using a MOB.

[+DZ-Jay]

Also remember that if you use GRAM cycling and the character is moving in either direction, you need to use at least 2 GRAM cards to cover the case the character overlaps to the next square, up to 4 cards if the character would be moving in two directions. Obviously you can store each frame pre-shifted as 2 cards to load, otherwise you need to both shift graphics data and redefine the GRAM characters you are reusing. I'm in the middle of evaluating various methods of implementing soft sprites, when it is more expense than gain compared to using a MOB (sprite).

 

Of course if the running man (or any other animation) stays in place, the GRAM cycling is a more obvious alternative to using a MOB.

That only applies for animating on the background. The Running Man is most likely to be animated as a MOB.

 

dZ.

[+nanochess]

Actually the running man is not so "available" because it's a trademark of Intellivision Prods.

 

If you've my book, the Monkey Moon example shows you how to animate a sprite by defining all bitmaps first and then cycling the right frame in the third parameter of SPRITE statement.

 

The other option is to keep fixed the third parameter and use the DEFINE statement to change the bitmap.

[blainelocklair]

Great info! I was guessing that the animations were pre-defined BMP files, but didn't know how to cycle them as part of the movement process. With running man or similar, they'd have to be moving upon controller input being received or as some element of the game not in the player's control. I think of Tron Deadly DIscs as an example. They are all running man characters, with one under the player's control and the others under the computer's control. None animate when there is no movement and all animate individually when there is movement. Running man doesn't have to the character, just the concept, for me to grasp this. I've modified some of the BMP images in separate copies of the provided sample project files, so I can at least create single-color 8x8 BMP sprites. I'll dig into how to animate them and see what I can accomplish. I think sometimes my grand ideas in my head are ahead of my learning curve for IntyBASIC. I've at least figured out music, sound, BMP creation, background screen color, text printing, and some other basic stuff. Everyone starts somewhere, don't they?

 

Thanks!
Blaine

[+DZ-Jay]

So, what you do is implement something called a "state machine." In simple terms, your sprites exist through various "states," depending on conditions in the game.

 

A simple example could be a player sprites that can be in one of the following states:

* Inactive - out of the play field, or just not participating in game play yet.

* Rest - standing still.

* Running - actively running around the play field.

* Dead - killed by enemy bullet.

 

Depending on the current state of the sprite, it could behave differently. For instance, while "Running" you could have the running man animation active, and then skip it when the state switches to "Rest" or anything else. Or, while "inactive" the sprite may skip collision detection; etc.

 

If you implement such states are sequential numbers (and use constants for them), you could use something like the ON GOSUB statement to call an appropriate routine based in the current state.

 

This is basically what the TRON game does. When the player presses the disc, it switches the state of the sprite to "Running," and when the player lets go of the disc, it switches it back to "Rest."

 

The animation engine then only has to say, "is it 'Running'? If so, then animate it; else skip animation."

 

Does this make sense?

dZ.

[carlsson]

Here is an example of an animated MOB. If you press the button (a couple of times), it animates on its own and if you press the button again, it will only animate when you move it.

 

 

 REM Running Something
 
 INCLUDE "../samples/constants.bas"
 
 MODE 1:DEFINE 0,4,gfx:WAIT
 
 FOR x=0 TO 11
   PRINT AT x*20 COLOR BG_WHITE + FG_BLUE,"                    "
 NEXT
 
 x=40:y=80:ox=0:dx=0:mf=0:ta=0
 
loop:
  fc=fc+1 : REM frame counter, to slow the animation down
  IF fc>4 THEN
    fc=0
    IF ta=1 OR ox<>x THEN
      mf=mf+1:ox=x:IF mf>3 THEN mf=0 : REM frame number to display
      SPRITE 0,$200+x-4*dx,$100+y+$400*dx,$804+mf*8 : REM lots of magic numbers here!
    END IF
  END IF
  WAIT
 
  IF ox=x THEN
    REM only accept input after a frame has been displayed
    IF CONT.LEFT AND x>10 THEN x=x-1:dx=1 : REM dx is used to mirror the character
    IF CONT.RIGHT AND x<150 THEN x=x+1:dx=0
  END IF
 
  IF CONT.BUTTON THEN ta=1-ta : REM toggle automatic animation
  GOTO loop
 
gfx:
  BITMAP "...oo..."
  BITMAP "....oo.."
  BITMAP "...oo..."
  BITMAP "...ooo.."
  BITMAP "...o..o."
  BITMAP "...o..o."
  BITMAP "....ooo."
  BITMAP "........"
 
  BITMAP "...oo..."
  BITMAP "....oo.."
  BITMAP "...oo..."
  BITMAP "...oo..."
  BITMAP "..o..o.."
  BITMAP "..o..o.."
  BITMAP "...oo..."
  BITMAP "........"
 
  BITMAP "...oo..."
  BITMAP "....oo.."
  BITMAP "...oo..."
  BITMAP "..ooo..."
  BITMAP ".o..o..."
  BITMAP ".o..o..."
  BITMAP "..oo...."
  BITMAP "........"
 
  BITMAP "...oo..."
  BITMAP "....oo.."
  BITMAP "...oo..."
  BITMAP "...oo..."
  BITMAP "..oooo.."
  BITMAP "..oooo.."
  BITMAP "...oo..."
  BITMAP "........"

 

 

I am not an graphic artist, but I'd believe you get something out of this.

[+DZ-Jay]

Actually the running man is not so "available" because it's a trademark of Intellivision Prods.

 

 

Congratulations! That's the right attitude to take. I imagine that you are now probably in business with Intellivision Productions, which caused your change of heart. Your earlier conversion projects didn't seem too bothered about pesky copyrights.

 

Good job!

 

-dZ.

[+nanochess]

Congratulations! That's the right attitude to take. I imagine that you are now probably in business with Intellivision Productions, which caused your change of heart. Your earlier conversion projects didn't seem too bothered about pesky copyrights.

 

Good job!

 

-dZ.

What are you talking about? Please enlight me about my "earlier conversion projects".

[blainelocklair]

Hi carlsson,

 

Thanks for posting that code. Please forgive my naïveté about this. Is the code a complete compilable set of BASIC that can be run as-is to demonstrate the animated MOB feature, or will it need to be added to another set of code? I have the constants.bas for the code, but the compiled ROM just goes to a black screen in jzinty. I'm sure I'm doing something wrong and just don't know what it is yet. I'm grateful for any help you can provide.

 

By the way, I've not mentioned this before, but I'm only in the IntyBASIC realm for three reason:

 

1) Have fun.

2) Contribute new software, especially with great music, to our beloved platform at no cost to anyone.

3) Help other new folks when I get enough knowledge and experience to be able to do so.

 

Thanks!
Blaine

[carlsson]

Yes, it was supposed to be a standalone program. I don't know how come you're only getting a black screen, as a missing path to constants.bas would cause the compiler to bail out before going to the assembler stage. Since I don't use the SDK myself, I don't know if the build scripts will run the assembler even if the compiler has failed though I strongly doubt it does.

[+DZ-Jay]

Yes, it was supposed to be a standalone program. I don't know how come you're only getting a black screen, as a missing path to constants.bas would cause the compiler to bail out before going to the assembler stage. Since I don't use the SDK myself, I don't know if the build scripts will run the assembler even if the compiler has failed though I strongly doubt it does.

With the SDK you don't need the path to "constants.bas". It will add the "lib" folder automatically to the library path during compilation.

 

So the first thing to do is to change that line to:

INCLUDE  "constants.bas"

Also, if the compiler fails, the assembler will not be run -- as long as it returns an error code to STDERR. Otherwise, who can tell what is the return status?

 

Blair, how are you compiling the code and how did you create the project for it in the SDK?

dZ.

[blainelocklair]

I'm using the intybuild and intyrun commands in the SDK to build and run it. I started to realize the path might be the problem also, so I've updated the code to match the SDK. Still a black screen.

 

I took the code from above and copied and pasted it into a new .txt file with rtf turned off to allow only plain text. Do I need to start a new project from the SDK first in otder to run the code? I created a folder in the Projects folder called mobdemo and the .bas file is named mobdemo.

 

Thanks!
Blaine

[+nanochess]

I'm using the intybuild and intyrun commands in the SDK to build and run it. I started to realize the path might be the problem also, so I've updated the code to match the SDK. Still a black screen.

 

I took the code from above and copied and pasted it into a new .txt file with rtf turned off to allow only plain text. Do I need to start a new project from the SDK first in otder to run the code? I created a folder in the Projects folder called mobdemo and the .bas file is named mobdemo.

 

Thanks!

Blaine

For some reason the Atariage forums sometimes include a non-breakable space, but as this is invisible, you'll find hard to discover it and replace it with a space.

 

I suggest carlsson to upload the original file.

[+DZ-Jay]

I'm using the intybuild and intyrun commands in the SDK to build and run it. I started to realize the path might be the problem also, so I've updated the code to match the SDK. Still a black screen.

 

I took the code from above and copied and pasted it into a new .txt file with rtf turned off to allow only plain text. Do I need to start a new project from the SDK first in otder to run the code? I created a folder in the Projects folder called mobdemo and the .bas file is named mobdemo.

 

Thanks!

Blaine

You shouldn't need to do anything more. The INTYNEW command does only that: create a folder in the Projects folder and a stub file with the same name. So that is fine on your end.

 

I think it's like nanochess said, that the code copied from the forum may contain some strange characters.

 

nanochess, how feasible is it to enhance the compiler to clean up white-space by itself or to beige resilient to these sort of thing?

 

dZ.

[carlsson]

Ok, this file is compiling correctly for me.

 

test.bas

[blainelocklair]

It compiled perfect for me also! Thanks so much for sharing this code with me. As I've looked over projects, samples, and examples, and also original games, the animated MOBs do seem to give a bit more life to the sprites as they more around. This will be a wonderful reference for me to use moving forward.

 

Again, thanks to everyone for your help! Y'all are always great to work with on these IntyBASIC projects. So cool to have such a great community of people behind it.

 

Blaine

[+DZ-Jay]

Great!

[carlsson]

Obviously as your game loop gets more complex, you might find that you don't need any delay counters but rather only want to make updates and wait for a new frame when you really need to, in order to keep the program running at a desired speed.

DZ-Jay's suggestion to setup a full fledged state machine is probably a better way to do it, though possibly it belongs to a later stage of your development process when you're so comfortable around the basics that you start to consider better and more formalized ways to implement the game logic.

[+DZ-Jay]

The state machine solution doesn't have to be too complicated. Like I said above, it could be as simple as a list of the various obvious states the sprite is in which elicit specialized behaviour, like running, shooting, dead, etc.

 

Then just a bunch of IF/ELSE blocks or an ON GOSUB statement to handle each case.

 

It's a matter of thinking about the sprite as an object reacting to the game world.

 

Personally, I prefer to do this for animations, since depending in certain conditions you may want to switch the animation sequence. The key point is to realize that in such cases, the sprite can only be in a single state at a time (e.g., it can be either Running or Walking or Shooting or AtRest) and therefore the state can tell you which animation sequence to use. (This only applies to the state related to animation only. If the sprite is Shooting while Running, which animation sequence do you want to use? You can't use both at once, so you obviously must pick one. Thus your sprite will only be in one state.)

 

Of course, state machines are very powerful and can be used in many aspects of a game and can get very complex. However, it should be simple for animation engines to reason through and to implement.

 

dZ.

[+DZ-Jay]

What are you talking about? Please enlight me about my "earlier conversion projects".

 

I guess I could be wrong. Did you have a license from Sega for Zaxxon? Or from Atari for Asteroids? Or from Stern for Aardvark? Or from the owner of Oh Mummy!?

 

If so, then I stand corrected.

 

In any case, my point was to applaud your effort of promoting the respect of copyrights in video game development. That seems to be a sensitive topic in retro-gaming communities, but it seems we should all be able to agree that the product of people's work and effort has value.

 

-dZ.

[+nanochess]

I guess I could be wrong. Did you have a license from Sega for Zaxxon? Or from Atari for Asteroids? Or from Stern for Aardvark? Or from the owner of Oh Mummy!?

 

If so, then I stand corrected.

 

In any case, my point was to applaud your effort of promoting the respect of copyrights in video game development. That seems to be a sensitive topic in retro-gaming communities, but it seems we should all be able to agree that the product of people's work and effort has value.

 

-dZ.

I didn't made Zaxxon but Space Raid, and it's a different game in its gameplay and behavior, no one could get confused. All the history can be read in each link you posted.

[blainelocklair]

Hi everyone!

 

Well, I'm certainly able to look at the cycling animation that Carlsson posted. It compiles perfectly and does exactly what it is supposed to do.

 

I am trying to find a way to use this code to animate the player in the game2.bas file. I copied over the code and tried to integrate it into the player, but it made the rest of the loop for the game go wonky. I know Carlsson's code is fine, it's me that can't figure out what to do with it. I just need a way to animate the player in the game so he doesn't look like a statue running around.

 

How do I integrate the code into the game loop on game2.bas? I'm getting close to sharing the first version of my mod to it, but want to put some polish on the little things first and commit them to memory. I can then create newer things. Gotta get these fundamentals down first.

 

Thanks!
Blaine

[blainelocklair]

Just a quick bump for the dev folks to see if there are any ideas for implementing the MOB animation code into the game2.bas file. Thanks!