Mord

So after a weekend of mucking with code, and making the obvious typo errors as usual I managed to hammer out a status bar. It's functional if not exactly how I want it yet. For one, different color choices need to be made. Secondly, the code explicitedly write out each line (no loops) and that annoys me. I'm going to try to loop things up in version 0.008 as well as add a Mana bar to go under the HP bar already functioning. I also have an idea for altering the max-hp size for the bar as well. Right now it's just showing the absolute max-hp that will be allowed. PF2 will be used to alter that before I'm finished. The reasons for doing the status bar at this point: 1. The Status Bar doesn't change from room-type to room-type, and every room-type must include it. So add it now then work on room formats. 2. The kernel for the status bar uses an async playfield setup. This is my first attempt at it. Where it's self-contained and predictable it's good practice for when I add async room types. In the next version, I'm going to continue working on the Status Bar, add to it, clean it up, etc. After I know exactly how many scanlines it'll use, and can take that information into account for the roomtypes, I'll try to define an actual roomtype rather than using the Test Room in there now. As you can see from the screenshot and from the rom attached, The left hand of the bar has the HP bar, and it reads the current value of PlayerHP and represents that visually compared to HPMAX. The other side of the screen holds the currently equipped item. Right now it just has a test item graphic there to show what it does. Later on it's color will be loaded from rom and whatnot. That side needs the most work, from positioning of the item better (I don't do a Hmove for yet) and I'm wondering if I want to have it represented as a double-sized sprite or not. Something for me to experiment with if nothing else. The rom includes an AlteringPlayerHP demo function that automatically increases the PlayerHP from 0-HPMAX and back down to 0 repeatedly. It still alters player movement like Version 0.005/0.006 does.

The black plastic variation of the 4-switch 2600 I would presume. The vader I picked up at a yardsale never did work, although given the condition it was in when I actually got it, I wasn't too surprised. (Took a day to get the dirt out of it!) The Jr I had I got rid of since it had problems with sound and the colors were messed up. The only one I have that works is the Coleco Gemini, which is what I typically use. I also have a 7800 but I tend to keep that packed away.

Not that there's much different between this and version 0.005, it's about all I'm going to pretty it up at this point. All I did was remove a few things here and there that weren't needed and were just messing up the code unnecessarily. I figured it was pointless to go through the display code right now as I'm changing/modifying it with the next goal anyway, which I'm hoping to have done by sunday night. That next goal is going to be the status bar. This will obviously cause changes to the display kernel, which is why I'm leaving it as is for now. I plan on having several different display kernels written as this thing goes on, but one constant feature of them all will be the player's status bar which I'm going to place at the top of the screen. This way I can just clear collision latches as the status bar finishes up so that any collisions detected at the end of the frame will only be caused by the in-game portion of the screen. At first I was considering putting it at the bottom but then I realized I'd have to save collision latches before the statusbar began, which isn't very efficient. Attached is a zip containing the source code for version 0.006 as it stands now as well as a binary of it. Anyone who's seen version 0.005 in action won't notice any difference. Yeah, I know the code isn't super optimized, I also know some of the things I can do to cut down a few bytes of rom space here and there etc. I'll likely change things around as I work on the next version. Was planning on doing that sort of stuff this week but ended up sleeping half of it away.

Except 5 people would not have voted for dung or guano. I don't know about that. Some people don't like strawberries.

I remember the original Star Fire schedule, so don't expect this before late 2005. Make that 2007

There were three errors that evaded me all day while trying to find out why the collision detection was weirded out. All three ended up being found in BackUpPlayer. The first error was having a bcc where it wasn't needed - and in fact short-circuited the code for the Up/Down position restoring. When this was removed, sliding against the horizontal walls worked fine, but approaching them head-on continued to act like crazy glue. Once you touched it, game over. No more moving. However, as an extra effect, pressing against the vertical walls was now consistant with each other. Rather than just being sticky on one side and being sucked in part way with the other, now both sides were sticky. So there was still problems. Looking over everything again, it took a while to spot by looking at the code itself, but the next error was caused by the TempVariable not holding the value I thought it should have when I needed it again. Forgot I used it in the subroutine in between loading/storing. This of course was suppose to have a half-rol'ed instance of the JoystickReading. As a result it shortcircuited some more code which was causing the sticky walls. I fixed this for now by pha and pla'ing the value. Works for now at least rather than using another scratch variable. So when this was fixed, sliding against walls was now fully fixed! Yay me! Then I remembered the crazy glue case. To see what would happen, I ran into the nearest horizontal wall hoping for a proper collision. And the wall sucked me right through it and out the other side. I turned around and tried walking back the other way, and sure enough it again pulled me through until I exited the other side. So there was still a problem. And for the life of me I can't remember what the heck that little insignificant problem was. It was likely having a bcc where I needed a bcs. For some reason I keep confusing the flag settings on cmp and whatnot. So anyway. Code fixed. Attached is screenshot of version 0.005. I added the castle back, mostly but got rid of most of the surrounding walls. I wanted to make sure the playfield could test corners and the screen-limiting boundaries for the player. Just having a block of playfield in the center doesn't help with all those possible cases. Also, the player's movement gradually changes over time to demonstrate the fixed-point movement. I think for version 6 I'm just going to review the code I currently have written and do various optimizations, etc. I've seen several places in the code during this version that was either not really necessary (old Labels no longer used but kept via copy/pasting) and places where some code was just redundant more for the sake of clarity than anything else. This'll give me enough time to consider what the next milestone should be.

