Jump to content
IGNORED

Beginner help with IntyBasic


dalves

Recommended Posts

I was wondering how it was done in games like Defender, Space Raid, or Space Patrol. They were able to scroll but still have scores (at least appear) stationary on the screen.

 

There are several ways to do scrolling:

 

1. Use the hardware facilities of Intellivision, it scrolls the whole screen. Relatively hard to keep fixed things over.

2. Simulate scrolling, redefining GRAM characters. Easy to keep fixed things over, difficult to update more than 16 GRAM per frame. (Space Patrol does this)

3. Simulate scrolling, moving only MOB over screen, maybe redefining some GRAM characters. (Space Raid does it this way, MOB only for fortress, GRAM for space background and MOB for planets)

  • Like 1
Link to comment
Share on other sites

Thanks Nanochess for the explanation. I'm wondering if the 2nd technique you mention would be the one I would need to look into further. Still very much a novice here, so this is much I don't yet understand. Something that appears to be easy from the outside looking in, may be move involved than I realize.

Link to comment
Share on other sites

I was wondering how it was done in games like Defender, Space Raid, or Space Patrol. They were able to scroll but still have scores (at least appear) stationary on the screen.

Ah that's simple, at for least Defender and Space Patrol: they don't scroll. They sequence the GRAM of the background cards to "animate" the background and give the illusion that it is moving, but the screen itself is static.

 

That avoids the cross-scrolling issue you are dealing with, but brings up its own set if problems that need to be addressed.

 

There is no such thing as a free lunch. They all require carefully considered trade-offs.

 

dZ.

Link to comment
Share on other sites

I was wondering if you guys know of any .bas examples that are available to show how this is done?

 

I'm assuming what you mean is that I would need to draw individual Bitmaps to simulate movement and then Print them to the screen. For what I'm trying to do, it may not be that involved, but I would imagine with a game like Space Patrol, that would involve a lot of work.

Link to comment
Share on other sites

So you are looking to port this game? Assuming enemies will be MOBs anyway, it is just the colour bars at the sides that need scrolling. That shouldn't be too hard to do, perhaps 2-4 GRAM cards repeated along both sides and then dynamically redefined on each frame. You could even predefine the possible 9 (?) patterns and point the DEFINE statement to desired frame.

 

Edit: Oh, there appears to be some slalom going on later on. I suppose you then need to combine coarse moving cards with the defines.

 

Edited by carlsson
Link to comment
Share on other sites

About scrolling, if you don't mind coarse/jumpy scrolling, Intymusic has an assembly function that only scrolls a portion of the screen. It leaves the right column and bottom 2 rows untouched to avoid redrawing piano and song title (it was flickering). I plan to release a new version this week, I updated the function to scroll up/down.

 

Here is a bitmap scroll effect using GROM cards:

 

 

x=0:y=220:g=0
PRINT AT 100,"Hi!"
mycolor=1 'blue
MainLoop:
#grom=GROMdata(g)+mycolor
g=g+1:IF g>3 THEN g=0

FOR y=0 TO 220 STEP 20
PRINT AT y+4
FOR x=4 to 16:PRINT #grom:NEXT x
NEXT y
FOR x=1 to 5:WAIT:next x
GOTO MainLoop
GROMdata:
DATA 166*8,168*8,170*8,172*8
'GROM 166, need to *8, bits 0-2=colors
'same as PRINT COLOR mycolor,"\166"

 

 

Edited by mmarrero
  • Like 1
Link to comment
Share on other sites

Thanks for the help and insight. I'm going to try my hand at that hopefully during lunch and see if I can get something together that works. I know the initial coding will still revolve around my comfort zone, but maybe this will be a step toward expanding my knowledge and I'll learn how to do some new things.

Link to comment
Share on other sites

I'm assuming if I use the "Simulated" scrolling method, that I won't be able to have multicolored blocks on the side because I would need to have 3 colors in each Bitmap. The scrolling option would be best if I could find a way to keep some text fixed. Otherwise, maybe I'll have to use one color for the side blocks and just change the color as each level changes.

