I'm really not sure what I'll use this blog for so I should probably leave this blank, but that would require backspacing. Much easier to just hit a period and stop typing.
I mentioned what had happened with version 0.009 prior to my scrapping the code and starting to work on the Real Deal. Due to running out of cycles the WSYNC in the player-draw lines were generating 2 lines instead of 1 since it would overrun the normal wait point then sit and wait for a full line. This generated an interesting, if shakey and in the end unusable, magnifying effect. You'll notice the glitch in the status bar as well - that part confused the heck out of me as I don't think I d
Thanks to vdub_bobby I fixed the ball routine so that it no longer pokes over the top - and it doesn't wait until when a sprite is suppose to start drawing before working. To keep timing in the HBLANK however I had to modify the way the player appears. Instead of being a pure strip we now have a dual-colored box! The colors naturally changing based on the colors of the sprites currently on the screen.
Doing this caused an unnoticed semantic bug to stare me in the face.
Notice t
Still ironing out bugs but it's starting to take shape somewhat. Sorta.
This is what happens when you forget to actually copy your new display code into the source.
So I copy it over again and fix the remaining label bugs and the like and I get:
I didn't alter my Playfield data for the double-scanline kernel. As a result, stretched vertically.
When in and changed all "F" sized zones to "8" sized zones. to fix the stretch. Edited colors and made sure the BGCOLOR
Final "release" of version 0.009. It does everything I set out to do for this version.
*> Displays 2 sprites on the screen.
*> Playfield is striped instead of solid.
*> Ball functions as an extension of the playfield in the form of a positional vertical bar.
*> Player is a little more "refined" - more out of timing necessity than on purpose, but still.
With respect to the display routine, there's a few things I still need to examine to make sure they're working pro
Beta 2. Second mini-goal done. Added in the second bar as planned, and set it so that the item-equipped displays properly. Also took a few seconds to replace the horrible looking sword with a horrible looking chalice.
I've pondered the idea of minor animations (2-4 frames) for the items, although where they're single color I don't know if that's really worth it. I am pondering allowing the item's color to change each scanline if I find I have time for it. That'll probably be a touch up
I guess I'm feeling better-ish, although still not top of the world. I decided to do this a bit more gradually instead of doing it all at once and assembling. The beta attached looks identical to earlier versions, and it isn't the finished version for 0.008, but it shows the corrected off-by-one error I mentioned earlier and the code generating the scanlines for the P bar is about 1/11th the size of version 0.007. I managed to loop it up with just a few bytes added to one sample line and m
I decided the final Status Bar scanline size will be 20. The top 16 basically handle the useful info, but I'm keeping a few lines reserved for repositioning the sprites used in the status bar to be used in the gamescreen itself. Obviously that's going to be needed.
As such, the final version 0.008 looks slightly different from beta 2. I'd love to finish the status bar completely but until I master a hmove 73 routine it just isn't going to be. I have a potential alternative to it if it be
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 chang
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. Howeve
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 w
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 o
I'm going to have to admit defeat on attempting to unlink the SP bar from the HP bar for now. There's a lot more to consider than I originally realized about needing the cycle73 routine. Especially when I use a regular hmove routine at the same time at other parts of the screen. (For the player which can be positioned during vertical blank.)
Essentially, since the movement registers don't change unless we reset them to the value 0000 with the hmclr register, or unless we alter them indivi
Procrastinating on the rom again. Punishment for this is near but for now I show one of the potential incarnations of the Ice Kingdom that I had mentioned I drew up a couple years ago. When I get around to actually designing the area it'll probably look quite different. (After all, the capabilities of the engine are far more than what the concept assumed when it was created!)
As you can see from the map, there appear to be 2 different entrances. One on the far side of the maze, and one ne
Now at Version 0.009 Beta 2. Beta 1 I'll release a bit later when I have more time (Going to bed!) this is just a screen shot of what the new display kernal is capable of. I'm surprised I got it working to this point from the initial stab at it this morning, there wasn't recognizable object displayed at first besides the status bar!
There's still a problem with the bottom of the screen's boundary clipping. I can have the player touch and press against it, and it won't cause a problem, but
One of the things I've been wrestling with as I write the basic engines for Action RPG is exactly how the player will be able to move about and interact in the game. As I make more and more progress it's getting harder to put off these decisions! So on the way to work yesterday I started writing down more notes and thought them over.
I intend on the player having access to a limited inventory screen to store various usable items, this may include some types of keys.
Of those items, o
Below is a map I had designed for a forest kingdom in Action RPG back in... I think it was 2005. It was well before I started on the current codebase which is why it doesn't even reflect the ability for alternating playfield colors. (I made a few attempts at starting this game in the past, but always got seriously distracted or had a harddrive failure, etc. )
I'm likely going to modify it before I ever get around to adding it to the actual rom, perhaps even start from scratch, so a looksee
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 n
So I had all day to procrastinate on the display. I mean to work on the display.
Admittedly, for code I didn't get much done. I ended up reverting the main source code back to beta2 in preparation for the next display kernel attempt. Then I cleaned up the variables some and reorganized them a bit to make them a little easier to find (for me at least.) Then I sat down and thought about all the things I want the display to be able to handle in a single frame.
1. Ball display.
2. Sp
On an earlier version I was describing some of the bugs that I ran up against but ended up forgetting what I did to fix some of them. This time I wrote them down!
After I put in the initial code for the new Display kernel, and fixed the common typo-syntax errors (you'd be surprised how important "#" can be.) the displayed screen was... unrecognizable. The player was back as a pillar (wasn't turning itself off) and I had a display consisting of the status bar (lookin' normal) with just mult
Bankswitching implimented, correctly this time. It does a little jumping around for the second-portion of the Variable init. I noticed there's an issue with the sprites displaying properly however (actual sprites 0 and 1, the robots) They work fine if they're set to either even or odd but show the wrong (but predictable and I know where) data if it's the opposite. This is caused by the double-scanline approach I took and interweaving of the sprites for space. I had thought I applied a fix to