Sim City Optimized

[Myself086]

I started optimizing Sim City SNES for fun since July 1st and I'm totally addicted. I'd like to share some of the progress I've made so far.

I always wanted the game to run better on SNES and it's apparent why it's so slow. The game's simulation is mostly written in C while the rendering is done in assembly.

I added Fast ROM, though incomplete in some areas such as lookup tables and loading screens outside of gameplay. No SA-1 yet.

The C code had some weird compilations such as:
- Comparing carry flag to then set/clear it to what it already is.
- Calculate a tile position, read it, then compare its data and the branch skips over a single NOP instruction. Inside a heavy loop.
- An if statement between testing flood and radioactive tiles is missing a BRA and doesn't reload the Y register so there may be a way for flood to also act as a radioactive tile. Though I highly doubt it's possible.

The game has 2 threads running: one for update, one for render. Each time the render thread is active, it renders 2 rows of tiles for BG1, BG2 and optionally BG3 if the magnifying glass is selected. The render thread only resumes once every 4 frames. However, once the render thread is done preparing tiles, it simply waits for NMI before changing to the update thread. I modified it to support changing to the update thread immediately under certain conditions.

The map is 120x100 tiles in size and the code has many different ways of multiplying by 120, 60 and 15. Most commonly used inside loops where simply adding another local variable eliminates the need to multiply.

I'm using the Bern scenario for benchmarking with a simulation speed of 1. It can go from January to budget screen in ~42.61% the time it normally takes. I expect sub 25% to be possible without SA-1.

Empty maps run about 6 to 8 times faster than in the original. It now takes just over a second for a month to pass on speed 3.

There's room for improvement such as using DMA to zero memory during updates if I can figure out how to synchronize the DMA to avoid ending on an HDMA start. There are some Move instructions (mvn, mvp) that could be replaced.

HiROM could be used for 64KB lookup tables to update the map faster.


I'm aware of this SA-1 project and I'm not sure whether to join this dev.
https://www.patreon.com/posts/simcity-sa-1-112786310

[NovaSquirrel]

That sounds like a cool project! Thanks for the really in-depth information on what you've been finding in the code, it's interesting. Makes sense it's written in C, given that it's a PC game port; I previously wondered if maybe the code had some giveaways of NES version code reuse (like keeping the registers 8-bit) but this makes more sense.

[Myself086]

I previously wondered if maybe the code had some giveaways of NES version code reuse (like keeping the registers 8-bit) but this makes more sense.

I haven't seen any hint of NES code. The game mostly runs in 16-bit mode and the C code uses REP/SEP for every call and return because the compiler seems to not care what mode it's supposed to be in after each call. There are some oddities with REP/SEP where it'll do REP #$20, run a few lines, then REP #$30.

One thing that stands out as odd and impractical on NES is the overuse of unique addresses for some local variables in the C code. There has to be over a kilobyte of them. It speeds up the code because the alternative subtracts to DP which is used as a stack pointer.

Thanks for the really in-depth information on what you've been finding in the code, it's interesting.

Thanks I'll share more.

I'm in the middle of rewriting electric grid fill. The code is so bad that I had to remake it from scratch. 2 bugs in particular popped up.
If the tile in the bottom right corner happens to be the center tile of a power plant (impossible without cheating) then everything loses power. This is because when updating the map, the tile data is copied to $0b89 and the electricity update doesn't clear it before its first read. Except my new code skips this process for tiles like ground, forest, parks, water and zone edge tiles.
The second bug can count certain tiles multiple times, making it possible to use less power by adding more power lines and I don't think I want to rewrite this bug for now. The local variable for counting power is 32-bit wide when the maximum power requirement should be 12000.

I will upload an IPS patch soon. I am not using HiROM because I assume it'll leave about half of the game's data visible in the IPS file, haven't verified yet.

This is giving me some ideas for a randomizer. I think it would fit well on SNES with a now more playable version.

[Señor Ventura]

What about 512x224?

Visuals > performance?

[SNES AYE]

This is all awesome work! Just curious—have you considered adding rumble support now that it's a viable option? It’d be amazing for anyone who has the means to feel the controller shake during an earthquake or when Bowser goes rampaging through the city!

[Myself086]

