tschak909 Posted October 3, 2016 Author Share Posted October 3, 2016 For anyone interested, I will be attending the Portland Retro Gaming Expo (PRGE), in Portland, OR, from the 21st, to the 23rd of October, and will bring the latest build of dodgeball with me on a Harmony cart. -Thom 2 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted October 4, 2016 Author Share Posted October 4, 2016 I am currently trying to debug a booger bear of a bug. Because you can now pick up both player balls, there is at least one race condition where the opposing ball can disappear into null... ugh. -Thom Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted October 4, 2016 Share Posted October 4, 2016 I am currently trying to debug a booger bear of a bug. Because you can now pick up both player balls, there is at least one race condition where the opposing ball can disappear into null... -Thom Did you make sure the opponent didn't pick it up? I assume you found this by doing the super score mode trick. I saw that too and figured the other player had picked it up. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted October 4, 2016 Author Share Posted October 4, 2016 Yup, I made sure. There is literally a race condition that causes both ball-in-hand to hit 0, while also having opball set to 0, but the opponent ball still being RESMP0'd. This essentially means the ball falls through the cracks of accountability. -Thom Quote Link to comment Share on other sites More sharing options...
tschak909 Posted October 7, 2016 Author Share Posted October 7, 2016 Once I had added player scoot, both for ice dodgeball mode, and for player hit collision, I was able to add player-to-player collisions, players now bump and ease away from each other. This needs lots of tuning though, because it introduced another bug, in some cases, the two players can get stuck together, just need to see if increasing the decay value helps here, or if I will need to do something more sinister. -Thom Quote Link to comment Share on other sites More sharing options...
InsertCoin25 Posted October 13, 2016 Share Posted October 13, 2016 Hey tschak909, loving the demo. I just have one question. Is the player when running into the walls, on the playfield, suppose to vibrate like that? I would love to play this on cartridge against people. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted October 13, 2016 Author Share Posted October 13, 2016 Yes, it is a side effect of the collision detection. I will do a new playtest (playtest3) once I debug the last two big bugs, which are:(1) Kernel timing has changed due to adding support for multiple playfields, needs to be fixed. (2) Sometimes opposing player ball disappears when held by opposing player (race condition somewhere) But the biggest change that you'll see in playtest3 is that players now can't overlap, and will bump against each other (preventing a specific class of bugs that were happening when ball targeting code would race against the opposing ball carry code) My time has been limited lately, but I will try to get this out as soon as possible... If you will be at PRGE, I will be showing off my latest build there, in a couple of weeks. -Thom Quote Link to comment Share on other sites More sharing options...
InsertCoin25 Posted October 14, 2016 Share Posted October 14, 2016 Sounds awesome!! I would love to attend PRGE at some point in my life, but I live on the east coast, so making it there is hard at this point in life. Best of luck at PRGE showing off the demo. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted October 15, 2016 Author Share Posted October 15, 2016 There are days that I _really_ love Free Software development, and using tools like Github. Today, I received a bug report from ZackAttack indicating some very interesting behavior when two players collide, occasionally one or both of the players will warp off to the other side of the playfield.... That one is actually interesting enough that I might consider that a "feature" ... But he also kindly did a pull of my code, and fixed the playfield kernel glitch (by slipping the initial writes out by 33 cycles) that has been driving me batty for days. I just merged the code into master after looking at it, and the result is awesome. Thank you, so much! -Thom p.s. This leaves one really knobby bug where a ball can disappear when a player has picked up both of them, but after that I can release one final play test, and then really start tightening this code up. 1 Quote Link to comment Share on other sites More sharing options...
InsertCoin25 Posted October 17, 2016 Share Posted October 17, 2016 Awesome, I am glad to hear everything is coming together for you. This will be fun when it is finished. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted October 22, 2016 Author Share Posted October 22, 2016 @ PRGE 2016. Great show, so far. Tod Frye and I played the latest build of the code, and he was _very_ positive. He was very impressed that I was trying to shove this into 2K of ROM. So happy. -Thom 6 Quote Link to comment Share on other sites More sharing options...
InsertCoin25 Posted October 26, 2016 Share Posted October 26, 2016 That is awesome!! Glad you got good feedback from Tod Frye, I can only imagine what a motivational boost that must of been . Take Care 1 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted October 26, 2016 Author Share Posted October 26, 2016 Here, we are talking about Tod's Xevious kernel... -Thom 3 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted November 5, 2016 Author Share Posted November 5, 2016 After a few days away from the code, am diving back in to fix the one last big bug, before I start cleaning up the code in earnest. -Thom Quote Link to comment Share on other sites More sharing options...
tschak909 Posted November 12, 2016 Author Share Posted November 12, 2016 Still working on this bug. Have had to work on other things, such as work, and...try to rest a bit, because I have a persistent ear infection which is forcing me to go take many breaks on the couch. -Thom Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted November 17, 2016 Share Posted November 17, 2016 Just a couple of comments... firstly "CMP #$00" is superfluous if you're just loaded the value and you just want to BEQ/BNE. The Z flag is set on loading. So you can discard the CMP and save a couple of cycles and bytes. Secondly, I watched the videos - and I'm not convinced the ball movement is correct. Sometimes it seems to go really smooth, and other times (particuarly when travelling near-horizontal slightly diagonal) it looks like it's stuttering. I think there's an issue. EDIT: In the sequence TYA / EOR #$FF / AND #$01 / TAY if you know Y is *already* 0 or 1, then this is better... TYA / EOR #1 / TAY Also, you do what I did when I was first learning... writing this AND #$01 instead of this AND #1 That is, using the most human-readable form based on context. That #$00 stuff is kind of silly use #0 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted November 17, 2016 Author Share Posted November 17, 2016 Hey Andrew! Thanks so much for the critique, you can see the full code @ http://github.com/tschak909/dodgeball I know the code is _very_ unoptimized at the moment. I deliberately do not optimize, unless it blocks progress. When I finish smashing all the bugs, I will go through and optimize the crap out of this code.... funny thing about 6502 code optimization, there is always one more byte that can be gained... Rob Zdybel, Tod Frye and I talked about that at length @ PRGE this year. The AND #$01 is intentional. It's easier for me to read, and I think in hex. As for the ball motion, yeah... the vertical motion of the ball is very choppy, because I am ANDing #$FC after I get to the right scanline count. I need to rethink my missile/ball placement code so that this does not happen, right now it's: LAX SCANLINE EOR BALLY2 ; 3 8 AND #$FC ; 2 10 PHP ; 3 13 Yeah, the Combat stack trick... anyway, any help pointing in the right direction is always welcome. I want to get this game done, and off my plate. -Thom Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted November 17, 2016 Share Posted November 17, 2016 Strongly disagree about that method of optimization (i.e. waiting until coding is complete). There are a LOT of potential problems that can arise when you begin trimming the fat...and many times, the cause can be a difficult sucker to nail. Better to cut out the wastes as they are discovered...all the more likely you are able to spot problems while playtesting is still going strong. As always - backup early, backup often...do not overwrite or delete any backups until it's cast in iron. 2 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted November 17, 2016 Share Posted November 17, 2016 There are different levels of optimizing. Heavy optimizing often obfuscates the code, so it requires a lot of comments to stay understandable. Then sometimes it is better to just note the opportunity as a TODO and come back later when required. Simple optimizations should be done immediately. Quote Link to comment Share on other sites More sharing options...
gauauu Posted November 17, 2016 Share Posted November 17, 2016 As always - backup early, backup often...do not overwrite or delete any backups until it's cast in iron. And/or use proper version control. Doing a git bisect has saved me hours trying to hunt down weird issues that I inadvertently introduced..... Quote Link to comment Share on other sites More sharing options...
GraziGamer Posted December 24, 2016 Share Posted December 24, 2016 I like the project! I design the OpcodeGames boxes/labels/etc (ColecoVision). If you need someone to develop the art box, labels, manuals, etc, you can count on me! 1 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted December 25, 2016 Author Share Posted December 25, 2016 I like the project! I design the OpcodeGames boxes/labels/etc (ColecoVision). If you need someone to develop the art box, labels, manuals, etc, you can count on me! Thank you, so much for your wish to help! I need to squash one more bug before I do the next playtest (it's been very difficult to solve.) As for the cover art, I envisioned Dodgeball as one of the lost launch titles for the original numbered run in 1977, something like: Note the numbering on the spines, the first 9 VCS games were done in this way. I did an initial test for the cartridge artwork (need to do another pass): Thoughts? -Thom Quote Link to comment Share on other sites More sharing options...
GraziGamer Posted December 26, 2016 Share Posted December 26, 2016 (edited) Ok, I have some ideas here. Which style do you prefer for the back of the box? The front: the only tricky thing is the illustration, we would have to make a composition or something.. do you have any images of dodgeball you have already selected or am I free to chose one? Label: Just little space adjustments to make. Edited December 26, 2016 by GraziGamer Quote Link to comment Share on other sites More sharing options...
tschak909 Posted December 26, 2016 Author Share Posted December 26, 2016 Actually..yeah... and it's a bit of an in-joke to the 2004 movie. some bits for composition: (I'm deliberately not doing multiple players, because this is a 1 on 1 game, but...) and of course...Patches.. -Thom 1 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted December 27, 2016 Author Share Posted December 27, 2016 As for the back, the former variation is probably more applicable. -Thom Quote Link to comment Share on other sites More sharing options...
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.