Chaotic Grill (BurgerTime remake) in progress

[+splendidnut]

12 hours ago, Silvio Mogno said:

You really don't need to use Linux. You can also work on Windows with GCC compiler.

Yes, I'm sure if I went looking, I could find a way to do that.  I used the phrase "documented toolchain" to specifically refer to SpiceWare's tutorials.

 

Personally, I'm not really interested in doing ARM game development on the Atari 2600.  I REALLY enjoy seeing what others have done with it.  It's really cool.  I cannot stress that enough.

 

But for me, the key of this project is:

On 5/17/2020 at 7:53 PM, splendidnut said:

So really, I'm trying to explore some weird kind of middle ground of unexplored territory

 

The fun and frustrating part of this project is trying to do as much as possible within the cycles available of the 6507. The compromise has been in using DPC+ to draw a bit more on the screen which makes a monumental difference.  Could it be done without DPC+?  Sure, but it would require a bit of gymnastics to accomplish... probably similar to the kind used in the Boulder Dash port.  And I'm already doing too many gymnastics with the sprites.

 

I'm relatively satisfied with the choices I've made. 

 

Granted... they haven't led to a completed game... but it's kind of there.  Like a sleeping hare... right before the finish line.

 

-----

 

If you were expecting something other than a somewhat defensive tangent... sorry.  Maybe later....

[+splendidnut]

PS... Good work on rubyQ  @Silvio Mogno !

[+Yurkie]

On 12/13/2020 at 8:58 PM, splendidnut said:

Yeah, I agree.  The current implementation (free-running timer with high bit signalling active state) was a quick and dirty way to get the bonus item working.  Nice for testing purposes, but too easy for general gameplay.  So, I'll switch the bonus item to utilize the burger count instead of the timer... when I look at the code again.

 

Currently, I have a bunch of changes sitting on my computer that I need to finish up/clean up.  One of the changes being a pretty major overhaul of the burger dropping system, which should take care of the really oddball bugs which occurred when dropping burgers.  I still need to fix some  scheduling issues with the burger logic so that I can get my scanline count stable again.  That may be the only thing that's stopping me from releasing another build.  I'm not sure, as I haven't looked at the code in a few months... and currently, I've been focused on getting more done with Paint The City.  But I might take a look in the near future... Despite the appearance of being almost done, there's still quite a bit I want to do with ChaoticGrill.

It's a REALLY sweet game as is it now.

[StephenJ]

Hi slpendidnut,
Just wondering if you have any idea when Chaotic Grill will be ready.

 

Thanks,
Stephen

[+splendidnut]

I honestly have no clue as to when it'll be ready.  I'm stuck in that void of an almost complete game that I could easily fall into the trap of cascading rewrites.  There's a list of areas that could benefit from being rewritten, and I have another list of things that I'd like to do.

 

Currently, I'm working on finishing up the Burger logic rewrite and I've almost got the timing issues worked out with it... The rewritten burger engine uses more time than the old one because it keeps track of ALL the burger pieces.  It can handle 5 moving pieces, after which it doesn't have enough time and overflows the scanline count for the frame.  This is because I'm trying to get it all to fit within the overscan region.

 

In addition to that, the burger-based collision code still has a couple of strange bugs that need to be fixed... and is in need of optimizing.

 

I'd really like to rework the enemy handling to be able to run all the enemies at the same rate as the chef: 60fps.

 

There's the temptation to create my own bankswitching scheme (based on DPC+) to help alleviate the gymnastics the kernel currently does to swap out sprites.

 

Also, I'm kind of in need of a better debugging tool and I've started looking at the source code for Stella to see about adding something to help me out in that area.  Basically, I need an easier way to see a list of variables, so that I can watch them better.

 

You could say it's some form of development hell and thus why it hasn't gotten the attention it deserves.  ?

 

Ultimately I have too many projects going on... and I've been meaning to put more effort into this one; I just haven't followed thru on that.

 

We shall see...

 

[StephenJ]

Thanks slpendidnut...for taking the time to reply with such detail.
Looks like you've got some hurdles to get over.

We're rooting for you! 

 

StephenJ

[Fort Apocalypse]

This is great! Is there a way to get the music to not have the pause before it starts again? It's minor, but thought I'd ask. I'm looking forward to the final version!

[+splendidnut]

