Skip to main content

Posts

Showing posts from 2016

Title Screen

What I really need is a title screen.  I don't have tons of graphics rom space left (this game is using the most simple, primitive cartridge setup, with very minimal graphics space), but I'm sure I can come up with something better looking than this.  I just don't have much inspiration, or confidence that I can make something that looks cool, given the limitations I have.



That being said, it's close to being done!   My todo list is down to only minor things: adding a scoreboard between rounds, adding additional music (the single song is going to get pretty annoying!), improving title screen and player-select screen UI, etc.

Oh, and testing, tweaking, and testing, testing, testing.

Testing the fun

Well, it's been about a month since my last post. I haven't said much.  Partially because I haven't done much.  Another consulting gig has kept me busy.  But also what I have been doing is mostly uneventful things that I haven't felt like talking about.

Getting a per-round splash screen working, getting different graphics and palettes for different rounds, etc.

But I did decide it's far enough along to actually start play-testing the fun.  Before I get much further, I need to know if I'm remotely on the right track.  First I got a coworker to play a 2 player match with me just to see if it seemed playable.  Despite some bugs, that worked out ok.

Tonight I made my family play with me.  My son (8) loved it. My daughter and wife put up with it.  That was a better test.  We found a few bugs and confusing things, but it seemed like there might possibly be some fun involved.  (Although the girls didn't exactly play competitively) I still need to get a few people …

Making the game fun

The real trick for Spacey McRacey (as I'm calling it now) is going to be making it fun.  And that's what I'm rather unsure about at this point.

I have a game design that basically works. The technical issues are mostly sorted out, I just need to get a few more implemented before I can seriously play test it.

But fun? It's hard to know if it's actually going to be any fun to play.  With a 4-player party-style game, it's seems like it might be hard to hit that fine line where everyone is close and competing, where everything feels exciting and tense, as opposed to tedious and boring.  And despite envisioning my game as fun, it might just be boring to play.

Some of that comes down to tweaking it. Tweaking the speeds, difficulties, etc, will make a difference. (If it's too easy to shoot people from behind, then it will be nearly impossible to hold a lead for very long, which could ruin it and make it no fun. If it's too hard to kill the guy in front, it wil…

Killer Queen

So at PRGE, I played an arcade game that just left me amazed.  Killer Queen.

It's a 10-player game. You have 2 cabinets linked together, and 5 players huddled on each one. Each one is a team of 5 people, working together to play a simple one-screen 2d platformer.  But what made it work was the high quality game design.

First, the game is relatively simple, yet there is a lot going on at once.  One player plays the queen, the most important and powerful character on the team. The others start as workers, but can become warriors who can fly around and attack in a very joust-like flappy contest of height.  The real trick is that there are three completely different ways to win: either collect a bunch of berries and bring them back to your base, or ride a REALLY SLOW snail across the screen (while other people try to kill you, and you hope your team protects you), or kill the enemy queen 3 times.  There's some other things going on as well (using berries to upgrade, capturing upgr…

PRGE

I couple weeks ago I had the chance to go out to the Portland Retro Games Expo, where Al from AtariAge had Anguna set up to demo.



What an amazing time. I could talk for a long time about how cool it was, but a few highlights:



Getting to see my game on display, and see people try it outMeeting people who had played previously Anguna and enjoyed itMeeting other homebrewers that I've interacted with on the forumsHearing from and talking to the developers of the old original Atari games, hearing about what it was like to make those games, and how they dealt with many of the exact same technical issues that I do now.  (At one talk, they started drawing out how the display kernels work, and talking about how you can use the RESP0 register to set up your kernel to reuse sprites on multiple scanlines....I'm not sure how many people in the crowd enjoyed that level of technical detail, but I had a blast)Playing Killer Queen, a ridiculously well-designed 10-player arcade game.  I'm go…

Titles

Thanks for the title suggestions everyone!

The 3 suggestions that I like the best were:

Pew Pew PewReginald McGillicutty's Big Boom Blast PartySpacey McRacey
After some thought, I decided:
Pew Pew Pew just isn't google-able enough. There's too many cultural references to "Pew Pew Pew" nowadays, which will make my game get buried even if people are looking for it. And alternative spellings (someone suggested Pew Pue Pu) are just too weird.
Reginald McGillicutty blah blah blah....I love this one from author Jeffrey Aaron Miller. What disqualifies it is really the format of the game required for the game competition I'm hoping to enter with this. The requirements of the game use a NES cartridge format that's quite limited in video ROM, which means I have to share space between the title screen and gameplay.  Which means I can't spend a ton on a giant fancy title screen. (Unless I'm misunderstanding the specs of the format, which is quite possible).  

Rapid Progress

I told my office-mate that if I ever finished that background mess, I'd start making much faster progress.  And it turned out to be true.

Earlier this week, I decided it was time to look at audio engines. I understand the concept of how audio engines work on the nes, but I just don't want to take the time to build one myself.  After trying out a couple of them, I found one that integrated really easily, and lets you play music imported from the popular famitracker format. After digging around, I found some interesting famitracker compositions under a Creative Commons license from a guy that goes by Ozzed.net. Turned out to be a really nice guy and was helpful in providing me info to get some of his music integrated into the game. So now I have background music!

The next steps were collision checking, explosions, and player bullets. No problems there!  Most of that is pretty simple stuff, or would be in C. In assembly, it's a little more error-prone and slower-going, but no…

PRGE, and I need a name

It's been awhile since I posted anything here!

First off, Anguna 2600 is pretty much done. I'm currently in the process of working on some promo material for the Portland Retro Game Expo, where we'll be showing off the game at the AtariAge booth.  I'm excited to be in a giant room full of people that are into retro-gaming, and have my game on display.  Should be a fun time.

I'm still slowly working on the nes game I talked about. I got hung up for awhile on displaying the barriers. I just kept running into bugs trying to get the game model to work right, then have it render properly based on the game model.  Part of it was scrolling -- the game has the appearance of scrolling through a world, but because the 6502 is only an 8-bit processor, I didn't feel like doing the math to track giant scroll values. So it's somewhat fake in terms of in-memory model.  The barriers move, the player stays motionless.  But because the nes background register is scrolling, …

Backgrounds and debugging

One of the hard things. Ok, so far the ONLY hard thing about NES development is how the background tile maps work.  In theory, they're pretty simple -- a big array of memory where you write a tile number, and the PPU (the video chip) draws that tile at that position.

But there's so many little gotchas:


The nes addresses 4 different screens' worth of data, but by default only has ram for 2 of them. So unless you provide more RAM on the cartridge, you set up (via actual wiring on the cartridge!) mirroring where data is duplicated between screens. The screen nicely pans and wraps between screens'-worth of background data. Except that there's only 240 tiles high, so you have to do math instead of letting bytes just wrap aroundSetting color palettes for tiles is painful -- you do it in a separate block of memory, mapped in a funky way where you map 4 tiles to 2 bits of a particular byte.  Which means you have to do odd math to work out how to change colors of backgrounds…

Atari vs NES

It's really interesting to me the differences and similarities between Atari and NES programming. They both use the same 6502 processor (well, a variation on the same processor -- the Atari's is missing a few address lines, and the NES is missing a BCD mode), clocked at similar speeds (the nes is about 50% faster).

