+Gemintronic Posted December 14, 2012 Author Share Posted December 14, 2012 Thanks for the help GroovyBee. Apparently bB doesn't like the number 10 for complicated arithmetic statements. I separated out the multiply by ten and it stopped bugging out. tempvar = ((rand&7)+1) player1y = tempvar*10 You suggestion to look at the assembly gave me the hint that it just wasn't parsed correctly. In other news I just figured out how to avoid artifacting when rapidly scrolling left and right. Now I can safely make a Metroid clone. Basically, you cannot immediately scroll in the opposite direction when sitting on the same x/y coordinate. Sprybug gives the player some leeway to move a little on the screen instead of being fixed in the middle. I *think* this is how he avoids this issue. Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted December 14, 2012 Share Posted December 14, 2012 I'd better explain that code . The routine randomize is called and leaves a value in the accumulator. After bitwise ANDing with 7, clearing carry and adding one the value in the accumulator is shifted left twice which multiplies it by 4. The contents of Areg are then added (so this should be the value in the accumulator before the x 4). So the accumulator is now 5 times the value "returned" from the randomize call. The accumulator is then shifted left once which gives and effective multiply of 10. Then a shift right gets you a divide by 2 before setting carry and subtracting 30. In pseudo code it would be :- a=(rand&7)+1 val=(((a*4)+a)*2)/2)-30 1 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted December 14, 2012 Share Posted December 14, 2012 Thanks for the help GroovyBee. No worries, Apparently bB doesn't like the number 10 for complicated arithmetic statements. I separated out the multiply by ten and it stopped bugging out. Personally I'd report it as a bug in the bB bugs thread. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted December 14, 2012 Share Posted December 14, 2012 Do you think you might need to use this? www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#multiplication include div_mul.asm Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted December 14, 2012 Share Posted December 14, 2012 Calling a generic multiply routine for a value of 10 will be much slower than the simple shift and add method bB generated. Even though bB didn't generate valid code in this instance theloon has a workaround to go forward with. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted December 14, 2012 Author Share Posted December 14, 2012 Do you think you might need to use this? www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#multiplication include div_mul.asm I double checked the source I posted at the beginning of this topic. It does indeed have the div_mul.asm at top. Removing that asm library generates the same error. Like GroovyBee said, I guess I've got a workaround for now. Thanks for the sanity check though! It's always good to double check the basics when things get too complicated. Now I have to decide if I want to refactor my code now that I have an idea to make scrolling westwards work without artifacts. Quote Link to comment Share on other sites More sharing options...
bogax Posted December 14, 2012 Share Posted December 14, 2012 re GroovyBee's comment about faster than calling a generic multiply, if you use *4*4 or *2*8 instead of *16 bB will use shifts instead of caling the multiply routine. There's other optimizations you could make also. (but they might mess with the clarity of your code) Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted December 14, 2012 Author Share Posted December 14, 2012 re GroovyBee's comment about faster than calling a generic multiply, if you use *4*4 or *2*8 instead of *16 bB will use shifts instead of caling the multiply routine. There's other optimizations you could make also. (but they might mess with the clarity of your code) Clarity of my code? Is that like the translucency of mud? I'm not sure how I could get a random number that would place the object in multiples of 10 with those operations. This seems to be the best useable method so far: tempvar = ((rand&7)+1) player1y = (tempvar*10)-30 It sometimes goes off screen to make object placement a little more spaced out. It also remains two blocks above the usual ground level so Barb (the player) can almost always hit the block. In other news I tried my idea to stop artifacts when scrolling left to no good result. So, I guess this remains a traditional Maryo type scroller after all Quote Link to comment Share on other sites More sharing options...
bogax Posted December 14, 2012 Share Posted December 14, 2012 (edited) I'm not sure how I could get a random number that would place the object in multiples of 10 with those operations. This seems to be the best useable method so far: tempvar = ((rand&7)+1) player1y = (tempvar*10)-30 I didn't mean that particular bit I meant elsewhere where there's a mutiply by 16 specifically, this line in the print_screenright routine: if change = 32 then worldx = rand*16 : change = 0 else change = change + 1 Edited December 14, 2012 by bogax Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted December 17, 2012 Author Share Posted December 17, 2012 Build #25 has passable collision detection. I tried merging the scrolling code into my earlier effort into 4 way scrolling without success. Instead, merging the collision detection code into the newer engine worked "better". Still, I'm having issues keeping Barb (player 1) out of solid blocks. I. hate. collision. detection. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted December 18, 2012 Author Share Posted December 18, 2012 The current build now has its first enemy! Enter the Red Helmet Demon!! I try a little harder to simulate an event driven system as far as coding goes. Each object now has creation, step and collision events - or at least related sections within sub-routines. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted December 20, 2012 Author Share Posted December 20, 2012 Okay fellas. Build #31 has a few changes. 1. New enemy type! The Badbees can shoot forward one to three at a time! 2. Barb (player 1) Starts out from her house. 3. Forward scrolling movement has been slowed down at bit. Please chime in if you guys have comments about the gameplay so far =) Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted December 20, 2012 Share Posted December 20, 2012 I'm going to see if my collision prevention/detection crap will work with this. Don't know how long it will take me, though. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted December 20, 2012 Share Posted December 20, 2012 How are you doing your collision detection with the playfield? I'm having a hard time finding it. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted December 20, 2012 Author Share Posted December 20, 2012 I'm going to see if my collision prevention/detection crap will work with this. Don't know how long it will take me, though. I'll definitely have to check out your example, again. I'd like Barb and Deb to shoot some sort of projectile weapon. The basic jist of my current collision detection code is to check one or two playfield pixels ahead in the direction the player is moving. gravity rem calculate the player x/y coodinate into the equivelent playfield pixel coordinates tempvar = (player0x/4)-4 tempvar2 = (player0y/10) rem Check for a playfield pixel at said coordinates and skip falling down if needed if pfread(tempvar, tempvar2) then goto skip_gravity rem Check the next horizontal playfield pixel for collision and skip falling if needed tempvar = (player0x/4)-3 if pfread(tempvar, tempvar2) then goto skip_gravity rem Pull the player down and make onground = 1 to confirm player is standing player0y = player0y + 1 onground = 1 return skip_gravity rem Make onground = 0 to confirm player is mid-air onground = 0 return It's not perfect in that sometimes you can inject yourself into the middle of a brick. This happens usually when you rush forward into a pit and catch the edge of the ground just after the pit. Also, the bouncing and extra hang-time when you bump into a brick above. Are these the things that made you want to explore retrofitting in your collision detection routines? Also, build #33 makes it possible to crouch by pressing down! Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted December 20, 2012 Share Posted December 20, 2012 Are these the things that made you want to explore retrofitting in your collision detection routines? Yeah, I keep getting inside of blocks instead of being on top. If you feel like doing a test to see if you can adapt my collision prevention/detection code, that would be nice because I'm working on a new little section for the bB page right now. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted December 20, 2012 Author Share Posted December 20, 2012 Yeah, I keep getting inside of blocks instead of being on top. If you feel like doing a test to see if you can adapt my collision prevention/detection code, that would be nice because I'm working on a new little section for the bB page right now. Okay, build #34 should be a bit better. Barb (player 1) now has a "walking gait" as a side effect of the adjusted collision code. UPDATE: Build #35 removes the mid-air floaty de-bounce when you hit a brick from above. Although more aesthetically pleasing the player has less of an advantage when jumping to avoid a passing monster. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted December 20, 2012 Share Posted December 20, 2012 That's better. Still need to fix the head bumping part so it will look more like this guy when he bangs his head: www.atariage.com/forums/topic/179473-fake-gravity-platformer-test/ Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted December 20, 2012 Author Share Posted December 20, 2012 That's better. Still need to fix the head bumping part so it will look more like this guy when he bangs his head: www.atariage.com/forums/topic/179473-fake-gravity-platformer-test/ Didn't have time to add more animation. I did adjust the head bumping jitter though. I also made the jumping arc a little more smooth. Also, the "walking gait" caused some unintentional unresponsiveness to triggering a jump that needed to be corrected. See build #35a. Thanks again R.T.! Quote Link to comment Share on other sites More sharing options...
KevinMos3 Posted December 22, 2012 Share Posted December 22, 2012 This is really shaping up. Once you get the running/jumping worked out, I think it will be a ton of fun. This is one I'll definitely be watching closely and looking forward to. 1 Quote Link to comment Share on other sites More sharing options...
Impaler_26 Posted January 3, 2013 Share Posted January 3, 2013 I just played this game a bit and i think it could become a really nice platformer. The scrolling is already quite good IMO but the player should really fall slower after jumping. Looking forward to see how this one turns out. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted September 9, 2013 Author Share Posted September 9, 2013 I'm having a hard time compiling this game with recent versions of bB. This is the message log: Compile started at 9/9/2013 3:42:42 PM Compiling C:\BatariBASIC\Projects\S3\sss36.bas 2600 Basic compilation failed! LINE --> complex condition detected Post compilation files deleted Has anyone else experienced this? I've tried rearranging where I put include div_mul.asm to no avail. Quote Link to comment Share on other sites More sharing options...
bogax Posted September 9, 2013 Share Posted September 9, 2013 just an additional observation(at this point I don't rememberif it's nonsequitor)you're talking about doing this: tempvar = ((rand&7)+1) player1y = (tempvar*10)-30 so if rand returns, say, 1rand&7 = 1(rand&7)+1 = 2((rand&7)+1)*10 = 20(((rand&7)+1)*10)-30 = -10is that really what you want? Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted September 9, 2013 Share Posted September 9, 2013 The bB page says: http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#inline Using inline will insert the asm code exactly where the statement is, so doing so at the wrong place (such as at the beginning of your program) will probably cause your game to crash. Are you putting it where it should go in your program? Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted September 9, 2013 Share Posted September 9, 2013 Think I found the problem. You have this in your code: __ if player0x = 77 gosub print_screenright else player0x = player0x + 1 __ It should be this: __ if player0x = 77 then gosub print_screenright else player0x = player0x + 1 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.