You know, I've been wondering why people keep asking about that.  I just checked and the arcade version doesn't have it... I have no idea why I put that pause in the music, so I'll take it out.

[StephenJ]

Cool!

[StephenJ]

Sure would be nice to get a 2600 cartridge of Chaotic Grill from Santa this year. Just sayin' 😏

[Ecernosoft]

On 12/15/2015 at 9:37 AM, splendidnut said:

ChaoticGrill is an attempt to bring a new version of the arcade classic BurgerTime to the Atari 2600.

You're name choice is hilarious. 

[+splendidnut]

On 10/12/2022 at 4:29 PM, StephenJ said:

Sure would be nice to get a 2600 cartridge of Chaotic Grill from Santa this year. Just sayin' 😏

I agree.... maybe next year.

 

ANYWAYS,

 

I started fiddling around with this yesterday while watching ZPH's AtariAge day.  I made some compromises and have done enough tweaks here and there that I feel somewhat comfortable providing a new release.

 

So:

    - New titlescreen!  It's a work in progress (and a bit hacked together), but the basics are done.  It uses a huge burger sprite that @NostAlgae37 made.  And it includes the credits.

    - New Burger logic... Instead of my hacky waterfall list debacle, this version now keeps track of ALL the burgers on the screen.  So this should -in theory- be less buggy.

    - Fixed the bonus item... it's now relies on the plated burger piece count.

    - Fixed the pause in the music.

 

The big compromise has been that I've bumped up the scanline count to 268... ugh.   This should eliminate most of the current overflows, but there will still be the occasional shimmy.  I REALLY need to rework the player / enemy logic to run faster.  I also need to try and optimize the sprite sorting, which currently happens EVERY frame.  Doing those things should allow me to get the scanline count back down to 264/262... but I'm not sure when I'll tackle that.  If/when I do tackle that... then a physical release can/will be planned.

 

Enjoy!

 

NTSC:chaoticGrill_NTSC_20221113.bin

PAL60:chaoticGrill_PAL60_20221113.bin

 

 

NOTE:  DO NOT REDISTRIBUTE THESE FILES.  If you want to share, please link to this thread instead.  Thanks!

 

[StephenJ]

It plays and looks great!
So glad you're finding some more time for this project.

 

Stephen

[+johnnywc]

I have to admit I haven't played this in a long time, but I finally got a chance to download the latest ROM and I must say it's awesome!  

 

@splendidnut you have done an amazing job bringing Burger Time to the 2600 - I'm looking forward to adding the cart to my homebrew collection some day!  

 

 

[+johnnywc]

One small suggestion in the graphics dept:  Not sure if it has been mentioned previously, but the animation of the chef in the arcade when he's moving up/down the ladders has the character 'bouncing' a bit.  In this version the animation is smooth and looks a bit out of place vs. the arcade (just because I've played the arcade version a million times  ).  Not a big deal but figured I'd mention it.  

 

I've played a bunch of games - lots of fun!  Thanks!  

[+splendidnut]

Thanks @johnnywc

 

A couple of people have mentioned the issue with the climbing animation before.

 

I just took a look and the arcade appears to have the chef climbing animation tied to the ladder rungs and the chef "snaps" to a rung if you stop on the ladder.  There's a bit of variation in how long the full animation cycle runs (4 to 6 frames based on 30fps youtube video - first level) and there's also an occasional "dip" frame in which the chef's upper body is shifted down a scanline.

 

I've punted on fixing that mostly because it's easier to debug things when the characters Y coordinate matches up with the screen scanlines.  But now I've probably reached the threshold of people mentioning it where it'll start to bother me and I will actually go fix it.  I have some ideas on how to go about it...

 

Meanwhile...

 

I'm currently working on putting in a level editor before working on anything else... to give people ample time to come up with their own levels for potential inclusion in the final release.

[Bomberman94]

31 minutes ago, splendidnut said:

I'm currently working on putting in a level editor before working on anything else... to give people ample time to come up with their own levels for potential inclusion in the final release.

Wow - this is a great idea. How many levels will there be in the final version and are the „original ones“ included, too? 😮

[+splendidnut]

The game will have the original 6 levels... plus I'd like to include 6 (or maybe more) community created levels depending on ROM space and the amount of community participation.  My plan is to get the level editor working and throw a build out there and see what happens, after which I will probably start working on more "under-the-covers" work while people play around with the level editor.