I've changed the way the player moves to make use of fixed-point math. In the rom right now I replaced the castle with a simple square in the middle so I could work on screen clipping with the new movement code. Took me a while to get that right, once again due to my confusing how cmp works with setting the carry flag. I seem to keep testing for the opposite case than what's called for. ^^; Also, another strange thing I had going was that movement got busted as soon as I swapped in the new code. If I moved directly down, it worked normally. If I moved to the right, I ended up moving diagonally down-right until I hit a wall where I'd get stuck. (The collision code is still using the old code, so it no longer works properly just yet. If I moved left or up however, I instantly got warped either off the screen or to the very top/left of the screen. I have to assume that's what happens in the left case, as the player would vanish under the playfield at the time. The problem with left/up was mainly with me not specifically setting all the movement variables. I didn't init the ones that should have been 0 figuring they should already be zero after going through the initialization code... There was also the flipped carry branch I was using with the screen clipping. After I corrected those things, those directions didn't cause too much of a problem. As for the diagonal movement, that was caused because in the original code, I was not using the accumulator for anything but holding the joystick reading as I rol'ed the bits out. Of course, the new code uses the accumulator heavily, and x and y in the math functions. So in the left/right cases, after rol'ing out a bit to test, I saved it to my scratch variable, TempVariable. Then when I would be ready to test the up/down half of the controller, I would reload it again. This fixed the diagonal problem. I worked on the diagonal problem first, so I can only assume if I worried about that last, then the up/left would have had a diagonal problem as well once it's reset-to-zero error was fixed... No rom to show this time. I'm going to start in on changing the collision code to work with the new setup first and post the final version of 0.005 when that's done.

