+Gemintronic Posted August 25, 2010 Share Posted August 25, 2010 Didn't want to hijack jbs30000 platform thread so I'll post this example here. This has: 4 way scrolling (up, down, left & right) Workable collision detection. Not perfect but good enough. Variable jump. Basic animation for player sprite. This does not show off level loading. The "level" is one screen big. Someday I'd like to figure out how to use pfplayfieldpos to get taller playfields to work but it's beyond me. Hopefully this example will encourage further platforming advances! pfplatform.bas pfplatform.bin 1 Quote Link to comment Share on other sites More sharing options...
Cliff Friedel Posted August 25, 2010 Share Posted August 25, 2010 (edited) Didn't want to hijack jbs30000 platform thread so I'll post this example here. This has: 4 way scrolling (up, down, left & right) Workable collision detection. Not perfect but good enough. Variable jump. Basic animation for player sprite. This does not show off level loading. The "level" is one screen big. Someday I'd like to figure out how to use pfplayfieldpos to get taller playfields to work but it's beyond me. Hopefully this example will encourage further platforming advances! That runs really smooth. Very nice. Edited August 25, 2010 by Cliff Friedel Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted August 25, 2010 Share Posted August 25, 2010 That runs really smooth. Very nice. Yeah, fast and smooth. This code will be fun to play with when I'm done with the example program I'm working on. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted August 25, 2010 Author Share Posted August 25, 2010 (edited) *somehow got double-posted* Edited August 25, 2010 by theloon Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted August 25, 2010 Author Share Posted August 25, 2010 (edited) Maybe you can add some random terrain to the engine Seriously! Some of my code is wacky because of workarounds. Most of it is whacky because I represent all that professional developers hate I wouldn't be surprised if the authors of Microsoft Code Complete have a hit on me! The whole collisions get registered only after drawscreen thing sucks. Not bB's fault at all but I don't like it one bit. I literally have to move the sprite into the wall and run drawscreen to detect the collision. It looks bad when I then have to redraw back at the non-contact location. Bouncy bouncy flicker flicker. Thankfully, I only have to call the collision routine once. The rest is pfreads. I still think this topic http://www.atariage.com/forums/topic/148427-vertical-scrolling-through-a-playfield-that-wont-fit-the-screen/page__hl__defaultbasbin has the key to multi-screen platforming goodness. Even if I can't figure out how to pfscroll left or right at least that topics examples can go up and down. See Kung-Fu Master CurtisP's Scroll3A.bas for what I mean. Edited August 25, 2010 by theloon Quote Link to comment Share on other sites More sharing options...
Rabbit 2600 Posted June 22, 2013 Share Posted June 22, 2013 Hm, I get a compilation error saying def is not a valid keyword when I tried out the source. Quote Link to comment Share on other sites More sharing options...
Cybearg Posted June 22, 2013 Share Posted June 22, 2013 Try replacing this: def true = 1 def false = 0 with this: const true = 1 const false = 0 Quote Link to comment Share on other sites More sharing options...
Rabbit 2600 Posted June 22, 2013 Share Posted June 22, 2013 Cheers! Quote Link to comment Share on other sites More sharing options...
Rabbit 2600 Posted June 22, 2013 Share Posted June 22, 2013 Another silly question, how is the speed of the playfield scrolling controlled? Quote Link to comment Share on other sites More sharing options...
Cybearg Posted June 23, 2013 Share Posted June 23, 2013 As far as I know, he's just calling the pfscroll functions that are inherent in all (or at least most) batariBasic kernels. So it's set somewhere deep in the Assembly, though I don't know where. Really, though, it's tough to vary the speeds too much because you can only scroll in a whole pfpixel at a time, so either it's going to snap in every 4 pixels going left/right or every 8 pixels going up/down (not counting for higher pfres settings). Not too smooth in either case. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted June 23, 2013 Author Share Posted June 23, 2013 I was trying to get boolean logic to be clearer in bB. I figured const/def true = 1 and false = 0 would be more readable. Problem is, I later found out constants don't mix with binary operations. You cannot say "IF mariostats{1} = true THEN GOTO foo" I've since given up on defining true or false. I just use 1 as true and 0 as false from now on. The speed really isn't controlled in this code. It just scrolls at this speed due to the speed of the 2600 running my program. The 2600 cannot scroll the playfield horizontally. All you get is scrolling one chunky playfield pixel column at a time. This makes side scrolling way too fast usually. When I shopped around for feedback in the Homebrew section they were much more unimpressed with the scrolling. I did a better job at side scrolling here: http://atariage.com/forums/topic/201771-s3-the-sensational-santuci-sisters-wip/ I couldn't figure out how to allow moving backwards and forwards when scrolling horizontally. Sprybug even gave me some hints but I couldn't really understand what he meant. All I know is that the screen starts tearing when I try to move left (with the sensational santuci sisters). 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.