ScumSoft

Remove any spaces from the path name and try again.

Pitfall 2

Basic flow control for debounce works like in the example, but that can look slightly confusing to those just getting introduced to bB. Conceptualize it like this with: rem if I press the fire button it should set the debounce bit and perform some bit of code rem also I want to see if the debounce is still set to 1, if it is then dont proceed until debounce gets reset to 0 rem if the player is no longer holding down the fire button, then clear the debounce bit if joy0fire then bit_debounce = 1 wait_until_debounce_clear if !joy0fire then bit_debounce = 0 if bit_debounce then goto wait_until_debounce_clear When you say "if bit_blah then dosomething", your asking if the bit is 1, when you say "if !bit_blah then dosomething", your asking if the bit is 0 Hope this helped, RT's examples are good references to keep referring back to when you forget how things are supposed to work.

Of course that won't work silly, you have to draw the white screen first THEN set it back to black. Your not drawing the screen between the changes.

[edit]Very nice bogax! My solution was way off

Pause the game with b/w set to a, when returned to b keep the game paused until the fire button is pressed?

You need to move your collision code to after the drawscreen this way it knows when P0x and P0y were in a non-collision zone, and can reset player0x and player0y to those coordinates. If they happen after a collision and before drawscreen, then it resets the P0x and P0y into the wall causing constant collision. It's not smooth as ice collision, but it works for now. I also fixed the hold reset issue and show how a simple debounce works. BalloonProtest3.bas

No problem, it's all good. Thought this was like that other post looking to flip 255 and 1, with only two values returned. Don't mind me carry on.

I would just do this instead: dim color = a dim FrameNum = b rem set starting color color = $40 Loop drawscreen FrameNum = FrameNum + 1 rem cycle color from 40 and 46 every other frame if FrameNum{0} then color = color ^ 6 COLUBK = color goto Loop

Yup unlike the normal kernals the DPC+ remembers what your objects and playfield are.

1) Nope can't use them, they existed in the original to keep the playfield in ram and are now used for the virtual sprites stuff. 2) pfread, pfclear and pfscroll aren't implemented yet. To define a playfield either build it with pfpixel, pfvline x(start) y x(end), pfhline x(start) y x(end) or: rem always set the DF#FRACINC at least once before attempting to draw rem the playfields or backgrounds DF0FRACINC = 16 ;16 = 11 rows of playfield, 32 is 22 ect DF1FRACINC = 16 DF2FRACINC = 16 DF3FRACINC = 16 DF4FRACINC = 32 ;PFcolors table, Always double the playfields DF6FRACINC = 32 ;BKcolors table bkcolors: $1E $2E $3E $4E $5E $6E $7E $8E $9E $AE $BE end pfcolors: $02 $04 $06 $08 $02 $04 $06 $08 $02 $04 $06 end playfield: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX end rem and to clear the playfield just define an empty playfield: playfield: ............................... end For defining multiple things to a variable for bit operations it's as easy as: dim MULTIVAR = a def Switch7=MULTIVAR{7} def Switch6=MULTIVAR{6} def Switch5=MULTIVAR{5} def Switch4=MULTIVAR{4} def Switch3=MULTIVAR{3} def Switch2=MULTIVAR{2} def Switch1=MULTIVAR{1} def Switch0=MULTIVAR{0} rem then to test if the switch is on if switch1 then goto SWITCH1_is_on rem to test if a switch is off if !switch1 then goto SWITCH1_is_off rem be sure to watch your capitals, because a label with the same rem spelling in it as a variable will confuse the compiler SWITCH1_is_on ;is different then Switch1 and switch1 rem however Switch1_is_on ;Will confuse the compiler since Switch1 is the same as the var Switch1 ;and it will try to convert the label into an invalid instruction Hope this helped.

Yeah I am still working hard on it, I've been reworking the collision mechanics and think I've found something that works well enough. But the real holdup is that I want to get Adventure and Pitfall done before the next release, I am trying to squeeze them in the best I can. Not sure when the next release will happen but I will let everyone know once it's finished thanks for the interest. As far as the crashing goes, the game is beta and RC3 has quite a few bugs in it. I've squished most of them but I am sure more will pop up, thanks for helping me test.

Ok this should be a good example to get things going properly, your guy has 16 possible exit locations actually. Also I would not bother with the background as multicolored playfields look far nicer I think but to each his own. Hope this helps! [edit]There are a couple typos in there, nothing major. Change if !GFXtimer then goto skip_enemy_reverse to if !GFXtimer{1} then goto skip_enemy_reverse That line is meant to slow down the motion of the enemy to every 3 frames balloon.bas balloon.bin

I'm on it, however I am doing a rewrite of most your routines to make them more clear. Also writing up some instructional tutorial text in there to help out.

I agree that the torch effect has been lost, but now it's got a more "magical effect". It kinda gives you the feeling of the Evil Magician's presence... Here's a thought, leave the color on so people can practice the maze until the Evil Magician is out, then make it strobe like that Mwahahaha!

In total, how many unfinished projects you have going right now? This one looks promising.

Well this is really psudeo 3D and is done with 2D visual tricks, so all in all it's still 2D The harmony would allow you to write custom routines for translation and rotation of the road, but I think the effect would be greatly limited to only certain perspectives. But the DPC+ is the way to go with it's writable bank6 for extra ram and fastfetch drawing.

Do you own a harmony cart?

It looks okay, but doesn't resemble torch flicker anymore. You need a fade in then a flicker out effect, then a flicker in

DPC+ is magic, that's all you'll ever need to know.

[edit]Sorry for the unclear explanation, that is what I get for posting at 4am on my ipod. def is nothing more than a double reference as a convenience to the dim statement, but is used differently. You can say: dim Apple = a dim Banana = b def Pear=Apple whenever you say Pear = 5, what gets said to the compiler is Apple = 5 (not pear), it's a convenience thing to reference the same variable by different names. A work around for your problem without changing compiler version would be to reference the reference: def Bit_Debounce_Fire=BitOp_All_Purpose_01{1} def Bit_Debounce_Joystick=BitOp_All_Purpose_01{1} rem becomes def Bit_Debounce_Fire=BitOp_All_Purpose_01{1} def Bit_Debounce_Joystick=Bit_Debounce_Fire That's what I meant in a VERY abstract sort of way.

Also fix your stair step by using the no_blank_lines kernel option.

Sounds like a plan! I think it should fit in 4k if you mind your coding style.

Sure thing then, I figured it was something basic. I'll have an example posted in a bit. [edit]Ok I've attached a small example that should be easy to implement, flicker changes depending on player position(player not drawn in example) use joystick to adjust flicker periods. I recommend linking it like I am (in my Adventure mini-game in EggVenture), to your dragon so that the flicker period is always being adjusted as he moves, and when he is killed then the flicker holds on a pattern based on where the dragon stopped, this way killing it has a good or bad effect on the game rem Adjust the FlickerTimer and choose FlickerPattern FlickerTimer = FlickerTimer + 1 if FlickerTimer & DragonX > 3 then goto FlickerPattern1 if FlickerTimer & DragonY > 3 then goto FlickerPattern2 Flicker.bas Flicker.bin

Put drawscreen into your lupe loop so that it syncs to ntsc by default.