Thomas Jentzsch Posted June 28, 2016 Share Posted June 28, 2016 Am losing...my...%#@%@#(..mind... the velocity/decay routines make for smooth motion, but correction from collision detection is nothing short of a fucking nightmare! Is the correction the problem or the detection itself? In your case, with only vertical and horizontal walls, the correction is dead simple: If you hit a horizontal wall, reverse the vertical speed If you hit a vertical wall, reverse the horizontal speed. That's all. In real life, depending on the objects colliding, some (varying) energy is lost too. So if you want to become more realistic, you can reduce the reversed speed afterwards (e.g. by 1/8th). Quote Link to comment Share on other sites More sharing options...
tschak909 Posted June 28, 2016 Author Share Posted June 28, 2016 I'm going to redo the motion code, today... but I realized that part of my problem on the horizontal side of things was that I wasn't setting HMCLR... (somewhere along the line I had removed it...I have version control so I could bisect and see where, if I cared...but..) -Thom Quote Link to comment Share on other sites More sharing options...
tschak909 Posted June 29, 2016 Author Share Posted June 29, 2016 VCS Dodgeball update: The current challenge? Get the motion and velocity bits of code to work together nicely so that when you bump into a wall, YOU DON'T GO RIGHT THROUGH IT. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted June 29, 2016 Share Posted June 29, 2016 When using hardware collisions, you always detect the collisions a bit too late. Your object is already (more or less) inside the wall then. So when you reverse the speed, you also have to correct this late detection. Therefore I would undo the previous frame's movement (of the reversed direction only or both) when you detect a collision. That safely moves you outside the wall and automagically fixes your current problem too. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted June 29, 2016 Author Share Posted June 29, 2016 Gotcha. I'm slowly learning the interesting warts of this hardware... hehe... -Thom Quote Link to comment Share on other sites More sharing options...
tschak909 Posted July 1, 2016 Author Share Posted July 1, 2016 Are you doing hardware collisions? If so then consider switching to software collisions. 1) Have a variable for the X position, as well a Y position. 2) Read the joystick, add in your velocity, and come up with the next X and Y positions. Store them as temp variables for now. 3) Check if there are any playfield blocks between the old position and new. - If no blocks were in the way, store the new positions and exit. - if blocks were in the way, either: a) Place the object directly in front of the playfield and kill all velocity (dead stop). Update new positions and exit. b) Bounce off the playfield (reverse direction, and figure out how many pixels the bounce should be). If motion is in two directions, You can bounce off a wall while keeping one direction (i.e. traveling up-left ----> hit wall ----> travel up-right, so direction changed only for the x-axis). What's important about two directions is you have to be aware that rebounds like this can end up back in a wall. So you have to program to avoid that. Then update new positions and exit. c) Hit wall and slide (this is for traveling in two directions only). Finally update new positions and exit. Example of bouncing off a wall into a wall: Collisions.png That should get you started. Before you start remember that how you store the playfield blocks in rom are not always how they appear on the screen. Some will be reflected. You need to figure out which parts are reflected and which are not. (ie which parts of left side PF0,PF1,PF2, and right side PF0,PF1,PF2 are reflected when compared to how it's stored). When checking the date you have to flip the playfield bits which are reflected in rom, or write some convoluted code just to chose the right bit. One thing you might consider is making a copy of your playfield data that is already correctly orientated so you simply don't have to deal with any of the flipping, or figuring out if it needs to be flipped. You can also overlap the data to save bytes, and it is very fast. It also might not waste as many bytes as it first appears. Often with the 2600 you will spend a long time writing some code only to realize it takes more bytes then a look up table and way slower. Thanks for the pointers. I will try to use them as best I can. However, I will state that since this is a 2K game, that I am trying to make as close to launch titles as possible, I am attempting to use hardware collisions (using patterns from Combat, which doesn't track X position at all)...maybe I'm nuts, but if Combat can do it (and do tank pong)... -Thom Quote Link to comment Share on other sites More sharing options...
Just Jeff Posted July 1, 2016 Share Posted July 1, 2016 Hi.. You know I'm new at this, but I'll try... Unless I missed it, it doesn't look like you are storing the players' last known good position before a collision. If you did, then your collision routine can simply put the player back in it. Right now it looks like you reverse the velocity, but don't move the player back out of the collision, so you continually get collisions and stay in the collision routine for a while. Hope that helps! Quote Link to comment Share on other sites More sharing options...
tschak909 Posted July 1, 2016 Author Share Posted July 1, 2016 Yup, while I do store Y position, I do not do this for X, as I am trying to simply use HMOVE for the X (like Combat). -Thom Quote Link to comment Share on other sites More sharing options...
Just Jeff Posted July 1, 2016 Share Posted July 1, 2016 Ah I see that too.. I think you might still run into the same problem with Y unless you store old coordinates as well as the new. Maybe. Does combat really not store x positions? I did not know that. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted July 1, 2016 Author Share Posted July 1, 2016 nope, it uses a known start position, and nudges X along with the horizontal motion register. Other than that, Combat uses a set of Direction values for P0, P1, M0, M1, which correspond to 22.5 degree increments. http://www.qotile.net/minidig/disassembly/dicombat.asm<- the canonical disassembly for Combat -Thom Quote Link to comment Share on other sites More sharing options...
Just Jeff Posted July 1, 2016 Share Posted July 1, 2016 (edited) Cool.. I haven't tried to read through the combat disassembly in a while.. Another thing that was way to complicated for me when I tried it months ago. I'll read it more tonight maybe. So- another guess at your collision issue. Is it possible that your HorizontalCollided routine conflicts with your CheckLeft and CheckRight. They will put in a horizontal value, but when you are always in the collision state, left will always be flipped to right and vice versa by HorizontalCollided? Edited July 1, 2016 by BNE Jeff Quote Link to comment Share on other sites More sharing options...
tschak909 Posted July 1, 2016 Author Share Posted July 1, 2016 That is indeed a possibility... I am going to spend part of the weekend doing some refactoring. -Thom Quote Link to comment Share on other sites More sharing options...
tschak909 Posted July 2, 2016 Author Share Posted July 2, 2016 Finally got around to testing this guy on real hardware, thanks to batari's wonderful Harmony Cartridge...seriously, I owe Fred a beer. Quote Link to comment Share on other sites More sharing options...
Just Jeff Posted July 2, 2016 Share Posted July 2, 2016 (edited) Nice! I tried to see how Combat handles the situation. It seems to use BumpTank, PhMove and a table, but nothing clear to me. If it were me I'd track the x axis in RAM. ('cause I know how to do that) Edited July 2, 2016 by BNE Jeff Quote Link to comment Share on other sites More sharing options...
tschak909 Posted July 3, 2016 Author Share Posted July 3, 2016 I'm going to branch master and do a new branch called x_y_pos, this one will keep track of X and Y, to try and make things a bit fucking easier. For now, master contains velocity code in it, and I may actually stash that off somewhere else for later perusal.. I _really_ want....really really want nice smooth, non-break-neck movement. But I must confess, I am not god's gift to writing algorithms....I have to keep all four volumes of Knuth's Art of Computer programming within reach... right now, I suck. Let's see if I can un-suck. -Thom Quote Link to comment Share on other sites More sharing options...
Just Jeff Posted July 3, 2016 Share Posted July 3, 2016 right now, I suck. Let's see if I can un-suck. -Thom Yeah I just took my latest program and (virtually) crumpled it up, lit it on fire, and threw it out into the front yard. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted July 3, 2016 Author Share Posted July 3, 2016 ah, the joys of coding at 4am in the morning: ;;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; ;; Yet another thwack at motion. No really, this ;;; ;; is getting really old. I feel like I'm Bill Murray ;;; ;; at this point. Actually, wait, maybe I'm schizophrenic ;;; ;; and I am both Bill Murray, and Stephen Tobolowsky? ;;; ;; Don't do drugs, kids... ;;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; ;; motion is RLDU 8421 ;; where left nibble is active directions ;; and right nibble is delay which is subtracted by 1 ;; to get mask, e.g. 1000 becomes 0111 ;; PlayerMotion: ldx #$00 DelayMotion: lda P0Velocity,x ; get P0 Velocity and #$0F ; mask off direction. sec ; set carry. sbc #$01 ; Subtract 1 to get the delay mask. sta Temp ; store temporarily. lda Frame ; get current frame and Temp ; mask with computed frame delay. bne PrepScoreForDisplay ; if we're not ready to do motion, skip it. ... -Thom Quote Link to comment Share on other sites More sharing options...
tschak909 Posted July 4, 2016 Author Share Posted July 4, 2016 The move to use X position paid off, now that I could recall the last good position, collision problems went away. I have temporarily implemented a 4-way joystick routine, for anyone who wants to pull the code and look at it, (it has been merged back to master)... ...now it's implementing the velocity addition/decay routines, which, hopefully will work a lot better, this time, which respond to joystick presses.... ...all this, to have something that feels right? ... yeah... As soon as I have the velocity stuff in and debugged, i'll put up a movement build, so that people can comment on player movement. -Thom Quote Link to comment Share on other sites More sharing options...
tschak909 Posted July 7, 2016 Author Share Posted July 7, 2016 Hey guys, need a little help. I'm a little tight on my kernel, and am wondering if I will need to kill PF2 updating in order to do this. The Ball and missiles are quantized at 4 scanline intervals (to make a large enough ball to be considered a ball), now of course the missiles can't be delayed, but the ball of course, can... If I do an AND #$FC, then I get the desired 4 scanline ball size, but the ball motion becomes a ripple, due to the quantization. I want to duplicate the ball enable on the next scanline, so that I can get the desired 4 scanlines, with the delay, but if I do this, my kernel spills over and I get an odd number of scanlines, (which causes my 2LK to go into oblivion)... What are my options? Code attached. -Thom dodgeball.asm dodgeball.bin Quote Link to comment Share on other sites More sharing options...
tschak909 Posted July 7, 2016 Author Share Posted July 7, 2016 More Dodgeball WIP: First bit of computer ball motion implemented, still need to implement the complete reverse (for corners). -Thom Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted July 7, 2016 Share Posted July 7, 2016 (edited) What are my options? Code attached. You should annotate (and aggregate) the CPU cycles in your kernels. That would significantly help you and those who may want to help you. Also your coding style is quite different. Many people here use: starting with lowercase = ZP variables starting with uppercase = global labels all uppercase = constants Edited July 7, 2016 by Thomas Jentzsch Quote Link to comment Share on other sites More sharing options...
LS_Dracon Posted July 8, 2016 Share Posted July 8, 2016 (edited) Hey guys, need a little help. I'm a little tight on my kernel, and am wondering if I will need to kill PF2 updating in order to do this. The Ball and missiles are quantized at 4 scanline intervals (to make a large enough ball to be considered a ball), now of course the missiles can't be delayed, but the ball of course, can... If I do an AND #$FC, then I get the desired 4 scanline ball size, but the ball motion becomes a ripple, due to the quantization. I want to duplicate the ball enable on the next scanline, so that I can get the desired 4 scanlines, with the delay, but if I do this, my kernel spills over and I get an odd number of scanlines, (which causes my 2LK to go into oblivion)... What are my options? Code attached. -Thom Have you 14 free cycles? http://atariage.com/forums/topic/65174-fastest-way-to-display-missilesball-2600/?hl=enabl&do=findComment&comment=804737 Edited July 8, 2016 by LS_Dracon 1 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted July 8, 2016 Author Share Posted July 8, 2016 Interesting thought... Thanks. -Thom Quote Link to comment Share on other sites More sharing options...
tschak909 Posted July 9, 2016 Author Share Posted July 9, 2016 I am putting a note here to remind myself ,that the game isn't truly finished until I rewrite the code to not depend on frame delays, and to use fractional values, instead...(this is also perhaps a public admission of guilt that I am, for the moment using frames as a delay...which is a big @($#@$#@ no-no)... -Thom Quote Link to comment Share on other sites More sharing options...
tschak909 Posted July 9, 2016 Author Share Posted July 9, 2016 I am _SO_ close, I have my ball collision detection code working, except I need to alter the angular velocity a bit so that it doesn't get caught in a loop trying to bounce back and forth! In the Combat code, I am spending tomorrow seeing what THIS entails, particularly the "Jiggering" part.... ; ; I always wondered how this works. Stella does not know the ; orientation of the wall that was hit, so this is how it ; reflects: ; ; Immediately after a collision, it tries a vertical reflection, ; jiggering the result so that it won't be exactly vertical or ; exactly horizontal. ; ; If this is the next frame (MxPFcount=$01) that failed, so ; we reverse direction 180 degrees to turn it into a horizontal ; reflection. ; ; On MxPfcount=$02 we take no action, since the missile may need ; the cycle to re-emerge from a wall. ; ; On MxPFcount=$03 or higher, we retrieve the original heading and ; turn it 180 degrees, assuming a corner reflection. And we keep ; applying this same bearing until it's out of the #*%@ wall. ; -Thom 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.