AnalogKid
-
Content Count
37 -
Joined
-
Last visited
Posts posted by AnalogKid
-
-
-
10 hours ago, slydc said:Ahh.....buttox again! Seems i'm always late.....
updated link:
-
2
-
-
On 4/26/2021 at 8:11 AM, leolopes79 said:File deleted. Please update the link.
-
2
-
2
-
-
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.
-
Yep, flame-throwers really add something
-
6
-
-
14 hours ago, NIAD said:Who will be handling the production and distribution of your games?
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)
-
1
-
-
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.-
20
-
1
-
-
7 hours ago, Vectorman said:Atarisoft made Robotron for the TI-99/4a and it looks pretty good. If they can make it on the TI-99, why couldn't they do it on the CV? Same video chip, different CPU.
They used characters for all of the robots to avoid the sprite flickering but it looks like the characters jump 4 pixels at a time. I've thought about that solution but I was picturing creating all the one pixel shift tiles for 8 directions of motion for something like 9 sprites and said "maybe later"
-
On 12/29/2020 at 12:37 PM, youki said:would love to see a Starwar clone by You!
I'm really fan of your games!
I've given it some thought, it's on my long-term to-do list. I've also been mulling Rampage as a good port prospect though it's further down on my list of favorite games. At the moment I'm in the middle of something pretty ambitious so I'm going to be busy for probably another month on it.
-
1
-
-
On 12/24/2020 at 12:41 AM, LoTonah said:Love it! Although if you're looking for feedback I'd have to say the only thing its missing is the line that zips up from your bases to where the cursor is. I don't know why, but that was my favorite feature as a kid. I could understand why you wouldn't want it (another bunch of lines to calculate might slow things down, I don't know how much slack you have to play with here) but yeah, it would make your version one of the best for any home console.
Yeah it is the one glaring departure from the arcade version. Only bitmap mode allows you to plot points to construct lines and you loose some capabilities and resolution in doing so. The missile trails you are seeing are constructed from characters which means I had to do all kinds of craziness to keep the characters from interfering with each other. This is why the mirv splits aren't nearly as cool as they are in the arcade version.
-
18 hours ago, Pixelboy said:The "1" at the end of the link is left out of the address, but it seems to work with "=0".
Anyway, I just tried it and it plays pretty well. I like it.
Have you considered doing a CV version of Mine Storm? That's one Asteroids clone I'd like to see, even if it turns out a little different than the Vectrex version.
Just a thought.
Yeah there are a lot of things I'd like to do with the game engine but you know how it is, you get burned out with a game for a while and want to put it away and work on something very different for a bit. I want to make a version of the original Space War with player vs player action and I wanted to add something that brings gravity into the picture, so maybe a black hole in the middle and the occasional asteroid comes in from the side and gets pulled in while the players shoot at each other and leave space-mines for the other player to either shoot or run into. It would be cool if Asteroids itself had other phases that emphasized flight like one where there was a black hole in the middle and you had to negotiate the asteroids being pulled in and also a phase where you had to dock the ship or land it similar to Lunar Lander, but the purists want the game to match the arcade version as close as you can get it. So, maybe Astrostorm II, the asteroids strike back. I was also thinking of using the engine to make Armor Attack but the thought of coming up with all the images for jeeps, tanks, and helicopters in all the phases of rotation put me off of that for a while :c) Coming up with 32 angles for just the Asteroid's ship was a serious pain and that's just a triangle.
-
2 hours ago, zyzzle said:As I thought, especially because of the 4 sprites-per-scanline limit, I don't think a full clone of Robotron is even possible for CV. As for Black Widow, vector games also aren't possible with CV, or am I mistaken? If so, we'd have TEMPEST by now, surely.
Thanks again for your gifts, and your talent in programming is radiently apparent.
My Asteroids port is one example of a CV vector port, Star Castle, which is very impressive btw, is another. The Star Wars port, to be honest, could be better. They kind of skimped on the TIE fighter images and the animation on the second screen is really jerky. The main challenge to porting Tempest is the sheer number of images you'd need to produce to get the perspective. It's the same thing that's keeping me from porting Battlezone, which is something I'd love to port. Probably the main challenge of Black Widow, apart from the large number of images, is the unusually high number of unique character behaviors you'd have to duplicate.
-
-
I gave some thought to a full Robotron port but since it's a two-stick game, I'd have to use the keypad for firing which seems like it would be a little awkward. Also it would be pretty disappointing because of the 4 sprites per scanline limit. I'd have to add logic to keep enemies vertically separated which kind of limits their mobility, or I'd have to switch to using characters, which would be tedious as hell, animating 8 angles of motion across characters. If I thought I could do a good job of it, I would give it a try, because that's one of those iconic games that I love as well. I'd have a better shot with Black Widow because as with my port of Asteroids, you can get away with more than 4 sprites on a scanline with vector graphics since the interference is much less noticeable.
-
I've added the indestructible hulk robots
https://www.dropbox.com/s/hlpxy3gkhp57pt2/cyborwar.rom?dl=1-
4
-
-
Here's another one to add to your collections. It started out as a testbed for my player/enemies engine and morphed into a Berzerkish/Robotronish type of game. It's still a work in progress but there's enough there to have fun with and I wanted folks to have something new for Chistmas. The enemy logic was designed for open playfields so they get a little hung up on the walls still and I want to add the "hulk" robot from Robotron. The robots patrol the halls until you enter their scanner range and then they switch to pursue mode. They evade your shots which means you can also force them back with cover fire. It needs more sounds and the sprites could use some work and it could always use more screens, but by early 1980's standards it's not too bad

-
8
-
7
-
-
My apologies if you've already fixed this Tony, but it seems as though when saving a two color sprite, in some cases the RLE encoding is leaving off the terminator signature, 0xFF, which raises all kinds of merry hell when rle2vram is called 🙂 Other than that though, fantastic tool! Without it creating multi-color sprites is the definition of tedious and the animation tester is brilliant.
-
2 hours ago, Itchy Scratchy said:Personally, I would use the three top keyboard buttons to pick where to shoot from.
1 - 2 - 3
Which would also be great for custom controllers.
Then add Super action Controller support.
Other than that, some excellent work.
How simple it would have been to port these games back in the day and yet it only takes 30 years later.
That's a great idea, why not support both fire buttons and the keypad and let the player figure out which they like better. It would also open up support for people playing on emulators on mobile devices.
-
2
-
-
Here's release candidate 2. I fixed a bunch of bugs and glitching. I also made the asteroid splitting more like the arcade game, i.e. the smallest ones splinter off more wildly, requiring the player to be smarter and not fill the entire field with chaos.
https://www.dropbox.com/s/4bkjpg9zlbvpqy4/astrostorm.rom?dl=1-
1
-
-
Here's the beta demo for those that would like to try it out. It still needs a lot of polishing but it's pretty far along. The next step is to enable the roller controller. With the joystick you press both fire buttons together to fire from the center site.
https://www.dropbox.com/s/93zz25pte9vcjqc/missilecommand.rom?dl=1
-
5
-
-
1 hour ago, doubledown said:Without Roller Controller support, in "Roller" mode, any ColecoVision Missile Command-esque game, is quite simply another missed opportunity.
I completely agree. I still would like to add roller support to my Asteroids port as well. Roller support in the Star Wars port might have been pretty cool too. I'd love to port the original Atari Football, the table style coin-op game with two trackballs that has the X's and O's representation of the players. Writing the code to have the players act out the selected play would actually be pretty fun.
-
Oh yeah almost forgot, I did try testing with the roller controller, but after rebuilding with the lib4ksa versions, the game starts to run fine and then explodes into psychedelic madness, so I shelved that for the time being. It may have been related to another strange behavior I have noticed with the SDCC generated code that I have since addressed. If my structs that I use for my collections of screen objects have too many fields, then instability starts to appear. It's like the internal Z80 pointer arithmetic has trouble with too many instances of structs with too many fields. I would have suspected alignment played a part but it has happened for structs with field of only unsigned chars. Once I backed down the number of fields, the instability immediately disappeared.
I did successfully play around with enabling the steering wheel for a racing game I have in the wings as well. However it seemed like ColEmm's translation of mouse movement to the spinners was a little shaky so I'm not sure if it's my polling of the input or the values being provided for the input. My goal was to translate the paddle nature of the wheel to something more akin to actual steering where you'd have to recenter to stop the X motion plus I wanted more granular X motion. I got frustrated by the inconsistency from the values the emulator was giving me so that's on the shelf for now too. The joystick steering however does work nicely. -
I had a feeling I'd raise some eyebrows with the pixel by pixel line drawing 😁 I puzzled over this for a while and was almost convinced that Missile Command was impossible because I really really wanted to have totally independent missiles that could move at different paces at different angles and split off into MIRVs etc. So my solution, and there may be plenty of better ones, was to create characters for all 8 animation states per character cell, for several different angles. There's a lot of overlap between angles so it's not actually an insane number of characters. After 8 animation states, I shift down one on the Y and depending on the angle, adjust the X. Using that I created ten angles, though I may add two additional more vertical ones. So then how do the missiles seamlessly cross paths, well at certain intervals, depending on the angle, the Y increment and the X animation cycle line up so that a missile with an opposing angle can slide past. This means the logic to place the missiles initially has to be very precise rather than entirely random, which is a pain in the behind, believe me. Also, the placement logic can time the missile appearance just right so that one that would otherwise trample the path of another fails to do so because the first hits the ground and the track is erased.
I do like the other solution proposed, where you modify the character on the fly and potentially bit-or it with any other missile characters you cross paths with, but I'm pretty certain that's beyond my ability to get working correctly. 😁 There's also the missile track cleanup to account for where you would have to non-destructively xor the missile track being removed and I'm sure I'd never get that working.
Now next big pain is to handle the updating of the missile bases so you see them being exhausted of missiles, as the bases span multiple characters. Once that's done, then, on to tackling changing the color table data on the fly for the ground changing to green, red, etc. -
17 hours ago, Swami said:3. Maybe top the max speed 25% faster, since the relative playfield is smaller (in the arcade mode).
4. Regarding the small UFO, in the arcade version, it starts appearing after 10,000 points, alternating with the large UFO. After 40,000 points, only the small UFO appears. I don't know the exact point values, but I'm guessing from experience that every 10,000 points, the small saucer becomes more frequent: every third saucer after 10,000, every other saucer after 20,000, the last 2 out of three after 30,000 and the only saucer after 40,000. I've also read that after 40,000, the small saucer forces you to move or shoot quickly, because it shoots right at you if you are sitting still.
I don't mean to nit-pick, I just wanted to point out some arcade qualities since one of the options is "arcade" version. I encourage creativity and variation in the 8-bit console ports, in general - it keeps the sense of nostalgia better. It's also probably more fun to make it slightly less hard compared to the arcade version, so it's not such a "coin-gobbler".
I appreciate the input. I did try to find information about the game-specifics because yeah, I agree, it does matter for the game to feel like a true arcade-port. I didn't manage to find any specifics, people seemed more interested in pointing out the bugs in the game or describing the UFO hunting scheme to run up the score.

Demo of my next game for you Colecovision enthusiasts
in ColecoVision Programming
Posted
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