Champ Games - Turbo Arcade (2600)

[+ZeroPage Homebrew]

24 minutes ago, Thomas Jentzsch said:

Well explained, thanks.

 

I guess one would have to play the game to really be able to judge this. But what you write makes sense. Maybe James and Tanya can provide more feedback.

These are great hints that John posted above to avoid crashes. I think I played it offline later when I did figure it out that pulling over to the side after crashing reduced my chances of getting demolished from behind. I also started to try to avoid clumps of cars duking it out on the horizon for fear of one flying at me after crashing into its opponent. I'm glad they'll start to obey the laws of physics in the next build rather than instantly reducing their velocity to zero after crashing! They turn into deadly bullets at that point!

 

While I'm here... I found when you're going around a turn, just on the seawall section, there seems to be an invisible barrier that doesn't let you go all the way to the outside of the curve (when it's either on the left or right side) when your near the bottom of the screen. In my screenshot here, this is as far left as you can go when it's curving to the right.

 

In other turns, you're able to go all the way over and hit the side of the road with no issues:

 

 

- James

[+johnnywc]

26 minutes ago, ZeroPage Homebrew said:

These are great hints that John posted above to avoid crashes. I think I played it offline later when I did figure it out that pulling over to the side after crashing reduced my chances of getting demolished from behind.

 I probably should have mentioned that on the livestream.  

26 minutes ago, ZeroPage Homebrew said:

I also started to try to avoid clumps of cars duking it out on the horizon for fear of one flying at me after crashing into its opponent. I'm glad they'll start to obey the laws of physics in the next build rather than instantly reducing their velocity to zero after crashing! They turn into deadly bullets at that point!

Good idea avoiding clumps of cars ahead of you!   I just checked the code and the enemy speed reduces to 0 in about a second (or at least it should), but I did find a bug where the enemy car moves a bit too fast if your car is going really slow, so hopefully the fix corrects that. 

26 minutes ago, ZeroPage Homebrew said:

 

While I'm here... I found when you're going around a turn, just on the seawall section, there seems to be an invisible barrier that doesn't let you go all the way to the outside of the curve (when it's either on the left or right side) when your near the bottom of the screen. In my screenshot here, this is as far left as you can go when it's curving to the right.

 

In other turns, you're able to go all the way over and hit the side of the road with no issues:

 

 

Congrats!  You found the "other"  bug!  (like there is only 2  ).  This is strictly a "not implemented feature" that I had on my to-do list but ran out of time.  The car/side boundary is done using software collision (not PF collision) because of Nathan's 'red bridge'  and I need to put in the proper deltas for detecting the collisions on the wall scenes.  (right now I think it's checking for the collisions using the medium road width by default).  Should be easy to fix!

 

Thanks for the feedback James!   

 

John

 

[+Nathan Strum]

41 minutes ago, ZeroPage Homebrew said:

These are great hints that John posted above to avoid crashes. I think I played it offline later when I did figure it out that pulling over to the side after crashing reduced my chances of getting demolished from behind.

You even mentioned in the after-hours stream that you noticed staying to the side helped avoid getting hit. Of course this is the sort of thing that will end up in the manual, but right now, there is none . This is the sort of thing we would've shared during the reveal as the game was played more, but with the mid-show interruption a lot of that fell by the wayside. 

Quote

I also started to try to avoid clumps of cars duking it out on the horizon for fear of one flying at me after crashing into its opponent.

This is how you deal with it in the arcade game, too.

Quote

I'm glad they'll start to obey the laws of physics in the next build rather than instantly reducing their velocity to zero after crashing! They turn into deadly bullets at that point!

Crashing cars usually retain some of their momentum in the arcade game, but some of them come at you really fast. The key will be reaching a balance where they're still a hazard, but an avoidable one if you're quick enough. There's months of gameplay testing, balancing and refining left to go.

Quote

While I'm here... I found when you're going around a turn, just on the seawall section, there seems to be an invisible barrier that doesn't let you go all the way to the outside of the curve (when it's either on the left or right side) when your near the bottom of the screen. In my screenshot here, this is as far left as you can go when it's curving to the right.

Yep. I've noticed that as well. But at least the cars are actually going around corners now.  

 

Edit: I see John just beat me to the reply. ?️

[+ZeroPage Homebrew]

3 minutes ago, johnnywc said:

