-
Posts
1,145 -
Joined
-
Last visited
About splendidnut
Profile Information
-
Gender
Male
-
Location
PA/NY Border
Recent Profile Visitors
9,018 profile views
splendidnut's Achievements
Stargunner (7/9)
1.9k
Reputation
-
Screen comes from the top and slowly goes down in Stella
splendidnut replied to atari2600land's topic in Emulation
It's dependent on when the game triggers the first VSYNC. That's not part of the CLEAN_START macro. -
Techniques for drawing player sprites
splendidnut replied to Elijah's topic in 2600 Programming For Newbies
Yes, the standard and multisprite batariBasic kernels both use SkipDraw. The bB multisprite kernel also uses SwitchDraw for P0. -
Chaotic Grill flicker management
splendidnut replied to splendidnut's topic in Atari 2600 Programming
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. -
Chaotic Grill flicker management
splendidnut replied to splendidnut's topic in Atari 2600 Programming
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.
-
Atari 2600 Game: Codename "One Liner"
splendidnut replied to ZeroPage Homebrew's topic in ZeroPage Homebrew's Discussion
Wow! You've gotten quite a lot done and it hasn't even been a month yet. -
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.
-
Modifying the Multisprite Kernel ... its complex for sure
splendidnut replied to Mike_at_AEI's topic in batari Basic
My only other suggestion is to try compiling without bblint. -
Paddlefield (was: Pong Wars) (Atari 2600)
splendidnut replied to Thomas Jentzsch's topic in Homebrew Discussion
How about: Particle Wars -
Modifying the Multisprite Kernel ... its complex for sure
splendidnut replied to Mike_at_AEI's topic in batari Basic
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. -
Modifying the Multisprite Kernel ... its complex for sure
splendidnut replied to Mike_at_AEI's topic in batari Basic
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.