ZackAttack

Btw, the falling off in PF0 region bug still exists, it just has 3 monsters going crazy when it happens now. You are able to reproduce this bug right? I suppose the biggest challenge with the coordinates is that you can't compare them directly because the widths of both objects are greater than one. So you need to create a hitbox for each and then test if the hitboxes intersect. Personally I would probably just mask off the lower bits of each coordinate and compare them like that. Chances are that would produce correct results most of the time. It would look something like this: ;**PSEUDO CODE** if (monster0.x & $e0)=(missile0.x & $0e) AND (monster0.y & $e0)=(missile0.y & $e0) then gosub HideMonster0 Of course you could always just go back to no monsters 25% of the time. Though getting ambushed does look cooler.

Sounds like you need to use the sprite coordinates to determine which sprite is closest to the missile instead of the collision() function. Or, you could pretend you hit the leader and make them all disappear at the same time after x number of hits occur.

I keep running into a situation where the screen doesn't change anymore. Instead he just falls off the level in the PF0 region. It seems to happen when you collect a fruit and no enemy appears. The changes are nice. I think they improved playability.

Ok, now I get what you're doing. m is multiplexed to hold if the current state is moving right and the sequence count. n is multiplexed to hold if the current state is moving left and the sequence count. Since the sequence count never exceeds 16 it only requires 5 bits and each state indicator only requires a bit each. You could multiplex all 3 into just a single variable. I don't think it would really make the code much more difficult to read and you free up a variable each place you are doing this. So it could be worth checking out. I can throw together some example code if you're not sure what I'm suggesting. Here's a few comments about your example that may be helpful. Aliases can be used to give variables more meaningful names. bB does support if else constructs. if joy0right then m=m+1 else m=0 ;is equivalent to if joy0right then m=m+1 if !joy0right then m=0 When a variable needs to be limited to a range of 0 <= var < 2^n it can be bitwise ANDed with (2^n)-1 to save a few cycles and make the cycle count constant. m = m & $0F ;is equivalent to if m>15 then m=0 This also makes it easier to multiplex the direction indicators into the same variable. ;Roll sequence count back to 0 without clearing direction flags (bits 7 and 6) m = m & $EF

Have you heard about learnfun & playfun? It's something similar for the NES, but the source code was released and I bet it wouldn't be terribly difficult to adapt it to the VCS. Another thought is that it might be possible to just brute force all the possible input combinations for a given game on the VCS since the system is so small compared to a modern PC.

I assume one of those variables is to count through the sequence of frames. How is the second variable used?

On the screen where the throwing stars fly at you, are they supposed to pass you without hurting you if you're slashing away at them?

I wouldn't mind contributing to this. Should I start a new topic or just send you updates via PM?

I'm not exactly sure what you mean by loops back and forth. Could you provide an example? I do agree with you on keeping the code simple when possible. Also, I'm not trying to say that the method you suggested is wrong or worse. I just thought it would be interesting to analyze them more in depth and figured why not share my findings. I was thinking it would be more focused on the "how it works" rather than "which is better".

For fun, let's look at the disassembly of both methods and compare them. I'm sure Papa already knows all this, but for the rest of us it should be educational. Method #1 (Chained IF statements) if a=0 then l1 if a=1 then l2 if a=2 then l3 if a=3 then l4 produces LDA $D6 CMP #$00 BEQ l1 LDA $D6 CMP #$01 BEQ l2 LDA $D6 CMP #$02 BEQ l3 LDA $D6 CMP #$03 BEQ l4 If the last branch is taken the total cycles consumed will be 4 LDA ZP (3), 4 CMP (2), 3 BEQ-not taken (2), 1 BEQ-taken (3) for a grand total of 29 cycles. This could have been reduced to 20 if the compiler was a little smarter about omitting the redundant loads. Another observation is that this code runs in O(n) time. In other words, the more if statements you chain the more valuable CPU cycles you consume. The other problem is the loss of ROM space. It takes 6 bytes to add the LDA/CMP/BEQ instructions for each if statement. Method #2 (on ... goto) on a goto l1 l2 l3 l4 Produces: LDX $D6 LDA MSB_Lookup,X PHA LDA LSB_Lookup,X PHA RTS *MSB_Lookup and LSB_Lookup each contain a byte per label in on ... goto construct In all cases the total cycles consumed will be 1 LDX ZP (3), 2 LDA Absolute,X (4), 2 PHA (3), 1 RTS 6 for a grand total of 23. What is even more interesting is that the code runs in O(1) time. In other words, it's going to take 23 cycles regardless of how many labels you have. An added bonus is that each new label will only use 2 bytes of ROM to expand each lookup table by a byte. So in conclusion, using the on...goto method is the better solution when efficient use of CPU is important. I'd also like to point out that both methods only dealt with a single variable. So I don't understand the claim that it will use less RAM. None of this should come as any surprise since RT generally provides sound advice based on many years of experience with bB. If any bB programmers found this interesting or usefull let me know. I may consider creating a blog where I analyze different commands periodically.

