Mord

For the versions and examples I've used up until now, I haven't actually had much use of sprites at all beyond the status bar's item icon. The player simply makes use of the two missile sprites overlapping each other. The version I'm working on now introduces the ball and the actual player sprites for the first time. Balancing it all is what's driving me nuts taking me so long to work on it. I am using skipdraw in one form or another in version 9 for the actual sprites however.

A little faster than before indeed, although not too difficult. The bigger problem is there's no delay between when you get hit and it lets you try running to the side again. In my case, if I got hit by the first elevator, I wouldn't be able to stop pushing to the side fast enough and before I knew it I was missing 5 lives. I'd find it amusing if the maid fell off the screen similar to how mario would when he got hit in Mario Brothers. (It would certainly take care of the needed delay. )

It's proceeding although I find the thing I'm having the most trouble with right now is fitting the code that would organize when to start displaying the ball or player and keeping track of how many lines of playfield remaining into the kernel. I'm going to have to step back and try to organize my thoughts on paper and see where I can reclaim some cycles or find a more efficient way to do some things. I'll probably think of something.

I have bought every generation system from the VCS to the PS2 but NO MORE! I will not be buying one of the new generation systems. After all my consoles are all stored away in the garage except for the Big Two, Atari and NES. I only play those two and I cannot see that changing. WP I'll likely eventually buy the new consoles, but it'll happen in much the same way as the PS2/GC/Xbox generation did. It'll be in the later half of that 5yr span before I likely buy the consoles. I may purchase a game or two in preparation for them, but the consoles themselves definitely have to drop drastically in price first.

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 did much if anything to the status bar routines. At any rate, I thought I'd post the binary and a screenshot of it since I haven't been doing that lately. Not that it's a requirement or anything.

Looking at what I want the screen to be able to do, there is a problem with trying to update sprites. There's just no time left in the hblank. A sane person would just say "Ok, let's just pull out the playfield color update. All you need is that one extra command in there." But I don't wanna. So if you can't do the update in hblank. You'd have to do it during the visible screen. The obvious problems with this would be what if you try updating it when it's being displayed? Are you displaying the right line of graphics depending on if the sprite comes before or after the sta GRP0/GRP1? With P0 and P1 to consider, both which can be displayed anywhere on the screen, the potential headache increases. But then, these concerns -can- be determined prior to drawing the screen. So what do we need? A way to vary where on the screen we're going to do the update of the sprite so that we know it won't corrupt either P0 or P1. See what I mean about ugly code? Yeah all because I insist on trying to keep that silly sta COLUPF in there. I'll be mightily impressed with myself if I can pull this off. *update* I don't know what to think of this. In way of checking the timing, I tried cramming everything I could into the most complex scenario I could think of. (Playfield Color & Data Change, Player Turn On/Off, Sprite Graphic Update) and it -just- fit in a constant 76 cycles. But there's no real room to have multiple trigger points for the sprite drawing during the visible dislpay. While typing this however I thought up something else that might be useful to enable me to actually get hblank sprite updates. It comes with a tradeoff of having the player's look change slightly on scanlines where this condition occurs, but that's not really a Bad Thing. Getting too tired to attempt it right now tho, so going to leave a note in my code to pick up tomorrow.

