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

    Getting Close for v016.

    By Mord,

    After so many weeks, I think I have noflicker objects on the path to working. In fact it appears to be working in the rom right now. Just have to do some code clean up, then rewrite the object's AI and collision and test it out. I have those things shortcircuited for now as I was more interested in being able to load the freaking thing properly and make sure it wouldn't flicker.
     
    While there were several changes I had to make in the object manager, and I changed the way I was going about it half way through, the things that caught me offguard and caused the most baffling problems were:
     
    lda (DataLabel),y is != lda DataLabel,y
     
    (Where DataLabel is a label in the rom. I should have known better but for some reason it kept looking right until last night when I was looking at a printout.)
     
     
    And apparently inc/dec Absolute does not work on the superchip's ram.
     
    Fixed that by reading the value in, adding to it, then storing it back out. It was messing up the roomloader as it tried to calculate where in the room's data the room object was to be found.
     
     
    So yeah. This weekend I should have version 0.016 finished. I already know how the AI etc are going to work - and they're already written, sort of. They're written for the original way I planned to do noflicker objects. I just have to rewrite them for the new way.
  2. Mord

    Another Week Passes.

    By Mord,

    Adding this special type of room object is proving to be a bit more difficult than I had planned. The idea is that one of the 3 room object slots would be able to avoid flickering even in the worst of conditions by just causing the other sprite to handle the flickering of all the other possible objects. This is best for when collision between two objects is important.
     
    At any rate it's not working properly yet. Haven't had a chance to check the object's AI and collision routines - I just have them short circuit with a rts for now. The problem is somewhere in the loading of P0 (our designated no-flicker sprite which is where a noflicker sprite will have to be loaded. Loading a noflicker sprite into P1 or into any other item slot besides Local_03 will just have it treated like a regular flicker-subjected object.
     
    All I know at present is that data is getting corrupted somewhere and as far as I know it's directly tied with how I handle the Local_03 object and P0 in the cases of noflicker objects. I can load the new room object into any other slot and it'll display properly. But if I try to directly load it into Local_03 - it doesn't work. In fact it acts the same way it does when I try loading it through the room loader.
     
    It's getting under control all the same but at least I'm a lot closer to finding the semantic bug(s) involved right now than I was on Friday. That being said, however, I'm giving it a break for tonight. I'll get back to work on this probably on Tuesday. Got some running around to do tomorrow so probably won't get much time in front of the comp before heading to work.
     
     
    On the plus side: The Object Manager is now more intelligent when selecting objects to display/flicker. If you're carrying an object or an object and you push it off the screen, the object manager will not load it into P0 or P1 for display - thereby reducing on object flickering. While I can't test it just yet to verify, the flicker problem between noflicker objects and normal objects should also be improved. Before this mess if you had just 2 sprites in the room, one noflicker and one regular (obviously), then the regular one would STILL flicker. (It would basically copy P0, the noflicker object, into P1 every second screen.) That issue should also be corrected.
     
    Hopefully work won't be too busy this week and I'll have more time to hunt down the above issues before friday.
  3. Mord

    Back to the Code.

    By Mord,

    I've also been playing Aardwolf more actively lately, but the main thing to report is that I've added the new code to the main sources yesterday. I had added most of it and things worked for the most part, properly. I noticed one of the hearts that would jump to a new position/room whenever I entered a new room and it kind of puzzled me for a bit.
     
    Then I remembered this was expected. Local_03 slot is cleared when leaving a room - all local/room slots will be like that eventually, so obviously the heart placer would detect the now vacant slot and roll up another random heart for it. So that was ok. But then I remembered. I never added any of the code associated with the new room object I wrote, including the data for it! I also needed to add the TickTimer code for splicing some actions up between frames. Things that don't need to be done every frame or would benefit from being don less often would go into this section of code.
     
    So I added that stuff.
     
    And things stopped working.
     
    All I'm getting right now is a black screen. Looking at the debugger in Stella, I see the ram alternate between an initialized state (all zeros) and a right-after initialized state. (Probably the result of the init-variables triggering.) And if I go with the Frame+ button, I see it alternate between the two states. So something in that code is messed up. Most likely a comparision or branch. I'll be doing some checking into it this afternoon after I wake up and before I go to work.
  4. Mord
    I live up the road from a fire hall. I'm use to seeing - and hearing - the trucks go by at least 2-3 times a day. This is the first time one of those loud beasts stopped at my apartment building. Seems half of the apartments are pretty much apathetic to this situation. I am not. I slipped on my sneakers and went downstairs, and despite being on the top floor, I was the first person down to let the gentlemen into the building. I saw a total of probably 3-4 others that were at least interested enough to step out into the hall to ask what was going on. (it's a 10-apartment building. I'm pretty sure all of them are occupied)
     
    Anyway, the firemen went downstairs to the ... I don't know if it's the electrical room or boiler room or what to call it. Suffice to say it's where the hot water tanks and heaters are located. They poked around outside and in the room etc.... but in the end left after not finding anything out of place.
     
    I'm hoping that indeed nothing is wrong... Now excuse me while for no particular reason I go for a short walk to admire the building from the outside. I'm glad I don't go to bed for another 4-6 hours anyway. Because I doubt I'd be sleeping much before then regardless.
     
     
    And yeah, this is going to slow down my code for a while. >_>
  5. Mord

    Definitely a bit late.

    By Mord,

    The code is getting written, modifications being made, etc but I still haven't gotten to the point where I can compile the code and actually expect it to work. Right now the point is to determine how to load the object in the roomloader bank without needing data that is in the display bank. I really don't want to make complete item copies in the roomloader bank, although a lite version of the data might be done - and the rest of the processing handled in the Vertical Blank on the following frame before objects are sized up and loaded for display.
     
    I had copied all the AI routines to the roomloader previously since some objects seemed to need to be processed in the roomloader screen. (Carried items in particular.) I have since made some alterations to the carried item code on the black key so maybe that isn't needed anymore. If it still is required I'll modify the AI routines in the roomloader bank to be nothing but empty jsr's if they aren't needed there. And have all those that aren't needed point to the exact same empty jsr.
     
    Oh well. Hopefully by sometime Sunday evening I'll at least have the code in the testing/debugging phase.
     
    *update*
     
    Nope.
     
    The more I look at it the more patched the code looks. Going to spend some time reorganizing and studying what I have written, as well making sure that the new code and existing code are cooperating properly before I even begin testing.
  6. Mord

    Perhaps a bit late.

    By Mord,

    For version 0.016. While writing the code I've been thinking about how it would react in flicker conditions. And it's quite likely I'll need to make some extra modifications to the Object Manager to give object preference at times. In other words, some objects, particularly room-loaded objects, may be negatively affected by flickering. So for those objects, it would be best to not let them flicker at all, at the cost of the other objects flickering a little worse. (or perhaps a lot worse, but it's not going to be possible to grab hundreds of objects and toss them in the same room in Action RPG so it shouldn't be TOO bad for these special conditions.)
     
    Been pondering the situation over the week while I dabble with the other code. The modifications that this'll need, along with the otherwise busy week at work, is probably going to prevent a Saturday release as hoped. But maybe I'll surprise myself.
  7. Mord

    Room Loader

    By Mord,

    Accomplished step 1. Optimize the Room Loader as it is now. Probably saved 30-50 bytes with the simplistic/obvious fixes I used. I'll probably ponder better ways later that include redesigning the room data's format. One that'll let me do all down-counters. Since the rooms currently used in the rom are test rooms only, I'm guessing it's safe to put it off until I have all the things I know I'll want implemented added to the format that relate to the room.
     
    Remaining steps:
     
    1. Write up the room-based object I want to add for this test. This includes it's graphics, it's AI, and it's collision routines.
    (I have the graphics done, and the routines written in pseudo-form. Just need to write the actual code.)
     
    2. Decide on how to add the object to the room format.
     
    3. Modify the current Test Realm slightly to add the room objects so they'll trigger properly when you enter the room.
     
     
    Not sure how much I'll get done tonight as I seem to be absent minded and wandering over to play the consoles. But I suspect the latest date for this version would be Saturday.
  8. Mord

    (Action RPG) Version 0.015

    By Mord,

    And done. Mostly it seems a couple of the glitches that cropped up were just me confusing the meaning of some variables. And then "fixing" things that weren't broken. In the end I refreshed some of the code I was fixing and found the real culprit. (A comparison on the Heart AI and unnecessary checks on hardware sprites on the key AI)
     
    Flicker works as expected although I can think up a few ways to help reduce flicker. Right now, for instance, even if the key isn't displayed on the screen due to being too close to the right it is still using up an object slot as far as the object manager is concerned. Thus causing just 2 sprites to flicker on the screen.
     
    I was also pondering newer display kernels and ways to make the screen scroll from one screen to the next instead of instantly loading the new frame. The horizontal scrolling would require async playfield use which would be impossible if the sprites are being displayed but I figure it would be acceptable. It makes sense to not display the sprites or update them while the scrolling is taking place anyway. (time is technically stopped during this visual effect! )
     
    Something to ponder at any rate. I would like to experiment with async playfields anyway so this would be a good enough reason to tinker with it in a future version.
     
    But for version 0.016 I want to tinker with the room loader itself. Optimize it a little. Perhaps alter the room format to use fewer bytes or enable the format to make use of existing data more often. (It can already do that for the playfield data itself as noticed by the castle rooms. One castle room points to the castle data of the other instead of explicitedly using bytes of rom for it's own copy.)
     
    Additionally Room Objects will be implimented. These are local objects that are loaded when the player enters the room, as specified in the room data itself. Eventually it'll be possible to load objects that are in the room's specs after certain conditions are met. (They would remain offscreen and non-flickering until that condition is met.) This keeps ram use regarding these objects to a minimum even tho they may be something that is always in existance - or at least must remember it's current state all the time.
     
    I've already thought of several potential uses for this. One of the easier uses of those you'll see in the next version!
  9. Mord

    Fix one, get another.

    By Mord,

    Modified the heart placer to spam more hearts out, but more problems surfaced. The display itself is fine. These are with the AI routines. The flickerishness works, although it helped to unmask the AI glitches. The black key can still be lost when moving from screen to screen - if you're leaving a screen currently experiencing flicker. And the heart AI isn't correctly testing for itself. I'm guessing it just accidentally successfully found itself since the value being loaded just happened to equal the Heart_Item constant ID. (both 1.)
     
    This makes itself apparent when you enter a screen and the P1 gets loaded with the flashing heart (something that wouldn't happen before) You'd start flashing the same color as you'd expect - but then you leave the room and you continue to flash, only not red. Apparently the default color, or perhaps black/white. This indicates that it's still picking up the heart's AI condition and running the routine.
     
    Going to look at it tonight and tomorrow. Hopefully I'll fix up the bugs by Saturday evening.
  10. Mord
    I wrote a small diagram for visualizing what the display code was doing in the top 2 lines where the graphics corrupt. I'm going to keep that diagram. It kind of puts the code into a very simple to understand light. At any rate I knew for a while that there was a 1-off error corrupting the graphics I just wasn't sure what variable was off. Turns out it wasn't a variable but a constant. I was loading Gamefieldsize and Gamefieldsize+1 as the scanline to calculate the initial switchdraw graphics for the top two scanlines.
     
    Turns out I should have been using Gamefieldsize+1 instead of Gamefieldsize, and Gamefieldsize+2 instead of Gamefieldsize+1.
     
    The top of the screen appears to be working just fine now for both P0 and P1 as tested by trying to push the black key through the top of the screen with and without the heart on the screen. (As noted before, the black key is pushed into P1 when the heart is on the screen, but falls back to P0 when the heart is absent. Not an intended effect, but it's proven useful for visual testing.
     
    *tests some more*
     
    And it looks like there's no problems with the bottom of the screen. I guess the only problems I had with that revolved around P0 and P1 not displaying on the same scanlines properly given identical Sprite_Y's.
     
    So the only things left to do for Version 0.015 is to alter the heart placer so that the flickering can potentially be observed with a few more objects on the screen. I should be able to handle that... tomorrow or Saturday. Going to bed soon. Had overtime at work all week so far, and Friday's shift is looking to be more of the same. It's usually our light night, but there are several people booked off for vacation!
     
    Ah well. I need the overtime anyway.
  11. Mord
    I've ironed out 99% of what I found wrong with the display since version 0.014. There's no more stretching at the top of the screen, an object of coordinate Y can now be positioned in exactly the same place regardless of if P0 or P1 is displaying it. (noticable when you pick up a heart when the key is in the same room. )
     
    While not intended, in the rom so far the heart always ends up being slotted in P0. The key will display with P0 if the heart isn't on the screen. If the heart is present the key gets shoved into P1. The way to notice this is that the player always takes the color of P1. P1 is defaulted to blue if it is not currently displaying an object.
     
    Anyway, I seem to have most of the glitches fixed. The only remaining glitch is again with the top of the screen but it's an identical problem with both P1 and P0. An object appears to display the wrong sprite data in the top two scanlines. At least it doesn't stretch like it use to.
     
    Too tired to fix that right now. 5am. Going to bed. (I work nights, so I'm not as mal-adjusted for sleep as it would appear. )
     
    I haven't looked at how objects act at the bottom of the screen yet. I think they display normally but knowing my luck they won't be quite good enough. I'll worry about that after the top of the screen is completely fixed.
     
    After both sides of the screen are fixed I'll try to modify the heart-placer routine to fill up the object slots and essentially throw hearts around the test realm. There will still be a key tho. And that will be the release of Version 0.015.
     
    *update*
     
    After a bit of observeration and testing when I woke up this morning, I've determined where the faulty info is being drawn from for the top two scanlines on the gamefield area portion of the display. The incorrect data for the sprites that go up to those two scanlines (and it's consistant with both P0 and P1) is the wrong byte of data being drawn in on those scanlines. Instead of taking the top data byte it's taking the byte next to it - which happens to be the sprite's color.
     
    Don't have a lot of time today to do comprehensive studiez on it to write a fix but I'll see what I can do when I get home.
  12. Mord

    Display Fixing

    By Mord,

    I've fixed the stretching effect you'd see in version 0.014 when the object would get too close to the top of the screen. At least I think I have.
     
    *checks*
     
    Ok, it's almost fixed. Looks like one of the two sprites, while it doesn't stretch, it doesn't display proper data for one scanline above where it should start displaying. But otherwise it's progress! I'll do some quick checking on that now this evening.
     
    After this is fixed I'll be working on object coordinates. In the display, the coordinate values used by objects are different from those used by the player. Which of course makes things a bit funky whenever you need to base an object coordinate based on the player coordinate or vice versa - much like what I need to do for any object that the player will carry around with him in an Adventureish way. Luckily there won't be too many objects that will be like that. Many will go into inventory or be used up when touched, etc. But you know that monsters will need to interact with player coordinates often so this is something that I'll have to work with. First thing I need to do however is reliably get objects placed properly regardless of if they're being displayed by P0 or P1. This is the next step I'm taking.
     
    *addition*
     
    Vertical Delay is a pain in the ascii.
     
    That is all.
  13. Mord

    Long Weekend

    By Mord,

    And thus starts my long weekend as I decide to use a vacation day owed me tomorrow/friday. Was just feeling lazy all week in between coding. (I've already gotten some of the various bugs dealt with!)
     
    Friday is suppose to rain however, so I guess it'll be a long weekend in front of the computer/tv! Last few games I've completed recently include GC version of Twilight Princess, Grandia III, and .hack//GU Vol 1. I tried getting back on track with Shenmue II but once again lost interest.
     
    Right now I'm pondering if I want to plug the NES in for the weekend. If I owned Warsong or Master of Monsters I'd probably hook up the Genesis instead, but alas... There's also Phantasy Star 1 on the SMS... so many choices (in between writing code and the like!)
     
    Hmm. I'll have to think about it when I wake up, as I don't feel like digging out any consoles just yet.
  14. Mord

    Action RPG Version 0.014

    By Mord,

    I'm done for the day. There are apparently some timing issues with moving between horizontal rooms. This is probably just a branch or something being pushed over a page boundary again. I'll deal with it when I jump back into the code for the next version.
     
    There are now two objects, both operating differently. The heart's been given an AI routine to make it flash it's color. Otherwise it acts the same way it use to as I haven't altered the Heart Placer function to fill up the item slots randomly.
     
    Additionally I added a black key. When you touch it, it'll position itself next to you and move with you. Indefinitely. There's no way to drop it for now. You can pick it up and move it around in the rooms. You'll see how the object manager handles 2 sprites together when you move it in a room with a heart.
     
    There are a couple of different sources of extra-scanline errors that have made themselves noticed with this version. They aren't critical on an emulator although i'm sure it'll cause a real TV to roll. Those are probably going to be the main focus of the next version but I'll also update the heart placer to fill up the item slots so that flicker can be observed just so there's a real difference in the rom between versions.
  15. Mord
    For budding 6502 programmers.
     
     

    ldx #7 ; We load the Collision Pointer. lda (SpriteP1_SpriteDataPtrLow),x ; sta Collision_PtrLow ; ldx #9 ; lda (SpriteP1_SpriteDataPtrLow),x ; sta Collision_PtrHigh ; jmp (Collision_PtrLow)
     
    This code compiles with dasm just fine.
     
    But it is INCORRECT. To get the proper addressing mode, you must use the Y instead of the X. Something I keep forgetting to double check since dasm won't break down on me when it compiles. I just spent an hour looking at the code and the associated code around it going "There's an error here. HERE. It is obvious. It has to be or I'd have found it by now... *stares at loading of pointer* I bet it's staring me right... in... the.... eye...."
     

     
    Anyway the basis for the real Collision Handler is now functioning for Player-to-object collisions. I can see some uses for object-object collision checks as well. That'll be easy enough to add in later. Next part to generalize is the object itself. Both it's AI routine, and it's collision routine. This step will be to rewrite the hardwired heart object so that's aware of where it is in the item list and act on the appropriate item slot. Right now it functions while hardwired to the Region 1 object slot.
     
    *edit*
     
    And I've just rewrote the collision function associated with the heart so that it can correctly update it's associated item slot.
     
    This caused a minor glitch in the graphics from timing issues - apparently the display code is so tight that it can't handle an item's graphics crossing a page boundary. I left a note in the source code close to where the objects would begin to keep an eye on that sort of stuff. (And to remind me it's an issue!) Regardless, cleared that up in short order.
     
    So only two parts remaining.
     
    1. Impliment the Object AI routines. (This would control monsters moving about, timers on temporary objects, etc.) This promises to be easy enough. It'll be harder to try to make it run faster later on, or split it's AI running across multiple frames, etc. But for now it'll just check all 8 object slots to see if it holds an item to update, and run the associated functions if so.
     
     
    2. Rewrite the Heart Placer routine to populate all item slots whenever it finds an empty slot. This is just a temp function so I can see how things are working.
     
    I will probably add a few extra types of objects as well.
     
    But for now. sleep.
  16. Mord

    Progress!

    By Mord,

    As the screenshot shows, I've fixed a couple of things from version 0.013 already.
     
    1. The Object Manager is in place. This is the Real Deal. Although it will need a couple more tweaks and I'll probably try to make the code a bit more compact, this code is probably going to be used from this point on. It cycles through the list of existing objects, and selects up to 2 to display on the screen. If it finds 0 or 1, it'll make 1 full run through the list. If it finds 2, it'll also update it's ObjectPointer to point at the object immediately following the second object chosen to be displayed. This way on the next frame it'll start checking the objects from the new position - and as a result we have flicker management.
     
    The Object Manager tries to allocate an object to P0 first, only using P1 if 2 sprites need to be displayed. The player is drawn with P1's missile, so you'll need 2+ objects on the screen before the player starts changing colors.
     
    2. The graphics glitches caused in the code due to vertical delay on the 2-line kernal is finally crushed. I had the issue crushed with P1 yesterday before going to work. Fixed it with P0 just then when I got home. Just required a minor adjustment on what I was doing with P1.
     
    3. I had to adjust the collision detection for the heart to include both P0 and P1 so you could actually grab it with the new routine. Just a hack of a hack. That side of the item code still has to be worked on.
     
    And that's going to be the focus for this weekend. Code Cleanup and completion of the Object framework. (replacing what's already there for the heart with something that I can use for the actual game.)
  17. Mord

    Action RPG v013. Finally.

    By Mord,

    Spent about 4 hours today hunting the code for what was causing problems with the glitches. As per the replies I got in the Atari 2600 programming forum, the glitches were being caused by the routine I was using to clear main ram. It simply wasn't doing what I thought it was doing, and since it was copied code I didn't suspect it as a problem. Since I'm positive I copied that code with copy/paste, I guess I copied it from one of the chapters that had an error in it. The proper routine (8 bytes long) works as expected to init the system.
     
    With that out of the way I had a few other errors that had to be fixed, and I believe I have them squashed for now. Although the system I have in the rom right now isn't the exact system I ultimately want. It has to be rewritten to deal with with more situations, flicker, etc. I already know how I'll expand the object system to handle the necessary situations. It's just going to take a while for me to get around to it. There are a few errors that are still present as well that need to be dealt with, but they're not critical for this release.
     
    *edit*
    The main error you'll notice is that the heart object will occationally have corrupted graphics. This is due to the double line kernal and how I've been handling the data. It needs a minor correction based on what hardware sprite is being used and if it's on an even or odd scanline. I've had ideas on how to fix that in the past but I'll have to take some time to review the code to make sure I know what I'm going to do about it. It's the very next thing to get worked on.
     
    I've fixed the corrupted graphics on my working copy. Just needed the SpriteEnd to be incremented by 1 in cases where vertical delay was turned on for the associated graphic.
     
    *end edit*
     
    At any rate, here's Version 0.013. It's the first version that has tangible objects in that the object is actually only found in a single room at any given time, and when touched it triggers it's associated collision routine. In this case, it's just a heart icon (or is suppose to be!) and when you touch it, it vanishes and gives you 8hp.
     
    A demo program keeps recreating the heart in pseudo-random locations in the region once it's picked up. If your hp goes
    over maximum, it gets roughly halved. At some point after it fills the object is going to randomly appear inside the wall somewhere and seem to disappear. (in the purple castle room) The pseudo-randomness is predictable right now since this is the only place the random number routine is used. Works well enough for demonstration purposes at least.
     
    The way the HP is added to the player when the heart is picked up is by the heart dropping the hp into a "health bank". The health bank then gradually moves the hp over to the player 1hp per frame. If I add a regeneration spell effect/power, I'll just add a check in this routine to add X hp to the health bank per game tick. Since the health bank's routine is called every frame, it'll do the rest of the work normally. This routine will also do the checking to make sure the player doesn't go over their max hp.
  18. Mord

    Action RPG Buggy Rom

    By Mord,

    Here's the rom of the elusive pseudo-random bug. I tested it on the krok cart and while the data was wrong still, it remained constant all the time. Probably an effect of how the superchip is done on the krok.
     
    To see the bug in action on the emulator (I've just been using Stella) start the emulator, start the rom. Notice the weirdness regarding the player. You should just be seeing a single copy of the missile sprite for the player in a squarish formation. Offhand not sure what the color is suppose to be, but you'll notice it's affected as well.
     
    If you esc out of that back to the rom list and start the rom up again, you shouldn't see a difference. It'll all look funky but in the same way it was before.
     
    Now shut down Stella completely. Start it back up, and load the rom again. You'll probably notice the player size/copies/color is different. It'll stay that same different configuration til you shut Stella down completely again.
  19. Mord

    Music Link Time

    By Mord,

    Oh Hi Thar. I thought since I'm listening through the songs on his site again, that I'd drop a link to Jonathan Coulton. Good songs, much fun.
     
    Still haven't had a lot of luck with the rom, although been editting it for a few little errors here and there. I'll dig up and post the last rom that shows the problem tomorrow so others can see why it's driving me nuts.
     
    Hm. Krokodile Cart supports Superchip carts iirc... I should try it on real hardware to see how it behaves on the 2600...
  20. Mord
    Working away at version for 0.013 and since I'm running away from the code I'll give a general idea what I'm planning on having this release do when I'm finished.
     
    The display has been lightened up some already, but it's looking like trying to iron out timing issues with branches crossing page boundaries is going to be a nightmare. I did a manual count of the bytes to see how things would fall. As it turns out there was a branch crossing right on the boundary. When I did a little moving of code to fix that, I still ended up with some problems. The skipping I noticed before was less noticable, but in some situations still happened - but now only when the player crossed the vertical lines occupied by the hardware sprite updates. Additionally, the status bar started acting up again due to it being moved and resulting in it crossing a page boundary. I've undone the changes for now. I'll work on that in version 0.014 as well as try to finish up a bit more in the status bar. I'm seriously considering getting rid of the purple mana bar and replace it with something else. Something for me to think about anyway.
     
    *cough*
     
    As for what version 0.013 WILL do, is have an actual item! Up until now the sprites seen in the test roms have all been for the most part preloaded and hardwired info. There was nothing to change them, nothing to move them, nothing to even check if they're -suppose- to be displayed or not. This will change, although the object code I'm placing in this version will be the absolute minimum required - if I let it get too complicated right now I'll never finish. (This is why I've been procrastinating on the code since christmas)
     
    So here's what will happen. I'll probably redo the data for the test realm and make sure it uses 8 bare rooms of various colors. Then the game will check a specific item slot in ram (to simplify matters.) for the Heart item. If the heart is not found, it will load the item into that slot, with random values for the room, X, and Y, and Input variables. Input is not a very descriptive name. It means different things based on the type of object. If the object was intended to move this is where it would look for what direction to move, for instance.
     
    For the heart, which is just a hp-up item, the value of Input gets added to current HP when it's touched then the item vanishes. This means I can either randomize the hp restored from a dropped heart or make the item's value slowly decrease, or increase, over time. Perhaps making it vanish when it's Input equals 0.
     
    I'm going to remove the HP alterating demo subroutine from 0.013. HP will be set to 0. There's not death condition in the code yet so I don't need to set it to 1. On startup the Heart won't exist so the game will quickly load one into one of the 8 rooms. Player moves about to find and pick it up. Their HP gage will fill slightly. Object is removed from the world and the game detects the missing heart so it recreates a new one. Again randomly placed in the rooms. This will repeat.
     
    I'm not going to bother adding a "win" condition to this as it's just a demo. I'll also not bother limiting the hp. I'll let it wrap around, emptying when it gets filled too much.
     
    I'm caught between having the hp restore happen gradually (at a rate of 1hp per screen) or all at once. All at once would be the easiest thing to do, but having the gradual restore might look better. Essentially I'd have the heart dump it's healing value into a different ram location which would then slowly be subtracted from and added to the player's health.
     
    I'll probably attempt it just to see, but if it looks like it's going to be more trouble than it's worth, I'll probably remove it again for this version, if not for all.
     
    I've lifted some random number code that I got off of either stella or the atari age forums. Probably both. It looks like it'll work well enough for my purposes.
  21. Mord
    For info on my wonderful week of the move, see here . I don't feel like retyping and whatnot.
     
    One thing I will add however is that during the move my 250gig maxtor harddrive which was put in an external usb drive kit had fallen on the pavement while putting it in the car. Lots of dust apparently spewed out of it according to my sister. I was ready to write it off as dead, but when I finally got power back and hooked it up, it apparently still works fine. It's mostly a backup drive anyway, so there's not much if anything that I would have really lost beyond convenience. (I would have to dig through the dvd discs for the lost data otherwise.)
     
    Anyway, I'm on vacation for 2 weeks now. Hopefully this means I'll have time for some serious coding.
  22. Mord

    Moving and Homebrews

    By Mord,

    Nearly time to go sign the lease and get the keys for the new apartment (on friday). Haven't heard back from them, so that's a Good Thing. (The appointment to get the keys is already set as a given, so long as there were no problems with the application at which point they'd call me. And as they said before, they aren't expecting problems.) Later today when I wake up I'm going to see about making sure some relatives are willing to help me move my stuff over the last week of the month so to hopefully avoid the need to rent a truck. I have almost everything packed away into boxes at this point, except for various things plus the few pieces of furniture I have for the bedroom.
     
    After I'm settled away at the new place, I'm going to see about putting a renewed effort into homebrews. Action RPG is tapering off almost like I expected to - I have plenty of ideas written up for it, but trying to get the determination to sit down and write code is hard right now. I'm hoping that the new living arrangement will help me get back into the mood, especially since I'll finally have room to hook up my 2600 for easy testing of new roms!
     
    I'm thinking about starting an extra game project on the 2600 as well, something far simpler, to help mix things up. Sometimes I get burnt out on Action RPG to the point where rather than face the code blocks ahead, I simply don't look at the code period. With something that's going to be (had better be!) simple, hopefully I'll just switch to that to tinker on for a while when Action RPG starts to make me run around screaming.
     
    Of course, there's also that Raster Music Tracker that I want to learn how to use. If anyone knows of some detailed, yet easy to understand, tutorials for it, drop me a link or two to it please.
  23. Mord

    Apartment Hunts

    By Mord,

    It's possible that I've got a new apartment to move into for the end of the month now. Damage deposit etc all paid, so unless they have issues with the application it's a done deal. They seemed to be ok with it and aren't expecting any problems at least, so I'm going to pray everything works out as planned. I'd rather worry about how I'm going to move and when, rather than the Where. (And seriously, if they take longer than friday to get back to me about it, it's really going to screw over my chances of finding another place in time.)
     
    Oh well. I guess I'll concentrate on finishing up the packing tomorrow...
     
    --
    Mord
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...