[+johnnywc]

1 hour ago, splendidnut said:

Thanks @johnnywc

Thank you!  I'm really impressed with this port and even more knowing you did it with mostly ASM and just DPC for the data fetchers.      Are you using any additional RAM (besides the 4K for the datastreams) for anything or just the 128 RIOT bytes?  I assume you're calling the ARM once a frame to just set the data stream pointers? (I don't think you can do this in ASM anymore, but I may be wrong). 

1 hour ago, splendidnut said:

A couple of people have mentioned the issue with the climbing animation before.

 

I just took a look and the arcade appears to have the chef climbing animation tied to the ladder rungs and the chef "snaps" to a rung if you stop on the ladder.  There's a bit of variation in how long the full animation cycle runs (4 to 6 frames based on 30fps youtube video - first level) and there's also an occasional "dip" frame in which the chef's upper body is shifted down a scanline.

Cool!  Yeah, the animation is a bit hard to follow but it sounds like you figured it out.    

1 hour ago, splendidnut said:

I've punted on fixing that mostly because it's easier to debug things when the characters Y coordinate matches up with the screen scanlines.  But now I've probably reached the threshold of people mentioning it where it'll start to bother me and I will actually go fix it.  I have some ideas on how to go about it...

Yes, I completely understand about debugging, especially in the early stages, and needing to count on the value you're seeing and not guessing the value based on what frame of animation is being displayed, etc.  I'm glad you'll be adding this in; for me, it's the only major detail that takes away slightly from the "Burger Time" feel.  Everything else seems pretty spot on; I was able to get 76,000 which is about what I get in the arcade version.   

1 hour ago, splendidnut said:

Meanwhile...

 

I'm currently working on putting in a level editor before working on anything else... to give people ample time to come up with their own levels for potential inclusion in the final release.

Very cool!   I designed a level editor for Wizard of Wor Arcade and had a similar 'contest' so people could designs and test their mazes.  I ended up including 3 of the winning mazes in the final release, but managed to have enough ROM to keep in the editor so you can modify any of the 3 custom mazes and even save your changes to the AtariVox.   The big hurdle was making sure only valid mazes could be created (I ended up using a rudimentary flood fill algorithm to validate the mazes to ensure that each area could be reached).  Easier said that done, but certainly easier with the ARM.  

27 minutes ago, splendidnut said:

The game will have the original 6 levels... plus I'd like to include 6 (or maybe more) community created levels depending on ROM space and the amount of community participation.  My plan is to get the level editor working and throw a build out there and see what happens, after which I will probably start working on more "under-the-covers" work while people play around with the level editor.

Looking forward to trying out the level editor! 🤓

 

Great job Philip!

John

 

[+save2600]

Holy smokes... the start of a beautiful relationship! Which'll undoubtedly end in a game that we all would've drooled over BITD!  😜

[+johnnywc]

1 hour ago, save2600 said:

Holy smokes... the start of a beautiful relationship! Which'll undoubtedly end in a game that we all would've drooled over BITD!  😜

I actually started a Burger Time game for the 2600 about 4 1/2 years ago, not knowing that Philip had started one (my gf is a huge BT fan and suggested I work on it  ).  I spent about 8 hours on it and came up with the basic layout for all 6 levels with the condiments; the big difference is that I was alternating drawing ladders/platforms on one scanline and the condiments on the other to get the different colors:

 

 

 

I like the approach that Philip went with, having the condiments solid with more space with the ladders, and the sound/control/graphics are spot on. 

 

This is definitely the version of BT we all hoped for back in the day, that's for sure!   

[+fdr4prez]

Here is an Intellivision BurgerTime level editor and it comes with 7 new levels.

 

It may give inspiration for Chaotic Grill

 

webknox (free.fr)

 

And for those with the Intellivision emulator, then you can test out your new levels

[+SpiceWare]

2 hours ago, johnnywc said:

I assume you're calling the ARM once a frame to just set the data stream pointers? (I don't think you can do this in ASM anymore, but I may be wrong). 

 