But beyond that, things start to diverge.  The most interesting to me is fundamentally where things happen, based on how their video chips work.

On the Atari, the video chip (the TIA) is designed to handle a scanline at a time. Which means that, like I've mentioned before, the whole time your TV is drawing, you spend that time babysitting the process, using all your processing time updating each scanline.  Then during vblank (the time the TV is repositioning the electron beam), you get to hurry and do your game logic updates.

On the NES, it's practically the opposite. The video chip (the PPU) is designed to handle a whole frame at a time (GASP!).  So during…

NES Game and LiveCoding

Well, I started messing around with making a NES game. I'm not sure I'm ready to tackle another big project right now, and there's still bits of work to be done with Atari Anguna (mostly fixing bugs as they get reported, then getting it ready for production), so I'm doing a little project:  sort of a simple 4-player space race game.



The fun part is that I thought I'd try LiveCoding it, which is basically where you live stream yourself writing code and explaining it as you do.  I've tried this for the past 3 nights.  It's a really weird experience.

First, I don't know why anybody would want to watch someone code. I mean, at least watching someone stream video games is interesting because there's a lot of action. Coding is mostly thinking and typing.

Second, it's REALLY HARD.  Now I'm trying to do all my thinking out loud. Which is a really weird process.  Everything feels blurry and sluggish in my head. I feel like I'm not coding well, an…

