Jump to content

DEBRO

Members
  • Content Count

    2,009
  • Joined

  • Days Won

    1

DEBRO last won the day on March 21 2010

DEBRO had the most liked content!

Community Reputation

336 Excellent

2 Followers

About DEBRO

  • Rank
    River Patroller

Profile Information

  • Gender
    Male
  • Location
    Atlanta, GA
  • Interests
    Atari game programming

Recent Profile Visitors

21,650 profile views
  1. Hi there, If the true intent is to control the player movement then you should move this code into the joystick routine where you are moving the player. In its current position you are controlling when to poll for the joystick input instead.
  2. Hi David, I think we can reduce the RAM usage if needed. I couldn't recreate this so not sure of the cause. Does this only occur in the new design of the Cave graphics? I do see your frame line count isn't consistent. It looks to fluctuate from 259 to 260. This may be the cause. I haven't determined the root of this at the moment. I have been able to recreate this one. This is occurring because your collision routine is not testing all enemies for touching the string. Your routine stops of jumps out once the first collision is found. The string is a special case where a collision could occur in all zones. I mainly see this occurring when an object above a Blue Bouncer collides with the string. Your collision routine identifies the top most collision and ignores the rest allowing the Blue Bouncer to pass through. I prefer the new design. Nice 👍
  3. Hi David, Couple of things. First the RAM. Comment out (or take away) lines 669 and 670. Next define tmpMissileVertPos as ds 2. tmpMissile1VertPos and tmpMissile2VertPos define these bytes. tmpMissileVertPos ds 2 ;-------------------------------------- tmpMissile1VertPos = tmpMissileVertPos tmpMissile2VertPos = tmpMissile1VertPos + 1 Also in the kernel around line 1462 you should have... cpy tmpMissile1VertPos ; 3 I believe you currently the compare with tmpMissile2VertPos This should get the missiles working again. Another thing I noticed is there is another extra scan line after drawing the top cave. I traced it to the vertical position of the top obstacle. It seems that sometimes when the top obstacle isn't present the vertical position is 23d. This causes the top kernel timing to go over. The kernel counts assumes you are not drawing the obstacle when you are done drawing with this section. You might want to look for how this is being set. If the obstacle isn't present then you could set their vertical position to a safe -1. The other thing is the "bouncing" is writing into the cave drawing. I'd think you'd want the obstacle to bounce above the cave? This might also be solved if the obstacle didn't bounce into the cave drawing area.
  4. That would make sense. Thanks
  5. Hi there, Does anyone know why Matt named this DASM?
  6. Hi Andrew, That is crazy! I don't think I've looked at it like that but you're right. Your and a lot of the original VCS homebrew games are reaching 20 years! If only we could get a [stella] @ 20+ documentary BTW, isn't Qb approaching 40 years old? Could we see a 40th anniversary release say on a Nintendo Switch? *nudge*
  7. Hi David, You can check the registers in the kernel. Checking in that spot would register the collision for the previous zone. I've attached two mock ups for collisions. One checking collisions in the kernel...storing the BALL collisions in an array and 1 byte each for the player and missile collisions. The other checking all collisions after the kernel is done drawing. The code isn't pretty but should give an idea. Hopefully I have my cycle counts correct with these. mr_yo_yo_kernel_mockup_INSIDE_KERNEL_COLLISION.asm mr_yo_yo_kernel_mockup_OUTSIDE_KERNEL_COLLISION.asm
  8. Hi David, You could check for collisions in the kernel and that is probably where I'd place them. The way your game is setup you should be able to determine the collisions outside the kernel. On any given frame an obstacle could collide with Mr. Yo-Yo. Checking the CXPPMM register would give you this condition. Now that you know this collision occurred; you can determine the zone for Mr. Yo-Yo to know the type of obstacle that triggered the collision. You can use a similar routine with the missiles and string (i.e. BALL). Once knowing a collision occurred, you can now determine the zone for the corresponding missile to know which obstacle triggered the collision. For the string, again you would look for the obstacle within the horizontal position of the string that triggered the collision. If you didn't want to use the time to determine the obstacle that hit the string then you could use an array to hold these collisions to make it easier to find outside the kernel.
  9. Hi David, Woohoo! So glad to see you making progress. I intentionally left the collision detection out of the kernel. I left it out as a potential exercise. There should be enough time in the drawing of the zones to check collisions and time outside to reset the register. You can ask for assistance if you find yourself stuck. I'll eventually get you an answer ;) And between me not logging in and answering another skilled developer may chime in as well. Yes, the remaining 90% of tweaks and hopefully optimizations. You should feel proud. While you work on the tweaks, I'd like to suggest considering PAL50 and fractional positioning. Your players will thank you...I know I would. I am indebted to @Andrew Davie for opening my eyes to fractional positioning. This will give you more control over your objects. Considering PAL50 could give you more vertical resolution for your player area and zones too. Since PAL50 allows 312 scan lines you could increase the size of the zones for PAL50 or maybe allow more zones if there is enough RAM to spare. An added benefit for your PAL players. Also, I was thinking about the current implementation of the missiles. Currently, one will have to be the color of an obstacle. This is fine but there may be a better way. I may be adding more work for myself for this but had to get it out :) Instead of using the BALL to draw the string we could use GRP1 for both the string and Mr. Yo-Yo. This could be done by setting the color and graphic of the string before launching the kernel then when time to draw Mr. Yo-Yo change the color and graphics. Then you could use the BALL and M1 for the missiles. In this configuration the worse case scenario (one missile is above Mr. Yo-Yo) would have one missile the color of the string and the other the color of Mr. Yo-Yo. The best case scenario (both missiles below Mr. Yo-Yo) would have both missiles the color of Mr. Yo-Yo. The collision routine would of course need work too since the string and Mr. Yo-Yo would share the same object. When a player collision occurred you would need to know the zone to know if the collision was with the string or Mr. Yo-Yo. This is all theoretical at this point. I haven't done anything to prove or disprove it could work. What do you think?
  10. Hi there, You are correct Karl. It is not a page boundary issue. I'm sorry about that. The issue is my kernel time counts. I missed removing the HMCLR around line 1285. This is adding an extra 3 precious cycles and causing the extra line when the kernel draws Mr. Yo-Yo on the upper cave line. David, you can remove that HMCLR because its now done outside the kernel.
  11. Hi David, The horizontal positioning routine in the kernel crosses a page boundary which adds an extra cycle for the branching. This is causing the extra scan line and affecting the horizontal positioning of the objects in the kernel. You might consider moving the display kernel to start at the page beginning or the beginning of your ROM bank to help with this in the future. I didn't add it in my mockup but Thomas has a CHECKPAGE macro you could insert in the kernel as well. It would help find these branches and stop the assembly when they are found. The reason the missiles move vertically with the player is because you are not setting the tmpMissile1VertPos and tmpMissile2VertPos correctly. These variables now represent the missile offset for the kernel. I'll try to explain what I'm doing. To draw Mr. Yo-Yo I'm using tmpYoYoGraphicIdx. This gets decremented and compared to the height of Mr. Yo-Yo to know if it time to draw him. This value is calculated outside the kernel in relation to Mr. Yo-Yo's vertical position. This same positioning is used to determine when to draw the missiles. So the missile kernel scan line position must be in relation to Mr. Yo-Yo's vertical position. I do this outside the kernel in the mockup like... sec lda yoyoVertPos ; get Mr. Yo-Yo vertical position sbc missile1VertPos ; subtract missile vertical position sta tmpMissile1VertPos ; set missile vertical position for kernel sec lda yoyoVertPos ; get Mr. Yo-Yo vertical position sbc missile2VertPos ; subtract missile vertical position sta tmpMissile2VertPos ; set missile vertical position for kernel I hope that makes sense.
  12. Hi David, Attached is a new mockup showing two missiles launching. This is a rough sketch but shows how it can be done. There should also be enough time in the kernel to read and store hardware collision registers. Hopefully this will get you moving. mr_yo_yo_kernel_mockup_20201221.zip
  13. Hi David, In the current kernel mockup I sent, each horizontal band holds a vertical position for a missile. Inside the kernel we pull the vertical position from missileVertPos,x (with x being the index for the horizontal band) and place it in the temporary variable tmpMissileVertPos. This value is decremented each scan line within the horizontal band. When the value reaches zero then the missile is enabled. A value of zero would be the scan line to show the missile. This is where the PHP trick comes in. I believe this can be done with less RAM. I think I originally was thinking multiple missiles could be in flight for a given horizontal band. It's been a while so I'm not really sure if that was my original thinking. If only two missiles can be active at a time then the kernel could be redone to where only two RAM locations for vertical positioning is needed instead of using 6 (i.e. 12 with two missiles). Also, the current mockup has a bug in it🤦‍♂️ Replace the PLP with PLA. The PLP opcode will affect processor status flags.
  14. Hi there, This has been asked a couple of times before. I believe the majority lean toward PAL60 by this poll. I live in an NTSC region but prefer seeing PAL50 to give true fractional positioning. If you can go further and give a true PAL50 display instead of a compressed NTSC display on a PAL50 TV then that would be icing on the cake. Not many games did this.
  15. Hi David, Glad to see you making progress. I'll attempt to answer this or comment. I'm familiarizing myself with your horizontal positioning. Your position routine gives your sprites a horizontal range of 5 - 164. This equates roughly to color clocks 73 - 232. If your sprites were ONE_COPY in size then the maximum horizontal position before a screen wrap would be 152 (i.e. roughly color clock 220). Your sprites are DOUBLE_SIZE. This gives a maximum horizontal value of 143 (i.e. roughly color clock 211) before a wrap around occurs. Currently, the kernel example I supplied is doing an HMOVE on each scan line within a zone. This masks 8 pixels on the left. Because of this masking you can have a maximum horizontal position of 151 (i.e. roughly color clock 219) before the player sees the sprite wrap around. Given this, your sprite range should be...0 - 151 (i.e. roughly color clocks 68 - 219). You have some decisions here. Here are some I've outlined though there could be more options... (1) Like Grand Prix you would need additional sprites to show a smooth transition. You could have an additional graphic for masking that all the obstacles share. You'd need an ~additional 7 cycles to set the masking LSB value and an additional 8 cycles to mask the sprite data. (2) You could add playfield graphics on either side of the playfield. Setting PF0 should give enough space to mask the player sprites for a smooth transition. The trade off though is the player looses ~ 8 pixels of the playfield on each side. (3) You could not worry about the smooth transition and have the obstacles "vanish" when they reach their perspective boundaries. It's not bad to do this. Other games have done the same. I personally would prefer to see the transition but it wouldn't hurt not having it. At the end of it all this is your game and whichever decision you make well...its yours. You only need to answer to yourself. So you want to be content on your decision. I wish I kept a log of how many times I restarted my Climber 5 kernel. Trust me, it was a lot. All of these are learning experiences. Keep pushing through and having fun.
×
×
  • Create New...