Link to comment
Share on other sites

If you can live with one full card of empty space between the scrolling blocks, I think it would work. Use one modifying GRAM for head of each block and one for tail. After the 8th frame, the old tail becomes the head of the next block which means you will need to plot all blocks again one line below and adjust colour attributes, and add a tail or main block at the top. I haven't implemented this yet, but in theory I believe it will work with each block having its own foreground without clashes.

 

Frame 1:
 
 -Main-   -Head-   -Tail-
oooooooo oooooooo ........
oooooooo oooooooo ........
oooooooo oooooooo ........
oooooooo oooooooo ........
oooooooo oooooooo ........
oooooooo oooooooo ........
oooooooo oooooooo ........
oooooooo oooooooo ........
 
Frame 2:
 
oooooooo ........ oooooooo
oooooooo oooooooo ........
oooooooo oooooooo ........
oooooooo oooooooo ........
oooooooo oooooooo ........
oooooooo oooooooo ........
oooooooo oooooooo ........
oooooooo oooooooo ........
 
Frame 3:
 
oooooooo ........ oooooooo
oooooooo ........ oooooooo
oooooooo oooooooo ........
oooooooo oooooooo ........
oooooooo oooooooo ........
oooooooo oooooooo ........
oooooooo oooooooo ........
oooooooo oooooooo ........
 
Frame 4:
 
oooooooo ........ oooooooo
oooooooo ........ oooooooo
oooooooo ........ oooooooo
oooooooo oooooooo ........
oooooooo oooooooo ........
oooooooo oooooooo ........
oooooooo oooooooo ........
oooooooo oooooooo ........
 
Frame 5:
 
oooooooo ........ oooooooo
oooooooo ........ oooooooo
oooooooo ........ oooooooo
oooooooo ........ oooooooo
oooooooo oooooooo ........
oooooooo oooooooo ........
oooooooo oooooooo ........
oooooooo oooooooo ........
 
Frame 6:
 
oooooooo ........ oooooooo
oooooooo ........ oooooooo
oooooooo ........ oooooooo
oooooooo ........ oooooooo
oooooooo ........ oooooooo
oooooooo oooooooo ........
oooooooo oooooooo ........
oooooooo oooooooo ........
 
Frame 7:
 
oooooooo ........ oooooooo
oooooooo ........ oooooooo
oooooooo ........ oooooooo
oooooooo ........ oooooooo
oooooooo ........ oooooooo
oooooooo ........ oooooooo
oooooooo oooooooo ........
oooooooo oooooooo ........
 
Frame 8:
 
oooooooo ........ oooooooo
oooooooo ........ oooooooo
oooooooo ........ oooooooo
oooooooo ........ oooooooo
oooooooo ........ oooooooo
oooooooo ........ oooooooo
oooooooo ........ oooooooo
oooooooo ........ oooooooo

 

 

Link to comment
Share on other sites

I'm assuming if I use the "Simulated" scrolling method, that I won't be able to have multicolored blocks on the side because I would need to have 3 colors in each Bitmap. The scrolling option would be best if I could find a way to keep some text fixed. Otherwise, maybe I'll have to use one color for the side blocks and just change the color as each level changes.

 

You could try "scrolling" only two colours per card.

 

Alternatively, since this is an Intellivision game and not an Atari VCS ones, you don't need to scroll solid blocks of colour. You could create a repeating pattern that simulates the scrolling, and get away with a single colour. I think this would work out better.

 

-dZ.

Link to comment
Share on other sites

Some thoughts on Worm War 1 for Intellivision.

 

1. The easiest way to do it -

Use real scrolling to move the background.

Use one sprite for the timer.

This leaves 2 sprites for the player and the shot, and 5 sprites for the worms and the refueling stations.

Show the score occasionally, between rounds.

(advantages - this way is easiest, allows colorful scrolling bricks).

