Entry 2018: Boot Hill

[digress]

Thanks, Any feedback like this is great. There are several things you mentioned I just haven't gotten to yet but things like the timer I didn't notice was so slow.

 

The collision detection is not frequent enough is why it passes through the character sometimes without hitting. I need to balance it more with performance as it is also checking tile collisions with the trees & stagecoach and can really slow the game play down. I actually want to speed it up overall.

 

I'll incorporate all the side buttons into the game . Sounds like a good idea

 

the ability to colour your character is why the gunfighters are on the screen and any colour gives it an option for stealth when playing 2 player i guess. It's optional so I kind of like it being an option.

 

there is no z-mode at this time so that deosn't really do anything yet but it might mess up something.

 

I'll remove the"SC" and probably put in the colour coded score or just assume player 1 is the left most is the same.

 

Thanks for posting the ROM. It's fun to try out a game that's quite a ways along but is still a work in progress.

 

This is going to be fun. I already like shooting my opponent in the back, though I'm sure that says more about me than it does about the game.

 

– It's frustrating right now when bullets pass through without getting a kill. Do you have to get a head shot?

 

– The timer is really slow. It takes 2:18 to count down from 60.

 

– The menu is... OK. It's not clear to me why the two gunfighters are on the screen and why they react for some options and not others. Going back to saying "Normal Mode" and "Zombie Mode" would make that choice clearer. "Music On" and "Off" instead of "ON" and "OFF" would lessen the collision of letters with the line above.

 

– Should black (invisible) be a color choice for a player? Seems like the left player can't pick that color.

 

– I agree with DZ about the "SC" used to indicate the score. Using the player color for the number should make it obvious. If the player color is black, you'd need a background color for the digits.

 

– It's not apparent that pressing 1 starts the game. That should either be in the list or at the bottom instead of the second copyright notice.

 

– The Intellivision side buttons aren't normally referred to as Fire, and "Fire 2 Change Colour" just looks clunky. Better to just list it in the menu as "8 - Change Colour"

 

– On the subject of the side buttons, they should all work in this game, whether it's on the menu or shooting. Some players will prefer shooting with the top buttons, and right now they're not used.

 

I'm looking forward to playing this again. With a human opponent, it should be a lot of fun.

[GroovyBee]

The collision detection is not frequent enough is why it passes through the character sometimes without hitting. I need to balance it more with performance as it is also checking tile collisions with the trees & stagecoach and can really slow the game play down. I actually want to speed it up overall.

If you are using the hardware then collision detection should be carried out every frame. It looks like your bullet is 1 pixel square. To improve collision detection :-

 

- All GRAM cards that disappear on contact with a bullet, add $8000 to their value as they are copied into BACKTAB.

- If the bullet collides with the background (using hardware) :-

* Compute its position in BACKTAB and then read BACKTAB at that position.

* If the value you get back fom BACKTAB is > $8000, zero out what is there.

- Make sure the bullet is in the top left of the card to make the BACKTAB location computation easy.

 

Thats the easiest way to determine if the bullet can pass through or hit something. If it can ricochet off things then thats a little more complicated.

[digress]

Ok so I switched to using the hardware sprite col1 etc and check it every frame so that is much better with no slow down

 

working on the second idea now with add 8000 and checking those tiles so I don't have to compare it against an array of 20 tiles I had been using.

If you are using the hardware then collision detection should be carried out every frame. It looks like your bullet is 1 pixel square. To improve collision detection :-

- All GRAM cards that disappear on contact with a bullet, add $8000 to their value as they are copied into BACKTAB.
- If the bullet collides with the background (using hardware) :-
* Compute its position in BACKTAB and then read BACKTAB at that position.
* If the value you get back fom BACKTAB is > $8000, zero out what is there.
- Make sure the bullet is in the top left of the card to make the BACKTAB location computation easy.

 

Thats the easiest way to determine if the bullet can pass through or hit something. If it can ricochet off things then thats a little more complicated.

[Kiwi]

Yeah, using hardware collision detection col0-7 will speed up your game a lot. I did try box collision, and it was too slow. Colecovision CPU speed spoiled us .

Ok so I switched to using the hardware sprite col1 etc and check it every frame so that is much better with no slow down

 

working on the second idea now with add 8000 and checking those tiles so I don't have to compare it against an array of 20 tiles I had been using.

For sprite vs bg software. For the water, characters and the enemies in Towering Inferno, I made this routine.

