Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

Mord

Members
 View Profile  See their activity

  • Content Count

    2,986

  • Joined

  • Last visited

  • Days Won

    2

Blog Entries posted by Mord

  1. Mord
    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 the extra thickness of the bottom? That should not be like that and in fact it's only like that half of the time. The stripped color of the playfield made it easy to find the cause. The problem was in the StopPlayer line. All 3 branches of this section are suppose to fall into the appropriate AfterPlayer Zone after completing one line. However the "Line2" variant, which is responsible for testing the LinesRemaining to the zone and branch to either UpdatePlayfield or NoNewPlayfield lines jumped back to the StopPlayer versions. This caused it to do one more line of displaying the player's outer box before jumping properly to AfterPlayer to turn it off.
     
    Beta 2 actually has this fixed.
     
    The only problem now is with the sprites. I must be using SkipDraw incorrectly which would cause it to either never trigger (always skip and load #0) or it's reading the wrong place in rom that just always happens to have 0's...
     
    And I don't know what it could be.
     
    If it's loading from somewhere else in ROM it should end up loading $FF's instead of 0's since in my experience so far with DASM that's what it seems to stuff into unused bytes. And I don't have any large segments of 0's placed in the rom. But I know it's at least triggering at the right time - roughly.
     
    The delay we saw in the previous version when the ball's VDEL was taking 30% of the screen to turn on? That was the line that one of the items -should- have started displaying. I hardcoded one to start drawing at (40,40) in the gamefield window. (Status Bar lines aren't counted.) The other was due to start at (130,130) but obviously we wouldn't have noticed anything special with that one.
     
    Guess tonight I study the math behind Skipdraw. I also have to double check the VDEL settings for P1 and P0 to make sure what I have set is still valid now that I've moved the GRP1 and GRP0's. At worst I'd just have to switch them around.
     
    Here's the fixed beta2 for version 0.009. The only thing left to do for this version is fix the sprites so they'll display properly.
  2. Mord

    I blog way too often.

    By Mord,

    My brain is frying but that's ok! The code is starting to take shape. Been spending most of today analysing and editing the PrePlayer branch. The rest of the code is just a copy/paste + minor editing affair I believe so as long as THIS looks like it'll fit in the scanline properly the others should as well. (And I want to make sure PrePlayer is perfect before I copy/paste otherwise it'll mean a lot more editting later!)
     
    As a bonus to me I added a check for screen termination that will end up in all the zones and is already figured in to the timing. No more "special cases" like I hacked into the last version. This is good as otherwise the code wouldn't fit in a scanline properly in the later segments. (the extra tests would kill the timing!)
     
    So hopefully the next entry I make will actually be Version 0.009.
     
    *update*
     
    Timing is too tight for this room display kernel so I'm limiting the ball. Ideally I wanted to be able to move the
    ball around and have it turn on/off in such a way so that it could simulate another player. That may still be
    possible but I'd have to rearrange a lot of code and it isn't strictly necessary for most of the rooms.
     
    So for the Basic Room display the ball is regulated to being a solid bar going the full length of the screen. The room data will be able to position it horizontally at any pixel and set it's thickness. This is good for blocking off the side exits rather than using missiles like other games.
     
    The initial code is written and while I think it's possible to pull off I have no idea how how long it's going to take me to fix the bugs I'm sure to encounter. Right now browsing the code repeatedly, fixing things as I see them. Some would get caught by a compiler but others would take a while to find if I jumped to the compiler right now.
  3. Mord

    Display Code Yet Again.

    By Mord,

    I've been trying to build up the scanline pairs for the first stage, the rest of it after that is generally an issue of copy/paste with a few modifications. I was topping out in cycles again so looked for ways to remove things from the kernel without removing anything from the kernel. I think I managed to do that although it cost a couple bytes of ram. By doing this it also freed up a lot of color selection choices for the playfield alterations.
     
    As a result, hopefully I'll have version 0.009 written and if nothing else in the debug stage this weekend.
     
    *update*
     
    Now started on writing the display code proper. Got a long weekend, so in amongst cleaning out the game collection to see what works and what doesn't. (I'm not quite as Pro Quality as my apartment tells me I should be ) I may take the Model II genesis down to the local pawn shop if I can confirm it works and I have enough spare connectors for my Model I genesis and the like. A few other odds and ends that might get traded in as well. I noticed they had a "Heavy Sixer" for sale down there, but after getting a closer look at it, it looked to be a CX2600 instead. Not too surprised I guess. I may just trade those things in for some more 7800 and/or 5200 carts depending on what they have at the time. I'm already up to 8 games for the 7800. I don't see them very often.
     
    As for the mentioned saved cycles above, I was altering the playfield color slightly in the hopes that it'd stand out a little more in the room. So we'd have 2 colors altering instead of just one for the entire screen. Is it really necessary? Not really. But darnit I wanna see it.
     

    lda PFColor eor #00001100 sta PFColor
     
    This is what I was doing every scanline. This format would keep the two altering colors the same hue but just vary their lum values slightly by toggling the same bits back and forth. I had bit 1 kept at 0 to make sure I could set it as a 1 and then use that for enabling missiles and the ball. That restriction saved the need of setting up the register since I always enabled the missiles or ball immediately after setting the playfield color. (Can't vdel the missiles after all.)
     
    By adding a second byte of ram, I could define PFColor_Even and PFColor_Odd instead of just PFColor. I could then set those two colors when I load the room and simply do a lda PFColor_Even or lda PFColor_Odd based on which of the two scanlines I'm in for the 2-scanline kernel now being used. from 8 cycles to 3.
     
    I know later on I'm going to end up with ram issues. Luckily in this game most items and monsters aren't going to be as ever-present like they are in certain other games.
  4. Mord
    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.
  5. Mord
    *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.
     

  6. Mord
    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.
  7. Mord

    wha.

    By Mord,

    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.
  8. Mord
    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.
  9. Mord

    (Action RPG) Version 0.008

    By Mord,

    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. )
  10. Mord
    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.
  11. Mord
    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.
  12. Mord
    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!
  13. Mord

    Blah.

    By Mord,

    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.
  14. Mord

    (Action RPG) Status Bars

    By 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.
  15. Mord

    (Action RPG) Version 0.006

    By Mord,

    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.
  16. Mord
    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.
  17. Mord
    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.
  18. Mord
    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.
  19. Mord
    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.
  20. Mord

    Coding Days Are Here Again

    By Mord,

    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.
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...