In DPC+ you set the data stream pointers using 6507 code. I'm sure you could set them using ARM code as well, but we didn't design it to be done that way (as running custom ARM code was a late addition). Stella doesn't even support DPC+ updating the pointers via ARM - check CartDPCPlus.hxx and you'll find the C arrays that keep track of the pointers:

 

    // The top registers for the data fetchers
    std::array<uInt8, 8> myTops;

    // The bottom registers for the data fetchers
    std::array<uInt8, 8> myBottoms;

    // The counter registers for the data fetchers
    std::array<uInt16, 8> myCounters;

    // The counter registers for the fractional data fetchers
    std::array<uInt32, 8> myFractionalCounters;

    // The fractional increments for the data fetchers
    std::array<uInt8, 8> myFractionalIncrements;

 

While in CartCDF.cxx you'll find offsets into the emulated RAM, such as myDatastreamBase. The offsets are initialized in setupVersion() based on which variation of CDF is being used.

 

  switch (subversion)
  {
    case 0x4a:
      myCDFSubtype = CDFSubtype::CDFJ;

      myAmplitudeStream = 0x23;
      myFastjumpStreamIndexMask = 0xfe;
      myDatastreamBase = 0x0098;
      myDatastreamIncrementBase = 0x0124;
      myWaveformBase = 0x01b0;

      break;

    case 0:
      myCDFSubtype = CDFSubtype::CDF0;

      myAmplitudeStream = 0x22;
      myFastjumpStreamIndexMask = 0xff;
      myDatastreamBase = 0x06e0;
      myDatastreamIncrementBase = 0x0768;
      myWaveformBase = 0x07f0;

      break;

    default:
      myCDFSubtype = CDFSubtype::CDF1;

      myAmplitudeStream = 0x22;
      myFastjumpStreamIndexMask = 0xff;
      myDatastreamBase = 0x00a0;
      myDatastreamIncrementBase = 0x0128;
      myWaveformBase = 0x01b0;
  }

 

The offsets are used in functions like this:

 

uInt32 CartridgeCDF::getDatastreamPointer(uInt8 index) const
{
  const uInt16 address = myDatastreamBase + index * 4;

  return myRAM[address + 0]        +  // low byte
        (myRAM[address + 1] << 8)  +
        (myRAM[address + 2] << 16) +
        (myRAM[address + 3] << 24) ;  // high byte
}

 

 

Part of streamlining CDFJ was to move all the pointer and increment initializations to custom ARM code. This simplified the driver, by eliminating a bunch of registers in cartridge space that DPC+ has to handle. This helped to reduce CDF's driver size down to 2K from DPC+'s 3K.

[+splendidnut]

2 hours ago, johnnywc said:

Are you using any additional RAM (besides the 4K for the datastreams) for anything or just the 128 RIOT bytes?  I assume you're calling the ARM once a frame to just set the data stream pointers? (I don't think you can do this in ASM anymore, but I may be wrong). 

The 4k RAM is divided roughly in half with a couple of small chunks used for other things:

  ~2k for sprites (static / ROM)

  ~2k for the burger playfield graphics + color buffers.

  64 bytes for burger state info

  64 bytes for level layout

  192 bytes for level playfield graphics

  ~20 bytes for kernel split / sprite multiplexing info

 

The new titlescreen also make quite a bit of use of the 4k RAM also.  (sidenote:  almost had a 4k vanilla ROM version of just the title screen running, but there were a few timing issues)

 

I actually don't ever call the ARM at all.... it burns all of it's time as the ROM emulator / DPC+ driver.

 

As @SpiceWare said, DPC+ does allow access to the datastream pointers from the 6507.  I am doing most of the register setup during VSYNC, but I also use a couple of the datastreams as the "level layout / burger state" access pointers.

 

3 hours ago, johnnywc said:

I designed a level editor for Wizard of Wor Arcade and had a similar 'contest' so people could designs and test their mazes.

I won't lie... That was the inspiration for doing the level editor here.  I believe you first announced that around the time that I redid the level layout code to it's current configuration (storing the layout in DPC+ RAM)... which made me realize that an integrated level editor could be done here too.

 

I've got some pieces already written for it... and I'm on vacation next week... so maybe we'll see a fully working editor soon. 

 

---

 

Thanks for your comments John! 

 

And thanks to everyone else who's commented, liked, and/or downloaded.  It means a lot to me.

[+SpiceWare]

StellaDS has been updated and now supports DPC+ games on the Nintendo DS.  I'm running it on my 3DS