(disadvantages - score isn't on screen all the time).

 

2. Next easiest way.

Fake the scrolling with gram cards.

Keep the score and timer on screen in backtab.

This leaves 2 sprites for the player and the shot, and 6 sprites for the worms and the refueling stations.

(advantages - score and timer always on screen)

(disadvantages - fake scrolling is more work than real scrolling. Background blocks are limited to 2 colors.)

 

3. Hard way.

Use real scrolling to move the background.

Create custom gram characters for the score and the timer that are "counter-scrolled" so they don't move on the screen.

This leaves 2 sprites for the player and the shot, and 6 sprites for the worms and the refueling stations.

(advantages - the score and timer are always on screen, allows colorful scrolling bricks).

(disadvantages - a lot of processor time is spent creating custom cards for the score and timer and copying them to gram.

score and timer require 2 vertical cards of height).

 

 

Catsfolly

 

Link to comment
Share on other sites

The Intellivision is capable of much better graphics than the 2600 so you can do so much more with the scrolling graphics, I hated that Activision games generally looked like their 2600 brethren.

 

Here is a snippet form the Inty-B Volume 2 showing fake scrolling using cards: The example only uses 3 card slots to simulate parallax scrolling. Unlike the 2600, you can make your side blocks look like something...

 

It looks way better at 60 fps.

 

[Click to Animate]

post-38229-0-31892100-1476892740_thumb.gif

 

  • Like 1
Link to comment
Share on other sites

Thanks to everyone for the suggestions and help.

 

Catsfolly's suggestion of the easiest way would seem to be just that. Since the scrolling speed is varied in the game, it would seem to be the easiest way to have the worms, refueling stations, and both center and outer blocks scroll downward at the same speed. Plus, for those who have played the game, you know that as the game advances, more and more blocks fill the main screen. It would seem like there would be a lot less coding to do this with the true scrolling feature. If there was no timer in this game, my problems would be solved. :) As I am new to scrolling, I don't know how to reverse scroll. I'll have to see what I can find and give that a try.

 

The flip side is since there are technically levels in the game, using one solid color for the side blocks and changing the color with each level could be a nice feature too. It's the coding that I may need to do to have smooth scrolling center blocks that makes me worry about doing it that way.

Link to comment
Share on other sites

Hey guys,

 

I try not to ask specific code questions unless it is absolutely necessary, but this may be one of those times. Can you use multiple "And" commands in a single if statement? I my version of Worm War 1 I'm using "If" statements to determine which worms you've shot and shouldn't be shown on screen. I was able to do this with a single worm and with two worms on the screen (Rounds 1 and 2), but now that I have three on screen (Round 3), whenever I shoot two worms, it will generate another one so there is always two on screen. I know the code is out of context, but I'm hoping you'll be able to see what I'm trying to do and where I may be doing it wrong.

 

IF ROUND=1 AND WONEHIT=1 THEN ROUND=2:WXONE=10:WYONE=10:WXTWO=20:WYTWO=20:WONEHIT=0
IF ROUND=2 AND WONEHIT=1 THEN GOSUB WORMTWO
IF ROUND=2 AND WTWOHIT=1 THEN GOSUB WORMONE
IF ROUND=2 AND WORMHIT=3 THEN ROUND=3:WXONE=10:WYONE=10:WXTWO=20:WYTWO=20:WXTHREE=30:WYTHREE=30:WONEHIT=0:WTWOHIT=0
IF ROUND=3 AND WONEHIT=1 THEN GOSUB WORMTWO:GOSUB WORMTHREE
IF ROUND=3 AND WTWOHIT=1 THEN GOSUB WORMONE:GOSUB WORMTHREE
IF ROUND=3 AND WTHREEHIT=1 THEN GOSUB WORMONE:GOSUB WORMTWO
IF ROUND=3 AND WONEHIT=1 AND WTWOHIT=1 THEN GOSUB WORMTHREE
IF ROUND=3 AND WTWOHIT=1 AND WTHREEHIT=1 THEN GOSUB WORMONE
IF ROUND=3 AND WONEHIT=1 AND WTHREEHIT=1 THEN GOSUB WORMTWO
IF ROUND=1 THEN GOSUB WORMONE
IF ROUND=2 AND WONEHIT=0 AND WTWOHIT=0 THEN GOSUB WORMONE:GOSUB WORMTWO
IF ROUND=3 AND WONEHIT=0 AND WTWOHIT=0 AND WTHREEHIT=0 THEN GOSUB WORMONE:GOSUB WORMTWO:GOSUB WORMTHREE

 

 

 

(After posting this, I think I found my workaround. Instead of using "W(number)HIT=1" as the determiner as to which worms should be drawn, I used "W(number)HIT=0" as the determiner instead and now it's working.)

Edited by dalves
  • Like 1
Link to comment
Share on other sites

Hey guys,

 

I try not to ask specific code questions unless it is absolutely necessary, but this may be one of those times. Can you use multiple "And" commands in a single if statement? I my version of Worm War 1 I'm using "If" statements to determine which worms you've shot and shouldn't be shown on screen. I was able to do this with a single worm and with two worms on the screen (Rounds 1 and 2), but now that I have three on screen (Round 3), whenever I shoot two worms, it will generate another one so there is always two on screen. I know the code is out of context, but I'm hoping you'll be able to see what I'm trying to do and where I may be doing it wrong.

 

IF ROUND=1 AND WONEHIT=1 THEN ROUND=2:WXONE=10:WYONE=10:WXTWO=20:WYTWO=20:WONEHIT=0

IF ROUND=2 AND WONEHIT=1 THEN GOSUB WORMTWO

IF ROUND=2 AND WTWOHIT=1 THEN GOSUB WORMONE

IF ROUND=2 AND WORMHIT=3 THEN ROUND=3:WXONE=10:WYONE=10:WXTWO=20:WYTWO=20:WXTHREE=30:WYTHREE=30:WONEHIT=0:WTWOHIT=0

IF ROUND=3 AND WONEHIT=1 THEN GOSUB WORMTWO:GOSUB WORMTHREE

IF ROUND=3 AND WTWOHIT=1 THEN GOSUB WORMONE:GOSUB WORMTHREE

IF ROUND=3 AND WTHREEHIT=1 THEN GOSUB WORMONE:GOSUB WORMTWO

IF ROUND=3 AND WONEHIT=1 AND WTWOHIT=1 THEN GOSUB WORMTHREE

IF ROUND=3 AND WTWOHIT=1 AND WTHREEHIT=1 THEN GOSUB WORMONE

IF ROUND=3 AND WONEHIT=1 AND WTHREEHIT=1 THEN GOSUB WORMTWO

IF ROUND=1 THEN GOSUB WORMONE

IF ROUND=2 AND WONEHIT=0 AND WTWOHIT=0 THEN GOSUB WORMONE:GOSUB WORMTWO

IF ROUND=3 AND WONEHIT=0 AND WTWOHIT=0 AND WTHREEHIT=0 THEN GOSUB WORMONE:GOSUB WORMTWO:GOSUB WORMTHREE

 

 

 

(After posting this, I think I found my workaround. Instead of using "W(number)HIT=1" as the determiner as to which worms should be drawn, I used "W(number)HIT=0" as the determiner instead and now it's working.)

I'm not sure I follow the logic.

 

Could something like this work?

ON (ROUND-1) GOTO DO_R1, DO_R2. DO_R3

D0_R3:
 	IF WTHREEHIT=0 THEN GOSUB WORMTHREE
DO_R2:
	IF WTWOHIT=0 THEN GOSUB WORMTWO
DO_R1:
	IF WONEHIT=0 THEN GOSUB WORMONE

IF ROUND=1 AND WONEHIT=1 THEN ROUND=2:WXONE=10:WYONE=10:WXTWO=20:WYTWO=20:WONEHIT=0
IF ROUND=2 AND WORMHIT=3 THEN ROUND=3:WXONE=10:WYONE=10:WXTWO=20:WYTWO=20:WXTHREE=30:WYTHREE=30:WONEHIT=0:WTWOHIT=0

Catsfolly

Link to comment
Share on other sites

Thanks Catsfolly. I think you get what I'm trying to do. I was able to get it to work, but will try your code suggestion as well. I've become very conscious that my programming is 90% "IF" statements. Just a comment on my limited knowledge on basic commands and the correct syntaxes.

Link to comment
Share on other sites

I think Catsfolly's version is the most elegant and simple translation of your code, but how about taking another approach to what you aim to do? If I understand correctly, you want to perform an action when a worm is shot, which could be different depending on the round you are in, and how many worms have been shot so far.

 

You could keep a variable with the maximum number of worms allowed for the round, which is updated at the start of each round. On each cycle, you test if a worm has been hit and if so, you decrement the maximum counter. If it reaches zero, the round is over and you move to the next one. Otherwise, you spawn a new worm.

 

Unfortunately, I am not familiar with the game mechanics of Worm War, so I do not know what triggers the end of level, so the above may not be the correct logic. However, you should be able to generalize your algorithm in a similar way, rather than processing every round and every worm through a distinct code path.

 

Also, remember that IntyBASIC supports IF/ELSE/END IF blocks, so you can enclose a block of logic within an IF/END IF.

 

-dZ.

  • Like 1
Link to comment
Share on other sites

Just to be clear, neither of WORMONE, WORMTWO or WORMTHREE would modify any of the variables used in the logic, so the way of further operation could depend on the outcome of a subroutine?

 

Also in case variables are not modified, does it matter if you GOSUB WORMONE:GOSUB WORMTWO or the other order of those two subroutine calls?

Edited by carlsson
Link to comment
Share on other sites

Thanks for the feedback. I think your ways of doing it are better than what I started out with. I was able to get the results I wanted when I changed the statement to check if the worms haven't been hit as opposed to checking if they were hit.

 

IF ROUND=2 AND WONEHIT=0 THEN GOSUB WORMONE
IF ROUND=2 AND WTWOHIT=0 THEN GOSUB WORMTWO

 

This way I was able to keep the animations for the worms moving and go to another subroutine when the worms are hit. I've attached the .BAS and ROM for anyone who is curious. The code is VERY MUCH in the sketch stages and I know I have a lot of commands saying the same thing that I need to clean up, but the basics are functional. I have the side blocks changing color after each worm is shot, but I may go back to changing it after the level is completed. I haven't added the timer or refueling stations yet, but that will be next. You can speed up and slow down at this point. I'm still thinking that creating the center blocks may be the most intensive part of the code. For those who have played the game, you know that as you move up in levels, the block all but fill the screen and your only option is to shoot paths through.

WW6.rom

WW6.BAS

Link to comment
Share on other sites

Hi, dalves,

 

I just played it and it works rather well. It's very playable, except that it looks too much like an Atari VCS game. :lol:

 

I know you are working on the game-play right now, but I suggest you also give some thought to the presentation. The Intellivision is capable of much better graphics than just solid blocks and lines and sprite animations do not need to be constrained to two frames either. Also, consider the colour palette available on the Intellivision. It may not be as extensive as in the Atari, but it allows for easier use of more colours within the play-field. :)

 

-dZ.

Link to comment
Share on other sites

Tricky thing for me, is it pretty much my favorite Atari 2600 game. So at least initially, the idea was to mimic the 2600 version as closely as possible. I figure once I get the rest of the game play down, then I might try customizing it to have more of an Intellivision look and feel.

 

I just looked up the Worm War 1 manual to see what the center blocks were supposed to represent. I thought maybe they're supposed to be mushrooms or bunkers... nope. They're just called "Blocks". :)

Link to comment
Share on other sites

Tricky thing for me, is it pretty much my favorite Atari 2600 game. So at least initially, the idea was to mimic the 2600 version as closely as possible. I figure once I get the rest of the game play down, then I might try customizing it to have more of an Intellivision look and feel.

 

I just looked up the Worm War 1 manual to see what the center blocks were supposed to represent. I thought maybe they're supposed to be mushrooms or bunkers... nope. They're just called "Blocks". :)

Start off mimicing the 2600 graphics then "improve" them as the levels go on. It is so easy to change graphics on the fly with the Intellivision. I get why you want to mimic the 2600, but as the game goes on, add gameplay and change things to add more play value.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   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...