This is from the water spray,

Mcard=PEEK($200+charx+chary*20)
Mcard=Mcard/8

if Mcard=21 then #SP=138:#SL=13:#VP2=69:#SL2=13:poke ($200+charx+chary*20),$08B1:waterlife=1:sc(4)=sc(4)+13:gosub AddScore:gosub firespread
if Mcard>3 AND Mcard<23 then arrowA=0:arrowX=0:arrowY=0
if Mcard=23 then 


#Mcard=PEEK($200+charx+chary*20)
if #Mcard=$1cb8 then #VP2=49:#SL2=20:poke ($200+charx+chary*20),0:waterlife=1:sc(4)=sc(4)+3:gosub AddScore
if #Mcard=$38b8 then #VP2=49:#SL2=20:poke ($200+charx+chary*20),$1cb8:waterlife=1:sc(4)=sc(4)+3:gosub AddScore
if #Mcard=$3ab8 then #VP2=49:#SL2=20:poke ($200+charx+chary*20),$38b8:waterlife=1:sc(4)=sc(4)+3:gosub AddScore
if #Mcard=$1ab8 then #VP2=49:#SL2=20:poke ($200+charx+chary*20),$3ab8:waterlife=1:sc(4)=sc(4)+3:gosub AddScore

end if

$200 is the backtab address. Mcard is an 8 bit variable so it'll shave off the top 8 bit and store the value into it. Then divide it by 8 to trim off the color information. Now you can get your card number 0-31. I'm not sure what value to AND it with a 16 bit number to get tile 0-63, so this way was easier. The cases Mcard activate the action it needed. Mcard =21 is when the water spray hit a window. If Mcard>3 AND Mcard<23 will despawn the water because it hit a solid object. Card Mcard=23 hit an object(fire), and get what object it hits and change it to another card.

 

The game loop for Fire Inferno runs at 30fps(having 2 wait statements gameloop). Hopefully this will help you a bit.

 

I did this way. Intellivision has bg to sprite collusion, but it needs the foreground color to determine as a hit. There's a border color collusion that the bullet can bounce off or despawn to prevent the bullet or other sprites from wrapping around the screen.

if col1 AND $200 then arrowA=0:arrowX=0:arrowY=0

$200 is the bit for the border I believe. And arrow variable was my experiment project, a better Venture for the Intellivision before I convert the engine to Towering Inferno.

Edited April 17, 2018 by Kiwi

[digress]

flag=#TileID/8 did it. Thanks. Much better now I just need the check the range

 

Noticeably faster. Now I should be able to put in the moving stagecoach.

 

Yeah I was doing box collision checking as it was converted from my coleco version. These new routines are much faster now.

 

Thanks

 

Yeah, using hardware collision detection col0-7 will speed up your game a lot. I did try box collision, and it was too slow. Colecovision CPU speed spoiled us .

For sprite vs bg software. For the water, characters and the enemies in Towering Inferno, I made this routine.

This is from the water spray,

Mcard=PEEK($200+charx+chary*20)
Mcard=Mcard/8

if Mcard=21 then #SP=138:#SL=13:#VP2=69:#SL2=13:poke ($200+charx+chary*20),$08B1:waterlife=1:sc(4)=sc(4)+13:gosub AddScore:gosub firespread
if Mcard>3 AND Mcard<23 then arrowA=0:arrowX=0:arrowY=0
if Mcard=23 then 


#Mcard=PEEK($200+charx+chary*20)
if #Mcard=$1cb8 then #VP2=49:#SL2=20:poke ($200+charx+chary*20),0:waterlife=1:sc(4)=sc(4)+3:gosub AddScore
if #Mcard=$38b8 then #VP2=49:#SL2=20:poke ($200+charx+chary*20),$1cb8:waterlife=1:sc(4)=sc(4)+3:gosub AddScore
if #Mcard=$3ab8 then #VP2=49:#SL2=20:poke ($200+charx+chary*20),$38b8:waterlife=1:sc(4)=sc(4)+3:gosub AddScore
if #Mcard=$1ab8 then #VP2=49:#SL2=20:poke ($200+charx+chary*20),$3ab8:waterlife=1:sc(4)=sc(4)+3:gosub AddScore

end if