Finished world map

Well, I'm still making a few tweaks (the most recent was based on feedback that the off-centered sword was annoying, so I made the sword centered by default, but let you use the difficulty switches to change it back to the old off-centered setting), but thought I'd share the final finished world map:


Beta Testing Time!

Ok, Anguna 2600 is ready for some testing!  I'm looking for testers to try playing the game (either in an emulator, or on an actual Atari with a Harmony cart or similar device), and let me know what bugs and issues you find!

The main features aren't likely to change at this point, but I'm looking to fix any bugs and possibly tweak the game difficulty.

You can download the instruction manual and current build from this post on AtariAge.  Please email me (nathantolbert at gmail) or leave comments if you find any bugs or issues.  If you find any problems that I fix, I'll also credit you in the instruction manual if you'd like, if so, let me know how I should credit you.


Next steps:

My friend Tim Lapetino, author of the upcoming Art of Atari book, is designing art for the cartridge label (hopefully to be re-used on the manual as well).I'll be updating the game and manual to fix any issues found during the beta testHopefully later this fall, if all goes well, everyth…

First full playthrough finished!

When I get near the end of a video game release, I have this phase. Where I play through the game, fix all the bugs I found, play through it again, fix all the bugs I found, play through it again....and so on....until I finally play through and don't find any new bugs.  (I've done this before)

It's somewhat miserable. But here we go again.

I finished the first full-playthrough tonight. Fixed a ton of bugs. Tomorrow I need to do another full playthrough, and then attempt a full playthrough on the actual Atari (which I'm not sure if I'll pull off, because my Atari controller is in poor enough shape that it will be really painful to go through the whole game!)

For anyone that wants to try the always-newest build and help me test, you can grab it from my jenkins server, which I'll be happy to email you the address to.....


Tons O Bugs

Well, my friend Daniel (AmishHack3r on Twitch) decided to give my game a try. And let me tell you folks, this guy is an amazing tester.

He found ALL SORTS of bugs for me. And diligently recorded video of each one, made drawings on a map of areas with glitches, and so on.  I couldn't ask for a better tester, thanks Daniel!

That being said, I have a lot to fix!

Getting close to done

I've been quiet here, because at any given point, playing Overwatch has sounded more fun than blogging about my game.

That being said, I've finished a preliminary "first draft" of the game, and on my first quarter of a playthrough, I've discovered quite a handful of little bugs. Mostly minor things (a couple screens where enemies glitch out, the reset switch not working exactly right, etc), but a few might take a little bit of work.

After this playthrough and testing round, then I get to play through it AGAIN, fixing any bugs along the way. When that's done, it's time for a sort of beta test, and hand it out to anyone willing to test it.  Once I get the bugs fixed that others discover, it's time to call it good!

Updated Map (Spoiler alert)

I've been chugging along filling out content, and getting really close to being finished!

