StupidBunny

Oooooh. I might have to take you up on that challenge if I can get everything else squared away. ...Which I think I've just done. The problem mentioned above with the X positioning on the blue boi going all screwy only occurred when "Drive unused TIA pins randomly on a read/peek" was enabled. I quickly found a helpful suggestion on another thread with a fix I would probably not have thought of otherwise but which makes total sense when I think about it. So PROTIP: mind your #s before anything you want to be an immediate value. Otherwise weird stuff happens.

This is a gorgeous-looking game. The titles and animations are great and there's already a ton of variety in obstacles and enemies even though I keep getting my ass kicked after just 30 seconds or so. The controls are limited but functional, forcing you to do one of two actions with just the right timing (well three actions, if you count doing nothing at all). Given this and the nonrandom sequence of hazards it definitely rewards persistence, that "just one more game" aspect of any good addictive arcade-style game that drives me to just want to see what the next thing that's gonna kill me is. Great work @vhzc. I can't wait to see how much I suck at Hard mode.

I do, yeah. I noticed also that when the blue boi's X position is near the left side of the screen, an extra scanline appears in the screen area where the monster's X position is reset. Again, this does not happen with any of the other monsters, no matter what their X positions. And it does not happen in non-dev mode. I guess it's also worth noting that @ZeroPage Homebrew tested this on an actual 2600 via a Harmony cartridge (@ZPH correct me if this isn't true) and this problem didn't seem to happen. In the interest of thoroughness, I went and tested the version that they played with dev settings enabled and the same problem happened. So what I have to wonder now is: is this problem actually something likely to repeated on a 2600, or is it only something that's only likely to happen in emulation? It's a pretty game-breaking bug and I don't like it there but I also don't want to get sucked down a rabbit hole of trying to fix something that isn't a real problem.

I've gone and tested the game with developer settings enabled (something I probably should've done initially, but better late than never I guess) and I've noticed that the hopping blue guy glitches with them on. Instead of hopping like he should, he instead flies horizontally across the screen, and appears to "scan" rapidly across the whole vertical range of the screen. My first reaction is that this has something to do with one of the ADCs, in particular trying to ADC a negative value, but I'm not sure why it wouldn't happen under normal emulation. Nothing else in the game that I can see changes behavior in dev settings, so it's specific to this one enemy. Does anyone know what might be going on here? Here's the code for his generation and hop routine. BlueBoi: .SUBROUTINE LDA #BLUEBOI_COL STA mnstrCol LDA #BLUEBOI BIT mnstrFlags BNE .Spec .Init: LDA mnstrFlags ORA #BLUEBOI STA mnstrFlags LDA #BB_HEIGHT-1 STA mnstrHeight LDA #BB_HEIGHT+7 STA mnstrYpos INC mnstrYpos LDA #160 STA mnstrXpos ;start monster at right of screen LDA #1 STA mnstrSpeed BRK .BYTE $0E ;randomize initial hop AND %00000110 CLC ADC #3 STA bbHopHeight STA bbHop LDA #7 STA mnstrFrame LDA #0 STA mnstrUnder LDA #<BBFrames STA tempPtr LDA #>BBFrames STA tempPtr+1 JSR GetFrames RTS .Spec: LDA #DEAD BIT gameState BNE .Return ;skip jumping if player is dead LDA #%00000001 BIT animDelay BNE .Return ;skip jumping every other frame of animation, to avoid ;weird animation clipping LDA mnstrFrame CMP #6 BNE .NoSound LDY #SFX_BB JSR SFXtrigger .NoSound: LDA mnstrFrame BNE .Return ;skip jumping if blue boi is still winding up ;is jumping LDA #7 ;this is actually the frame BEFORE the jumping ; animation, since it always INCrements in the Monster ; routine STA mnstrFrame ;keep at "jumping" frame while in the air LDA mnstrSpeed EOR %00000001 STA mnstrSpeed ;one way of doing 1/2 monster speed LDA mnstrYpos CLC ADC bbHop ;add "hop" to Y position STA mnstrYpos DEC bbHop ;decrement hop distance (through negative) LDA bbHop CLC ADC bbHopHeight BNE .Return ;if not, skip to input testing ;has landed LDA #BB_HEIGHT+1 ;otherwise, reset Y position... STA mnstrYpos BRK ;randomize next hop .BYTE $0E AND %00000110 CLC ADC #3 STA bbHopHeight ;set new hop height with each jump STA bbHop INC mnstrFrame ;start advancing animation once on ground LDA #0 STA mnstrSpeed ;monster doesn't move forward while winding up to hop .Return: RTS .Init is only run once, when the monster is first generated. .Spec runs every frame.