Congrats!  You found the "other"  bug!  (like there is only 2  ).  This is strictly a "not implemented feature" that I had on my to-do list but ran out of time.  The car/side boundary is done using software collision (not PF collision) because of Nathan's 'red bridge'  and I need to put in the proper deltas for detecting the collisions on the wall scenes.  (right now I think it's checking for the collisions using the medium road width by default).  Should be easy to fix!

Only two bugs, that's pretty good! But seriously, the game plays incredibly and could be released as is and would still blow people's minds. I think the software collision is worth it for the Red Bridge, that bridge is awesome looking when you go through it.

 

3 minutes ago, johnnywc said:

Thanks for the feedback James!  

You're very welcome! ?

 

- James

[Thomas Jentzsch]

4 minutes ago, ZeroPage Homebrew said:

...could be released as is and would still blow people's minds.

That's something which always makes me really sad. People should expect serious polishing, testing and fixing. There should be a big feedback difference between throwing half-done stuff at the people or investing a LOT of time to really finalize a game.

 

When people cheer for unfinished stuff, they will eventually (only) get what they are asking for.

[+ZeroPage Homebrew]

1 minute ago, Thomas Jentzsch said:

That's something which always makes me really sad. People should expect serious polishing, testing and fixing. There should be a big feedback difference between throwing half-done stuff at the people or investing a LOT of time to really finalize a game.

 

When people cheer for unfinished stuff, they will eventually (only) get what they are asking for.

They definitely SHOULDN'T release it as is, it was meant as a commentary on how incredibly playable that John and Nathan are able to get the game so quickly.

 

In the short amount of time that I've played it I'm sure I've only scratched the surface of what bugs will reveal themselves. I also look forward to all the fun Champ Games variations they usually put into the game like with dual player Galagon & RobotWar: 2684.

 

- James

[TrekMD]

I need to watch the stream on YouTube but those images of the game looks awesome!

[+Karl G]

2 hours ago, Thomas Jentzsch said:

That's something which always makes me really sad. People should expect serious polishing, testing and fixing. There should be a big feedback difference between throwing half-done stuff at the people or investing a LOT of time to really finalize a game.

 

When people cheer for unfinished stuff, they will eventually (only) get what they are asking for.

I've generally not taken comments like this as a literal suggestion when I've seen them. I see it as just a way of making it clear how great things are so far as an encouraging comment. And I doubt @johnnywc would release anything half-finished, anyway.  ? 

[+batari]

On 5/22/2021 at 1:43 PM, Thomas Jentzsch said:

Harmony/Encore and PlusCart/UnoCart are not compatible. I suppose the game would have to be recompiled for the latter and probably a new driver has to be developed too. 

Technically, existing Harmony or Harmony Encore carts can run this game with an upgraded CPU.

 

However, I am not offering CPU upgrades to Harmony/Harmony Encore at this moment, however, due to the fact that the upgraded CPU won't run current versions of Harmony firmware natively. Someday I might make changes to the firmware to support the upgraded CPU, just not today

[chewy]

well i have harmony regular- what are my options? eventually a physical cart release perhaps? of course i can try on stella n stuff w/ the keyboard just to try it...

[+batari]

31 minutes ago, chewy said:

well i have harmony regular- what are my options? eventually a physical cart release perhaps? of course i can try on stella n stuff w/ the keyboard just to try it...

Eventually you will be able to have your Harmony cart upgraded when I have a chance to update the Harmony firmware to support the upgraded CPU. The difference is pretty minor between the original and upgraded CPUs so the changes aren't all that involved.

 

Most likely a physical cart release will come well before that.

[Thomas Jentzsch]

8 hours ago, Karl G said:

I've generally not taken comments like this as a literal suggestion when I've seen them. I see it as just a way of making it clear how great things are so far as an encouraging comment.

The problem is, that there are such people (not you or John).

8 hours ago, Karl G said:

And I doubt @johnnywc would release anything half-finished, anyway.  ? 

Of course he would never do that. 

[+johnnywc]

Hi all,

 

The first public demo ROMs for Turbo Arcade (NTSC and PAL60) are now available for download on the Champ Games ROM Demo Download page. 

 

NOTE: Since this is using the CDFJ 64K bank-switching scheme, it does *NOT* run on Harmony or Harmony Encore (or any multi-cars).  The game is only supported in Stella v6.0 or better (for now).

 

Have fun and enjoy the long weekend (US)!  

 

John

 

[TrekMD]

Hmm, I can't access the page.  Is anyone else having an issue?  I turned off my VPN to see if that had anything to do with it but it made no difference.