$200 is the backtab address. Mcard is an 8 bit variable so it'll shave off the top 8 bit and store the value into it. Then divide it by 8 to trim off the color information. Now you can get your card number 0-31. I'm not sure what value to AND it with a 16 bit number to get tile 0-63, so this way was easier. The cases Mcard activate the action it needed. Mcard =21 is when the water spray hit a window. If Mcard>3 AND Mcard<23 will despawn the water because it hit a solid object. Card Mcard=23 hit an object(fire), and get what object it hits and change it to another card.

 

The game loop for Fire Inferno runs at 30fps(having 2 wait statements gameloop). Hopefully this will help you a bit.

 

I did this way. Intellivision has bg to sprite collusion, but it needs the foreground color to determine as a hit. There's a border color collusion that the bullet can bounce off or despawn to prevent the bullet or other sprites from wrapping around the screen.

if col1 AND $200 then arrowA=0:arrowX=0:arrowY=0

$200 is the bit for the border I believe. And arrow variable was my experiment project, a better Venture for the Intellivision before I convert the engine to Towering Inferno.

[digress]

So i've been adding in the stagecoach moving. I've got it going as I want but the obvious flicker when it shifts tiles up 1 . Any suggestions

 

it has 8 frames to move the smoothly shift the stagecoach within the tiles box (3 x 4 ) tiles then I shift the whole box up 1 tile row. But it's briefly flickering before updating.

 

https://www.youtube.com/watch?v=Xg3DrDKxMCw&feature=youtu.be

[+nanochess]

You don't need to erase the whole stagecoach.

 

If you're doing definition of tiles before it should be done this way.

 

