Always good to see clever optimisations and that profiler is a great idea!
Good Job Smile . Will the Enemy Sprites stay in one position or eventually move?
The enemy tanks will eventually move around. I'll probably implement the early level tanks that just wander around randomly first, but eventually, I hope to also add the tanks from the later levels that are actually somewhat intelligent.

Right now, I'm trying to give them some actual graphics, rather than just numbered squares, which will make it more obvious which direction they are facing when moving. However, convimg isn't cooperating - I tried updating it so that I won't have to rewrite my config file again in the future, and now my tilesets don't work.
I've gotten enemy tank rendering working:

I'm using a dynamic palette, where each tank color gets 5 unique colors, plus 2 shared colors for the wood tread. This means that I only have to store one copy of the enemy tank sprite (per rotation) in the program, and I can generate the rest later. I also set up a system to automatically trim the sprites and store the amount trimmed by to use as an offset. Combined with sprite mirroring and compression, this means that not much of the program actually stores sprite data.

The tanks look a bit off to me - I think that that's because the color that I'm replacing for the dynamic palette is really saturated, which means that there's not much contrast between the different sides of the tank. I don't really feel like fixing that right now, as I don't have the palette generation automated for the other tank colors, and I don't want to re-enter 50 different RGB colors.

Hopefully, the tanks will look a bit better when they're moving around and rotating, as our brains are generally pretty good at working out motion from even blurry videos.

The game is still running at 31 FPS in the screenshot, even with 7 tanks. Of that, 14.8 ms is spent on rendering tanks, 10.2 ms is spent on AI, and 3.8 ms is spent on processing collisions. This is pretty good, as my target is 30 FPS and I still have plenty of things to optimize to give time for movement AI.

Next, I think I'll work on enemy motion, so that the game is actually playable, then finish up the graphics.
After that, I've been thinking about how to implement multiplayer, both in a 2-player co-op mode like in the original game, and an online multiplayer PvP mode using a similar architecture to TI-Trek.

Also, do you guys think that a series of short videos explaining how the game is implemented would be interesting?
Looks great man! I particularly like the palette strategy and storage tricks you're using to keep the size down.

I'd be interested in dev videos for sure.
My last GitHub release is really old, and someone messaged me on Discord about it, so I've decided to make a new release so that you can try it out without having to install the LLVM toolchain, which takes ages. It includes the rather buggy AI.

Here's the download:

Minor progress update: I added an aim indicator, then realized that the precision on physics objects is so bad that the shell's trajectory is several degrees off from the aim indicator.
I've made a few graphical improvements - namely, the border around the map, and the kill and life counters.

I may add some more variation to the border, as is present in the original game, but that's a low priority for now.
And it turns out the issue with the aim indicator wasn't with precision; I just forgot to skew the angle to match the perspective. That's been corrected as well

Here's the download, if you want to give it a try yourself:

So apparently, the original game uses a different set of levels depending on the aspect ratio. My reference images and video are all from the 16:9 version, but the CE's screen is 4:3. That explains why I was having so much trouble getting everything to fit on-screen.

So, I guess I can either leave everything as-is or re-enter all of the levels and re-scale all of my graphics to match the larger block size. That's going to take a while, but hopefully, it will mean that more of the screen will be used by stuff actually relevant to gameplay.
I've switched everything over to the correct 4:3 levels and sprites.
I've also added rendering for shells:

I plan to enable clipping to stop the banner at the bottom from bugging out. The other visual bugs are also on my to-do list and will be fixed prior to release.

Here's the download, yada yada.
Wow it's coming along so fast now, it's playable!!!
I fixed the super broken enemy tank rendering:

I added more different colors, fixed the bug where some colors were transparent, and the bug where the rest were all actually the same color. I'm unsure how I previously thought that the code was working.
I also set up a Python script to automatically generate the dynamic palette, which took me forever to do by hand last time.

I've also fixed the UI, though I forgot to show it in the screenshot.
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 3 of 3
» All times are GMT - 5 Hours
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum