splendidnut

@Living Room Arcade Why did you just trash your OP and title of this thread?

I just noticed you created a separate topic for this. My answer from the other thread: Other than that, @Thomas Jentzsch basically stated what I was going to add here.

Yes it's possible. The total number of cars (on screen + off screen) would mainly be limited by their RAM requirements and how much CPU processing time each car needed.

It appears that VCS Game Maker does give you the generated batariBasic code... probably the text code you're talking about. So you probably just need to select all that text, paste it into a text editor, and then save as a file ending in .bas.

Yes. If the CLEAN_START macro clears out RAM, then BGColor will initially be loaded with 0.

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.

And for a general idea of what the current code entails: It's mainly just notes (sample frame with timestamps), but might provide some more insight into what is currently being done.

For sorting sprites, ChaoticGrill's flicker management utilizes sorting networks which are essentially just an order-optimized routine of compare and swap routines. A single compare/swap takes upto 21 cycles. A list of 6 items takes 12 compare/swaps. For 6 sprites, the full sort takes about 3 scanlines (252 cycles) which is done every frame. Sprites are rotated via lookup tables based on a master frame counter. So, sorting and rotating are probably the most optimized sections of the code. Currently, the biggest issue with the code is that there's only a single split in the screen, and that split requires a 10 scanline gap between sprites. The 10 scanline gap is due to the fact that each repositioning kernel can only reposition a single sprite per 5 scanlines. During the display kernel, repositioning a sprite requires about 6 DPC+ register reloads and 2 TIA register reloads... that has to work around 8 TIA updates required per line to draw the burger pieces. Since there's only one split, both Atari player objects (sprites) are repositioned one right after another, which adds up to the requirement of at least a 10 scanline gap to even attempt sprite reuse. Potentially, there is improvements that could be made with the current code... but that would probably involve reworking ALL of the 18 repositioning kernels. Beyond that, I think that sprite drawing may need to be rethought completely. Either way, it's a lot of work that I'm just not that interested in doing myself. I have thought about converting this portion of code into ARM... but I'm just not that interested in doing that either. I'm mainly looking for someone else who is interested in taking on the challenge of improving this area of code and doing the work. I'm more than willing to share access to the private Github repo where the source code to ChaoticGrill sits.

I've done a bunch of work, and while it is mostly under-the-covers type of work, there's a couple of fun things that have been added. Lantern tracking is now fully implemented and there's a prototype of a 4th screen (what I'm calling the 'garden' area). Once all the lanterns have been collected from the first three screens, the player can 'drop' down to the garden area from the 1st (left-most) 'village' screen. It's only semi-implemented at the moment, but you can at least see what it looks like. NOTE: There's an invisible ladder in the middle of the new screen for development purposes. Bruce needed some way to transport building materials. Some updates: - Initial pass at drawing 4th screen (garden area). - Added lantern inventory tracking system and started working on game progression 'goal' system. - Improved lantern collision detection. - Switched to 16k ROM scheme. - Added new kernel to handle user-defined walls (asymmetric wall kernel). Currently used by 4th screen. - Some refactoring of the player / enemy code to work towards supporting a player-controlled Yamo. The project is currently clocking in around 10k and uses 6 different custom kernels. The bank containing the graphics and kernels is close to being full, so there's definitely some rethinking that needs to be done in that area if I want to try and keep all the graphics stuff in a single bank. I might be able to get one or two more screens in before having to do something drastic. It seems that this project is almost begging to utilize either DPC+ or E7 for the extra RAM... for storing/modifying the playfield graphics (or drastically simplify things like the platform graphics, would be a shame though). There's still quite a lot of work to be done, but I feel like this is a decent amount of progress. I'm not sure what I'll work on next. Anyways, enjoy! BruceLee_bB_20240319-NTSC.bin

I would suggest using a Photoshop-esque program (Photoshop, GIMP, Paint.NET) to break the image into layers (3 would probably be enough): background, birds, table/foreground. Then each layer could utilize it's own 4-color palette. The greatest strength of the 7800 is the ability to overlay a bunch of objects and it would be nice to see that used here.

It would help if you posted a screenshot of the error.