Any ideas why an i2c device’s SCL line would get stuck at ~1.2V when powered by 3v3 and not attached to any interface?

I did solder 30ga wire to a flat flex connector, but I’m not seeing any direct shorts.

A picture of Sim City running in mGBA

A picture of Sim City running in mGBA

A picture of Sim City running in mGBA

A picture of Sim City running in mGBA

WIP Release of Micropolis (SimCity) for the Gameboy Advance:
github.com/TaraHoleInIt...

Wish it was possible, but I was too sick to take co-ops during the eligibility period :/

I’m better now, but yeah I feel like I missed an important opportunity I can’t get back.

I’m in this weird space where I’m not even sure if I’m applying to the right jobs.

Embedded dev has been my world since I started working on Nintendo DS homebrew back in 2006, but looking at the job listings makes me feel like I’ve done everything wrong.

Please tell me this gets better :/

How the heck do you get a job, anyway?

I graduated, fixed up my resume, and tried to keep my GitHub reasonably active, but I’m just not seeing anything I can apply to.

Everything so far has been a rejection, the location is too far away, or they want a “senior”.

Sprite sheet for Micropolis (SimCity)

Result:
Drastically reduced sprite VRAM usage.
More space for UI sprites.

All of the game sprites now neatly fit in a single sprite sheet.

This is the fun part about embedded hardware and software: finding ways to squeeze in just a little more with the hardware you have :)

Luckily, the GBA 2D graphics hardware has free rotation, scaling, and mirroring :)

If you look at the sprite sheet you'll see that I'm only using 5 frames instead of the 16 from before.

At runtime, each frame is looked up and assigned a graphic to use as well as what transformations to apply.

16 frames of a monster sprite

Let's look at the monster sprite:
Size: 32x32 = 512 bytes per frame at 4bpp
Frames: 16
Total: 8KB!

The monster sprite took up 25% of my available VRAM!

The Gameboy Advance has 32KB of VRAM for sprites, which in sounds like a lot, but you can quickly find yourself running out of room.

While porting Micropolis to the GBA, I ran into this very issue. I had enough room for all of the game sprites, but I had no more VRAM for UI elements.

The software used to convert the tileset into a GBA friendly format is able to see these duplicate tiles and make references to them rather than having duplicate tiles in VRAM.

Everything just baaaarely fits as you can see in the image attached to the first post :)

Because the tileset contains multiple animation frames, I decided to sacrifice the one with the most frames: fire.
There were 8 fire tiles, each representing a frame of animation.
I overwrote every other frame with the graphics that came before it, that essentially brings it down to 4 unique tiles.

I ended up cutting down the font to only the upper and lowercase characters to make the font smaller, but it still wasn't enough.
A trade-off had to be made.

It was getting closer to fitting, but I still needed more room.
I needed space for a font, and 3 background maps of 2KB each: one for the game, one for the text foreground, and one for the text background.

In order to fit everything in, the main tileset had to be reduced.
Several tiles in the tileset were obvious test tiles, and so those were cleared out.
Next, I checked the source code to see what other tiles were unused and cleared those out as well.

The fun part was trying to fit everything into VRAM.

The GBA has 96KB of VRAM of which 64KB is shared between the tile graphics and their maps (background vram) and 32KB is used for sprites.

The tiles would have taken up all but 4KB of the 64KB background vram leaving 0 space for ingame text.

More work on my port of SimCity to the Gameboy Advance.
With the help of the gba development discord, we were able to extract the 8x8 MCGA tileset from the DOS version of SimCity.

Working on porting Micropolis (SimCity) to the Gameboy Advance.
Pictured on a DSi, it is running in GBA mode.

Source:
github.com/TaraHoleInIt...

All it does now is run without sprites and you can scroll around.

In order to find out if this is worth it, I still need to add scrolling.
If I cannot scroll smoothly, then there really isn't much point in continuing :)

I've written a very basic metatile (grouping of 2x2 8px tiles) allocator, and as shown above it seems to work somewhat.

I haven't optimized it yet, but mapping that 16x16 metatile map onto the 32x32 screen tile map is taking around 5ms.

I was curious if I could get Micropolis running on the GBA, and the answer is maybe?
Problem is that the GBA tile engine can only address 1024 8x8 tiles, while Micropolis uses 1024 16x16 tiles.

It's taken a lot of fudging the tile data, but I believe it might be reasonably possible.

I always use PlatformIO with VSCode for as many projects as I can. It makes everything so much easier and more flexible.

Maybe moving to Arduino now would expand the audience a bit?

I wonder if I should move my Micropolis (SimCity) port from ESP-IDF to Arduino.
Not that I don't like ESP-IDF, but this might open it up to being usable on more platforms.

Like, I need to use my TFT_eSPI shim for LCD initialization currently, but I know most won't bother.

Yeah; it's fairly simple though.

I mean, that would work if I had a drawSpritePixel() routine which checked if each pixel in the sprite was within the bounds of the camera.
Seems like a lot of branching though, so I'd have to test it and see how much it impacts rendering performance.

Devs:
How would you plan out a sprite renderer that can properly handle sprites that are partially off-screen?

I'm planning on doing a naive cull to start, but I want to know how to plan a better sprite renderer.

Do you start by sketching things out?

Hitting a bit of a snag porting SimCity to the ESP32: the graphics are indexed but do not use a global palette.
So sprites each have their own palette, but that palette often differs (by index only) each frame?

I need a way to create a global palette from all of the graphics somehow.

The cursor is the inverted patch of pixels near the upper middle of the screen. To do this I just made a copy of the tile data that's inverted rather than waste cycles inverting it at runtime.

More SimCity on the ESP32.
I rewrote the tile engine to render into an indexed frame buffer which gets converted and pumped out over SPI in 16px tall chunks.

Currently at ~39-41ms for a full frame including rendering and sim ticks.

I still need to do scrolling and sprite rendering.