Jump to content

Photo

Entry 2018: Boot Hill


40 replies to this topic

#26 digress ONLINE  

digress

    Dragonstomper

  • Topic Starter
  • 976 posts
  • Location:Toronto, Ontario, Canada

Posted Mon Apr 16, 2018 12:40 PM

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.



#27 GroovyBee OFFLINE  

GroovyBee

    Games Developer

  • 9,783 posts
  • Busy bee!
  • Location:North, England

Posted Mon Apr 16, 2018 2:02 PM

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.



#28 digress ONLINE  

digress

    Dragonstomper

  • Topic Starter
  • 976 posts
  • Location:Toronto, Ontario, Canada

Posted Mon Apr 16, 2018 7:29 PM

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.



#29 Kiwi OFFLINE  

Kiwi

    Stargunner

  • 1,503 posts

Posted Mon Apr 16, 2018 8:48 PM

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 :P

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 by Kiwi, Mon Apr 16, 2018 8:52 PM.


#30 digress ONLINE  

digress

    Dragonstomper

  • Topic Starter
  • 976 posts
  • Location:Toronto, Ontario, Canada

Posted Tue Apr 17, 2018 7:49 AM

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 :P

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.

 



#31 digress ONLINE  

digress

    Dragonstomper

  • Topic Starter
  • 976 posts
  • Location:Toronto, Ontario, Canada

Posted Wed Apr 18, 2018 10:15 AM

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.

 



#32 nanochess OFFLINE  

nanochess

    Processorus Polyglotus

  • 5,322 posts
  • Coding something good
  • Location:Mexico City

Posted Wed Apr 18, 2018 11:48 AM

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 / 8) * 20 + (x / 8), 3, 4, 3   ' So near to WAIT as possible
        GOTO game_loop


#33 Kiwi OFFLINE  

Kiwi

    Stargunner

  • 1,503 posts

Posted Wed Apr 18, 2018 12:55 PM

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.



#34 artrag OFFLINE  

artrag

    Dragonstomper

  • 885 posts

Posted Wed Apr 18, 2018 2:00 PM

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 / 8) * 20 + (x / 8), 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 by artrag, Wed Apr 18, 2018 2:01 PM.


#35 nanochess OFFLINE  

nanochess

    Processorus Polyglotus

  • 5,322 posts
  • Coding something good
  • Location:Mexico City

Posted Wed Apr 18, 2018 2:32 PM

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.

#36 artrag OFFLINE  

artrag

    Dragonstomper

  • 885 posts

Posted Wed Apr 18, 2018 2:37 PM

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



#37 Kiwi OFFLINE  

Kiwi

    Stargunner

  • 1,503 posts

Posted Wed Apr 18, 2018 3:46 PM

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


#38 nanochess OFFLINE  

nanochess

    Processorus Polyglotus

  • 5,322 posts
  • Coding something good
  • Location:Mexico City

Posted Wed Apr 18, 2018 4:51 PM

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


#39 Kiwi OFFLINE  

Kiwi

    Stargunner

  • 1,503 posts

Posted Wed Apr 18, 2018 5:18 PM

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*

#40 digress ONLINE  

digress

    Dragonstomper

  • Topic Starter
  • 976 posts
  • Location:Toronto, Ontario, Canada

Posted Yesterday, 6:53 PM

made the death animation better

fixed the stuttering stagecoach

stagecoach can now kill the cowboys

probably somehting else

 



#41 Kiwi OFFLINE  

Kiwi

    Stargunner

  • 1,503 posts

Posted Yesterday, 11:13 PM

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.intelliv....php?title=STIC

http://wiki.intelliv...itle=Memory_Map


Edited by Kiwi, Yesterday, 11:16 PM.





0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users