JUST WHEN I THOUGHT I WAS DONE it turns out I'm not.
Anyway, I'll just reproduce what Al wrote to me and ask: anybody have any explanations or a fix?
If anybody has a Kroc cart or a CC and want to test Reindeer Runner for me? Manuel, I'm assuming that you have already, since you ran this on a real TV to test the PAL colors.This has me baffled; it is beyond my "expertise."The only weird thing that the game does is hit HMOVE at an odd time and, as mentioned in Eric B's weblo
NOW YOU CAN blow up the walls! Plus I fixed the maze generator so that it (should?) cycle through the 255 possible different mazes.
I forgot to mention this last time (until a late edit), but press RESET to cycle through the mazes.
NES VERSUS 5200, how does the hardware compare? This question is interesting to me, so I did some research this morning, refreshing my memory and digging a little deeper. I was going to post this in the (latest) thread on the subject in the 5200 forum but it had degenerated into name-calling
So, anyway, here's what I've got. Please let me know about any inaccuracies or errors!
I'm going to use the term "5200" to stand in for the the 5200 as well as the 400/800 line of computers, so I
SO IT'S BEEN A WHILE since I've been very active on AA; but in the last few weeks I have again started some fairly intensive 2600 development. I'm sorry to say, Nathan, that it isn't RPS - which is still on my slow-moving to-do list - but rather a project that I toyed with years ago: a semi-faithful port of Tank Battalion.
I'll try to find time to put up the in-progress ROM of what I've got so far along with some screenshots, plus other details. And I am having some difficulty with the gra
HERE'S what I've been working on, slowly, over the last few weeks. Well, besides the tile demos I've posted in the homebrew forum, which are mostly just a sideline - for now, anyway.
Both are very rough and likely will roll on a real TV.
NATHAN has probably given up all hope, but never fear! I am actually working on it, though veeeeeeeeerrrrrrrrrrrrryyyyyyyy slowly...
Most of what little I've done so far is simple stuff to help me understand the code better.
I did, however, get one of Nathan's new hand graphic sets in, and I cleaned up the scanline counts and some of the transitions where the screen would jitter or jump. And I changed the copyright date.
Lot's still to do:
; To do:
; fix scanlin
BEEN PRETTY BUSY WITH RL over the last week, but found a few hours here and there to work out the code to generate mazes programmatically:
To my surprise, I was able to get something working that actually doesn't look too bad. The algorithm is roughly based on the so-called "sidewinder" algorithm, though with some tweaks. To geek out about this for a minute, it is a pet peeve of mine that every maze-generation algorithm i've ever seen always works on the assumption
INITIALLY I WAS PRETTY disappointed with the goofy tech demo I wrote (see previous post). It was pretty tricky, and a fair amount of work, to get the kernel working. And in the end, it didn't look much better than if I had just multiplexed a single sprite!
But I kept playing around with it and I think it might be useful afterall. Maybe.
Here's a possible way...look at this demo. At first, a mild-mannered, kinda-weak-looking Demon Attack clone:
But you hit the fire button and then!
NOW THAT KOTAKU.COM has ruined redesigned their website, I'm looking for a different video game news/reviews/opinion site. Something reasonably intelligent, platform agnostic, and comprehensive. Where do you all go for video game news?
LATEST 'N' NOT-SO-GREATEST version of the Elevator Repairman knockoff:
The sprites is all screwed up because I rewrote part of the kernel and didn't have time to fix the variable setup routines. The kernel works fine; the variables just aren't being setup properly. But that's no big deal.
Oh yeah, I also took out a bunch of stuff (score, 48-char display, etc.) that was using RAM - I needed the RAM and I didn't want to waste time optimizing when the kernel is s
YOUR POWERS ARE WEAK!
Just thought I'd share some amusing pictures of Darth Vader as a kid:
Adjusting the fit...
Using the Dark Side of the Force to terrorize the house! Oh no!
This helmet plays various Darth Vader phrases and sound effects. Usually it's used by the older two, but recently Jo has had a fascination with it. Good times, good times.
ELEVATOR REPAIRMAN, now kinda playable. Also rethemed a bit:
Changes: I stopped trying to develop the 1K and 4K versions simultaneously and am now using a table to change the background color, rather than manipulating the line counter and plugging that into COLUBK. Also created a sprite. Also cleaned up the display a bit, tweaked the left/right boundaries.
The main changes, though: a) the score, b) the timer, and c) collisions. It's all very rough, but now all of
NOW WITH ENEMIES that move!
Not too exciting, really - they just change direction randomly when they hit an intersection. But it's something!
Also, your tank will now turn whichever way you press the joystick, even if a wall prevents you from moving.
Press RESET to start things off and to switch through the different mazes.
THOUGHT I'D REVISIT this topic again this year.
-I have two big 2600 projects that have been kicking around in my head for a while; I'd like to make some significant headway on one or the other this year. One is an RPG for the supercharger, the other is a 32K+ Street Fighter II-ish fighting game.
-I'd like to possibly do something for the A800. Though I might be satisfied just porting Squish 'Em to the 5200; I'm about halfway there already.
-Create a PAL60 version of Elevators Ami
NOW WITH shooting! Also a proper (though lame) maze, sort-of finalized kernel (and sort-of finalized tank graphics), and a glowing base to defend.
In answer to what I think was Thomas' question, right now the maze is hard-coded. If I can come up with a good algorithm for generating mazes, I'd really like to do that. If I can't come up with an algorithm that generates high quality mazes, I'll probably just create several by hand. It helps that the game will have walls
THINGS ARE MOVING ALONG, though my self-imposed deadlines are looming and looking more and more unrealistic the closer they get!
Unsurprisingly. I'll keep plugging away, though, and we'll see what happens.
-Scrolling now works, though the kernel isn't completely tightened up yet.
-Randomly generating girders, monster colors and positions.
-Player movement constrained. Now pressing up scrolls the screen, down does nothing.
WANT TO GET 'em all!
I am trying to pick which homebrews to pick up from the AA store...
Here's my long list:
Feet of Fury
Unfortunately, funds aren't unlimited. So I've got to narrow it down.
So, shorter list:
SO, FOR LACK of anything better to work on, I decided to see if I could actually get a kernel working for a VCS Metroid.
The answer is yes.
Right now it supports a partially asymmetric, striped playfield (PF1 & PF2), one non-flickered sprite, up to five (limited by RAM) intelliflickered sprites, M0 and M1.
I'm kind of amazed that I got it working, actually. Some of the missile writes come at non-optimal times (around repositioning scanlines) but not too bad.
SO IT'S been a while since I've posted anything...or coded anything.
But I was inspired by...well, by something I can't talk about. Um. Anyway, I revived an idea that I kicked around almost two years ago and banged something out:
I haven't tested it with an AtariVox myself - but Nathan did and it seems to work fine.
What does it do? It's a way to quickly play with your AtariVox using your 2600. Add/edit/adjust sounds and control codes and then play 'em!
MANUEL got me thinking about a Wild Western port.
At first I thought it was too simple of a game to need the Supercharger, but I'm reconsidering.
Using strips of RAM to display sprites/particles would allow this kind of kernel:
sta ENABL ;+45
Assuming that Y ranges from 0 to 160, that would require about 800 bytes
AFTER MAKING BIG plans earlier this year I've done a whole lot of nothing so far.
Hmmm...strike that. Looking back through my blog, I've done more than I thought. Mostly I just haven't managed to produce a game.
I was going to use this blog entry as a data dump for everything I've half-assed over the last couple of months - and don't worry, I still will use it for that purpose! - but I think I will change gears and use it as a sort of retrospective of the year so far. Maybe help me
GTD STANDS FOR Goofy Tech Demo, by the way.
So I wasn't real satisfied with the way things looked yesterday; so I decided to give up using the sprites for the player's bullets, and use the missiles instead. This means no crazy weird shapes/colors for bullets, plus it also means no background starfield.
But, you can actually see your bullets, which I think is a little bit more important. Plus I figure I can use sprites for special weapons that move slower and might be easier to see.
BASED ON SOME COMMENTS I have received, especially in response to Reindeer Rescue, I thought I'd attach some of the stuff I use to help with 2600 tunes.
First off, gotta give big props to my brother. He created these worksheets and has helped with almost all of the 2600 music I've done. Except for Reindeer Rescue, curiously.
Tommy made this worksheet for me; based on P Slocum's music guide and E Stolberg's music chart. I find this much easier to use, plus it really shows what you ha
Dug up old PMs from Nathan and saw that he had made a title screen graphic for it already, so I added that in:
This required expanding the ROM to 8K, so that's the other thing I did - which was a giant pain, as it always is. In the process I screwed up all the scanline counts, but I think all the graphics are stable.