Jump to content

AnalogKid

New Members
  • Content Count

    54
  • Joined

  • Last visited

Everything posted by AnalogKid

  1. I concur that it's not an easy thing to pick up. It took me a while for it to really click that the control values are about attenuation so up is down, higher is "shorter", etc. and if you don't get the math right, a sound will taper off and then blast you with zero attenuation or will drop below the lowest frequency and cycle around to pitches that only your pets can hear. I keep a file of "happy accidents", cool sounds I found on the way to trying to make something completely different. It's full of splinks, sploinks, sproings, raspberries, and some things I'm sure I'll use later like a helicopter and a crackling fire. Now when I play games like Turbo, Zaxxon, or Frenzy I can recognize how they achieved more interesting non-musical sounds and I appreciate them all the more.
  2. I would agree with you. The latest version of SDCC is surprisingly efficient for the if/then/else logic, case statements, and basic math. Where it falls down is that it's a general purpose compiler and doesn't have game-oriented heuristics that efficiently deal with C structures which is of course what you'd typically use for game characters, but I certainly can't fault them for that. That's where you'll want to take its ASM output and replace C code with inline assembly that walks the structure members efficiently. This is also why the ordering of structure members is actually one of the most important optimizations you can make for both size and speed.
  3. 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.
  4. It's actually now ready for me to hand off the ROM image to beta testers
  5. A teaser demo ROM is available for download: Robotron Demo ROM
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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
  12. 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.
  13. 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
  14. 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
  15. 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.
  16. 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.
  17. Thanks, I'm glad you like it. Pressing both fire buttons together should launch the missile from the center base.
  18. Yes it is. I did some optimization and (hopefully) fixed the issue where the game could hang in the really high levels when the action is full-throttle
  19. After picking up the most recent Windows 10 update and the corresponding .Net updates, unfortunately the sprite editor stopped working on my PC. The app launches and I can see the icon in the taskbar with the focus highlight indicating it's active but there is no app window. I deinstalled and reinstalled the app with no change to the behavior, ran it as administrator, no dice. Is there any log I can look at or any other method of debugging I can employ? The Windows update affected a lot of things it shouldn't have (isn't that always the case) and I fear that, in my case, the sprite editor has been affected by some security fix or other patch.
  20. I've been approached by a few publishers and since this one is an original, not an unlicensed port, I am inclined to have it distributed. It's by no means up to professional standards yet, the work so far has mostly been to get the non-player characters moving intelligently and with minimal flicker and getting the code small as possible so I can jam as many rounds in as possible, so the playfield graphics are still quite rough and I haven't spent much effort on sounds. However, at the moment, I'm playing around with arming enemy soldiers with flame-throwers, to provide some variety. I'm also thinking of adding body-armor that the player can pick up and maybe having enemies drop ammo but keeping track of ammo and dropped ammo is going to eat up bytes so I don't know. I think flame-throwers are worth more to the game for the cost of the bytes :c)
  21. Here are some screen captures from a work in progress, Infiltrator My goal with this game was to make something with smart non-player entities that didn't just bounce about and require more than button-mashing. I wanted to make something that doesn't seem tile-ish so I made it so characters walk "in front" of trees, boulders, towers, walls, etc. and shots can travel "behind" them. I chose to make the sprites multi-color which compounded the challenges of flicker avoidance but hopefully you find the resulting character animation was worth the effort. I'm toying with the idea of making ammo not unlimited and requiring the player to pick up clips dropped by the enemies when they're shot.
×
×
  • Create New...