Jump to content
IGNORED

Paint The City - WIP


splendidnut

Recommended Posts

Ok, it appears something is wonky in the music engine.  Currently the code is dependent on that working completely working for the game to start.  I switched to starting the game in running mode, and things work now, but no music.  I'm going to try and fix that and post another build, hopefully soon.

  • Like 1
Link to comment
Share on other sites

Ok, so it was a stupid mistake on my part.

 

The sound/music engine is a modified version copied from ChaoticGrill.  So the right difficulty switch turns the music on/off.

 

BUT, with this, the game starting sequence is completely based on detecting the countdown tune finishing.  So, if the music is off when this game is started, the game won't start until you turn on the music.  Oooops.

 

So, I've switched to using a regular timer for the start sequence... and I've removed the music on/off switch.

 

Here's the fixed version:

 

PaintTheCity-(early_demo)-(20210104).bin

  • Like 3
Link to comment
Share on other sites

21 hours ago, splendidnut said:

Ok, so it was a stupid mistake on my part.

 

The sound/music engine is a modified version copied from ChaoticGrill.  So the right difficulty switch turns the music on/off.

 

BUT, with this, the game starting sequence is completely based on detecting the countdown tune finishing.  So, if the music is off when this game is started, the game won't start until you turn on the music.  Oooops.

 

So, I've switched to using a regular timer for the start sequence... and I've removed the music on/off switch.

 

Here's the fixed version:

 

PaintTheCity-(early_demo)-(20210104).bin 8 kB · 24 downloads

Working now, sounds and I can 'Paint the City'. (Tested on my 7800).

 

  • Like 1
Link to comment
Share on other sites

  • 2 months later...

Oh, wow, it's been way too long.

 

I've actually been occasionally poking at the enemy logic for Paint The City, and I think I've finally gotten it in a half-decent state.  It is buggy, and chaotic, but it kinda works, and the game is now kind of playable.  Enemies follow the level, they spawn at different speeds, you can crash into them.   Sometimes they behave properly, sometimes they don't.  And... Bullets collisions are still not implemented.

 

BUT, really I just want to show off my title screen.  It ended up looking better than I expected.

708832239_ScreenShot2021-03-27at10_14_26PM.thumb.png.6077af4f3ac8928d64b56521d38a8198.png

 

Oh, and here's a ROM to try out.

 

Enjoy!

 

NTSC:

PaintTheCity-WIP-NTSC-20210328.bin

 

PAL60:

PaintTheCity-WIP-PAL60-20210328.bin

 

  • Like 12
Link to comment
Share on other sites

Already uploaded to the PlusStore by your hardworking ROM-Admin [mention=66922]Prizrak[/mention]
Absolutely, as often as I check the forums for rom updates it makes me wonder if anyone is on here as much as I am lol. For those PlusCart users, I got your back.

Sent from my SM-N960U using Tapatalk

  • Like 1
  • Thanks 4
Link to comment
Share on other sites

ZeroPage Homebrew is playing Paint The City on tomorrow's (Tue Mar 30, 2021) stream LIVE on Twitch at 6PM PT | 9PM ET | 2AM GMT! Hope everyone can watch!

 

 

Games:

 

(SET VIDEO TO 1080P60 FOR FULL QUALITY)

 

 

 

Edited by ZeroPage Homebrew
  • Like 2
Link to comment
Share on other sites

  • 3 months later...

Is this still being updated? Because this seems pretty promising so far! I knew about City Connection prior to today, but only now decided to give it a fair shot on the Nintendo Switch Online NES app, and one of the first things that popped into my head was "this would make for an awesome 2600 game!" I'm honestly surprised that it took the homebrew community this long to actually try and tackle it, but here we are (assuming that this project hasn't been abandoned).

  • Like 4
Link to comment
Share on other sites

  • 6 months later...

At some point, I'll pick this up again.  Currently, the project is in a broken state and the latest source code won't build/assemble anymore.  The source code has a ton of macros, so that's making it hard to track down where the issue is.  Ultimately, it could do with a good revamp.  I've been debating whether I want to try and fix that issue or restart the project in my new programming language I'm developing.

 

