18 replies to this topic

[Animan]

This topic began here, but I feel this is a more appropriate place for this kind of stuff.

Basically, this is a WIP I am working on. It is a game not unlike Monaco GP. So far, I have a drivable car, simple scrolling demonstration (which I can edit the playfield and colors in the code on the fly), and one enemy car.

The latest binary and source is in that topic, but all future binary's and source codes will be posted here.

[rmaerz]

I didn't get to play the game yet, but judging by your pix you should consider making the bridges not as wide if you want to capture the feel of Monaco GP. In Monaco GP, as you may know, you can only go two abreast on the bridges.

[Animan]

rmaerz, on Mon Aug 30, 2010 6:27 PM, said:

I didn't get to play the game yet, but judging by your pix you should consider making the bridges not as wide if you want to capture the feel of Monaco GP. In Monaco GP, as you may know, you can only go two abreast on the bridges.

Yes, indeed. Right now I am more concerned with actually getting all the "physics" and enemy's working, but I might make that change when I begin working on it tomorrow.

Yes, that very narrow bridge. That game is brutal.

[yuppicide]

I'm jealous. You got your feet wet in ASM and I'm stuck on bB. Great job so far!

[Godzilla]

can't wait to see monaco 2600

[Animan]

Sorry it's been a few days since an update. I can feel myself losing interest in this project, like what has happened to me before. However, I am doing my best to motivate myself to keep doing it. Now that my Trashmania update is done, I think now I can focus on this. Plus, it's a 3 day weekend for me at school (labor day), so I might have more time to keep working on it.

[Animan]

A really minor update to prove I am doing something.

-Changed car sprites to look closer to the arcade ones.
-Changed sound of when you are on the grass to sound more like it does in the arcade.
-(incomplete) collision detection with the car. It is harder because the enemy car is not drawn on the same scanlines as the player's car due to timing issues. Basically, so far it slows you down when you are close to the car vertically (horizontally it isn't detecting where it is yet, so it slows you down everytime you pass it).

Attached Files

•  MonacoGP2600b5.txt   8.13K   30 downloads
•  game.bin   4K   84 downloads

Edited by Animan, Sun Sep 5, 2010 5:11 PM.

[Animan]

Been slacking off a bit...

Updates:
-Made the cars single colors. This allows me to have the cars on the same scanlines, and make collision detection much easier.
-Enemy car changes color everytime it leaves the screen.
-Enemy car moves back and forth. It's an incomplete AI (I don't think the original game was much better).
-When the cars collide, your car slides over to the right. Shows that the collision detection is working.

Attached Files

•  MonacoGP2600b6.txt   8.51K   24 downloads
•  game.bin   4K   73 downloads

Edited by Animan, Sun Sep 12, 2010 3:30 PM.

[Nukey Shay]

I don't think that the arcade game even used AI for opponents. Looks like they just slide from side-to-side from an initial starting position.

[Animan]

Nukey Shay, on Sun Sep 12, 2010 3:40 PM, said:

I don't think that the arcade game even used AI for opponents. Looks like they just slide from side-to-side from an initial starting position.

Yes, I believe that's how it was. It was still hard to avoid them, though. That, or I suck at that game.

[Animan]

Just a quick update today.

-Cycles through all the main levels from the arcade (excluding later levels, which are the same as the earlier ones with different colors). It goes to Green and Yellow, icy roads, Tunnel with red on sides, and bridge. After each screen, it goes back to green and yellow, and then to the next screen.
-Enemy car is invisible in tunnel level. Headlight system is not in yet, so trust your luck here! (Or just stay on the left the whole time and never get hit).
-Colors don't scroll in, and they just appear (the road color changes first, and then the side colors). I know this doesn't look too good, but for now it works for now. This is, again, a timing issue.

Attached Files

•  game.bin   4K   57 downloads
•  MonacoGP2600b7.txt   9.67K   39 downloads

Edited by Animan, Mon Sep 13, 2010 4:50 PM.

[yuppicide]

Looks great. Keep up the good work.