I've uploaded a minor fix of the last version--I found a way to squeeze in just a few more bytes, and also figured out why I needed to redefine GRP0 twice (the vertical delay thing is very weird). I'd like to do a PAL conversion now and want to know what the standard is, i.e. should I go to the extra trouble to making the game PAL 50 compatible or just change the color definitions to be PAL friendly and be done with it? I figure even if I do the former, I'll probably just make the top/bottom areas of the screen extra wide and keep the actual gameplay area as is, and just let the framerate change be what it'll be. I read in a different, old thread that most PAL versions of NTSC-original homebrews go the latter, PAL 60 route, but I'm not sure how many PAL TVs actually work with 60 Hz games.

As noted at the top, I've posted another update, probably the last one before I call the game final since I'm running out of space and I'm resolute on keeping this below 4K. There are a couple minor bugs left, none of which that I've found influence gameplay in any way, but mainly I'm posting this semi-final version to see if anybody has some last suggestions to either improve the gameplay or tighten up the code (which I probably need to do anyway, to fix aforementioned bugs.) Obviously I don't want to eliminate any features in the name of freeing up space--and I don't think I'll need to--but won't dismiss the option if you think something is unnecessary. If anybody can playtest this with an actual Atari controller of one sort or another, that would be a big huge help especially (since I've been testing this on my keyboard and, at least for me, the keyboard is a way easier way to control the game than the joystick). How is the pacing? Is the provisionally named Speed Mode too merciful? Too insane? How about the regular game? Is the source code hideous? And so forth. Either way, I'm starting on writing the manual and drawing up the manual and cartridge art for the game. Once you guys give me some ideas/suggestions/thoughts/beratement I'll get the game finalized and hopefully have a finished product before too long

I will certainly if I'm still up, although that'll be starting 3 AM my time so we'll see how much of a grandpa I feel like I need to be tonight. Either way I look forward to watching it! By the way, I've reuploaded the game with a couple minor bugfixes. I expect this'll be my last update for the night, there's not a whole lot left to do to the game to begin with bar stomping a couple small lingering bugs and general code optimization (which, if successful enough, might leave room for one or two little extra goodies but who knows.) EDIT: @ZeroPage Homebrew sorry I couldn't hop in to the chat after all--as anticipated, I was asleep--but nonetheless thanks for giving the game a play! (And some other cool looking ones too of course.) Definitely gave me some good notes for things to change and add moving forward.

I've posted another update. With some of the extra bytes I found I made something resembling a real title screen. I've also edited the control scheme slightly, so that now you can make the player return to the ground faster after jumping which offers a wee bit more control. @ZeroPage Homebrew I'm not sure if it's too late to use the updated version in the stream tonight but I suppose it doesn't make an enormous difference either way.

Neat, I actually had a similar idea for the game I’m making (an invisible divide between an area for “flying” and “ground” enemies so neither had to share scanlines) but never got far into the implementation; it sounds like yours will have more than two sections though. At any rate given that I’m not terribly experienced at this I’d probably not be the person to ask but I will say based on my limited efforts that it should be doable and not overly complex if you can set the criteria for your enemy types such that they never “walk over” each other, maybe with one enemy type forcing constraints on the other’s movement as they move. The most annoying visual problem I had was that the player would smear while crossing the boundary, but if the only thing crossing your boundaries is the Ball then that ought to be much less of an issue.

*grumble grumble* The server didn't seem to be playing nice with me when I uploaded it last night. It seems to have pulled itself together today, I've reuploaded both so you can try and give the most recent one a look.