game_loop:
        ' Supposing stagecoach is 3x4 cards (3 horizontal, 4 vertical)
        DEFINE 32,4,VARPTR stagecoach(frame * (3 * 4 * 4))     ' Pseudo-code, so near to WAIT as possible
        WAIT
        SCREEN VARPTR stagecoach(frame * (3 * 4)), 0, (y /  * 20 + (x / , 3, 4, 3   ' So near to WAIT as possible
        GOTO game_loop

[Kiwi]

I think it would be easier to use MOBs for the stage coach, reduce the max bullet count to 2 and use 2 MOBs towards the stage coach.

I would try above first. I usually use put_frame() to print group of tiles for the Colecovision. I haven't made a dedicated function for that yet.

[artrag]

You don't need to erase the whole stagecoach.

 

If you're doing definition of tiles before it should be done this way.

 

game_loop:
        ' Supposing stagecoach is 3x4 cards (3 horizontal, 4 vertical)
        DEFINE 32,4,VARPTR stagecoach(frame * (3 * 4 * 4))     ' Pseudo-code, so near to WAIT as possible
        WAIT
        SCREEN VARPTR stagecoach(frame * (3 * 4)), 0, (y /  * 20 + (x / , 3, 4, 3   ' So near to WAIT as possible
        GOTO game_loop

 

Does the SCREEN command crop the copied image if it falls partially outside the back tab area in ram?

It is just a curiosity (eventually to be reported in the manual), not a feature request

Edited April 18, 2018 by artrag

[+nanochess]

Does the SCREEN command crop the copied image if it falls partially outside the back tab area in ram?

It is just a curiosity (eventually to be reported in the manual), not a feature request

No, it doesn't crop the image. But it's easy to add a comparison for that in the game.

[artrag]

This allows to (mis)use it also for general purpose copies, as a block copy command for rom to ram or ram to ram

[Kiwi]

I think I did request a function that behaved like the put_frame function that the Colecovision bios has, I think MSX also has that. Put_frame only check the x. Which is block copy of ROM to be upload to the VRAM memory. I don't know if Intybasic let you make your own function that takes arguments. I would make a for loop to do block copy to specific region to the backtab.

For example is my block copy to print group of tiles to backtab:

#scenepointer=77:x=4:y=2
gosub drawscene

drawscene:procedure
for i=0 to 76
poke $200+x+(y*20),jailpic1(#scenepointer+i)
x=x+1
if x=15 then y=y+1:x=4
'wait
next i
return
end

[+nanochess]

I think I did request a function that behaved like the put_frame function that the Colecovision bios has, I think MSX also has that. Put_frame only check the x. Which is block copy of ROM to be upload to the VRAM memory. I don't know if Intybasic let you make your own function that takes arguments. I would make a for loop to do block copy to specific region to the backtab.

 

For example is my block copy to print group of tiles to backtab:

#scenepointer=77:x=4:y=2
gosub drawscene

drawscene:procedure
for i=0 to 76
poke $200+x+(y*20),jailpic1(#scenepointer+i)
x=x+1
if x=15 then y=y+1:x=4
'wait
next i
return
end

 

You can replace your code with this and it will be way faster:

 

drawscene: PROCEDURE
  SCREEN jailpic1, #scenepointer, x + (y * 20), 11, 7, 11
  END

[Kiwi]

drawscene: PROCEDURE

SCREEN jailpic1, #scenepointer, x + (y * 20), 11, 7, 11

END

 

I should reread the screen function. And the Intybasic been open for a few days. *Goes and read it*

[digress]

made the death animation better

fixed the stuttering stagecoach

stagecoach can now kill the cowboys

probably somehting else

 

https://www.youtube.com/watch?v=Xz9JlnRGREU&feature=youtu.be

[Kiwi]

Just thought of remember something regarding to the video mode switch which we see flash of tiles. Check if your memory segment in the cfg specific A000-BFFF segment and see if it is greater than 8KB. The cause of your video mode change is because $C020 is the Active Display Strobe, and $C021 is the Mode Select Strobe. It is a STIC alias of address $0020/$0021. So reading your music data is causing the strobes to be read and activate. So I would put asm org $C100 for your largest segment of data. And you can remove mode 0 from your game loop to see if the problem has been fixed.

http://wiki.intellivision.us/index.php?title=STIC

http://wiki.intellivision.us/index.php?title=Memory_Map

Edited April 24, 2018 by Kiwi

[digress]

nah didn't work . good idea though. There was less than 1 kb in the segment and I then cut & pasted it to a compltely different area with no change... I'll try using the music statement and see if that fixes it.

 

 

Just thought of remember something regarding to the video mode switch which we see flash of tiles. Check if your memory segment in the cfg specific A000-BFFF segment and see if it is greater than 8KB. The cause of your video mode change is because $C020 is the Active Display Strobe, and $C021 is the Mode Select Strobe. It is a STIC alias of address $0020/$0021. So reading your music data is causing the strobes to be read and activate. So I would put asm org $C100 for your largest segment of data. And you can remove mode 0 from your game loop to see if the problem has been fixed.

http://wiki.intellivision.us/index.php?title=STIC

http://wiki.intellivision.us/index.php?title=Memory_Map

[wolfy62]

I love all the colors with what you are doing here!

[+Steve Jones]

any chance of an updated rom? been playing the one you released, most of my comments are the same as previously mentioned, re colour of scores,

menu layout, should say Press 1 to start etc.

for some reason when I press 2 to change from 2 player to one, I have to press it twice.

to change from 1 player to 2 it only takes 1 press.

 

took me a while to figure out how to aim, wasn't obvious and didn't know I could until I watched a video and saw you doing it so knew there must be some way.

 

pushing 3 in menu doesn't seem to do anything on menu screen but then when I start game it

comes up ZOMBIES DEFEATED and game is over before it even starts.

 

various gfx glitches on my Sears system but I realize the rom was a very early build.

 

Thanks.

[digress]

Update:

 

https://www.youtube.com/watch?v=SflMFuoLO9M&feature=youtu.be

 

Test rom.

 

 

boothill.rom

[digress]

Smoother zombies

better collision detection

more balanced gameplay and animation.

Mistake with some tiles

 

https://www.youtube.com/watch?v=cE8PKUH547c&feature=youtu.be

[carlsson]

Looking good!

 

Actually I misread that first as "zombie smoothies" and was reminded of that graphics text adventure Gremlins [Adventure International] where one of the first gremlins has hidden in the mixer and you eliminate him by turning the mixer on. (Aha, also in the movie)

Edited May 15, 2018 by carlsson

[GroovyBee]

Its coming along nicely. A few comments based on watching your video :-

 

- There are a couple of bum notes in the tune that you might want to address,

- Come up with a nice transition effect to put up between differing screens. The change is very abrupt as it is now and it would allow the player some time to get to grips with what the next screen challenges will be.

- Don't let the baddies move around if they are in their death animation frames.

- The time and bullet counters are a bit flickery.

[digress]

working on some transitiions. I did add some flashing and a time to get adjusted.

added a new title screen. I like it much

trying some different music.

mostly done now!

 

https://www.youtube.com/watch?v=Qx017ahHWfA&feature=youtu.be

[carlsson]

How are you recording those videos? It looks crisp like an emulator, but I'm hearing background sounds like if you were filming a TV.