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
    As "punishment" for falling behind on my code, here is a zip containing binaries, screenshots, and source code for Version 0.011 of Action RPG as it stood prior to me adding in bankswitching. I'm aware of inefficient code and excessive - and not always correct - comments. So anyone using the code for their own nefarious purposes keep in mind there are likely more efficient methods and don't always listen to the comments. Except with respect to the nop. It does in fact look darn purdy.
     
    The Test Realm source is slightly more advanced than the regular rom, having the test realm's info added to it but also a slightly better recovery on collection detection for when you try to diagonally press against a wall while walking through a room exit. I'll still need to revisit that to get a real fix for the problem added. Got ideas for it so shouldn't be that difficult.
     
    And now I'm stepping out for a sub.
  2. Mord
    Caffeine free for almost 3 weeks baby!
     
    I'm sure the stores have noticed a change in my purchases by now. Especially the clown. I was getting fed up with the employees trying to predict my (fairly predictable) order anyway - especially since they would routinely screw it up.
     
    I'm hoping Al can get the attachments working so I can apply "punishment" for falling behind in my action rpg coding. (And the upcoming move isn't going to free up a lot of time for it either. )
     
    --
    Mord
    (I use to drink diet colas like water prior to this last attempt to quit.)
  3. Mord

    Back to code.

    By Mord,

    Maybe it's the sudden intense 15 degrees celcius outside yesterday, but I picked up the codebook again tonight along with putting more effort into the last couple map redos I'm doing for Scrapyard Dog. (only 3-3 left! yay! ... I thought I had more than just 2 to do for some reason, probably what helped procrastinate on it. )
     
    Codewise, I just started hacking into a flicker routine for Action RPG. There's a limited number of objects to check for with the item/monster setup I have in mind and the routine itself for choosing which of the X items to load into sprites 0 and 1 for each frame seems simple enough.
     
    Seems simple enough.
     
    SEEMS.
     
    I know I'm going to be scratching my head later over some little detail.
     
     
    Another thing I was pondering was making an atari 2600 paint utility. One that actually runs on the hardware.
     
    The disadvantage of doing it as an actual rom is extracting the sprites for use in another program - I'd have to make it so the person could copy down on paper the values of the bytes.
     
    The advantage of doing it as an actual rom include making sure the colors look exactly the way you want (if you're sitting in front of the TV on real hardware at least) and making it so that the atarivox/savekey can save images.
     
    I'm probably going to attempt it in the near future, obviously before Action RPG is even remotely finished. The idea being that I can use the finished Paint 2600 to help me draw sprites for Action RPG. It would also get my feet wet with programming the Atarivox (saving sprites to/from the eprom) which will also be required for Action RPG.
     
    Eh. We'll see how it goes.
     
     
    --
    Mord
  4. Mord

    It's time for a change!

    By Mord,

    ... of budget!
     
    Seriously, I have to beat this stupid spending habit I have for junk food and fast food etc.
     
    It's not a good thing when the local Dairy Queen knows what the "Usual" is. Sitting down and just doing a few quick calculations kind of made my heart jump a bit, even as I reached for the diet cola.
     
    And so hopefully I'll be able to sit down and write out a few changes to my spending pattern while allowing for other things to continue. For instance, I really have to stop buying games that I don't really know much about but get to "round out" a collection for a particular system.
     
    Has. To. Stop.
     
    I also have to stop buying CDs because I hear a song on the radio I happened to like. Way too often these last few years I've found I'd get the CD home and listen to it and find that song on the radio is the only song on it that's worth anything at all. There are a couple of european bands I'll continue to collect for all the same as while those bands will NEVER be played on the radio, I've found I've overall enjoyed entire albums by them.
     
    Ah well. We'll see how it goes. I've tried curbing it in the past but .... well, it obviously hasn't worked. *grin*
     
    In other news, with the maps for Scrapyard Dog almost finished (although I'm planning on redoing a couple to help out with the cleanups etc) I've started thinking more on Action RPG. Part of those thoughts have been for how to handle items/mobs and a flicker routine, another part has been for a potential different display routine.
     
    Having a new display routine of course would take me probably a few weeks to a month to get working properly so I'll probably hold off on that for a while. I intended on adding multiple display routines from the beginning anyway.
     
    Plans for this weekend currently only include Action RPG and Twilight Princess.
  5. Mord

    OH EM GEE.

    By Mord,

    It's the 16th and I haven't made a post yet this month?
     
    Well, I guess that's bound to happen when I'm not doing serious coding. I have, however, been somewhat productive overall. Only 3 levels left to map out for Scrapyard Dog (4-3, 5-3, 6-2) - I've actually gotten a bit faster with doing them compared to way back when I was doing level 1-1. I'm not anticipating problems with 6-2, although the x-3's are going to be a pain I'm sure. Hopefully I'll be able to finish all 3 tomorrow.
     
    In game news, after finishing Ar Tonelico last month I went on and started over with Grandia 3. For a 2-disc game it felt incredibly short. I'm quite sure I missed stuff by staying fairly on track with the story so I'm probably going to attempt looking around it some more later on.
     
    But before that, I think the next game on the agenda is Baten Kaitos. This means I'll have to hook up the gamecube again which would be the first time it's been hooked up since my last apartment move - roughly 15 months or so. I was working through it prior to my move but ended up losing interest for various reasons that I can't really remember anymore. Probably something about watching some of my healing cards evolving on their own over time. When I sit down to start playing it, I'm going to start over from the beginning.
     
    I seem to be on a RPG kick this year.
  6. Mord

    Projectz

    By Mord,

    Spent precious little time on the rom this month. Most of the (free) time I have has been split between the Scrapyard Dog Project, Ar tonelico, and working on my Aardwolf Area on their builders port.
     
    I have been sitting down and thinking about how I want to handle objects and monsters in the game, but haven't decided on a method just yet. Since most objects will go into inventory and can't be stolen, things can be compacted a bit by declaring various things "regional" to a specific portion of the kingdom(s), monsters are a little more complicated since they move about, but most of them will end up being local (to a screen or two) or regional as well - meaning they'll somewhat reset if the player leaves the region and returns. A few monsters and potentially items, will be global however. (Meaning they can chase you all the way around the game!)
     
    Crap, I have to remember to mail back my atarivox soon. x_x
     
    What brought that up? I've been pondering how to impliment the atarivox for the game, a few blocks for save data would probably be quite beneficial. It's certainly something to look into at least.
  7. Mord

    I'm a slow programmer.

    By Mord,

    That subject works on so many levels.
     
    Anyway, I sat down and patched the relative exits for the proper detection of the Zero Nybble case. No bugs or troubles in adding it. I altered room 6 so that it used relative exits for the dead exits instead of normal exits in the main rom. Since there's literally no visible change to the player (... again. ) I'm not going to bother posting the rom this time.
     
    The rest of this week is going to be split up between thinking about items/mobs and working on the Scrapdog project.
  8. Mord

    (Action RPG) 8K.

    By Mord,

    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 it already but after checking the Vertical Blank logic - I didn't.
     
    All it needs is during the Vertical Blank to run a check to see if P0 or P1 has the appropriate even/oddness for itself (each one is different!) and if it doesn't, we do a quick "1" mod to the graphics pointer after refreshing the pointer itself if necessary. Thinking back, I believe I was holding off on adding that for when I was going to add actual item management to the display (for flickering items when necessary.)
     
    Either way, just an update to prove I'm still working on it. I still have to make a few fixes to the roomloader to properly patch in relative exits. They work now but they don't handle the special "0" case yet. That 0 case is suppose to render the exit dead - right now it just adds 0 to the room base. The dead exits in the Test Realm right now are handled by Explicit Room Exits which handle the case properly.
     
    Going to work on Scrapyard Dog a bit more on Saturday morning (world 2-2 map) before working on my Aardwolf Area a bit - I hope to finalize at least 3 mobs and 1 more item. (2 items finalized already) After that, I'll sit down and think about how to handle objects/monsters for Action RPG so I know how I'll continue.
  9. Mord

    Scrapyard Dog

    By Mord,

    Haven't been working on the rom lately much, despite knowing what I need to do to finish the bankswitching glitch. With the spare time I've had I've been trying to work on an area I was building for a MUD called Aardwolf. (http://www.aardwolf.com/) The area has been on the builders port since like... 2001. The person I was building it with vanished, probably for good at this point since it's been over a year now. Most of it was done prior to 2002, there's just been extended interruptions/waits as either myself or the other person was MIA for months on end, etc. Finally got a "friendly nudge" to try to finish it up earlier in the month so looking at it again. No point waiting for the other person to return anymore. But the problem at this point is that the building guideliens have changed many times over since 2002. So now even tho everything is -there- and set up, mobprograms need to be redone (I've unlinked and deleted the ones that were there) the items and mobs all need to be rebalanced for alignment/levels/repops/etc etc to fit new stricter guildelines, etc. And it's a pain. in. the. ascii. I've reset the mobs and items all to level 1 so I can easily tell which ones have been rebalanced and which need to be redone/balanced.
     
    That's going to be eating into my coding time for sure. The mobprogs that'll be added to the area this time around won't be so complicated and mostly just for atmoshpere. Otherwise it'll be another 5 years. >_>
     
    The other big thing I've been working on, for those who avoid the 7800 forum, is working on "nintendo power style maps" for Scrapyard Dog. Easy enough to find the thread I'm sure. So far I've done the maps for 1-1 to 2-1, getting the actual maps done. The others have been doing the modifications/tip-addition etc to each of them.
     
    I'm going to practice level 2-2 when I get home from work tonight as I'm about to fall asleep now. Once I'm familiar enough with the level I'll go ahead and snap up the map of it. Hopefully I'll be determined enough to work on the rom again this weekend at some point.
  10. Mord

    Still workin' on it.

    By Mord,

    Bankswitching can be a pain. Or more accurately, my failure to preplan it better. Haven't gotten it compiled yet as I've had to overcome various compiler errors caused by label-dependant code being in the wrong bank. So been moving those things around etc. I think the last thing I'll have to change before it'll compile will be a way to jump into the roomloader bank when it detects a new room to be loaded. Already got a good idea of how I'll do that.
     
    I think I have Dynasty Warriors 5 Empires out of my blood for a while finally tho. That thing was taking up a hell of a lot of my time. *grin* So as long as I don't turn around and start playing Dynasty Warriors 4, I should be good to go on the rom more regularly again.
     
    *edit*
     
     
     
    Finally got the bankswitched version to work, sort of. Given I never changed anything in the graphics (at least not intentionally!) or the room data itself, there's obviously some problems to overcome.
     
    1. The trophy now looks like ET. Seriously. Stare at it for a while.
     
    2. The exits aren't working.
     
    I wonder if both might be page-related errors propping up from the moving around within the rom(s).
     
     
    *update*
     
    The exits failed because the thing I copy/pasted for the room info was an older version. I thought I had updated the copy in the roombank rom to match what I was using in the normal bank prior to adding the bankswitching, and I was wrong. ^^ Pulled the right info out of a backup.
     
    The "ET" error is baffling me however. Right now, and without seeming to do anything directly to it, it's no longer an ET in the current compiled rom. Not only is it not displaying the proper bytes (Where it -should- be pointing to!) but I know where it's actually reading it from.
     
    It's somehow positioned directly over the joystick ports (among other registers around it.)
     
    Basically the picture alters as I try to move around (As the predictable bits go on and off - both player 0 and player 1 and it responds to the console switches as well. x_x
     
    I'm trying to figure out how it's doing this. It's seriously messing with my mind here.
     
    With the bankswitching I had to split my temporary variable hardwiring routine up so it inited variables in two different banks. It needed some labels to init in the display bank but when the game is all done and finished, there will still be some variable initilization required - and I want that done in the roomloader bank.
     
    According to the output.txt dasm generated, the pointer in ram is being loaded with the proper address to point to the graphics so assuming that's true I must be corrupting it somewhere to make it point to around $280.
     
    ...
     
    ....
     
    ...............................................................
     
    after being confused with this for a couple days, just typing that made me realize what the hell was probably going wrong.
     
    The labels are being inited poorly in the display bank.
     
    here's what's happening... ^^;;;;;;
     
    If it starts in the Roomloader Bank, it initializes the system then loads the room then goes about it. It bypasses the Label Initalization in the Display Bank.
     
    If it starts in the Display Bank, it inits the labels, then jumps to the roomloader. AND INITIALIZES THE SYSTEM. As in, goes through Andrew's 9-byte routine that I have in there thereby overwriting what was loaded and continues on it's merry way as if it had started in the Roomloader bank.
     
    I suck.
     
    I'll go fix that later today or tomorrow morning.
     
     
    On another note, Dynasty Warriors 4 is still kinda fun.
  11. Mord

    Bankswitching

    By Mord,

    Started work on converting the rom to an 8k as per my initial plans. Just pondering exactly how to set things up and I've changed my mind on the setup/naming strategy a few times already.
     
    That, and Dynasty Warriors 5 Empires, are what's taking me so long to update.
     
    Either way work is continuing now but updates of any sort might not show until the weekend. One thing I HAVE done is remove the variable and constant declarations I'm using and moved them to their own .h files so I can just include them. Especially with bankswitching being added this seemed necessary. It's certainly not because I'm getting sick of scrolling over them whenever I'm looking for something specific.
     
    The next thing on the To Do list is a look at items.
  12. Mord

    new mp3 player

    By Mord,

    I broke down and bought a new (cheapish) mp3 player to listen to at work. I've been using my failing cd/mp3 player (uses cd-r's) for a while since the last mp3 player started to break down in the earphone connector. overall it was just 10 dollars more expensive than the last one but I don't really expect it to be much better than the old one. Still, this one wasn't on as big of a sale as the last one when I bought it so... Listening to the sound on it, it seemed to be about the same as the old, which is inferior to my cd/mp3 player. Guess I'm just use to having bass-boost on etc.
     
    I have a $25 dollar gift certificate for ebgames from christmas still. Not entirely sure what game I'll end up getting although some of the ones I've looked at just aren't released yet. Since new releases hit stores on Tuesdays (only took me a few years to notice that. ) I'll drop by ebgames today on the way to work.
     
    For the rom, one thing I forgot I was going to do was reposition the display code to the front of the rom. Guess that'll be my plan for the week.
  13. Mord

    Test Realm

    By Mord,

    Ok got the new roomloader working. Here's a little map of the realm. I've moved the sprites to push them off the screen for now. They're not serving a purpose yet anyway.
     

     
    You start in room 1 when you start up the rom. Room 2 is the only room right now that is using relative-exits. I had problems with it in the code at first so changed all the rooms to explicit then turned 2 back into relative to test. The problem was me, not the code. Basically I was adding the wrong thing to the room data. I could go back and change the rooms back to relative but no drastic need for the test Realm.
     
    The top of room 6 loops back into the bottom of room 2, much as it did before. The side exits in the room demonstrate dead exits. The ball is used for the side wall in rooms 3 and 5.
     
    Room 7 (and room 6) both use indirect playfield loading. Room 7 uses the playfield data from Room 1. Room 6 uses data from Room 3.
     
    Room 4's side exits loop back into the same room. It has the effect of repositioning the player but doesn't drop a frame to reload the room.
     
    The collision detection still has a few details to work out so you can't push against a wall smoothly as you exit a room - it tends to stick the player. However walls should no longer grab the player permanently like they did in the last version. (I've added Region/Room info to the backup routine.)
  14. Mord

    Room Format Modifications

    By Mord,

    I've been tweaking with the room loading routine and added a few things to it to allow me to reuse roomdata. There's no need to explicitedly set byte-for-byte all the playfield data for all the zones of a room in all rooms of all regions. Especially when you consider how many 3-byte strings will be identical.
     
    Now in the room data I just specify the starting offset (low-address) for where a 3-byte string will be taken from. The highbyte/page has been pushed into the high nybble of the Zone-Counter byte. There will never be 15+ zones of data in a room simply because I'm not reserving ram for that many zones. In fact I have the room loader designed to limit the zone counter if it tries to tell it there's more zones for the room than the program allows. Since the high-byte for the graphics page will always have the form of $FX, I only need to store the X portion and add the F in afterwards via an ORA.
     
    For the relative exit format (2 bytes are used instead of 4 to specify the 4 room exits) each nybble holds an offset value from the CurrentRoom variable. What I do is load CurrentRoom, subtract 8 from it. Then add the nybble back into it. IF the nybble is 0 however, I don't bother with that and just assign 0 to the room exit. Room 0 in the code indicates a dead exit so this way I can always kill an exit even when using relative exits.
     
     
    Due to the subtracting of 8 from current room, when we add the nybble back in we get the offset as follows:
     

    0 | 1 2 3 4 5 6 7 8 9 A B C D E F <-- nybble value. X | -7 -6 -5 -4 -3 -2 -1 0 1 2 3 4 5 6 7 <-- offset from CurrentRoom
     
     
    With careful planning this could save a lot of space without hurting the world layout. If relative exits were the ONLY way to specify exits then you'd have trouble with the world layout. ("What do you mean I've already used all rooms that are within range!") But I can explicitedly set exit values as well if necessary. The only catch is that a room has to be entirely relative-set or entirely explicit-set. I could probably change this later since I have two more bits in the RoomStatus nybble. (Which occupies the top nybble of the RoomStatus/RoomType byte.)
     
    The addition I'm making right now is the ability to either load the playfield data for a room as I mention above - or give the room/region pointer for a different room. In effect it would jump to the new room, totally ignore the color/ctrlpf/exit information for that room, and just load it's playfield data. Between use of the ball positioning and playfield-mirroring that can be different, the exact same playfield data could look quite different despite being the exact same data. Additionally I'm thinking about allowing specific zones to be loaded/overwritten after I load a different room's data.
     
    I suppose I could look at the playfield loading as direct and indirect playfield loading.
     
    At any rate I plan on spending today and tomorrow rewriting the room loader then I'm going to change the Test Region layout. The new layout will make use of all the different aspects of exits and room loading. (Dead exits, tying exits so they lead back into the same room, direct/indirect room loading, relative/explicit exits, etc.)
     
    After that I'll upload a new rom of the new Test Region.
  15. Mord
    With version 0.011 I've added/fixed a couple things. First of all the sprites are positioned properly. They're hardwired for now, and there's no mechanism to determine what sprites need to be displayed each frame, if any, depending on the room. There are no actual items yet!
     
    There are, however, actual rooms!
     
    The exits are working although it's not prefect yet. I still have to add the room exit info to the collision detection routines. So if you try pressing against a wall while walking through a room exit be prepared to restart the rom as the wall will grab you. I just wanted to make sure it would work with the non-collision code before adding the same minor alteration to the direction test routines.
     
    For testing purposes there are 4 rooms in the Test Realm for now.
     
    Next version I'll be adding the room changing code to the collision code so walls won't grab you and probably work on some simple room alteration flags. (swapping of colors etc)
  16. Mord

    I suck.

    By Mord,

    I've begun moving room data into a real room loading procedure. I had a few issues to work out but after a few hours of wondering WTF was going on with the data that was apparently NOT what I trying to load, and finding a few errors in the code along the way (not that they would do anything to fix the situation apparently) I finally got it working normally again.
     
    All I have to say is this.
     
    BNE != BEQ
     

  17. Mord

    Getting back to coding.

    By Mord,

    I refreshed the code back to version 0.010 and redid the modifications to the code to make things work. The weird problems didn't restart and I even fixed up the code a little better this time to make sure no jumping of scanlines was occuring when P0 or P1 was touching or crossing over the top of the gamefield. (too much time taken - in each of hte lines where I updated P0 or P1 via a modified Skipdraw.)
     
    Then I tried altering the playfield again and noticed the exact same funkiness return. This time it only took me a couple of seconds to realize what was likely the problem.
     
    It's been so long since I touched the main display that I had forgotten that I use the playfield color to help enable the player. And to help save more time in the kernel I simply hit ENAP1 (I think) every scanline during the player lines. I can avoid testing etc that way. So if bit 1 was 0 on any of those lines the missile triggered by it would turn off. The playfield is striped, so...
     
    Bah. Remembering that a week ago would have saved me some time, but at least everything is working now. I may have to add one more line to the In-Between zone however as we still have the hmove bar for the last player positioning visible.
     
    But do I take it from the status field or do I take it from the status bar. I'd prefer to take it from the status bar. I need to consider if I REALLY need to prefix the bars with a letter to indicate what it is. If I were to support a B/W mode it'd probably be necessary, but I'm not going to. Their color should suffice for a player to tell them apart. Red for health, purple or something for the magic. Should be fine... This would let me make them thinner too, which may make it easier to finally unlock the magic bar so it would have it's own meter values.
     
    I'll still need a modified cycle 74 hmove to pull that off efficiently tho.
  18. Mord

    YARG.

    By Mord,

    I won't be making version 0.011 before christmas. Had to reload from version 0.010 because at some point really messed up things happened and I didn't have the slightest idea where to start debugging the cause. Basically it went something like this. The collisions only test the outer missile. Something funky was going on that caused hte outer missile to somehow turn off randomly. And at the same time the inner missile was striped (horizontally).
     
    Additionally, the playfield's color seemed to have an effect on the player. If I changed one of the colors to #0 we wouldn't see the player at all...
     
    There is no reason for it to be able to turn on and off each line that I'm aware of. it's turning on and off normally is only suppose to happen once each per screen draw. I still have the new code I was copying into version 0.010 so I'm not starting off from nothing. But I've only got today and tomorrow to do any coding. I'm already about to fall asleep so...
     

  19. Mord

    Found the problem. x_x

    By Mord,

    I use the stack pointer as an extra register during the gamefield zone scanlines, namely to keep track of the scanlines to generate - it's faster than updating ram itself. Problem ended up I was setting the stack pointer before the last sprite positioning subroutine call that I added in to the zone between status bar and gamefield. This corrupted the playfield that was intended then returned the stack value to "normal" so the screen would still generate the proper number of scanlines.
     
    Noticed it after procrastinating on the code all day, then saw it right before bed. So left a comment to find it again today as I was way too tired to rearrange code last night.
     
    Oh well, now that that's fixed it's time to find those extra few cycles I need. I think I freed up a few cycles in the process all the same so I may have the time now to set the sprite's direction & size/copies.
     
    In a way I'm glad the playfield was the values that were corrupted. I might not have noticed it until sometime later if it was something not graphically displayed.
  20. Mord
    I copied over the code I've been working on to fit as much of the setup code into as few lines as possible for the vblanking. Here's what it looks like in stella. Looks the same in z26.
     
     
     
     
     
    Sprites are fine. unlinked and all that as they should be. Haven't tested for their correct scanline yet but it should be. I still have to add code to set up the sprite's reflection (if needed) and size. (which would also adjust the sprite's coordinate for drawing with the position-a-sprite routine)
     
    But what's bugging me is the playfield.
     
    For the record, the routine kernel is suppose to be using the Standard Adventure-type Castle Room data. The data hasn't changed but for some reason things are messed up.
     
    Too tired to locate the glitch now however, I'll find it in the morning.
     
    *edits*
     
    But because I had to confirm something for myself, I changed the test room to the No Playfield version. (Mostly used for testing screen boundaries and checking sprites out)
     

     
    ...
     
    So yeah. It's pulling data in from somewhere it shouldn't be, or the wrong data is being pulled in the ram locations as it's loaded... If page boundaries can cause problems like that, then maybe that's the cause. I'll explore it more thoroughly in the morning. This time for real.
  21. Mord

    Back to the grind.

    By Mord,

    Seems every time I finish a tiny milestone, as each version tends to be, I get a kind of rush. Of course this means much procrastination for a job well done.
     
    At least I spend that time -thinking- about the upcoming goals for the next version.
     
    So while it's already been a week I'm getting back to the editor. Work is a little heavier right now up until christmas but I'm sure I'll get a few things done before Christmas Eve.
     
    Goals for Version 0.011:
     
    1. Patch in Eric's faster double-move routines for the horizontal tests. (Done!)
     
    I've tested the double-subtract in the different situations it's likely to be encountered. (normal collision testing + hitting left-edge of the screen during collision) and both seem to be handled properly. I was worried about the carry assumption not holding, but where I handle that situation with the screen clipping no problems surface.
     
    2. Make Sprites repositional for the Gamefield rather than using left over settings from StatusBar. (In Progress)
     
    The code is written, and takes up 4-5 lines. I haven't patched it into the main source yet however as I'm still looking for potential bugs. I'm always overly cautious like this. What I have written -should- work however and it uses up just about every free cycle that would otherwise be wasted in the calls to the PositionASprite routine. That is, the routine is called near the end of a scanline to minimize unnecessary deadtime.
     
    This code positions P0 and P1 regardless of if they're used. If a sprite isn't to be displayed on a frame then it'll draw a null object. Same effect as if there's nothing there. It also sets up the VDEL for the sprites, handles the changing of the colors, using default colors for the player if a sprite isn't to be used for P0 or P1, updates the CTRLPF register with our Shadow copy since settings between Playfield and Statusbar aren't always going to be the same, positions the ball and enables it if necessary, calculates sprite height (would be necessary if flickering different sprites with the same hardware sprites) for skipdraw, sets linecounters I currently use, and clears collision latches just before the gamefield begins to avoid corrupted collisions caused by the status bar.
     
    There's likely some extra things to add in there if I can squeeze it in. Such as setting sprite attributes. (flipped, copies/size) but I'll look at that more over the weekend.
     
    3. Ensure the proper positioning of P0 and P1 so it's appearing on exactly what line it should - no one off errors. (To Do)
     
    Right now it's -working- but as I've said before I'm fairly certain I'm not positioning them properly on the scanlines. It's just going to be a matter of looking at what's in place and then testing new Y positions for the sprites, then making alterations until they're perfectly positionable.
     
    4. ORG the Display code and move the Status Bar code above the logic code. To at least minimize instances where the code messes up due to page boundary issues. I'll handle this last after all the modifications are done to the display for this version. Would hate to do the ORGing then find a few modifications threw things out of sync again.
     
     
    Those I think are the main goals I have set for this version. If I don't get distracted, and if I don't run up against any major setbacks, I'm hoping to have it finished by monday.
  22. Mord

    Found it.

    By Mord,

    So there's nothing wrong with the actual code as far as I can tell.
     
    The problem of it dropping a scanline seems to be based on how it exits the timer-based overscan section. Enabling or disabling the various demo subroutines alter how the extra line is dropped obviously, but so does adding nop's and/or WSYNC's right before it enters the:
     

    ; ------------- Enter Overscan Logic Above ------------------- DisplayOverScanLoop lda INTIM ; 2, 3 ; bne DisplayOverScanLoop ; 2, 2/3; wait for Overscan timer sta WSYNC ; 2, 3 ; finish waiting for the current line jmp StartOfFrame ; 3, 3 ;
     
    at the end of it.
     
    For instance, adding a sta WSYNC + nop right before entering that gives a fairly stable-looking scanline count in z26 - except when I push against a vertical wall (as I try to go left or right) at which point it alternates between 261/262.
     
    Alternately, if I just remove that nop and hit a WSYNC prior to entering the code above, the screen appears to ALWAYS give out a 261 count - but turns full-circle and gives a constant 262 so long as I'm moving in ANY direction on the controller. (regardless of if it hits a wall or not)
     
    This is with the demo programs off of course.
     
    ...
     
    *turns them on and checks hardware*
     
    Ok... so z26 tries to tell me it's giving a solid 262 (I don't see a blinking 1 in there) but at the same time it's still rolling on hardware. Is there something special about timer-based overscan/vblank's that I'm not aware of?
  23. Mord

    Hardware Rolling

    By Mord,

    I'm convinced that the cause of the hardware-rolling is not in the logical section. I swapped out one of the big time-wasting functions in there with something that did the same task in a third of a scanline. I see no change. More importantly however is that according to stella's scanline count/frame, we have it outputting exactly 262 scanlines MOST of the time. Under various conditions which I'm still trying to track down, the scanline count drops, rather than increases, to 261.
     
    So.. commented out the 3 demo functions. They alter the player speed, alter the player HP, and move the ball.
     
    The screen remains stable while I move around with 2 recreatable exceptions.
     
    1. If I try to touch the very bottom of the screen. (I'm guessing I'm generating 1 line too little in that case as it shortcircuits and avoids the AfterPlayer zone. That should be easy to fix.)
     
    2. If I try to crash against a wall horizontally, the screen will start rolling so long as I keep trying.
     
    Interesting enough it won't start rolling if I try to hit it vertically. Naturally, if I try to hit diagonally it'll roll since it'll see the horizontal collision. But why one line LESS in any of those cases? Bottom of the screen I can understand. For the horizontal test though?
     
    Perhaps version 0.010 will just be finding the cause of the rolling.
  24. Mord

    (Action RPG) Version 0.009

    By Mord,

    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 properly. Mainly to make sure that given the valid range of Y coordinates that it positions the sprite on the proper line. I'm quite sure that's not working properly right now, but where I'm positioning them in the middle of the screen for now, that's not important. I'll save that for version 0.011.
     
    Additionally, I don't actually have the sprites positioning themselves horizontally. That'll be added for version 0.011 as well. Just have to make better use of the lines between the Status Bar and playfield so that I can add the routines in. This will generate Ugly Black Bars, but no helping that for now. For now the sprites use the left-over horizontal position of P0 and P1 from the Status bar. This is why one is a double/quad sized sprite while the other is normal and why one is moving.
     
    It doesn't show in the screenshot, but the Ball is blinking while it moves from left to right. This is because I decided to use bit 0 of the Ball_X variable to indicate if the ball is to be shown or hidden. The demo function is just incrementing that value, resetting it to 0 if it hits 150. Fun thing is, due to the way I'm currently doing collision detection, the ball won't hinder X movement while it's blinking like that. It does hinder Y movement. I'm changing how I do collision detection with version 0.010 so I don't know if this kind of behavior is of any use to me.
     
    Finally, for Sprite display, I had 3 choices to choose from as far as I could think of.
     
    1. lsr the offset generated in Skipdraw prior to moving it Y to be used.
    2. Count Scanline Pairs instead of Scanlines.
    3. Interleave the sprites.
     
    I went with option #3. There isn't enough time to squeeze a lsr in the busiest lines of the kernel. And counting scanline pairs needed additional calculation to determine what scanline it should be on for the scanline pair. (The lsr seemed cheap by comparison.)
     
    Interleaving the sprites required no special code or additional cpu cycles during the kernel. The trade off is that it's going to be a nightmare keeping track of the sprites manually once there's a lot of sprites. If I get that far and find it impossible to keep track of them by hand even with the comments and labels I can probably resort to writing some small program to import/export sprites. Importing would generate the .byte data tables, premixed with the necessary labels and comments. Exporting would take a sample of interleaved .byte data and convert them to an easy to read txt file for editting. I'm rusty at C/C++ but with a bit of help from friends who code in C far more often than myself I'm sure I could do that.
     
    So. Version 0.009 finally done. After several betas and some wtf's and one refresh of the source code. Before I go ballistic on the display code, I'm switching back to looking at the display code. Partly to see if it's actually causing the screen to roll on real hardware or not and definitely to redo the collision detection. I'd have to redo it eventually anyway because it's not 100% foolproof. Randomly I'd find it'd still let walls grab players and hold on to them until you shut off the rom. In the real game that wouldn't be much fun. "Yay, beat the boss final-DAMMIT!!!" The way I'm thinking of right now feels like it would be far more efficient in time and rom-space. I suspect most of those glitches are caused by the AlterPlayerSpeed demo which wouldn't exist in the main game anyway but since changing speed is something that can happen in the real game it could still happen in the game itself.
  25. Mord

    *sob*

    By Mord,

    Well gee. I wonder why the heck my test item here would never show.
     

    Item_Heart .byte %00000000; ........ .byte %00000000; .xx..xx. .byte %00000000; xxxxxxxx .byte %00000000; .xxxxxx. .byte %00000000; ..xxxx.. .byte %00000000; ...xx... .byte %00000000; ........
     
    Excuse me while I put my head in the oven.
     

     
    So anyway. Once I actually filled in those magic zeros. ... Something started to display, but not the entire item.
     
    At first it looked like it might be upside down, but closer examination looks like lost lines.
     
    *tests*
     
    Ok, maybe it's both.
     
    AH!
     
    The scanline counter! Skipdraw is dependant on the number of lines remaining, and I've been decrementing the lines EVERY scanline. For some reason I thought I was being smart. Obviously this is going to omit every second line of the sprite, since they're updated every second line. Additionally, the lines that are skipped will alternate depending on what line (Even/odd) the sprite starts on.
     
    So I should be decrementing the scanline count after every scanline-pair (So after hitting up skipdraw on Line2, before starting line 1 of the next pair.)
     
    I should be able to fix this now. Version 0.009 incoming.
     
    *edit*
     
    Incoming probably tomorrow. Counting scanline-pairs doesn't seem right either.
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...