Tonight I added a bunch more rooms, then realized that I really need a few more room layouts for variety. With some playing around, I was able to create 3 new room layouts using the existing graphic chunks, only rearranged slightly. So each of these layouts only requires 4 bytes of rom space each, instead of the 75 that I'd normally need!  I haven't added them in yet, I'll need to go back and replace some other rooms.

Until then, here's the current map! Just a few white spaces left to fill in!


Overworld finished!

As the title says, I finished the overworld tonight. 45 out of 196 rooms left to go (dungeons 4 and 5).

I don't have an updated map to show yet (I updated the engine by 1 scanline, so my new screenshots don't exactly match the old, I need to update my script that crops and adjusts them before I can get the new rooms on the graphical map).

I'm at the point now though, where every bug that gets fixed requires searching through old code to find places I can optimize a few bytes away. Fun times.

Optimizing space, adding a switch.

Thanks to the nice folks at AtariAge, I got some feedback, mostly about various bugs, which have been cleaned up.  Now I'm trying to power through and add the rest of the content. Which is tricky, because I just don't have that much space left.

The biggest area of concern right now is enemies.  My space left in the bank where I store enemy data is small. Just a couple hundred bytes.  And I needed to add definitions for at LEAST 3 more enemies (bosses for the next 3 dungeons). And hopefully, another 3 or so more general enemies, so the 2nd half of the game isn't completely boring.

The first order of business was to read through the existing enemy definition code, and start optimizing. The first few enemy functions were unnecessarily huge. The amount of code for the slime and toady were just silly. I managed to compact it all a little bit, and squeezed in the 3 boss monsters.

Without much space left, the next 2 enemies were just palette/graphic swaps with more HP/Damage of …

Looking for feedback

I've posted a build of Anguna on AtariAge, with most of the code of the game finished, and about 1/2 the world done.  At this point, I'm looking for people to try it and give feedback. Does it work? Is it fun?  Are there major issues with it?


If you have time and an Atari emulator, let me know what you think. Thanks!

Prepping for 1/2-finished demo

As far as I can think of, I've finished all of the major features of the game now, so mostly what's left is mapping out new rooms, and making new enemies.  I've finished the entire eastern-half of the world map (including dungeons 1 and 2), and so my next goal is to get it all cleaned up, and post another demo on AtariAge to try to get feedback from the fellow Atari nerds.

This week I've been trying to clean up the most obvious bugs, so I can then go back and do some actual play-through tests myself. (I've played through the first dungeon a number of times, but haven't yet played through all the content that I have in sequence -- I just change the starting room to whatever room I'm currently working on).

Things on my radar this week for fixing:

When you die, it should automatically select "continue" instead of "start" on the title, so you don't inadvertently start over.Right now, the mechanism for restarting in whatever respawn locati…

Deadly Towers

After talking about Deadly Towers a couple weeks ago, I decided to try that game again. Like Super Pitfall, I've always been intrigued by this game. It was no fun to play, simply painful. But I always felt a sense of mystery and adventure from the large sprawling world that seemed to be hiding behind the misery of actual gameplay.

So using my trusty emulator on my phone, complete with save-state cheating, I decided I needed to play through the game to see if the game-behind-the-game was any good.

Unlike Super Pitfall, this game wasn't 100% horrible once you understood it. It was just mostly horrible.

