splendidnut

On line 2053, the IF statement is a missing THEN: ;``````````````````````````````````````````````````````````````` ; Decreases status bar. ; if pfscore2 > 0 : pfscore2 = pfscore2/2

Yes. I do like writing in C more. For me, it's quite a bit easier to manage code in C vs ASM. The biggest benefit is that the structure of code is clearer and that really helps me with keeping things organized, especially with larger projects. The compiler I wrote gives me insight into how big code (functions) and data structures are, and how memory is allocated for global and local variables. Those things would have to manually be tracked (or macros created / used) in DASM. I also very much like the ability to do both. I really like the ability to write things in C first and then convert over pieces to ASM.

Setup is usually pretty straight forward. I'm using the compiler I wrote to do this project, Neolithic C. I run the compiler straight from the command prompt (win) or terminal (mac). I utilize VS Code as a code editor and I use Subversion for version control. I use Stella for running the project and the primary debugging tool. I have a very basic C library for the Atari 2600 that has the TIA + RIOT registers defined in a couple of structures. It also includes a few routines that help with using the RIOT timers for handling the video frame and the horizontal positioning routine. And I have a 6-digit score kernel that I usually copy into every project. That all forms the base that I start from for any project I do in C. The challenges that come about are usually when I stumble upon a bug in my own compiler. It usually takes me a bit to figure out my code is fine and that the compiler screwed up.

That nicely sums up my feelings on this project. It's very much a fun coding challenge.

A bit negative, but I appreciate you acknowledging that. Ultimately, it's good feedback to have. It will definitely be hard to beat the SuperCharger version of the game as that is a fantastic port. I was doing some reverse engineering on that version back around November / December, and that's partially what triggered this project. This is very much an experiment to try and squeeze a version into 4k. With the music, I only put in the intro tune and a partial piece of the first song because I wanted to get basic gameplay done first before working out all the extra pieces... So I do want to do more with the music, since as you said, that's a very important part of Frogger. Music data is relatively lightweight here, so it should be possible to fit in most, if not all, the rest of the music.

@Zoyx Being as you were a former forum moderator, I would think that you would be a bit more tactful and respectful here. I've already asked you to stay on topic. Do I need to remind you again?

Yeah, I've had similar thoughts as well. I was also thinking about doing something with the ball... which I believe James mentioned during the ZPH showing. Currently, the row kernels are a bit limited because they're written in C, so more should be able to be done when they're converted to ASM. The current 'lily pad' concept is an experiment that I could get working quickly within the current constraints. Thanks for the feedback!

@Zoyx I'd appreciate it if you would stay on topic. If you want to ask about the Supercharger version and how to get that on a cart, please create a separate topic for that. You are more than welcome to ask questions regarding this version... as that would actually be on topic.

I can make a PAL version at some point in the near future. I just need to setup the color table for that.

The arrays (itemXpos, itemYpos) need to be in the same bank as the subroutine, and wherever else they are used.

'AND' and 'OR' do exist in batariBasic... they're just done using C-style syntax instead: AND is done using && OR is done using || For reference: https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#if_compound_statement ------ For your missile position implementation, it would probably be better to use data statements to create an array of coordinates. And then have the IF/THEN collision statement increment the array index and load the coordinates that way. Like so: if collision(missile0,player0) then gosub MoveItem ;------------------------------------------ ;---- somewhere else, place the following: ;--- define some object positions (4 locations, indexed by 0..3) data itemXpos 10, 10, 50, 50 end data itemYpos 10, 50, 10, 50 end dim itemPosIdx = z MoveItem ;-- move to next index (next location) itemPosIdx = itemPosIdx + 1 if itemPosIdx = 4 then itemPosIdx = 0 ;-- load missile0 object with new position missile0x = itemXpos[itemPosIdx] missile0y = itemYpos[itemPosIdx] return

A remake of Frogger, in 4k, without flicker (currently). It has always been on my want-list to have a nice cartridge version of Frogger; a version that doesn't require the Supercharger, nor any other extended hardware. I always felt that it could be done, because Frogger is a simple game that seems to align nicely with the capabilities of the 2600 hardware. So, I've finally done it, I've got most of Frogger implemented and working pretty well. It does contain a bit of level progression (it's subtle, so it might be hard to notice). Currently, it's missing the Lady Frog, the Fly, the Crocodiles, and the Snake... and more objects in the river, and maybe some more variety (the kernels are relatively flexible). Some of those things will definitely require adding flicker to the mix. I have ~300 bytes left, so I might / should be able to squeeze all those things in. Overall, this was a fun project that took about 4 weeks. Most of the project is written in C. Only the score kernel, the frogs-at-home kernel, and the repositioning routines are written in ASM. I'll probably convert the other kernels over to ASM so that I can utilize early-HMOVEs to hide those black bars on the far left. I figured this was a good point to share a ROM with everyone. Enjoy. Frogger_20240401_NTSC.bin

It's dependent on when the game triggers the first VSYNC. That's not part of the CLEAN_START macro.

Yes, the standard and multisprite batariBasic kernels both use SkipDraw. The bB multisprite kernel also uses SwitchDraw for P0.

SDL vs SDL2 will not affect the color palette. The color palette is controlled by the emulator. There is probably a difference in where configuration settings are being loaded.