---

 

Anyways, this ended up happening:

1172269581_Atari2600BestWIPHomebrew(Port).png.78f1f43c1b40b33fb768acdc560d10df.png

 

 

 

I must be doing something right :)   Lots of great entries. Go check them out and Vote!  https://atariage.com/forums/forum/203-atari-homebrew-awards/

 

  • Like 8
Link to comment
Share on other sites

So, I discovered that this project is DASM version dependent (needs 2.20.14.1) due to the way macros are used.  I don't quite remember what the macro issues were, I only vaguely remember when I ran into them before.  Also, this project doesn't like to build within Atari Dev Studio... which is something I should probably fix.

 

I am using a repository for this, but it is completely outdated.  There are a lot of changes that I need to sort thru and commit (last commit was the January 5, 2021 build).

 

Anyways... I've got this monster building again.

  • Like 5
Link to comment
Share on other sites

12 hours ago, splendidnut said:

So, I discovered that this project is DASM version dependent (needs 2.20.14.1) due to the way macros are used.  I don't quite remember what the macro issues were, I only vaguely remember when I ran into them before.  Also, this project doesn't like to build within Atari Dev Studio... which is something I should probably fix.

 

I am using a repository for this, but it is completely outdated.  There are a lot of changes that I need to sort thru and commit (last commit was the January 5, 2021 build).

 

Anyways... I've got this monster building again.

It might be useful if you ever do find what those macro issues were - or even the changes required.  I'm curious as to what changes were made to the dasm codebase/specs that caused your project to fail to build.

Edited by Andrew Davie
Link to comment
Share on other sites

The failure is probably all on my end.    Going back to DASM 2.20.12 clued me into what the issue is.

 

DASM 2.20.14.1 works.

DASM 2.20.13 makes it thru 3 passes, claims everything is resolved, then complains about "Unrecoverable error(s) in pass, aborting assembly!".  Hmm...

DASM 2.20.12 fails on the first pass due to unresolved macros... There are macros calling macros across files which are only included via the parent file.

 

To clarify with an example:

    main.asm is the only place where file includes are done.  (it's the parent file of everything)

 

    It includes the following:

        player_macros.asm   - macros used for player logic

        main_kernel.asm      - main drawing kernel

 

    main_kernel.asm has no includes, but calls a macro in the player_macros.asm to setup REFP0 for the player during display (after the scoreboard is drawn).

 

    Latest version of DASM can resolve things just fine, but the older versions can't.

 

I remember I kept running into issues with duplicate identifiers when I tried including files where they were needed.  Only including files once in the parent seemed to resolve that... but it seems it locked me into the latest version of DASM.

 

I think I leaned too much into a "C" mindset when creating this code and then had to apply whatever workarounds were needed to get things built and running.  I was attempting to leverage MACROs to allow me to make easily relocatable code.  BUT, that doesn't seem to have worked out too well.  I should probably take the time and revamp the code base.

 

Ironically, the Chaotic Grill code base is not nearly as chaotic as this :)

Link to comment
Share on other sites

5 hours ago, splendidnut said:

I remember I kept running into issues with duplicate identifiers when I tried including files where they were needed.  Only including files once in the parent seemed to resolve that... but it seems it locked me into the latest version of DASM.

Did you make the include files idempotent ?
In C, we do this by wrapping them with something like:

#if not defined (__THIS_HEADER_FILENAME_H__)
#define __THIS_HEADER_FILENAME_H__
... the rest of the include file
#endif

Obviously you would have to use the DASM equivalents.

Also make sure that the objects are defined only once in proper module files.
The include files should only have extern references to them.

Link to comment
Share on other sites

7 hours ago, Thomas Jentzsch said:

Have you tried to increase the number of passes (-p or -P)? 