Nice demo. It's a very interesting approach. I wonder how it would look if you reduced the vertical resolution to 96 lines and drew each line twice to fill out the screen. Maybe that would be possible if you moved more of the processing to the kernel.

I like the game concept, it's very entertaining. You may want to swap the left and right controls to make it feel more like you're in a t-rex simulator. Right now it feels like you're controlling the fleeing student instead of the dinosaur.

It might be speed related too. I saw it happen to a lesser degree with the ant which also moves quickly.

Very cool. With a little cheating I was able to make it to the boss fight. Another thing I noticed is that you can wrap your health back to full in the boss fight if you keep jumping to the side when the boss hits you. Effectively making you invincible. Looking forward to the next build with easier ants!

I did not find the boss. Is it based on how much fruit you gather or how many screens you make it through? The ant is difficult for me too.

I'd like to make a couple bees flying in a overlapped figure-eight pattern as one of the enemies in this game. Does this sprite look ok? Any suggestions on how to improve it? I'm aiming for something similar to this. It needs to be a normal width sprite, but it is full resolution and can be as tall as you want.

Great job. The graphics look awesome. Have you noticed that the random fruit drops sometimes get placed off the side of the level in the PF0 region? Bitwise ANDing with $7F (127 decimal) and ADDing $10 (16 decimal) should allow you to quickly put your random X coordinate in the desired range of 16-143. Hope that helps.

I think as long as there are no power or AV cables going to the cartridge it qualifies as a 2600 game. I don't think it really matters how much of the processing is offloaded onto an in cart CPU as long as the TIA is used to generate the video and audio. To me the TIA is what defines the 2600.

After watching the video I can see that I was mistaking the magic sequence for a crash. Sorry for the confusion. It sounds like you're more interested in having people praise your game than having honest feedback that may allow you to improve the game further. For the record, I don't care for all the screen flashing either. In fact it's the main reason I thought the game was crashing. I'm glad you love your game and I hope many others will enjoy it also. Basic without DPC+ really limits the visual effects. Have you considered trying to write the next game in assembly to make it look even better than this one?

If I have some time later I'll put it on the harmony and see if I can capture it on my 7800. It would be interesting to see a short video of the game by someone who doesn't completely suck at it like I do.

Try holding UP and the button for a while right after the game starts. It crashes pretty bad. (I'd screenshot it, but you have to see it in real time to really appreciate how bad it is) Try holding DOWN and the button for a while right after the game starts. Is that normal? I'm not a fan of all the flickering and flashing either. I do like the animation when an enemy is defated. It's cool how they shatter into pieces.

Maybe you could include the flipper animation state in your collision detection and only deflect the ball at full speed if the flipper is in its upswing. You could probably do that without anymore variables. Pseudocode: if collision(Ball, LeftFlipper) AND LeftFlipperState == MovingUp then BallDirection = UpFast

While playing I noticed that the ball will occasionally pass through objects when it's traveling straight up. I think it even passed through the top of the screen once. The easiest way to see this is to just hold up and watch the ball bounce around for a bit. If you can find a way to improve the ball and flipper physics, this will be a really awesome game. Keep up the good work!

This was the first thing I had tried but I quickly found that it wouldn't work because it takes too long to update all 3 PF registers twice per scanline. Instead I will be changing the background color at precise times and smoothing out the color change with one of the graphic objects. The platform in the last video was just the P1 object, but once I get around to implementing hills and loops you'll start to see where changing the background color mid scanline is needed. Nice! This will look awesome in the next demo video.

When they gunmen are facing right the bullets come out of their left shoulder instead of the gun barrel. You should change the starting position of missiles and balls when they face right.