Jump to content


New Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

177 Excellent


About AnalogKid

  • Rank
    Star Raider

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Ok guys, it's beta time. First off, my thanks to everyone for being patient. It has been an interesting odyssey, learning assembly, moving up to SDCC4, diving into cvlib source to convert it and also make more specific and optimized versions of functions, then diving into bios source and doing the same, learning the CV hardware, learning how SDCC thinks and figuring out how it wants me to code, etc. etc. So now, I could use a few beta testers. Ideally I'd like someone to run the ROM on original CV hardware and someone to run on the Phoenix. For playability I'd like to hear from people using dual-stick options as well as people using single-stick. I found the single-stick is still very playable because of being able to use the second fire button to fire backwards while evading. The keypad mode is there too but that's more for those using 3rd party sticks with better keypads. At the arcade skill level the pacing is still a bit more forgiving than the arcade version partly because you have almost 50% less vertical play area, partly being character based the grunts can speed up only so gradually, and partly because I want people to be able to at least make it past the first tank wave successfully and maybe see the grunt-mob. Dual stick players will have an advantage and I want to hear if I need to ramp up the action more when into the 20-30 level area. I've been playing the game for three months now so I'm an expert, I don't want to put out a game that is frustratingly hard. I'm going to do another round of experiments with how much I can put on the screen without loosing the race with the nmi, now that I've completed yet another round of optimizations, so it should be possible to ratchet up the action a few more notches.
  2. It's actually now ready for me to hand off the ROM image to beta testers
  3. A teaser demo ROM is available for download: Robotron Demo ROM
  4. To reduce character collisions I made the human score strings fit within a single character and three digits was all I could fit. Because of that I scaled the other scoring down accordingly. It would look odd if a grunt or spheroid walked across half the score and turned 1000 into either 100, or worse 000. Plus, with two characters it wouldn't be centered and that would trigger an OCD twitch in me Using characters as sprites is a real pain, let me tell you. The scale-up/down math is annoying enough, what's worse is having to clean up their tracks as they move, as you can't safely rely on getting the background and restoring it, as character sprites can cross each other's paths.
  5. Here's the final preview video for Robotron. It's feature complete and now into the final testing and fine-tuning stage. I've moved some critical code out of C and into assembler libraries because frankly SDCC just doesn't have the AI necessary for writing efficient code for structs. As a result I was able to get up to 20 enemies on the screen along with 7 humans, 8 bullets, a couple of spheroids, and the player. The limiting factor is now the 1K RAM and I've just about used it all. I strongly recommend checking out GearColeco as a development tool. It supports stepping through assembler code and has a RAM viewer which not only helps with keeping an eye on free memory and debugging but also helps identify stack leakage. The video capture rate kind of spoils some of the visuals but there will be another hands-on demo available to play with soon.
  6. I rebuilt a cvlib-based project with 4.2.0, after rebuilding the libraries of course, compared the asm output to 4.1.0 and saw the obvious improvements, and then tried to run the rom... nothing. In Gearleco the VDP viewer shows that the name table, pattern table, and sprite table are full of garbage and the program is stuck on a HALT waiting for an interrupt. 😕 Existing asm libraries need to be updated or else the library header files will need to be updated with __sdcccall(0) for things to keep working. Update: I modified the header files, adding __sdcccall(0) to functions with parameters and/or return values, and that fixed everything. Aside from the function call optimization, 4.2.0 does appear to generate slightly better assembly code.
  7. Well there is a sort of pattern to the levels, increasing numbers of robots, increasing numbers of electrodes, increasing numbers of hulks, etc. and then a brain wave every X waves and a tank wave every Y waves, so I can put wave initialization into a loop with some incrementing counters. Meanwhile the enemies will get a little faster over time, will shoot more often, etc. Unfortunately there are limits to how many enemies I can throw at the player. I'm just squeaking by under 1K, I've used all 32 sprites, and I'm just beating the screen refresh when I have all the knobs turned up to 11. I've been using the Atari 5200 version of Robotron for comparison of what I should be able to achieve though the 5200 has more RAM and some helpful BIOS routines I don't have. However the 5200 version has very low-rate low-res animation which is how they managed to squeeze the game onto the console. I don't want to sacrifice any of the visuals.
  8. What you're seeing is entirely written in C using a library but that being said, for this project I've paid close attention to the generated assembly file to get the best performance. I'm going to be writing a separate post about all the performance related tricks and pitfalls I've learned with this project. A seemingly benign change can save you or cost you hundreds or even thousands of clock cycles and if my math is correct, you only get roughly 59000. If you already know C well then that's a very good start. Next you'll want to learn how the SDCC compiler wants you to write C code, and that's what I'll be covering. All my games have the same core engine that I wrote which was designed to make animation simple and it's why I can crack out a game in a couple months because I only have to focus on the unique aspects of the particular game. The main challenge for Robotron, other than scalability, was integrating character based "sprites" with regular sprites because there's the extra code for rendering the characters and there's twice the collision detection code plus the scaling 255x191 to 32x23 and vice versa is a pain because of all the inaccuracy it introduces. If I could have written it using only sprites it would have been done in a month, but there would have been so much sprite flicker that it would cause seizures.
  9. Here's a progress update on Robotron 2084. The video capture program I used seems a little off so the action looks a little faster than it actually is, so just tweak the playback speed. I managed to get 18 enemies, 6 humans, 4 enemy shots, a spheriod, 4 player shots, and the player all moving around the playfield at the same time with a good animation rate and just under 1K. The last bit that needs work is quarks spawning the tanks, scoring, and sound and then it's bug fixing and polishing. In my battle with beating the refresh I've learned a lot about generating optimal assembler and I'm going to share my findings in a separate post. Robotron 2084 Demo
  10. For those who would like a check out a very early preview of the game, here's the link: Robotron 2084 ROM It's still in the very early stages so people don't need to point out what's wonky or doesn't behave exactly like the arcade version. The brain's shot sprite hasn't been animated yet so it's using the tank's shot sprite and the brain doesn't reprogram the humans yet. I had to take some time to compress the structures being used for enemies and tweak the accompanying code because the goal is to get as many enemies on the screen as possible without blowing my 1024 bytes. The true challenge of the game is there are so many specific behaviors for different enemies and that grows structures and grows code. I'm also going to have to tune the hell out of the code to keep 20+ enemies and their shotsplus a half dozen humans updated. Asteroids was a piece of cake by comparison: a bunch of rocks moving in straight lines, a ship, a UFO, and some shots.
  11. Here's a demo capture of my latest project, one of my favorite games from the 1980's, Robotron 2084. I've wanted to port this one for a while but was a little stumped on how to support the amount of on-screen characters and the dual-stick nature of the game. It supports a single-controller mode using either the keypad to shoot in the 8 directions or the buttons to shoot in the direction the player is facing. It also supports dual-stick mode which is great if you have a roller-controller expansion module or if you create some kind of side-by-side mount for your controllers. As for managing the characters, the grunts and the humans are obviously characters rather than sprites so the flicker should be relatively manageable. Robotron 2084 demo robodemo.avi
  12. Just in time for the holidays, something new to play. This game was inspired by a game from 1980 called Space Zap with a touch of Star Castle thrown in to the mix and a hint of Asteroids to finish it off. Like my Asteroids port it's meant to be vector-ish and I was going for an early 80's retro look and feel. Left and right stick rotate your cannon around the base, the left button fires plasma bursts and the right button slows down the rotation for more accurate aiming. The space station's shields auto-regenerate over time but in an emergency you can give them a boost with any key on the pad, other than pause. The demo lets you play the first round of the game. https://www.dropbox.com/s/vo0jg2ezqlkgfbz/DeepSpaceSwarm.rom?dl=1 https://youtu.be/LdeXp_ZQNfw
  13. A tip for anyone else who ran into trouble launching the app after a Windows update: I found that changing the shortcut's Run property to Maximized solved the issue. Maybe something about my particular Windows configuration caused the app window to come up with a 0 by 0 window size, who knows.
  14. Yeah, I'm still around, and I haven't stopped coding, things are just slower now that the good weather is here and I'm allowed to have a night-life again. I was finishing up Infiltrator when I got inspired to write a circus based game because I wanted to code something that has a lot of physics. I always liked games that had interaction with the environment like elevators, springboards, vines to swing on, etc. and a circus game has a lot of opportunities, with the trapeze, trampolines, high dive tanks, cannons, ladders, etc. The game has all those playfield elements and your character is a clown who's goal is to grab balloons that are floating upward and returning them to the kids that lost them. Meanwhile other clowns are impeding your progress by throwing pies and juggling pins at you or just getting in your way while you're climbing ladders, walking the high-wire, swinging on trapeze, etc. So it's kind of like Popeye but upside down and the player can utilize shortcuts like diving into the high dive tank, being fired out of cannon, etc.
  15. Thanks, I'm glad you like it. Pressing both fire buttons together should launch the missile from the center base.
  • Create New...