[Animan]

Sorry it has been a while since the last update. I am at the moment trying to implement a score system, and it has proved harder than I initially thought. I began using the 6 player row trick, but the digits would keep moving with the cars. I tried a lot a things to fix that with zero luck. Now, I have decided to use the playfield as the score (which is fine since the arcade game only had a 4 digit score board). This has also been quite a challenge. So hopefully in the next few days I should have it working.

[Nukey Shay]

Animan, on Tue Sep 21, 2010 5:14 PM, said:

I began using the 6 player row trick, but the digits would keep moving with the cars. I tried a lot a things to fix that with zero luck.

You could have just posted the problem. Very easy to correct. Most-likely, old HM data is still present when you reposition, so HMCLR before the areas where HM's are updated.

[Animan]

Nukey Shay, on Tue Sep 21, 2010 5:29 PM, said:

Animan, on Tue Sep 21, 2010 5:14 PM, said:

I began using the 6 player row trick, but the digits would keep moving with the cars. I tried a lot a things to fix that with zero luck.

You could have just posted the problem. Very easy to correct. Most-likely, old HM data is still present when you reposition, so HMCLR before the areas where HM's are updated.

OK, I tried the HMCLR by putting it right before the score bar begin drawing. However, this caused my car to not be able to move at all. I thought it wouldn't work just doing that, but I don't know how to implement it.

Here is the source to the current version. There is a small block in the score bar that moves with the car. This will become the score digits. Maybe the source could give you some idea as how it can be fixed? Because I have wasted more energy than I should be on this, and it's a road block right now (no pun intended).

In other words, how can I have this block not move with the car?

Thanks for any help.

-Jonathon Bont

Attached Files

•  game.bin   4K   81 downloads
•  MonacoGP2600b8.5.txt   10.79K   29 downloads

Edited by Animan, Fri Sep 24, 2010 2:35 PM.

[Nukey Shay]

Well, your program is taking advantage of existing HM values to move the opponent cars after they've been initialized. That's why HMCLR stops their horizontal movement. You ought to keep track of their horizontal position so that they can be reinitialized on every frame instead of relying on old data. Without having the means to reset HM, you are out of luck using them for independant sprites for scores (and would have to resort to using PF registers for scoring, like so many older games did).

In addition, cars are being drawn too late into the scanline, so there is some sprite shearing for objects in the center of the screen. You can correct that by either writing earlier so the effect is hidden, or by using sprite delay registers (VDELPx).

Also, steering the car was impossible in Z26. This could be due to having read the port more than once (which is not advisable). You could just load the value and check it in A. Results in shorter code too:

  lda SWCHA
  bmi noright ;branch if bit7 set
  ldx #$F0
noright
  asl ;move bits to the left, bit6->bit7
  bmi noleft ;branch if bit7 set
  ldx #$10
noleft

Port is read once...and pushing bits to the left easily checks for left movement (bit7=negative/positive).

[Animan]

Nukey Shay, on Fri Sep 24, 2010 3:19 PM, said:

Well, your program is taking advantage of existing HM values to move the opponent cars after they've been initialized. That's why HMCLR stops their horizontal movement. You ought to keep track of their horizontal position so that they can be reinitialized on every frame instead of relying on old data. Without having the means to reset HM, you are out of luck using them for independant sprites for scores (and would have to resort to using PF registers for scoring, like so many older games did).

In addition, cars are being drawn too late into the scanline, so there is some sprite shearing for objects in the center of the screen. You can correct that by either writing earlier so the effect is hidden, or by using sprite delay registers (VDELPx).

Also, steering the car was impossible in Z26. This could be due to having read the port more than once (which is not advisable). You could just load the value and check it in A. Results in shorter code too:

  lda SWCHA
  bmi noright ;branch if bit7 set
  ldx #$F0
noright
  asl ;move bits to the left, bit6->bit7
  bmi noleft ;branch if bit7 set
  ldx #$10
noleft

Port is read once...and pushing bits to the left easily checks for left movement (bit7=negative/positive).