Anyone who's played the game knows how frustratingly hard it is. There's usually tons of enemies on the screen at once, and one or two hits will either kill you or knock you back off a cliff where you die. To make it worse, there are invisible warps all over the place that take you to these vast dungeons filled with tons of featureless rooms (each dungeon is a 16x16 maze o…

Experience!

Thanks for the comments, all.

Sounds like my everyone likes the idea of leaving in the XP/levels. Like Rob said, I'll have to play with the tuning, I definitely don't want grinding to be necessary.

Right now, the only random drops are meat (hp restore) and arrows (once you have the bow, the way to get more arrows is by picking up drops).  The idea of randomly dropping significant powerups sounds really tempting, but I'm not sure that it will work nicely into the system of persistent state that I've built so far. I'll have to think about it.

Right now, the direction I'll plan on going with it is that max HP is determined by your level and experience, and attack/defense is determined by which pre-set powerups you've found. But you never know, I may end up changing it after all.


Experience?

Ok, I need feedback from all 2 of you people that read this.

In GBA Anguna, you were motivated to fight enemies as you explored the overworld, because they dropped money, and you needed money.

In Atari Anguna, there's no money. I just don't have the ROM space for shops. I'm toying with the idea of replacing it with experience/level-ups. You get enough experience, your max HP goes up a level.

The advantage is that it motivates you to fight your way through the overworld instead of just running past everything.

The disadvantage is that it encourages/allows grinding, which I hate.

Opinions?

Is it fun?

This week I ran into the same introspective question that I hit multiple times with Robo-Ninja: Is this game going to be any fun?

It's just really hard to tell, as the developer. I'm way too closely attached to every minute detail to have any idea if this game is remotely fun to play.  I'm pretty sure that's what happened with Deadly Towers.  The only explanation I can come up with is that they didn't get outside input to tell them how bad their game was, and they were too close to see it.  I really don't want to make the next Deadly Towers.


Asymmetrical rooms

One of the weird quirks of the Atari is that, while there are some registers to control the playfield layout (so you don't have to "chase the beam" to draw the entire background/playfield), there's only enough registers for half the screen, so it repeats the same graphics on both halves of the screen. There's another register that lets you determine whether it should be mirrored or duplicated.

Some games get around this by updating that register in the middle of the screen (which I also do when I'm drawing the subscreen map), but with the other stuff I'm trying to display (multi-colored main character, multiple enemies, missiles, etc), I don't really have time to do that. (as a counter-point, see the game Super Cobra, where they manage to cram that all in along with updating the background, although they have some clever limitations on movement to simplify things very slightly)


ANYWAY, my solution in Anguna is just to force every screen to be symmetri…

Compact it, Compress it, Recycle, Make Less of it!

My mission this week was to compress things. To compact it. Make less of it.  I was running out of space, and I needed more.

First pass was to go through my code looking for macros that I could convert to proper subroutines. I found a couple, which freed up a little space, maybe a couple hundred bytes total.

Next pass was to do with enemies what I had previously done with room layouts:  In my room definitions, I had a pointer to the enemy type that would be in that room. Pointers in 6502 are 2 bytes. I have less than 256 enemies, so it made sense to, instead of storing a pointer in each room definition, just use an index.  It took a tiny bit more code, but quite a bit less total space. That saved another couple hundred bytes.

The biggest savings, though, was redoing my room layouts.  Because of how the atari playfield registers work, and 6502 indexing works, it's easiest to store 3 chunks of data for each room layout -- one for the outside edge, one for the middle of each half-scr…

Darkness, and running out of space

This weekend's work was to add dark rooms. (at least, dark until you have the lantern) Which has been tough. I've given it a ton of thought, and have never been completely happy with what I've come up with. But with a good bit of trial, error, and wasted code, I've got something that works:

Dark rooms are limited to a single enemy. What I do is a trick that dates back to the catacombs from Adventure: I use an enemy sprite (set to 4x width) in yellow as a glowy area around the player. Then I change the background and walls to the same color, but change the rendering priority flag to put the playfield (walls) on top, the sprites 2nd, then the background last. Which means that everything looks black unless the glowy light is there, which gets rendered underneath the walls, showing where the walls are.



Now because I have other enemies that I want to render as well, I have to have some flicker going, and render the light and the enemies in alternating frames. (I just don…

Password Entry

It's late. I'm tired.

But by golly, I got the password entry UI working. With 133 bytes to spare. WHEW.


Of course, it doesn't actually let you start the resumed game from here yet, so maybe that's what I'll do with those leftover bytes.....

Password

Tonight I started working on what happens when you die, and where you respawn, which ended up getting me excited about trying to make the password system work.  So tonight's project was building a reusable bit of code to both display the current password, as well as display the password UI while the user is entering a password.

I don't really have the UI part of it working yet, but after a couple of hours tonight, displaying the current password is working fine, including a checksum to keep people honest:



As I stare at it, I think the password logic might be a little too obvious, so I may end up obfuscating it just slightly by rearranging some of the graphics for the numbers/letters in the password. We'll see.

Subscreen Map

Well, I had originally said that I planned to wait and see how much space I had before making the subscreen map that I planned on.  But this past week, after working on the overworld, I realized that with my limited range of different screen layouts, the overworld was going to be a big boring place that's easy to get lost in.

What I really needed was a map.  With a map, at least the overworld becomes a big boring place that's not quite so easy to get lost in.


So I added the map on the subscreen. It took a bit of work to get the colors all lines up the right ways, using the different graphical objects available, but I think it's working now. The white dot tracks where you are on the world.


I did manage to get the kernel all working with my multiple colors, like I mentioned last time. I was even able to animate the water of the river, so the color moves down the screen, which is fun.



I think it's time to post some builds to the Atari homebrew forums to try to get some fe…

Squeezing and compacting

I've been plowing away at the game, adding some nicer graphics on the subscreen, fixing a bunch of minor issues, getting some bugs worked out with items, and starting on the overworld.

When I got to the overworld, I realized that my first couple screens were really boring.  Here is the hero standing outside of the cave that leads back to the first dungeon. I want to add some trees or something to the bottom half, but the way my engine works, each room only has 1 wall color.  I stared at this for awhile, but just wasn't happy with it.


Thus I started a new quest to squeeze yet one more thing into my display kernel. This seemed like crazy talk to me, as I already was having trouble getting all my timings right during the kernel. But Atari programming is all about crazy, so I stayed up WAY too late last night trying to find places to slightly tighten up the speed of my kernel code, so that I could squeeze in just a couple more instructions to update the color every few lines.

Turn…

Subscreen

Ok, I finally took the time to sit down and work on the subscreen, and it turned out to be pretty fun, actually.

For now, I omitted the password portion -- I want to include it, but because the total ROM space is going fast, I want to make sure I have the rest of the content first. So right now the subscreen looks a little weird, all bunched up at the top. I'll spread it out a bit if I decide not to do the password.  And I need to adjust a few things (key colors, horizontal alignment of the keys, etc)

I'm also alternatively considering adding some sort of low-resolution map to the bottom half instead. I have no idea how that might actually work, or if I have any possible way of actually doing it with the limited resources I have. But it sounds cool.

The picture above shows all 6 keys, 17 out of 17 HP, 0 attack and 0 armor (which shouldn't ever happen), 0 arrows, and all the special items (bow, dynamite, lantern, ring, and boots).

More with title screen

I've currently spent some time working on the inventory screen, which for some reason hasn't been easy to get excited about. It seems like a lot of hassle trying to get everything to nicely display.

The first part is getting the player's keys to display. Because you can tell the atari to triple each sprite, it's easy to get potentially 6 keys to line up on the screen. The trick is getting the timings exactly right to change the color appropriately for each key.  I'm pretty close at this point.

Unfortunately, my code to pick the colors based on the key type isn't quite right yet.

The next part will be to display numbers (or if that's too hard, bars) for health, attack power, armor level, number of arrows, and other items.

Then what I really want to do is also have a password system, similar to early NES games, where you can continue by entering a password.  But I'm not sure that I'm going to have ROM space -- showing the current password is pretty ea…

Working on hardware

Well, I bought a new RF adapter, soldered on a new controller jack, and bought a Harmony Cartridge.

With that in place, it only took about an hour to solve the problem:


Going through the process of starting with ridiculously simple sample code, testing on the Atari, and then slowly adding complexity until it broke, I finally narrowed it down to a relatively small subset of places that the problem could be.

It turns out that I was trying to do some fancy bank jumping acrobatics before properly zero'ing out everything.  Ok, boring explanation time:

When you turn on the Atari, the entire block of ram, and the state of the CPU registers, are completely unknown. So the first thing you should do is start zero'ing them out.

Now one of the things that's unknown is also what memory bank you're running in. Which means that although you know what memory address the program starts at, it could be in any bank. So one of the first things you need to do is, in the same place in every…

Ugh Ugh Ugh

Well, I've run into 2 big problems.

First, is that although I thought I had all the scanline jitter solved, it turns out that I had a few places where there was still jitter. And this has been really hard to track down.  After a few angry evenings staying up too late debugging, I finally realized that it wasn't actually my display kernel causing the problem (where I had spent the longest time debugging), but that occasionally I was taking too long in my main update code, and not rendering the screen in time.  So I need to do some combination of optimizing, removing code, or running updates every other frame.

The other problem is harder to deal with. I asked a friend if he could test with his Harmony Cart (an sd-card-based atari cartridge to run on a real Atari), and the game doesn't work. AT ALL. It won't do anything, not even display anything on the screen. So something's really wrong.  Unfortunately, I have no idea what.  At this point, I think the only thing I c…

Title screen

Thanks to the sample code of really smart people out there, I now have a working title screen!

The hardest part was similar to the last problems I talked about: cycle timings getting messed up while crossing a page boundary.

To get a nice large "hi-res" graphic on the atari, you have to take both sprite objects, tell the Atari to repeat them 3 times close together, and then stagger them.  (Imagine the 3 repeated planes on Combat, or the 3 players on Football. Then imagine 2 sets of those interleaved with each other) That gets you halfway there, but then you have to very exact timings to update the sprite's graphic data mid-scanline.  Because the Atari is so doggone slow, the timings are really tricky. (Although the technique eventually became fairly well-known -- any game with a 6-digit score display most likely used this technique).

I got the code all working thanks to that sample code I posted to above, but if I fiddled much with the graphics data, the timings would ge…

Crossing Page Boundaries

For awhile, everything was working perfectly in my 3-enemy display kernel on Atari Anguna. Then this weekend, I added some new graphics (for the crocky boss monster at the end of dungeon 1).

Suddenly, things stopped working right. Enemies started jumping around horizontally instead of smoothly moving. It looked choppy and horrible. And all I did was add some new graphics data.

HUH?

Well, the issue was probably pretty obvious to any veteran Atari programmers.

On the Atari, when you reuse a sprite with a new horizontal position, you often get the weird black lines that appear on the left of the screen. I wrote a post about it awhile back, how if you write to the re-positioning register on exactly the 74th clock cycle the scanline, you'd prevent the line. If you did it earlier, you'd get the line. If you did it later, it might not HMOVE at all.


Another important piece of the puzzle is the 6502's conditional branch opcodes. In general, they take 2 clock cycles if the jump was…

Making things!

A few random updates:

My Life in Space game is done, I think. The Jam ends in about 5 days. I'm doing some last testing, and then will submit it. If anyone has an Android phone and wants to test for me, holler. It's pretty small compared to some of the crazy stuff that other people are doing for the jam, but I'm just happy to have a finished project that I think is interesting.I'm finally about done with the crop insurance project, which means more time for hobby projects!I've actually started working on Atari Anguna again in earnest. I'll probably be talking a bit more about that, but I've done a bunch of work on cleaning up my half-finished door code, fixed a number of small timing issues with my kernel, and even got the Bow and Arrow item ALMOST working!I really liked having 2 projects at once with Robo-Ninja and Atari Anguna, so that means it's time to start thinking about my 2nd project.  Right now, the major options are either port Anguna to Androi…