[Arenafoot]

15 minutes ago, TrekMD said:

Hmm, I can't access the page.  Is anyone else having an issue?  I turned off my VPN to see if that had anything to do with it but it made no difference.

nope - no issues here. Went straight to the page and downloaded both of them with no issues.

--using Google Chrome on PC

 

 

[TrekMD]

Now it's working.  Go figure.

[atarifan88]

Going to give this a try.  Anyone know if this works on the community build of Stella on the Retron 77?

[Thomas Jentzsch]

1 minute ago, atarifan88 said:

Anyone know if this works on the community build of Stella on the Retron 77?

Should work.

[+Nathan Strum]

7 hours ago, atarifan88 said:

Going to give this a try.  Anyone know if this works on the community build of Stella on the Retron 77?

Confirmed - it works just fine!

 

(I keep forgetting to switch my HDTV to "Game Mode" though. Without it, I get terrible display lag which makes everything unplayable.  )

[JetSetIlly]

On 5/28/2021 at 11:07 PM, johnnywc said:

NOTE: Since this is using the CDFJ 64K bank-switching scheme, it does *NOT* run on Harmony or Harmony Encore (or any multi-cars).  The game is only supported in Stella v6.0 or better (for now).

 

In the ZPH reveal, what speed is the ARM chip in the custom cart running at? Is it 70MHz like the Harmony?

 

[Thomas Jentzsch]

It should be the same speed. Maybe at 60 MHz, since I remember the Encore clocked a bit slower than the Harmony cart.

[JetSetIlly]

9 hours ago, Thomas Jentzsch said:

It should be the same speed. Maybe at 60 MHz, since I remember the Encore clocked a bit slower than the Harmony cart.

Interesting. I'm asking because according to my ARM cycle-counting, at one point (the same point in every game) the ARM program consumes too much time and causes the screen to roll. It's probably my counting that's wrong but if the ARM is running above 70Mhz it would make a difference.

[Thomas Jentzsch]

10 minutes ago, JetSetIlly said:

Interesting. I'm asking because according to my ARM cycle-counting, at one point (the same point in every game) the ARM program consumes too much time and causes the screen to roll. It's probably my counting that's wrong but if the ARM is running above 70Mhz it would make a difference.

There was a discussion about MAM, which was buggy in the early chips and Harmonys. Maybe they enabled it now. IIRC it accelerates memory access.

[JetSetIlly]

38 minutes ago, Thomas Jentzsch said:

There was a discussion about MAM, which was buggy in the early chips and Harmonys. Maybe they enabled it now. IIRC it accelerates memory access.

No write to the MAM control address as far as I can tell, so the MAM doesn't seem to be enabled during the program.

 

Probably my cycle-counting although I'm curious as to what the upgraded CPU looks like. According to this post it is an upgraded CPU.

 

[+johnnywc]

2 hours ago, JetSetIlly said:

Interesting. I'm asking because according to my ARM cycle-counting, at one point (the same point in every game) the ARM program consumes too much time and causes the screen to roll. It's probably my counting that's wrong but if the ARM is running above 70Mhz it would make a difference.

Hi there!  The game does not roll on real hardware; I'm assuming the point in the game is when the hill appears or during a transition screen wipe to another screen?  The ARM cycle counting thing sounds very interesting; how is it done and is it something developers can use?  Probably the most frustrating part of developing for the ARM is trying to speed optimize code without any true benchmark telling you whether or not the changes you've done are helping or not. ?  

2 hours ago, Thomas Jentzsch said:

There was a discussion about MAM, which was buggy in the early chips and Harmonys. Maybe they enabled it now. IIRC it accelerates memory access.

Yes, MAM is enabled in Turbo Arcade.  The screen will roll without it (mostly because we need to update the entire 40x184 view screen on every frame from compressed data).

1 hour ago, JetSetIlly said:

No write to the MAM control address as far as I can tell, so the MAM doesn't seem to be enabled during the program.

MAM is enabled, but we never write to the MAM control address because Chris aka cd-w provided me with a CDFJ+ driver that has MAM enabled by support so I can save a few bytes of ROM not having to enable it in code (same for RobotWar and Gorf Arcade).   

1 hour ago, JetSetIlly said:

Probably my cycle-counting although I'm curious as to what the upgraded CPU looks like. According to this post it is an upgraded CPU.

 

It is an upgraded CPU but I'm not sure what the specs are.  @batari Fred would have all the info about that.