+Karl G Posted March 13, 2019 Share Posted March 13, 2019 It's looking really good! I would think that whatever player is below the other should have priority regardless of ball possession, though? Quote Link to comment Share on other sites More sharing options...
easmith Posted March 13, 2019 Author Share Posted March 13, 2019 It's looking really good! I would think that whatever player is below the other should have priority regardless of ball possession, though? Thanks! Ideally yes.. unfortunately attempting the priority swap threw a wrench into the logic, and I have made many band aids to try and fix it and did so many changes it's hard to identify the issue. I will keep thinking about it, but if I cannot fix it at least it works at the most important time . There are a couple of other things I need to still fix . Quote Link to comment Share on other sites More sharing options...
easmith Posted March 13, 2019 Author Share Posted March 13, 2019 Any way to get the ball orange while leaving the backboard and lines white ( which are also PF) ? I am not currently using M1. I have experimented with a few things and cannot get it . Quote Link to comment Share on other sites More sharing options...
CrazyChris Posted March 14, 2019 Share Posted March 14, 2019 (edited) easmith, May I recommend keeping your progress to one thread. You are making more work for yourself, and making it confusing for your audience to follow. Chris Edited March 14, 2019 by CrazyChris Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted March 14, 2019 Share Posted March 14, 2019 Any way to get the ball orange while leaving the backboard and lines white ( which are also PF) ? 30hz flicker might be the only way here. Taking that approach can get things back to single-scanline resolution, and have a round ball too. Players on 1 frame, ball and shadow (and maybe a detailed basket) on the other. The priority issue is easily fixed by using indirect-Y addressing (as mentioned). Quote Link to comment Share on other sites More sharing options...
easmith Posted March 14, 2019 Author Share Posted March 14, 2019 easmith, May I recommend keeping your progress to one thread. You are making more work for yourself, and making it confusing for your audience to follow. Chris ok sorry, don't know if everyone looks at both and was hoping to reach as many people as possible. Most of the technical questions are here. Will try not to duplicate anymore Quote Link to comment Share on other sites More sharing options...
easmith Posted March 14, 2019 Author Share Posted March 14, 2019 Use indirect vectors in the kernel instead. Then you can swap them before you position the sprites if needed. Whoever is lower onscreen gets GRP0. Very easy to set up (indirect),y addressing here, there's enough cycle time in the scanlines (currently). This actually simplifies the kernel, since the Y index would always be zero. In any case, the kernel is still pretty small...so you could just go with a duplicate instead. I would need a bit more handholding here to truly understand ( like examples). Currently, If P1 is lower ( and now only if has ball) , then before the horizontal positioning, I swap P0X with P1X and P0y with P1y. Then if swap is activated go to alternate kernel, then after kernel swap back before game logic , which depends on player positions. The other problem is that any routine that involves collision detection ( steals, rebounds, blocks) have to be adjusted to account for collision with P1 sprite or P0 sprite activating P1offense = 1. for example. Much of the logic depends on the values of the indicator for who's in possession of ball. So this threw off some of my routines which had to be adjusted. All of this requires a lot of ROM bytes , although I do think it is a must have ( at least the way I have it now to when P1 has possession) Quote Link to comment Share on other sites More sharing options...
easmith Posted March 14, 2019 Author Share Posted March 14, 2019 30hz flicker might be the only way here. Taking that approach can get things back to single-scanline resolution, and have a round ball too. Players on 1 frame, ball and shadow (and maybe a detailed basket) on the other. The priority issue is easily fixed by using indirect-Y addressing (as mentioned). Hmmm...... I think this would mess with my block and rebound schemes which depend on hardware collision detection with P0 and P1. These would not register if objects were not on same frame. I suppose I could alter these ( steal detection, dunk detection , collision of feet, and detecting which zone player is in use a different method). Would require more free space. Don't know if the orange ball color is worth it though. Going back to single line I would have to redo all player and PF graphics . I can live with the square ball but I can see some folks seeing square ball and having it be a dealbreaker. I have an idea for getting the ball to be a + , but that is no better in my opinon. This level of polish is the difference between really advanced programmers and dabblers like me. 1 Quote Link to comment Share on other sites More sharing options...
easmith Posted March 14, 2019 Author Share Posted March 14, 2019 posted the wrong .bin. correct is up now. too many old versions I need to delete. Quote Link to comment Share on other sites More sharing options...
easmith Posted March 16, 2019 Author Share Posted March 16, 2019 Why do you have the shadow of the ball below the players feet? It looks like the ball is closer than the player where it should be vice versa or the same. Also, if you put the ball shadow on the feet level, the shadow color won't have to change when players overlap vertically. I moved the shadow up. Using M1 instead of M0 solved the color issue Quote Link to comment Share on other sites More sharing options...
easmith Posted March 23, 2019 Author Share Posted March 23, 2019 Very close to finished now . Have AI opponent pretty solid . Latest rev here. Thanks to all for assistance . http://atariage.com/forums/topic/288985-one-on-one-atari-2600-asm/?p=4243252 Quote Link to comment Share on other sites More sharing options...
easmith Posted April 22, 2019 Author Share Posted April 22, 2019 (edited) I got the message below from a cart maker . I tested to make sure the game starts up in all 4 banks ( I think ) . Can anyone help? latest ROM is here ********************************** "It appears the game does not always initialize correctly on real hardware. a couple of them do which is frustrating - so far I have made 12 and only 3 are reliable. Some of them will work if you turn the power off and on quickly - which is also not a good solution. I built other 16K games to test the boards, etc. They work fine. It is this ROM image. Something is amiss when it first powers up and initializes. It may be that it is too quick and the Atari isn't ready and it crashes." Edited April 23, 2019 by easmith Quote Link to comment Share on other sites More sharing options...
+Karl G Posted April 22, 2019 Share Posted April 22, 2019 If some of the carts are reliable and not others, and it's the same ROM image for all of them, then how could it be the ROM image that is the issue? Edit: That being said, I'm getting inconsistent startups when running this in Stella 6 with developer settings. Quote Link to comment Share on other sites More sharing options...
+Karl G Posted April 22, 2019 Share Posted April 22, 2019 In Stella, under "Developer..." choose "Random startup bank". I get inconsistent startup when this is enabled, but not when it is disabled. The code needs to assume that it can be started from any bank, and jump to the correct one upon startup. 1 Quote Link to comment Share on other sites More sharing options...
easmith Posted April 22, 2019 Author Share Posted April 22, 2019 (edited) yes so am I . But when I just do the reset system and then change startup bank it seems to work fine Edited April 22, 2019 by easmith Quote Link to comment Share on other sites More sharing options...
easmith Posted April 22, 2019 Author Share Posted April 22, 2019 I thought typing reset, then changing bank, then hitting "exit " replicated this . Quote Link to comment Share on other sites More sharing options...
easmith Posted April 22, 2019 Author Share Posted April 22, 2019 (edited) In Stella, under "Developer..." choose "Random startup bank". I get inconsistent startup when this is enabled, but not when it is disabled. The code needs to assume that it can be started from any bank, and jump to the correct one upon startup. I think I fixed it now thanks Edited April 23, 2019 by easmith 1 Quote Link to comment Share on other sites More sharing options...
+Karl G Posted April 22, 2019 Share Posted April 22, 2019 Startup with randomized startup bank seems to be working for me in Stella with this version. I can't test on hardware at the moment, since my console is on loan for the week, though. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.