What about 512x224?

Visuals > performance?

Native 512x224 requires using fewer backgrounds. Are you willing to redraw every tile to remove the top left BG1 tile that adds depth compared to the PC version?

This is all awesome work! Just curious—have you considered adding rumble support now that it's a viable option? It’d be amazing for anyone who has the means to feel the controller shake during an earthquake or when Bowser goes rampaging through the city!

I had no idea rumble was a thing for SNES. It doesn't sound too difficult to implement. Do you know where I can find documentations for SNES rumble?

[SNES AYE]

I had no idea rumble was a thing for SNES. It doesn't sound too difficult to implement. Do you know where I can find documentations for SNES rumble?

You might want to start here: https://tech.limitedrungames.com

Beyond that, you could reach out to folks like Randal Linden, Kando (kandowontu), or Infidelity for more information.

[Señor Ventura]

Native 512x224 requires using fewer backgrounds. Are you willing to redraw every tile to remove the top left BG1 tile that adds depth compared to the PC version?

I'm not asking to do the work, i'm talking about the techical possibility.

P.D: Mode 5 has two backgrounds too, What i'm missing?.

[creaothceann]

Sim City uses BG3 to create the dark area surrounding the command buttons, and for the messages that sometimes appear at the bottom.

[Myself086]

Bern scenario is now down to 14.36% process time and there are a few more things I want to optimize before uploading it.

Filling the electric grid alone takes about 5% the time process time it originally took. It came at the cost of a minor rendering bug that can mostly be mitigated. It also freed a bit array of 12000 bits that can be reused to identify which tiles can be updated instead of slowly checking each one 4 times per month.

I found another bug when optimizing RCI zone updates. The traffic around the zone is randomized and each tile position is put into a list. This list is written with increment before writing which means it's always going to contain a coordinate of 0, 0 in the list. One can simply put a road in the top left corner and it will accumulate traffic just because a RCI zone updated somewhere on the map. Traffic value is on a 60x50 map instead of 120x100 so it'll cover a 2x2 square in the top left corner. You'll need at least about 12 zones on the entire map to start seeing this bug.

Native 512x224 requires using fewer backgrounds. Are you willing to redraw every tile to remove the top left BG1 tile that adds depth compared to the PC version?

I'm not asking to do the work, i'm talking about the techical possibility.

P.D: Mode 5 has two backgrounds too, What i'm missing?.

Mode 5 is missing a 4bpp background which means we either have to:
1, remove quality on the top of buildings and rework how announcements are rendered at the bottom of the screen.
2, remove the top of the buildings entirely and redraw each building so they all fit within their given tiles.

[SNES AYE]

Side thought: Since someone mentioned using other modes, it reminded me of something—once you’ve finished this wonderfully optimized version of SimCity on the SNES, would you ever consider a similar improvement project for SimCity 3000 on console? It’s a surprisingly impressive game for the platform, especially in how well it uses the 8bpp visuals, but one area where it could really benefit is performance—particularly speeding things up as much as possible. Even basic actions like scrolling the screen to check different parts of the city can feel very sluggish and would greatly benefit from optimization if at all possible. Now that I would love to see!

[Myself086]

Side thought: Since someone mentioned using other modes, it reminded me of something—once you’ve finished this wonderfully optimized version of SimCity on the SNES, would you ever consider a similar improvement project for SimCity 3000 on console? It’s a surprisingly impressive game for the platform, especially in how well it uses the 8bpp visuals, but one area where it could really benefit is performance—particularly speeding things up as much as possible. Even basic actions like scrolling the screen to check different parts of the city can feel very sluggish and would greatly benefit from optimization if at all possible. Now that I would love to see!

I'm assuming you meant Sim City 2000. I can't say much about it because I haven't seen the code and I don't care to optimize it. I have 2 other projects on SNES for Final Fantasy 6 randomizer Beyond Chaos and Sid Meier's Civilization.

[SNES AYE]

I'm assuming you meant Sim City 2000.

Correct

[Myself086]

Here's a first version. There's still room for improvement.

[DrAcOFoto]

Here's a first version. There's still room for improvement.

This is great, enjoying the speed bump. Excited for future updates. SuperNES mouse support someday? Are you planning to use FastROM later?