Lol I saw your post just as I was about to upload an updated version of the game and code. I squeaked in a couple of your suggestions but will go hunting for other 16-bit adds/subs when I have time, which isn't right now. I haven't touched the VSYNC section or the Random bit in the update (apart from making Random into a BRK sequence) but I may be able to shave off just enough that I'll have room to jazz up the title screen a bit. There's also a couple of the playfield graphics that probably could be automated and don't need tables, I might be able to save a couple bytes that way too. Thanks for the feedback, glad it looks fine at 5 AM anyway and let me know if you find anything glaring in there.

Thanks for the feedback splendidnut. Yeah I haven't touched any of the animations in a good while, I can think of at least a couple of them that could be easily touched up without the overhead of new frames. I wrote off doing color tables for the enemies a while ago but if I come up with some way of saving space elsewhere it's something else I'd consider. I'm currently trying to rejigger the Random subroutine to be a BRK routine instead; I stand to save a small but useful number of bytes doing so, but need to study up a bit more on how BRK actually works since I'm getting glitches with the hoppy blue guy. It's fun getting into the nuts and bolts of all the machine's inner workings, but I guess that's what VCS programming is.

Hi y'all ? So this is a project that, as the changelog shows, has been sitting in my work queue for a very long time, and like most projects I do has seen flurries of activity interspersed with long stretches of working on other things in my life. I conceived this to be something very simple, what with it being my first Atari project and all (and, indeed, the first computer game of any sort that I've programmed from scratch and seen through to completion.) The gameplay is similar to...I guess the dinosaur game in Chrome, complete with very primitive cacti, although there's a broader array of enemies with somewhat varied behaviors that come at you. I don't envision the game to expand into much more than that. Because this is my first serious game programming project of any sort I'm completely sure it's full of inefficiencies and tons of clumsy ugly messy bits that could be implemented a lot better, but it's at least playable in this state and I wanted to put it out here for you good folks to look over and offer some review and suggestions HOW TO PLAY Since there's no manual yet here's the Cliffnotes version of it. Your goal is to jump over stuff. At lower right is a timer: the longer you hold out, the better you do, there is no scoring besides that. However if you manage to jump over 10 monsters in a row without dying then you are awarded an extra life. If you die, then the streak resets. BUTTON: jumps FORWARD: hop/jump forward faster BACK: hop/jump forward more slowly UP: when jumping, makes you jump higher DOWN: accelerates you downward when in mid-jump If you turn on Speed Mode (set with difficulty switch 2) then the rules are the same with the addition of one more: there's a meter, which I'm calling the Doom Meter, under you, which you should always keep above 0. The meter increases (good!) if you run forward, and decreases (bad!) if you don't; it decreases extra fast if you move slowly. In other words, move as fast as you can. As soon as the meter hits 0, everything dies and the game ends. Known bugs, and other things for possible implementation: Delay, and maybe startup sound if I've got room, when game is initialized or restarted ? Second lives reflects when monster is reflected (easy enough to fix, bar the space limitations I've run into) ? Last line of player graphic appears on top of counter for some reason when player drops below ground level on downward acceleration ? Get rid of that line under the purple worm's neck when it goes back into the ground ? Ditto with the funny pixels appearing above the Eye ? Sometimes when there are two munchers onscreen they both disappear at the same time when the first one runs off (EDIT: I think I might have fixed this one, but we'll see) Another really fun idea that I hope I have enough ROM for UPDATES (older ones in spoiler box for viewing concision) 11/26: A major update. Since there are a whole 46 bytes left free in the ROM it's probably the last major update too. The majorest part of the update is that there is now a Speed Mode (which I might change the name of to something more fun, once I have written the game manual), which can be enabled with difficulty switch 2. In this mode, there is a Doom Meter pictured beneath the player--let the meter drop to 0, and the game ends. The only way to refill the meter is to run forward; regular speed won't cut it (and slow speed will drain it faster). I found a sneaky bug in how the monster frames are loaded, which means that the problems of weird pixels appearing above/below the floating eye and purple worm things are no longer a problem, and also that monsters' vertical movements are a lot smoother now. Leveling has been made a bit more gradual. Accelerating downward now works while moving forward and backward, offering even more jump control. The flash algorithm has been changed, making it a bit more subtle. 11/28: I fixed both of the remaining bugs I'm aware exist (and, in the process, finally figured out how that vertical delay register works! Seems like some fun could be had with that...) LATEST: BBB_20201128.zip OLDER VERSIONS