Adding simple collision detection was easy. Test missile vs playfield/ball, back up the player if collision detected. Of course, that gives the predictable result of sticky walls. I wanted to be able to slide against the wall. Less frustrating that way. That wasn't quite as easy, and failed brilliantly... and comically... a couple times as I wondered why the heck touching upper walls acted like some sort of player trap that would drag their butts violently off the screen regardless of any hardcoded screen boundaries. Then I found my two problems. 1) A 0 indicates that a button is pressed. Not a 1. Changed the associated "and"s I used into "ora"s. That fixed up some of the sliding, but horizontal walls were still sticky. Took a little bit longer of looking at the code to notice my little tests counter wasn't being reset properly all the time. If the horizontal test succeeded (it's the first of two) then the counter wasn't brought back down to 0. As a result it wouldn't retest the horizontal movement again unless I tried moving against a vertical wall (Which did reset the counter properly) At any rate... 2) Added a clearing of the CollisionTests counter whenever we were looking at the joystick again for input. The only time it checks the joystick for input is if it didn't spot a collision with the playfield/ball, so obviously we should reset the variable. This way the next time a collision -is- detected, it will properly (and reliably) perform a horizontal test. Version 0.005 is about collision detection, which is technically done. But there are a few more things I want to fix up or clean up before I consider it "done". For one, collision testing like this causes the player to slow down while moving against the wall due to the lost frames of checking for movement in the X or Y direction. I want to speed that up. Moving further in the direction tests to make up for the lost frames should make it seem to the player that no speed is lost at all. However. I was planning on changing the simplistic movement code that's hardwired in there right now with something that works on fractional/fixed-point math. I might as well do that now while I'm working on this, or I'll just have to come back and muck with it again unnecessarily later. Attached is a binary of what's done so far for version 0.005. You'll notice the slowdown while sliding against the walls. Horizontal testing is done first, followed by the vertical test. This is why vertical sliding looks absolutely horrible compared to the horizontal. I'll have that fixed and the normal vertical movement put back to it's normal rate by the time I finish this version. Hopefully.

Thanks for the tips. I haven't added sprites into the kernal yet as I build this thing up little by little, but things like that have been on the corner of my mind for a while already. Looking at the other note about the playfield zones, I have a vague idea what you're talking about, but something's not clicking somewhere. Probably a good thing that I'm going to look at collision detection next for a bit so I can hopefully figure out exactly how nukey's technique works.

Adding the playfield was a nightmare. I had thought up ways of trying to impliment it but not only could I not get them to work at first - I also saw the glaring problem of excessive ram usage that really wasn't necessary. As a result, versions 0.002 and 0.003 are dead. I could have just named this as version 0.002 but given this version does reuse some of the code I wrote in both versions 0.002 and 0.003... The playfield has a similar, but greater, resolution as Atari's Adventure. Adventure divides the screen up into 7 zones. the middle 5 being twice as big as the top and bottom zones. Using some simple math on 192 scanlines for a visible picture, you see that it uses a 16/32/32/32/32/32/16 zone approach. This is ok, but since I'm planning on bankswitching this rom later on, I can afford to use up the extra rom to have equal sized zones. In this version, I drew the yellow castle as the playfield. It has nothing to do with the game idea I'm heading towards, but does show some of the possibilities. Additionally, I'm surprised I've still managed to keep in the background changing code so far. There was almost not enough time to do everything I wanted however so when I go ahead to adding a few more things it'll probably have to go, or get limited somehow. Two problems I had with this code - not updating things fast enough in instances where I had to update the player AND the playfield at the same time. I was just barely late in updating the Playfield registers. As a result it gave me an odd looking error in the form of "playfield bleeding" onto the next line. Because I forgot that P1 is arranged differently than P0 and P2, it took me a while to figure out exactly what was going on. It was only affecting the left side however so I knew it had to be a timing issue. ^^;; To fix it, I moved some things with the background color around, pushing the update of the variable to after the playfield was updated (5 cycles freed) then moved the loading of the bgcolor variable just before the line's WSYNC instead of right after it. (3 cycles) There was also a case where the screen would roll whenever the player crossed over a zone boundary. (the top line of the player only) The problem was with how I had added the code to set PlayerSize into Y to determine how long to keep displaying the player before we turned it (the missiles) off again. dec LineCounter ldy PlayerSize bne .SomeLabelI'mForgettingTheNameOf ^^;; Basically that's what I did. I shoved the ldy right between a DEC that was trying to count down the lines remaining in the current zone, and the bne that was waiting to test for the Zero Flag that the dec would at one point set and signal a new zone. Because PlayerSize is always non-zero.... Anyway, moving it fixed the problem. My next goal is to play with the collision latches and to start in on the collision detection between the player (missiles) and the playfield. This should be a simple update compared to adding the playfield. X_X Oh, and while I'm now calling it "Action RPG", don't anyone get their hopes up for a finished rom any time soon. For attachments, I've included a screenshot of what version 0.004 looks like, as well as a zip containing screenshot, notes, rom, and source for version 0.001.

Heck, check out this version of the main page as well while you're at it. http://www.homestarrunner.com/main13.html

So the idea I had for adding the playfield is quite a bit more complicated than I originally thought. But then I'm also working on an actual usable system that'll be kept from version to version from this point on instead of a simplified test case. It does use up quite a bit of the ram, but then I'm writing this with the superchip in mind. Not going to use the extended bytes of ram until the rom itself gets more complicated at any rate. I'm more surprised that I'm still working on this. This is longer than I usually go before getting distracted. That's right. A week. I was planning on having version 0.002 finished for today, but I'm still ironing out how I want to approach it. I'm fairly sure how I want to impliment it at this point, just looking for ways to cut down on unnecessary complications. I'll post version 0.002 when I get it done at any rate, which I hope to get done this week. It's goal was for adding the playfield and collision detection, but depending on how long it takes me to complete the playfield aspect, I may just opt to add that for this version and work on collision detection for version 0.003.

I started coding on the 2600 again recently. I have this horrible habit of starting it, dabbling with it, getting carried away with some aspect of it, then losing interest and dropping everything for months and months. Thus when I get back to it again... I end up not knowing what the heck I was doing. So I start over. Usually with some totally different idea anyway. I have like 4-6 different game ideas in my head as a result, some more hammered out than others, for the most part with little idea if any of them are doable in their current design. Time will tell? Maybe. I pulled out the shell program yet again, and after releasing it on the forums, re-spotted the same error I keep forgetting to fix. For the shell itself, it doesn't matter, but if you want RAM or the TIA to retain any values past a frame you'll have to move the StartOfFrame label from where it is (next to the Reset label) to AFTER the init code. I always forget that. This version has it fixed, so I shouldn't have to worry about that again. Anyway, from the shell this time I decided to start simple and build up each version to an ultimate goal. This way each version, while changing in how the kernal is drawn obviously, ends up with some reusable code to carry on. The shell for instance started by having the init code (By Andrew Davies), groundwork for overlays (From the tutorials again, although also seen in other places like Stella ML etc) and the sprite horizontal positioning code. (This incarnation from the Atari Age forums, but again originally seen on Stella) From that, version 0.001 (I expect this to be a long process before I get to my goal ) added in a player similar to what was used in Avalon with the missile sprites overlapping one another. Took me a few tries to get the sprite priority thorugh my head. Then I added movement with a joystick reading routine. With that, I found Fun Things happened when the player tried to move off the screen. So I added boundary checking which caused a few problems in it's own right. Namely making sure I was checking the proper boundary values and getting the kernal to switch it's little zones fast enough to prevent color bleeding. The only way I noticed the bleeding was because I kept the horizontal colored bars. So it was an exercise (although unnecessary ultimately) in thinking efficiently to get rid of it. It was unnecessary only in that I was planning on scrapping the kernal display technique with the next version. But I figured if I couldn't fix that at this point, it'll just be more confusing later on when I start adding in new stuff. And so, Version 0.001 (player_demo.bin) looks identical to atari2600-shell.bin with the minor exception of the moveable player. Next up, I'm going to attempt to add the playfield and collision detection.

In that program there are no sprites. The shell program is just a framework to start a new project from without having to write out some fairly basic things from scratch. Generally when I start tinkering with an idea I'll open up this thing and start going from there, adding and modifying code as necessary.

Just something I put together that serves as a shell program whenever I start yet another attempt at fiddling with the 2600. Just added the sprite positioning code that I found recently so while the program compiles, I can only assume it works properly. Posting it in case anyone else finds it useful. It's been heavily commented. atari2600_shell.zip

If we're talking just this intro section here (Which would have little reason to be done if you ignore the majority of the game right ) then yeah it could probably be doable although if the shyguy was to be thrown down to the bottom screen then you'll already have flicker issues to deal with between the door/mario/shyguy - unless the door was to be taken out and left black with the background color.

Damn, at this point it almost feels like spam to repeat what everyone else has already said many times over. Atari Age store -> Still fiddling with the krocodile cart I got last winter as time permits.

Got an expansion port on mine. Now just need to get more games to play on it at some point to make it worth hooking up. (Space is limited. ) -- Mord

Atari 2600 stuff and the like are semi-rare to find around where I am. I haven't had the time to do much yardsaling although I rarely found anything worthwhile when I did. The weekly fleamarkets always seem to have one person who specializes in old game systems and the like, but the selections are rarely captivating. There was one that had a large supply but that person seems to have either stopped participating at the fleamarkets or has moved elsewhere. On the other hand, one day walking to the convenience store in the rain I almost stepped on a perfectly good Colecovision Q-bert cart.

Both, although writing my own being the bigger of the two. I'm horrible at getting distracted by other things then taking forever to get back on track, which is why I haven't mentioned anything I may or may not be working on. *grin* The reason is now upgraded to "I'll start working on them when I finish playing with my Krokodile Cart" -- Mord

Got mine as well. Won't have much time to play with it before the weekend unfortunately but I was nothing but impressed by the quality of the krokodile cart and Qb. One less reason for me to put off homebrewing now. -- Mord

If they agreed to it, and could get the boards necessary for it, I think having both versions on the same cart would be the best route to go. I know it'd jump a couple of notches in my own priority list of future purchases at least. Both are looking quite nice. It'd be a hard decision to make if I had to choose between getting one or the other. -- Mord

In my case, someone has to explain exactly how that holey dma thing works. I keep reading it and for some reason I keep missing something. Every explanation I've seen of it thus far has been been just as confusing to me. -- Mord

I can always count on this thread when I start getting worried about if my collection is getting to large. One glance and I'm cured! -- Mord

And thusly I wait for my krokodile cart all the more. -- Mord