Thanks for the advice.

I might just use the playfield for the score digits (again, the original arcade game only had 4 digits, so I won't be losing anything there).

[Madaracs]

Animan, on Fri Sep 24, 2010 3:25 PM, said:

Nukey Shay, on Fri Sep 24, 2010 3:19 PM, said:

Well, your program is taking advantage of existing HM values to move the opponent cars after they've been initialized. That's why HMCLR stops their horizontal movement. You ought to keep track of their horizontal position so that they can be reinitialized on every frame instead of relying on old data. Without having the means to reset HM, you are out of luck using them for independant sprites for scores (and would have to resort to using PF registers for scoring, like so many older games did).

In addition, cars are being drawn too late into the scanline, so there is some sprite shearing for objects in the center of the screen. You can correct that by either writing earlier so the effect is hidden, or by using sprite delay registers (VDELPx).

Also, steering the car was impossible in Z26. This could be due to having read the port more than once (which is not advisable). You could just load the value and check it in A. Results in shorter code too:

  lda SWCHA
  bmi noright ;branch if bit7 set
  ldx #$F0
noright
  asl ;move bits to the left, bit6->bit7
  bmi noleft ;branch if bit7 set
  ldx #$10
noleft

Port is read once...and pushing bits to the left easily checks for left movement (bit7=negative/positive).

Thanks for the advice.

I might just use the playfield for the score digits (again, the original arcade game only had 4 digits, so I won't be losing anything there).

Well, this is exciting. I own a real Monaco GP! As soon as I get my Harmony I should be able to check this out no?

[Animan]

Madaracs, on Sat Oct 2, 2010 7:43 AM, said:

Animan, on Fri Sep 24, 2010 3:25 PM, said:

Nukey Shay, on Fri Sep 24, 2010 3:19 PM, said:

Well, your program is taking advantage of existing HM values to move the opponent cars after they've been initialized. That's why HMCLR stops their horizontal movement. You ought to keep track of their horizontal position so that they can be reinitialized on every frame instead of relying on old data. Without having the means to reset HM, you are out of luck using them for independant sprites for scores (and would have to resort to using PF registers for scoring, like so many older games did).

In addition, cars are being drawn too late into the scanline, so there is some sprite shearing for objects in the center of the screen. You can correct that by either writing earlier so the effect is hidden, or by using sprite delay registers (VDELPx).

Also, steering the car was impossible in Z26. This could be due to having read the port more than once (which is not advisable). You could just load the value and check it in A. Results in shorter code too:

  lda SWCHA
  bmi noright ;branch if bit7 set
  ldx #$F0
noright
  asl ;move bits to the left, bit6->bit7
  bmi noleft ;branch if bit7 set
  ldx #$10
noleft

Port is read once...and pushing bits to the left easily checks for left movement (bit7=negative/positive).

Thanks for the advice.

I might just use the playfield for the score digits (again, the original arcade game only had 4 digits, so I won't be losing anything there).

Well, this is exciting. I own a real Monaco GP! As soon as I get my Harmony I should be able to check this out no?

I wish I had a real Monaco GP cab, but I am just a broke teenager. Besides, my parents wouldn't be too happy about having one in the house (My sister actually had an NFL Blitz cab she won at some contest GameStop hosted when they just opened up here. It remained in the garage, and eventually got sold later on). However, if anybody is willing to donate a machine for free, I would be more than happy to take it .

I have been relying on YouTube videos of the gameplay (again, this game uses TTL chips, so it can't be emulated in MAME), the one experience I had with the game at Cedar Point, and I have been considering getting the Sega Ages Memorial Vol. 2 disc for the Saturn. However, it is a little pricey since it is a Japan exclusive. The only other ports I know of are an SG-1000 port (which wasn't very good, and it had a jump ability added for no reason ), and a GP2X homebrew which is decent.

Hopefully, you can give some feedback on how close it is to the arcade, and what could be improved. I already have a general idea, but it's nice to hear from someone who owns the real deal.