Jump to content

splendidnut

+AtariAge Subscriber
  • Posts

    1,145
  • Joined

  • Last visited

6 Followers

About splendidnut

Profile Information

  • Gender
    Male
  • Location
    PA/NY Border

Recent Profile Visitors

9,018 profile views

splendidnut's Achievements

Stargunner

Stargunner (7/9)

1.9k

Reputation

  1. It's dependent on when the game triggers the first VSYNC. That's not part of the CLEAN_START macro.
  2. Yes, the standard and multisprite batariBasic kernels both use SkipDraw. The bB multisprite kernel also uses SwitchDraw for P0.
  3. 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.
  4. 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.
  5. 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.
  6. 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
  7. 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.
  8. It would help if you posted a screenshot of the error.
  9. My personal opinion: I'm not a fan of the original game, but I like the the graphics updates you've made. I'd rather see those characters put to better use in a more enjoyable (potentially original) game.
  10. Wow! You've gotten quite a lot done and it hasn't even been a month yet.
  11. Is there anyone interested in improving the flicker management in Chaotic Grill? It will probably involve a massive rewrite of the display kernel and I just don't have the energy or motivation to take that on at this point.
  12. My only other suggestion is to try compiling without bblint.
  13. You could always try removing that macro: ;--- remove the macro for setSpriteGraphics Start player0x = 76 player0y = 25 ;-- add/uncomment these lines: player0pointerlo = _Player0_Plane_up_low player0pointerhi = _Player0_Plane_up_high ;-- remove the following: asm setSpriteGraphics 0, _Player0_Plane_up end It was an experiment to try and make it easier to set the player graphics pointers.
  14. While I'm not familiar with bblint, I think that's a false positive. It's complaining about a missing 'end' statement that's not missing at all. The 'asm' is on line 98... and the 'end' statement for it is on line 108. It should compile using bBasic v1.7. That's the version Atari Dev Studio is using on my system.
×
×
  • Create New...