I figgered if I managed to think up something like that, it'd have to be fairly obvious. Although the other things you mention I hadn't even considered. I was thinking timing shouldn't be a problem for using the halt line but I guess it depends on exactly what happens to Sally when it's halted. (Something I saw being discussed in the programming forum.) If Sally stops immediately, then timing should be fine for switching to Maria's bank, as Maria has to spend some cycles looking up the first DLL before it dives into the ROM (IIRC Maria's lists are required to be in system ram due to timing requirements, as well as all within a single (or was it 2?) banks. 512 bytes rings a bell but it's been a while since I read the maria.txt file I downloaded a few years back. If Sally continues until it's current instruction is finished, it might be a problem due to it potentially trying to read (or write if there's cartridge ram) to Maria's bank - as we'd assume the HALT line has already gone up/down. On the other hand, what if Sally was interrupted mid-instruction (As I believe they mentioned was the case) then when the halt line goes back down when Maria is finished, if Sally was just about to finish an instruction, would it still be in Maria's bank? Ideally this would be the case, and we'd just have to hope the rom can switch faster than Sally's cpu.

Just a random thought I had while procrastinating on the display half-asleep. (I will work on the kernel again this weekend darnit!!) The halt line controlled by Maria on the 7800 extends out to the cartridge. So what if that line was tied to the highest address line on a 17-address-line rom? Since the HALT line effectively identifies which CPU is in control, it would automate the task of changing between a rom that Sally saw (filled with data tables, sound info, and algorithms/routines) and a rom that Maria saw that was filled completely with graphics data. It would potentially be a headache to organize pointers to the graphics data, but I'm sure it'd be doable. With my limited skillz at hardware, that should work just fine... although it would become a lot trickier if you tried to bankswitch the split roms as well. Bankswitching itself could be easily done, but Maria and Sally would always change their banks to look at the same thing. (Well, more accurately, when Sally changes her bank, Maria's will be changed as well.) This could be a Bad Thing if Sally needed to change banks often for some reason (Maria could be trying to display the screen on different scanlines and be looking at different banks on different lines!) so ideally Sally's active bank should be independantly selectable from Maria's active bank, unless bankswitching is kept to a minimum (to limit excessive data/graphics duplication) or used intelligently. At which point having them tied would be fine. Ok time to sleep. I'll work on the display when I wake up. I've been reading over skipdraw and vdel for the last couple of days and I think I know how I can use them properly. Now it's just matter of trying to write it up, then spend a week debugging the monstrosity I'll end up with.

*cough* I'm glad I stumbled upon a thread that pointed to the mini-dig. While I've been there and poked around in the past now and then, I randomly checked Eckhard Stolberg's description of how VDEL works. That's saved me a few rewrite versions. But at the cost of needing to think about how this'll impact my upcoming display kernel. Hm. Might work out. Might be hell. In other "news". I think I've mentioned it before but odds are in the process of building up Action RPG's functionality, various aspects could be well suited for an independant game project here and there, often with some of the resulting code in the separate project finding it's way back into Action RPG, likely in some modified form. There are now 2.5 separate game ideas. The 0.5 is for a game idea that would start completely from scratch but would probably be well suited as a mini-game in Action RPG if space allowed. So the code porting would be one way only. I'm not clamping Action RPG to a 4k rom size so odds are if there's a free bank that the in-game bonus game could go in, it'll get added later on. While this game is the first to be started, it won't be the first to be finished! The other two game ideas require me to get this display working. One could be worked on as soon as the current display code is functional, and a modified form of it's logic code would be returned to Action RPG for inside one of the dungeons/castles/whatever. The other requires a scrolling room. (A later room-type to be designed.) Anyway. Too tired right now. Overtime at work this week. Good for wallet (needed for wallet!) but bad for code. Oh well, hopefully I'll wake up early enough today. I'm considering bringing some older games I'm not going to play again down to the local pawn shop for tradein credit. They have a couple games for the master system I'd like to have.

Aye, I'm more than aware that ugly code will have to be written at some point, and some point -soon-. Although I'm glad I randomly poke around the forums and stella in case I stumble upon things that'll help me in the days ahead. Which will bring me to my next blog entry.

Or so I'm letting myself believe. I'll find out later if that's true though. I've been thinking over the code needed for what I described in the last entry and I think I have a good idea what's needed. It just feels real ugly. I hate ugly code. This is why I'm thinking about it more than coding it. I want to make the code as simple as possible, yet as understandable as possible. (For me if nobody else. ) As a result serious attempts at the code are being put off little by little as I think about it. I just know if I rush this it's going to blow up in my face spectacularly. Heck, initial stabs at the player/playfield only kernels blew up spectacularly at first due to stupid semantic errors. While I was hoping to have a version of it at least written by the weekend it looks like there's a chance I won't even start a serious stab at the code until then.

I have neither the cash nor incentive to get any of the new consoles this year. These days I find I have no desire to pay top dollar for the buggiest version of a console just so I can play the least impressive (launch titles) titles that'll exist for it due to companies still learning how to tap the power of the consoles. If there's a game for the consoles I absolutely must play, then I'll probably buy the game itself, and stow it away til the console prices drop. Consoles are going to always be available for it during it's lifetime, and will become cheaper as time goes by. A game may become impossible to find however. If I pick any of the consoles up next year (or the next year after!) it'll probably be the Wii as I'd like to play Twilight Princess at some point. (With Twilight Princess being something I'll probably buy after christmas.)

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. Sprite display for P0 and P1. (Graphics and color change per scanline) 3. Playfield/Background color changing. 4. Player display via missiles. 5. Playfield updating. That's a mighty tall order. And one that's virtually impossible as I've been observing. Most of the impossibility comes from the playfield, and updating PF0/PF1 in time. I can vertically delay the ball and sprites so that I can update their graphics at the end of a scanline instead of rushing it in the hblank, but their colors still need to be set up in hblank I believe. As I check timings and whatnot, I made a few compromises as I knew I would. (The above was only a wish list after all. ) 1. Ball display, changed only on odd scanlines. 2. Sprite display for P0 and P1 (Graphics only. Color constant.) 3. Playfield color changing. (alternating colors) 4. Player display via missiles. 5. Playfield updating, checked only on even scanlines. This keeps playfield and ball code separate so they'll never conflict with one another. Changing the color of the items wasn't a high priority and in most cases I can see it not being too useful anyway. The playfield changing is fairly limited, a simple altering between two colors, or more accurately two shades of the same color. Just something to liven up the playfield a bit compared to the bgcolor. I was worried about being able to turn on the player in time when updating playfield color and the playfield itself, but I think I've thought up a solution that should work with a couple restrictions in place. From what I've written, it looks like it just might work but it's not ready for testing yet. And yeah, I'll be giving up the bgcolor changing. The way I was implimenting it was going to take up too much rom to store the data, and too much time on the scanline to load/alter. And for all that work it would still be too limited for the things I wanted to use it with. For this room display kernel tho, having it a single solid color will do fine. I plan on doing different rooms that should be able to have more detail here and there, or be able to display more monsters at once without flickering madly, etc. I'm still working on the code, and fairly early in it so no screenshots/binarys to share this time. (And I'm about to go to bed for the night as it is!) but hopefully I'll have something to show next weekend. The plan for version 0.009's demo is to display 2 objects with a mostly symetical playfield - the ball will be used to slightly alter one side to give the illusion of it being an asymetrical screen. I also plan on removing the hardwired player screen-clipping. (that keeps the player from moving off the screen.) and enabling the variable-based screen clipping. The variables have been declared for several versions now so might as well officially go in and replace those 4 constants with the variable names, and then init those variables. At this stage they'd just be inited with the same constants, but later on it'll be defined during room-loading. Yeah, I have ideas for how I'd use those changable clipping limits already. But for now, sleep.

Ahahaha. I suck goat eggs. I had a little bit of time to work on the rom today so I decided to try to fix the bgcolor so that it wouldn't start a scanline late at the very top of the game screen. (you'd notice the playfield drawn 1 line over what looked to be the menu still, but it was really the menu dipping into the game screen.) I've already fixed what's going on in the rom and moved on but thought I'd share the odd reaction to my code. And as I was unhappy with how the bgcolor was set in the last version (it works to a point, but it's not really what I wanted) I was adding to it and altering it and ... bam. Too much time wasted. That rom had a cool looking magnifying effect for the scanlines with the player as it was generating an extra line for every line of the player. Counted up the cycles and sure enough was going near or over 76. I was expecting that to happen with the code I was adding to it tho. doesn't mean I want to get rid of it just yet, but it does need to be re-examined to see how I want to use it. I'll figure in time for turning on/off the ball and updating sprites from rom tables to see how much time is left over after that.

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 multicolored lines for the playfield. Plus the movement clipping for the bottom of the screen was broken. That was expected since I increased the size of the status bar just before but didn't adjust the clipping range to match it. Anyway... from there I dove into the code and found the following fixes needed. 1. Forgot to set ScanLineCnt to PlayerY in Vertical Blank. (only inited it.) Screen started displaying random colors entire length instead of only a few lines. 2. Removed some old setup code at the end of StatusBar that mucked up what was needed in new code. Didn't notice much difference except in the colors displayed. 3. Forgot to change both instances/cases to turn off the player to #0. I had copied the code from the start-player lines. (I tend to find copy/pasting is causing almost as many problems as writing it all out by hand a second/third time would cause with typos.) Player was once again a proper square instead of a pillar. 4. Had to change: dex stx LinesRemaining to: lda PF0_Base,y and #%00001111 sta LinesRemaining Whenever we started a new zone. I mean really. COD HAMMIT. No need to decrement a lines remaining of 0 when it needs to be reset instead!! Playfield began displaying sorta, but the top row took a full 16 scanlines to display, I have 16 used for all the zones right now so that means I was doing something wrong! (Zones are one off? Damn 1-off errors I warned everyone about. ) Basically I was loading the counter for the first zone before entering the zone. Then having to wait those lines before the counter hit 0 to indicate it was time to update the playfield. roar. 5. 1-off error for the Ram copy of Playfield data. As a result, the bottom zone/row would grab data from the zone next PF over - from it's top-of-the-screen row. So we had the top of the castle's PF2 data in PF1's data on the bottom. Ick. Thing is, I need MaxZone to equal the one less value for the loops. So just fixed it for that declaration there. At this point I've gone from a garbage display to the playfield looking proper - but with the intended changing colors based on rom tables (I swear there are uses for it, even if it's cosmetic! ) not changing properly. the code didn't generate errors on assembly and it looks right at a newbie glance... wth is wrong?! Yeah, that's just a dramatic setup to bug 6. 6. 3 of 5 sections had THIS happening. (commented ora was not commented!) lda (ColorIndexLow),y and #%11110000 ;ora LinesRemaining sta BGColor After commenting, not much changed. It was just wasting time in there, and since LinesRemaining was always 0 at the time this code would execute, I guess it went as expected. A walk in the cold later, I came back to look at it again. I wondered about the addressing mode being used you see. Obviously if "lda (ColorIndexLow),y" was compiling, surely it was legal! And it was! 7. However, I was using "lda (LuminiousIndexLow),x" where the problem was. That doesn't exist. DASM however, ever so helpful, converted it to "lda (LuminiousIndexLow,x)" for me. Awww, how sweet. >_< (I found this out by checking the output.txt file) "lda (LuminiousIndexLow,x)" doesn't work the same way as what was intended, and was of course pulling in the wrong bytes. The change to correct that was hideous. It probably takes as much or more time than updating the playfield. ^^; To make sure it's done in time, I calculate the bgcolor a scanline in advance so I don't have to worry about it being done before the hblank finishes. As I said, bgcolor setting isn't critical to keep, but keeping it until the end is like a challenge in it's own. It forces me to think efficiently before I strictly need to, so if I run out of cycles and just can't squeeze anything else out... I have something I can remove. 8. Problem with too many lines generated when player was touching bottom of the screen. This was because there was no way for the player to quickly exit the screen display kernal and forced it to generate at least one extra line for the player-hide routine when it really isn't needed. I provided a short-circuit in the early half for when the playerY was supposedly touching the bottom of the screen. Fixed it almost up. Now the second last line doesn't always seem to work, but at least it doesn't fill the screen with garbage. This is one of those tempting bugs to leave alone, since in the real game the only time you'll hit that scanline is when you're moving out of the room. And it may be difficult to notice the line-jump that pops up on the second scanline that split second before you load up the next room. I'm going to look through and analyze the code I've written so far so I can predict exactly how it works. I should be able to happen across a fix for that in the process. But that'll have to wait for tonight at the earliest. I have to add more things to the room details as well like exits and ball placement. Since the missiles are used for the players, I'm using the ball to augment the playfield by adding a small degree of asyncness to it. I can have solid lines hiding secrets or acting as left/right exit blockers this way and it'll look a little more uniform imo. But I'll do that after I analyze the display code written.

At present it's more just to show I can I guess, although I can see instances where it can be used. With just a couple letters changed I can have that changed to playfield changing color for instance. I've also been finding it useful for finding timing problems. The debugger is also useful for finding those as well of course but I've been finding it faster just seeing the lagging color updates and from there diving into the code. All that needs to be added in to the kernal right now is setting the ball and updating sprites graphics/color. If I can get all those things in as it is with the background changing like that, I'd be mightily impressed. If I end up seeing there's absolutely no time for it however, the background changing would be the first thing to go/become restricted. What can I say? I'm still learning this stuff. I've had a good idea how the hardware works for years now, but I'm seeing more and more of the ... quirks as I go. I'm one of those that probably have to learn the hardway.

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 for some reason the scanline right above it is causing problems and making the screen roll. I'll have a full debugging list tomorrow morning before I continue. *edit* Shortly after posting this, I managed to stop the rolling. However now occationally the bottom of the screen stops drawing one scanline too soon when the player is on the (I believe) second last line from teh bottom. The screen pretty much rushes up to meet you, but backs off as you go that one step further. It doesn't seem to always trigger, probably from the speed code allowing you to jump over it. I'm looking at how to fix it, but at the same time if I can't, it might not be such a big deal. In the game itself, odds are you'll jump right through to the next screen connected to it. I only notice it right now because I can repeatedly bash the square against the bottom without causing the screen to change. Adding a binary of the modified beta 2. screenshot still applies. it just doesn't roll anymore. (or shouldn't!)

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 becomes necessary, but for now I'm keeping my hopes up! For version 0.009, I'm returning to the display kernel and rewriting it into a Basic Room routine. I'll be writing multiple kernels for displaying rooms in this game eventually as I think I've mentioned before. This room is as it says, Basic. It'll be one of the simpliest room types! (Although I'm sure I could (and may) write a simplier one.) Up until now, the display code for the playfield was intended mainly as a testbed. The room was completely hardwired in. My intention, despite common sense, is to load the room details into ram. This takes up a lot of ram, yes. About 40-50 bytes of it actually. Still, it'll add some flexibility to other things I have in mind, and if I run out of ram I'll do the alteration to assume the cartridge has a Superchip. If I do that I might end up letting the superchip hold all the room details plus various game variables. (An idea I've had since the beginning anyway) In version 0.009, the room loading will be hardwired in still, but it will be loaded properly into ram instead of pointing to hardwired rom-tables etc. It'll also show a new way of handling the background color. (Assuming what I have already written actually works. )

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 individually ourselves, whenever we hit hmove, anything with a specified offset is going to move. But here's the real problem. With a regular hmove, the value of 0000 in the movement registers indeed represents "no movement" or "move to the right 0 pixels"... With a cycle 73 hmove, that same 0000 suddenly represents -8. (A shift to the left by 8 pixels). So anything positioned with a regular hmove command will suddenly be affected by this unless we can alter it's movement register first, changing it to "1000" (Which means 0 in the cycle 73 hmove. - it means move by +7 in regular hmove's tho, or something similar) In addition to this, there's some timing issues involved with the branch used in the HP bar. When it triggers it ends up taking a cycle too long and pushes the cycle 73hmove I try to use to hmove cycle 75+. (Haven't examined it to see exactly how bad the time cost is) So as a result, my hmove73 suddenly changes to a regular hmove at times, which totally throws off timings and positions. What I'm going to have to do is try to develop my own cycle 73 hmove routine it seems so I can replace the regular hmove routine I currently use. Using two different routines is just going to complicate things. But before that I want to work on the playfield again for a while. I've been looking at the code supercat posted in the msgs earlier in the blog and while some of it is still greek, I do see how it works. I'm going to see what it'll do to reduce the size of the existing display code I use. I can already see it freeing up a register, so that's good. So I guess beta 2 was actually the final for Version 0.008.

It's a rock solid introduction, explaining everything you need to know to get started. After that it's a never ending learning experience as you find out things both here on the forums and on the Stella mailing list. I doubt I would have been able to do anything with the 2600 if not for Andrew's explanations on the basics which helped me understand what I was dealing with, why things are the way they are, and the sorts of limitations you're up against both on the scanline race and ram/rom limits. As for things I've done with it, well... I get distracted easily so I'd start tinkering, then get distracted and wander away for months so until recently haven't done much as far as actual programming is concerned. But I'm progressing at a fairly nice pace for me now. I seem to have the pdf version here, I can try to post it as an attachment if it's no longer available elsewhere, although it won't be updated compared to what use to be available. As for Andrew continuing, that's always up to him. But since it's been a few years since the last session...

It might have at least saved me the trouble of attempting to construct the table myself (and avoid the typical off-by-one errors I seem to make commonly but... however that at least gave me something to look for, so I dove into my gmail where stella has been accumulating steadily for a few years and found it. Posting it in case anyone else may need it. I only have excel-viewer on my comp tho so I can't go editing things to see how it changes, but I might be able to look at the routine in it as a guide when I give up hope for a pre-packaged cycle 73 routine. I may still have to look at playfield graphics/storage tho at this point. Horizontal_Position_Timing.zip

Yerg. Before I attempt this for a third time (As I'll probably put it off until later and get back to playfields for a while) does anyone happen to know/have a horizontal sprite positioning routine they're willing to share that triggers hmove at cycle 73/74 so as to avoid the ugly comb? Right now my sprite positioning could be done in vertical blank so using a normal hmove was just fine. But the more I think about what sorts of things I'll be trying to impliment, I'll be needing to update on the visible screen on many occations. Any suggestions would be appreciated.

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 for version 0.009 or something... I'm also pondering if I should consider using double-spaced sprites since it doesn't seem like much space is used there. I can adjust the P2 register to close up some of the empty space left on the right side of the sprite anyway. I'd also like to reposition it some more as well. Right now it still doesn't have an hmove to fine adjust it's position. I just use a resp1 to place it where it is. As for other changes: 1. I've declared a couple new constants. They're the Player's Default Colors, for now being White and Red. Before I had some colors either hardwired in (pre-status bar versions) or left them the same color as whatever the statusbar's routine left them as. So now our Adventuring Square is canadian eh. 2. The second bar is in, but simply mirrors the status of the player's HP bar. Also, both bars are marked with "P". This is not hardwired in, and they do read their own rom table graphics. I'm just too lazy right now to adjust them. Just did a copy/paste and a slight edit. I will eventually change the red bar to "H" for Health/HP. And the purple bar to S for Spellpower/MP. I can't think of any other letters that fit such a small resolution with playfield graphics that make sense offhand. And I know the S is going to look like crap... maybe a T for technique? Hm... 3. I played with the background color settings and tied it into the player's Y coordinate just for fun. I'll likely unhook it again when I get back to playing with the Display kernel itself. Final, and hardest goal is yet to come. Allowing the second bar to correctly display the player's Spellpower/MP instead of just mimicing the HP bar. This is likely what caused a lot of the errors with the initial stab at it.

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 moving a couple things around to account for the difference in timings. I guess the majority of the problems with the last attempt were with adding the second bar, since I have to attempt to reposition P0 in a single scanline while maintaining a slightly async playfield. "slightly" in that only PF2 changes during the line I attempt to reposition P0, to keep the item-equipped displaying properly on the right side of the screen. The next thing I tackle however, will be modifying the status bar so that it properly shows both bars. However both will always read the same value as I won't attempt the sprite repositioning to read the player's Mana/Spell Power for the second bar just yet. and Happy Halloween!

I had something done for this week's Action RPG (version 0.008) but upon finally getting to test it, it failed spectacularly. It was so mucked up I didn't even know where to begin to debug it (all semantic/timing bugs) so I'm scrapping it and I'll start over. Perhaps the problem was trying to get too much done. I tried looping the kernel up some, modifying a position-a-sprite routine so it would execute all in one line, and adding the second bar. Also, I'm starting to feel a bit under the weather. I blame Daylight savings time. Just because. I'll work on the status bar again over the week and hopefully have something done by next week, even if I only manage to loop up the HP bar. NOTE: I just noticed the little glitch when the hp hits about the middle of the bar. At the very end of the bar you see the red come back for one pixel. This is because my hp conditional check was off by one. (You'll see this off-by-one error happen a lot.) I have that, at least, fixed.