I just tried that, and it doesn't change the outcome in those older versions.  2.20.12 definitely doesn't support what I'm doing here and I'm not really sure what's going on with 2.20.13, but it may very well have been a bug specific to that version.

 

2 hours ago, stepho said:

Did you make the include files idempotent ?

...

No.  I highly dislike that C programming idiom (#ifdef safety net in header files) even though I always use it in C.  It is an interesting idea and would probably make the source code backwards compatible.

 

BUT

 

I'm not too concerned at this point since it does build properly in the latest version of DASM.  If anything, I'd rather work towards cleaning the code up and eliminating the semi-complicated dependencies since they are a cause of confusion.

 

At this point, I need to re-familiarize myself with this code before doing anything else with it.

Link to comment
Share on other sites

  • 2 weeks later...
  • 3 weeks later...

Finally, an update!

 

Some good stuff has been added:

   - Level complete detection.
   - Level progression - at least to level 2.
   - Added oil collision and car bumping.  When oil hits a car, it spins out... if the player then bumps the car, it will be knocked off screen.
   - Crashed + Gameover messages.  Player can now continue playing if there are still lives left.  (Balloons currently give more lives)
   - "Better" collision detection... hardware + software collision detection that still sometimes has issues.
   - Color tweaking.
   - Added a few more sound effects.

   - Lots of code cleanup and optimization.

 

STILL TO DO:
 - Fix and improve oil can throwing system.  Currently can only be done when player is driving on the road.
 - Switch balloons to warp the player to the next level.... requires more levels!
 - Scoring system.
 - A few more music pieces.
 - Extras?

 

I figured this was a good point to post an update, because...

 

I've hit a point where I want/kinda need to switch bank-switching schemes to give me more elbow room.  I've done a lot of optimizations and there's probably more I can do, but doing that takes time away from actual game logic coding.  And it's getting a bit harder to recover good size chunks of space.

 

For bank-switching, I'm debating between CBS RAM / FA scheme (128 bytes more RAM + 12K ROM) or M-Network E7 scheme (2K RAM + 16K ROM).  I don't really need the extra RAM, but it could potentially help by letting me having multiple background layers.  Ultimately, I could just stick with the SuperChip schemes and bump up to 16K ROM.  But what fun would that be?

  

Anyways,  Enjoy!

 

NTSC:

PaintTheCity-NTSC-20220224.bin

 

PAL60

PaintTheCity-PAL60-20220224.bin

  • Like 8
  • Thanks 1
Link to comment
Share on other sites

On 2/7/2022 at 7:54 PM, Glenn Main said:

Happy that it's not my noggin having to figure all this timing!

If you are referring to the display kernel... it actually wasn't too terrible.  It only gets tricky when I need to go in and add something else to it.  I've been putting off fixing the oil can system (player shooting oil cans at other cars) for that reason.  Oil cans are currently only drawn directly above oil barrels... because I forgot about them when I originally wrote and unrolled the display kernel.  Oops.

 

If you are referring to the movement of the enemy cars/cat/oil barrels...

There's a trick there.  I committed some time early in the project to build a flexible speed control / fractional movement system.  Once implemented, I only needed to do a bit of trial and error to get things looking decent.  The car spawning system runs off of a data table and a timer.  The cat and the oil barrels just have a spawning timer.  When the player switches directions... there's some code that goes thru and changes the speeds and directions of everything else.  Gravity gets applied separately.  It took a bit of debugging work... but it worked out in the end.

  • Like 1
Link to comment
Share on other sites

  • 9 months later...

Trivia: the name 'City Connection' is a play on the premise of driving around multiple cities...  In a Honda City.

 

1984_honda_city-turbo-ii-motocompo_7e6542a8-0b2a-4f5a-9a43-b5451fe2bd70-78921.thumb.jpeg.9679cbf7e9b1f69bab1165c98d43e8cd.jpeg

 

This was a car that could be ordered with an optional folding motorcycle (the Motocompo) that fit in the cargo area when folded.

 

Excellent choice to port, btw :D

  • Like 4
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...