Jump to content

Mord

Members
  • Content Count

    2,986
  • Joined

  • Last visited

  • Days Won

    2

Blog Entries posted by Mord

  1. Mord
    So while trying to do up semi-humanoid characters, I realized I suck at doing this. More than I anticipated that is. So, let's just BS an armless blob of a monster with stubby feet and call it the hero! It's going to be "fun" trying to figure out what this guy's powers are going to be. XD
     
    Going to be more fun trying to figure out what kind of game I'm even making. Oh well, to heck with planning, it's only ever aided my procrastination anyway!
     

     
    Yes I'm aware of the number of colors used in the image, given any game with this little blob will likely be in 160A. That's not an issue as the teeth and eyes will be drawn first with a specific sprite, then the main monster plotted over it - letting the eyes and teeth shine through some transparent gaps in the main sprites. Animations for walking left and right are done. Up and Down walking are tentatively done but I want to try to rework them a bit more.
     
  2. Mord
    Sharing a post I made to Livejournal just to potentially get more responses. I'm mostly just looking for suggestions and opinions at this stage, I'll be doing my own research throughout the summer anyway before I start trying to buy components likely 1/month.

  3. Mord
    I seem to have started regaining a desire to make the 2600 Do Stuff.
     
    Most likely I'm going to try to start from scratch on the whole Action RPG/Maze Realms idea. Trying to get the old program to do anything new generally resulted in a lost month of bug fixing with nothing done.
     
    Dasm and crimson editor is installed again, and I've re-bookmarked the old resources I use to have on the old computer. Going to try to find time to actually do stuff with it by the weekend - at least try to work out how the display kernel is going to work. I'm pretty sure I've already planned far more ideas than will be able to fit on a cartridge, but oh well!
  4. Mord
    I've recently taken the 486 computer I've had in storage since 2004 and put it back together.
     
    For the most part, it works! Well, as much as it ever did. The only thing of note is that the left ALT key on the keyboard doesn't seem to function. I'm not sure if there's just something wedged under it or if it's outright broken.
     
    *checks*
     
    Could be either. I'll know for sure if the crap I blew away from it was causing the problem the next time I turn it on. The right ALT key works fine at any rate so it's not that big a deal.
     
    There are things on it I'd like to get off like old qbasic programs, etc but to do that I needed 3.5" diskettes as that's about the only way to take anything off of it's 400 megabyte harddrive.
     
    Luckily I found some of those at Future Shop today! Might start using the comp just for fiddling around with qbasic rather than messing around with some other basic in a more current console. I've got ideas of what I want to test out, and I know that they should be within my capability since I've already done similar programs with qbasic back in the 90's. So the question is whether or not I'll remember enough of it to do anything productive.
  5. Mord
    Just so you know where the subject is coming from, it's from here.
     
     
    You know, the whole attack on the secondhand game market makes me sick.
     
    The rabid fanbase that defends the attack as something nobel and justified also makes me sick.
     
    It makes me violently ill whenever I see those dicks trying to rationalize it, especially when they compare buyers of secondhand games to the likes of copyright infringers. "Pirates" for those who like incorrect terminology.
     
    Needless to say, I get sick reading Kotaku comments on any article that touches on this.
     
    Here's my take on the situation. Individuals and companies that produce some sort of new content, regardless of type of goods, have the right of first sale. This is because they are the only ones allowed to actually create new copies. However once a particular copy is sold, and to do so this means the producing company has earned their money on the sale of that particular copy, their rights to future $$ brought in by the resale of that game IS NONEXISTANT. This is how it is suppose to work. It doesn't matter how much the game/cd/movie/microwave cost to develop. If it's costing more to develop than the profit it brings in, and you're actually trying to support a company on it, either remove the waste from the development cycle or charge enough to get by. Or learn how to do Hollywood accounting like the movie industry so you can claim you "just" break even on every game that earns you 500 million dollars profit.
     
    So needless to say one of the reasons I hate the turn to DLC is because it's just a way to cripple said secondhand market. A way to devalue your over expensive games to anyone else even though it's still in mint condition.
     
    Another reason I hate it is because 10-20 years down the road when the DLC is no longer hosted (See Microsoft's current decision to remove all original Xbox DLC/patches from their service) everyone will be left with defective, bug ridden discs to trade back and forth. Even if they bought it new AND paid for the DLC. Your harddrives aren't going to last forever in those consoles. It's being shown now that the DLC won't be around forever. And in some cases the game patches are borderline NECESSARY to enjoy the game. (Fable II is a good example of this apparently.)
     
    Ugh. Making me sick even talking about this shit. I'll conclude with this. IF a publisher or developer wants extra profits from the secondhand market, they should actually PARTICIPATE in that secondhand market. (The problem of course is that THAT costs more than crippling the product and charging people to "fix" it.) There is NOTHING stopping a company from instituting their own buy-back system for their own games, even if it's just on their website. And as the original developers of the game, doing that could position them to offer more unique things for buy-backs than some discount on a future release.
  6. Mord
    So let me get this straight.
     
    No UMD Drive.
    Smaller screen.
    Non-replaceable battery that's as weak as the 1001 series.
    No memory stick duo support.
    Higher cost than existing PSP 3000. (Close to the price of a PS3 with the Slim's drop in price)
     
    No sale.
     
    I find it funny how they're trying to entice the european market to buy one with 3 free games from a limited selection of old first-party games. IF they already own a PSP. To qualify for the free games with your PSP Go you apparently have to sign into the playstation network with your old PSP with a umd in the drive. It's also more expensive over there, costing as much as a PS3.
  7. Mord
    Well, that was ... interesting.
     
    After spending the better part of yesterday with various installs of gnu/linux, most notably debian, I'm back on windows for the meantime. Debian would install properly but I couldn't for the life of me figure out exactly how to configure the adsl so I could get online. The required packages (apparently pppoe-config) were obviously not on CD1, which of course prevented me from apt-getting it. (or even successfully configuring the mirrors for apt-get to begin with.)
     
    I only had the first cd since the torrents on cd2+ of 20 odd were fairly devoid of any seeds and the website kept on saying "don't get them all, it's a waste of your time!" .. waste of time only if you can get online to apt-get it of course. You'd think they'd have all the necessary tools for getting online on the first CD >_>
     
    And debian didn't understand the file table format thing of the externals as well. apparently that's in a separate download as well. Well, at least it was able to detect it.
     
    So it's been a learning experience. I'm now currently on XP again and doing update patches. At least this got rid of all the useless programs that use to be on the comp that I installed at some point but never really used. So when that's back up to date, I'll see about obtaining a full set of the current debian install CDs at that point and possibly trying again. Hopefully by then I'll have a second computer.
     
    So ultimately the problems were: non-trivia internet setup, (could be fixed by adding that program knoppix uses), and ensuring support for that file table format thing. ... It's odd not knowing offhand what it's called when I know what I'm actually talking about. Oh well.
     
    By comparison, the Windows install just went on through, although it did a few reboots during the process. Not a fair comparison to make however. The recovery CD I have is MEANT to work on this particular hardware.
     
    *update*
     
    A friend helped me find potentially vital info for getting my connection set up with the debian installer. Vacation starts soon so I'll be offline for a while anyway, so I'll hold off until when I get back to take another stab at it.
     
    Seriously, I only had 2 noticable problems with Debian. The above explains how to hopefully fix the first one, and the second one can be fixed via an apt-get for support of the ntfs file system after the net is up. (From what I'm told!)
     
    So I'll live with windows for a few days, soak in the sun and rain for a few weeks, then get back and handle any outstanding colecovision shell orders I can afford and finally work on debian again.
  8. Mord
    While Ubuntu failed me, it looks like I can boot with either Knoppix or Slax from the liveCD. I'm posting this here, in fact, from Knoppix 6.01.
     
    Looks like they have noscript added to Ice Weasel (Basically rebranded firefox iirc) included. Excellent. I had a few problems at first trying to figure out how to connect with dsl, but help from irc friends got me through it.
     
    I suspect I'm very close to installing it directly to the harddrive, but I think food will come first.
  9. Mord
    I had my final wisdom tooth extracted about 24hrs ago. Took yesterday and today off work. Yesterday was obvious I wasn't going to get to work. While the pain is subdued at this point, I'm not sleeping that well and still have swelling and the like to deal with.
     
    Here's my livejournal entry that I made 16hrs after the operation at about 2am. Not too much to add to it except I've watched more anime dvds, including:
     
    Lost Universe Vol 3-4
    Tenchi Universe Vol 7... I think. Last in the series either way.
     
    Currently watching Blind Guardian's Imaginations through the Looking Glass. It should be over soon, at which point not sure what I'll watch. I was HOPING to watch the old VHS tapes I still have, but it looks like the cheap VCR I bought back in 2004 from Wal-mart died a quiet death in it's non-use at some point.
     
    For the extraction, there's obviously some swelling still, which is probably what's causing any pain I'm feeling. Nothing intolerable, but still I can't see myself doing much else today but sitting on the couch and resting/sleeping. I may have to run to the corner store to pick up more juice, but that's about it. I'm hoping I'll be eating pudding at the very least by the end of today.
     
    I guess my stomach understands the situation. I haven't had anything beyond a few glasses of juice and water in the last 32hrs or so and it's still not complaining.
  10. Mord
    While I posted this in the programming forums for others to use, I figure it'll be easier for me to find it later in my own blog if I need a backup of this thing or something. Right now it takes too many lines to position an object since I have the actual HMOVE separated from the positioning but it's at least a start. I guess the next thing I'll be doing is trying to integrate the hmove into the equation while keeping the time used constant. I'm guessing this is where the real pain starts for this kind of thing.
     
    As an overview of what's happening in the picture, the solid yellow strip is where the cycle 73 positioning is going on. The red dot is P0, the 4 bars is P1. P1 is being positioned regularly with a standard hmove during the VBLANK. P0 is being positioned during the yellow strip. Both are getting their X position from the variable Xpos and thus should always line up. Moving left and right is limited in range from 0-159.
  11. Mord
    Took me a few tries over the week, but nailed it this afternoon. Got all the legendary gear and remembered how to get the bell/ruby. Kept forgetting to meet with Catherine in the seaside town. When I finally got to the last castle, I decided to get the bell to help me get through the castle. Managed to get to the dragon with half life remaining plus a revival potion still in tow.
     
    I wonder if having the second best boots in the game are better for attacking the dragon. With the legendary boots you jump a little too high to efficiently clobber him in the head, perhaps with the second best boots you'd line up better. But that would make some other parts of the game harder to do so. Eh.
     
    One of the best tips I can probably give for making sure you have plenty of cash onhand for the legendary stuff is to avoid buyin the knight armor (150gp iirc). And instead make sure you can skip that and buy the Heavy armor which is technically better but for some reason costs just 100gp. Whether that's a bug/oversight or planned feature I have no idea, but it saves you a bit of cash in the long run. Also make sure you take advantage of the few overlapping maps. Like in the seaside town where the boss is that floating squid like thing. Make sure you don't fall underwater to get to that boss, collect the key and all the coins from it and on top of it's little room then go underwater. When you get back you're in a nearly identical map and the boss is fightable again for extra cash plus a life refill. There's a couple of places like that in the game.
     
    Anyway, next up is Phantasy Star 1 on the SMS. If it uses battery saves, I might have to hold off on it a bit if the battery is dead. If that's the case I'll open the cart to see what kind of battery is used and if I can replace it. Haven't tested it yet as I'm not going to start in on playing the game until tomorrow.
  12. Mord
    Eh, those two topics in the subject are unrelated at this point.
     
    Anyway, tried the ubuntu 8.10 live CD. Obviously have some hardware problems or something. It'd get to the menu no problem and I'd try to run from the disc (top option) both regularly and through the F4 option of a Visual Safe Boot setting. It would work away for a little bit and I'd see the unbuntu logo with a progress bar (that's really kind of pointless).
     
    Then it'll break to trying to Do Stuff. You'd see references of ada2.00 doing something and failing. Repeatedly. Over and over. Not entirely sure what it was doing, although I think it's mostly the exact same thing being done and failed over and over again. Left alone it'd keep doing so for 5+ minutes or more. The first time I tried this the screen blacked out after a while, but for all I know that could have been a screen saver kind of deal since I hadn't touched anything at all. I dunno. Regardless, it won't progress after this point. -_-
     
    I'll probably try to write it down next time to see if any linux veterans know what's going on.
     
     
    For homebrewing, after a year of not touching it, I decided to try to get back to Action RPG. I had made some pretty big messups a year ago and was trying to fix it up now and then but would always give it up after a while and ultimately nothing would get done. I'm reverting it to the last working version (0.018) and trying again. I still need to rework the way items work, but there are a couple of other things I want to fix prior to that that are less painful.
     
    I'm going to redefine "noflicker" objects to simply be whatever item is being held by the player. Up to version 0.018, it was possible for me to flag a room object as noflicker - such as a castle gate. In the new version the gates will obviously flicker. But if you're holding the key to it, the key won't! Which means it should remain fairly easy to open the gate even if it's blinking madly.
     
    For this attempt at version 0.019, that change will be made plus I'll add a bounding check for objects that pass through the left wall. (mostly due to being carried.) That check will just stop the object from being displayed if it's supposedly gone past the edge of the screen in that direction. In the current rom, what ends up happening is we get an extra scanline being generated in those situations which cause the screen to bump a bit. I've got a few ideas on how to tackle it.
  13. Mord
    Posted on my live journal about this as well, but I've been inspired to attempt switching over to linux again. I think there's a free program for most everything I do on the computer, although I'd have to find out what people use for 7800 emulation, if anything. Was mostly for games that I would drag my feet on the switch (As I'm too lazy to bother with dualbooting ) but when I think about it, I don't really play games on the computer anymore beyond the occational randomly addictive flash game so eh. So long as I don't procrastinate on it I guess...
     
    The goal is to be 100% linux (With wine for a couple things I guess) by the end of Febuary. We'll see how it goes.
  14. Mord
    And Portrait of Ruin is complete. I didn't unlock everything or get every spell/weapon this time around, I just focused on getting the good ending. I still have my save game for where I DID unlock just about everything however! The map complete is like 999.8 or something like that. So I'm guessing it's just missing dracula's room.
     
    Hm. Despite owning the DS for a few years longer, I seem to have more PSP games. (mostly rpgs) Trying to leave the games I still have in shrinkwrap sealed (About 10 that I bought this year - just never got around to opening them.) until I play through most of what I have that's unsealed. This leaves me with just 3 choices for the next DS game. Trace Memory, Tao's Adventure, and Lunar: Dragon Song. I bought Dragon Song because I'm a lunar fan, although I'd have to agree with most of the reviews I see of the game and say it's Not That Great from what I have played of it. But then I haven't played too far into it in the past before getting bored. I suspect I'm not going to make a decision right away. I could just as easily play through some of the GBA games instead. Ah well.
  15. Mord
    Finished this on the PSP today, the good ending. Got all the maidens and maria unlocked and both the original Rondo of Blood and Symphony of the Night unlocked.
     
    Funny thing. While just playing with SotN I decided I wouldn't attempt for the keep-all-your-gear trick with Death at the beginning. I could never get it to work anyway on the playstation. At the last second I figgered "What the heck." and got it. So I moved on to the first save point for it and saved. Didn't feel like playing through it tho.
     
    Played a little of the original Rondo game as well, although I'll probably save going through that for later. Not sure what game I'll pick for the PSP next but it might be one of the rpgs I got for it.
     
    Otherwise going through Dynasty Warriors 6 musou modes still and powering up characters. Completed Ma Chao, got so far with Zhao Yun, and on the last stage (I think) for Zhuge Liang. Going to need to power him up a little more in free mode however. Also started redoing Portrait of Ruin after all. Figured I might as well get all 3 of the DS castlevanias out of the way.
  16. Mord
    I've started attempting to learn php again in an attempt to overhaul my own website in the future. Should be relatively easy this time since it's actually a lot like Kermit, which I've been fiddling around with at work lately. Which means they're both similar to C.
     
    Printed off a bunch of tutorials to read on break at work regarding file manipulation and the like. I'll be printing off the less advanced stuff as well tomorrow or something just so I know the syntax. This is pretty much the same approach I had towards learning assembly for the 2600 - printing off all of Andrew's tutorials and putting them into a binder to review whenever I had a spare minute. That and actually doing as well.
     
    I currently have my main site up on dreamhosters at present, which has php installed, so testing random stuff should be fairly easy. I just have to decide on a layout for the overall page now so I can get an idea of what I actually need from php.
  17. Mord
    They are distilled liquid pain to use.
     
    I hooked up the 7800 to test out the new games I got for it over the weekend (Dark Chambers, Ms. Pacman, Galaga, Pole Position II (a double, but a dollar wasn't a bad price tag) Donkey Kong, and Xevious.)
     
    I couldn't play for even 15 minutes. (Although Ms. Pacman wasn't that hard to play.)
     
    I suppose I should seriously consider getting some of those european styled controllers.
  18. Mord
    Phase 1 was simple. Just adjusting the hotspots for the existing rom and adding 2 dummy banks. I did that in 10 minutes without any glitches.
     
    Phase 2 was more challenging. The moving of all vertical blank code out of the Display Bank (bank 0) into it's own bank (bank 2) and then adjusting the code to allow quick movement between the banks. One problem with this is that I also wanted the startup code out of the Display Bank. But the Display Bank was where the labels were. Got around this the cheap way by compiling the Display Bank first, then looking through the output for the label values to plug into Bank 2 before compiling it. The less unnecessary code I have in the Display Bank, the more space I have for different monsters/items.
     
    After replacing a few labels here and there and patching the values in, it assembled properly. Of course, it had better have assembled properly since I didn't edit the code itself, and I was after re-re-re-re-re-rechecking the code and stepping through the source code to make sure it was all linked properly long before the first assembly attempt. Yeah, that's why there haven't been any real updates in a week.
     
    Plus I procrastinate.
     
    The final phase is to take the remaining tick-based code, collision code, and other misc overscan logic and shove it into Bank 3.
     
    This will give me a general layout of:
     
    Bank 0: Display Code + Object Graphics.
    Bank 1: Room Loader + Room Data.
    Bank 2: Screen Setup (positioning/loading sprites etc) + Object AI.
    Bank 3: Collision testing and Game Tick code. (Game Tick code being stuff that only triggers once every 5-6 frames.)
     
    Eventually I'll probably step up to 32k to get the extra 4 banks but we'll see about that a bit later. It should be easier to add banks from this since different banks hold different things. For instance some room types may require a new display kernel. I could just write the new kernel in bank 4 and have the vertical blank switch to the proper kernel with a quick test on room-type or something similar.
     
    Additionally I'll eventually be wanting sound effects etc. Sound code could all go into it's own bank and I'd probably add Atarivox related code to that bank as well.
     
    Food for thought for now at any rate. One thing I want to do at the end of this upgrade is to modify the random-number routine. Right now it's just:
     

    NextRandom SUBROUTINE lda random beq .doEor lsr bcc .skipEor .doEor: eor #RAND_EOR_8 .skipEor: sta random rts
     
    A routine I yanked from either the Atari Age forums themselves, or the mini-dig or something like that.
    RAND_EOR_8 is a constant defined in constants.h based on suggestions given with the routine. It works well, but it's a bit predictable and limited when you really try to see it's effects in the version roms I've released up to now. (The repositioning hearts are using it to determine their new position)
     
    So the new routine will probably run something like this
     

    NextRandom SUBROUTINE lda random beq .doEor lsr adc SWCHA adc Incrementer adc GameTick bcc .skipEor .doEor: eor #RAND_EOR_8 sbc SWCHB .skipEor: sta random rts
     
    Essentially the same routine but with a few constantly changing variables thrown in. Incrementer is incremented by 1 every frame. GameTick works similarly, but it only advances up to 5-6 (based on tv type) before it wraps around. the SWCHA and SWTCB are self explanatory. Any other variables I add will have to be something I can depend on changing over frames. The sweet spot would be finding X changing variables while keeping the speed of the function itself within reason.
     
    There's all sorts of variables I suppose that could be used really, but perhaps the above should be fine. I'll test it out later after the overscan is moved.
  19. Mord
    I've worked on that some more since the last time I looked at it. And I was apparently wrong with it being a problem with the Tick based code. (That might have been a problem as well, but fixing it didn't change the behaviour)
     
    The real problem, (this time I'm pretty sure it's the case!) is that I was examining the P1P0 collision during the Vertical Blank of the following frame in AI routines. The problem is that, by necessity, the AI routines are processed after the Object Manager does it's work.
     
    What does the Object Manager do again? It handles the object flickering of course. So basically, unless there was no flickering going on, by the time we examined the detected P0P1 collision, our key object would have been swapped out with a different object to be displayed. Because of this, when the key touched the gate it would fail to recognize it because it would be checking the new object loaded into the hardware sprite to see if it was the key - and of course it wouldn't be!
     
    I could probably test this by having just 1 other object in the room touching the gate instead of the key. What would happen is that that object would be touching the gate and causing it to react as if it were the key - so long as the key was on the screen.
     
    So I'm re-writing the approach and at the same time making the GateMovement routines generalized enough to handle all possible gates. There will be probably up to or more than 8 gates in total. (1 bit per gate to keep track of if it is currently open or closed)
     
    Hopefully I'll have it done by the end of the weekend. The code is 2/3 written (just the AI to do) but you know there's going to be weird bugs all over the place.
     
    *update*
     
    As mentioned in comments below, here's a beta for 0.018. It's got all the physical changes I want to do - and the only thing anyone would notice by looking at it is the gate collisions aren't messed up by flickering - but still have to update to a 16k rom size to finish this version.
  20. Mord
    Ok, so adding the fire button to drop the objects wasn't as difficult as I feared. Just make sure the latches on the fire buttons are turned off, and add a counter on the frames. Incrementing it (up to FF but no wrapping) when it detects the button is pressed, and taking an action when the button is released based on the counter. If >= SomeValue, then drop the object, otherwise assume the player wanted to use the currently equipped item.
     
    Equipped items don't work yet obviously. So pressing the button quickly just results in no action.
     
    The current value is set to 60, for roughly 1 second in NTSC types. Later on when I actually consider PAL systems, I'll be setting up the constants file to compile with different settings based on what type of system it's being compiled for. So for a pal system the value would be roughly 50 instead.
     
    Sadly, there are no sound effects yet. So you won't know if you successfully dropped the item until you try to move away from it after releasing the button.
     
    Additionally I noticed that sometimes the gate won't open when touched. I'm not sure exactly what causes this, other than it only happens when it's flickering. Based on the flickering colors of the player, there's some wastage going on - you can see the default blue color flashing in between the black and heart colors. This means no object at all was selected for that frame. Still, there are frames when the key IS on the screen. And the gate is never blinking... so it -should- respond anyway.
     
    I'll worry about that in the next version. If you notice that happening, just pick up the hearts in the room first and try again.
  21. Mord
    One of the things I've been wrestling with as I write the basic engines for Action RPG is exactly how the player will be able to move about and interact in the game. As I make more and more progress it's getting harder to put off these decisions! So on the way to work yesterday I started writing down more notes and thought them over.
     
    I intend on the player having access to a limited inventory screen to store various usable items, this may include some types of keys.
     
    Of those items, one will be considered "equipped". In the rom, the equipped item would appear on the right side of the status bar, where I'm currently using an ugly looking trophy thing as a place holder. If an object can go into inventory, it will immediately disappear and go there when the player touches it. How the object will react if the inventory is full I'm not sure of yet. Something to decide later.
     
    Additionally, there are some objects that can not go into inventory. Instead their effects take place as soon as the object is touched. The hearts in the current rom are an example of these.
     
    Finally (for now) there are holdable objects. These objects don't go into inventory, nor do they take effect as soon as they're touched. Instead you pick them up and carry them around with you. You will be able to hold only one object at a time in this manner. Picking up a different object while holding another one will cause the first one to be dropped. (Much like in Adventure.) The black key in the rom is not a complete hold object. It's just a hack job to get something like that working temporarily. This next version of the rom however should have the key updated to be pretty much how holdable objects will work.
     
     
    At any rate, I was having trouble thinking of how to get using the equipped object and dropping held objects with just the fire button until yesterday. Instead of looking for the button to be pressed, I'll wait for the button to be released. So:
     
    To use equipped objects (something that may be needed to be done quickly) you would press the button and release it relatively quickly. Every frame a counter would increase from zero topping off at FF on any frame where the button was found to be pressed. If the button is found to be not pressed, it would check the counter. If it's zero, do nothing. (Wasn't pressed since last frame) If 1-SomeNumber, likely 50-60, then Do_Equiped_Object_Effects. Otherwise, drop item. (keeping in mind that it wouldn't see the zero case in that "otherwise". ) In both DoEquipedObjectEffects and DropItem, the counter will be zeroed as well.
     
    Some people may want the DoEquipedObjectEffects to happen as soon as the button is pressed however - the delay can throw off someone's concentration/aim/etc. So I've been thinking of reserving one of the difficulty switches to switch between the "modes". That way they can just reach down to the console and flip it as needed. Hm. Maybe the BW/Color switch would be a better candidate...
  22. Mord
    Z's are always hip.
     
    Problems propped up with my object code test, from the superchip detection to something causing it to read the zero page for information. Thus, no rom over the weekend.
     
    I'm probably going to attempt to work on the rom's organization a bit this week and re-examine the new code I had prepared. Right now I think I'll try to find the isolated code segments (Vblank code, Overscan code, the collision detection code, etc) and move them into their own files and have them include-ed in the main rom. Would be easier for me to find the code I'm looking for if nothing else.
     
    Oh, and Dr. Pepper sucks. I'm glad I won this one rather than buying it outright.
  23. Mord
    I've been wracking my brain in hopes of having a new way to do Action RPG's display kernal to save space. Manually counting up the the byte requirements, the display kernal requires about 689 bytes. Could be a bit more. Could be a bit less. But 689 is a lot, especially when you consider it's a 5-stage display kernal. I wanted to find a way to reduce that, hopefully drastically. If I could get it to fit in 512 or less bytes I'd be happy. But that means I needed to find a way to drop some of the stages.
     
    At first I considered using a modified SwitchDraw to determine when to turn the player on and off but I was a couple cycles short. That's when a google search ended up reminding me of Banked Draw from here.
     
    Banked Draw is slightly faster but has it's own limitations and of course requires the large rom table. When you're trying to reduce rom used, adding a large rom table is counterproductive. So Banked Draw wasn't useful. However it did get me wondering how to use a similar technique to trigger the player's ENAM.
     
    To make a long story short, while working on this twisted attempt to drop rom use to 2.5 stages, I realized I would have to reduce myself to using only 1 missile for the player.
     
    So if I was going to do that, I decided I can probably cut out a couple stages in the existing routine without much change and achieve the same effect. So that's what I've done so far. I had to sacrifice one of the missile sprites for this but that's fine for now. I tried adding the second missile back in afterwards just to see what would happen (We'd have the striped player back instead of the box) but found it would occationally take up too many cycles and cause the screen to jitter as an extra line is added. Doing a few cycle counts, it looks like at least one branch is using EXACTLY 76 cycles. But at least one of it's branches in the line is crossing a page boundary in some conditions :!:
     
    So, there's a small chance I might be able to add that missile back in before version 0.013 is finished. I just have to examine the code under a microscope and see if I can reposition the code so that no page boundaries cross. (I'm way too tired for that right now at 3:30am)
     
    I'm too tired to do a manual count of the bytes used in the new routine as well. However by counting the first stage, knowing that all 3 stages are similar in size, it looks like the final routine is somewhere in the range of 450 bytes. If that's accurate then I've met my <512 byte goal!
     
    Beta for 0.013 is below and a screenshot. Yeah, I know not much change from the last many versions. I'll see about adding some extra functionality to this thing before 0.013 is completed. (Hopefully by the weekend if I can stay focused!)
     
     
    And for the love of binary will somebody take my commas away from me. I'm after going back up and removing over 17 unnecessary commas from this post while previewing.
  24. Mord
    The company I work for gave out cheques for 1 week's pay to employees since it was another record breaking year for the company (compared to it's performance in previous years and whatnot) So it looks like I may be able to place an order in the AA store after all. Still can't get much, and certainly can't spend over 100 for the free christmas cart, but I'm definitely going to look into an Atarivox if nothing else.
     
    With regards to the rom, more work is necessary than I originally expected for this version. Don't know if I'll have version 0.011 done before christmas. Got some timing issues to look at and make sure the way I'm storing sprites is handled properly. The way it's done right now, with sprites interweaved, I have to make sure that I adjust the SpriteEnd variables for P0 and P1 depending on if they're even or odd. If it's the wrong value (thanks to the scanline pair approach) then it'll show the wrong sprite and usually a cut up portion of it. An easier fix would add two lines for every line of sprite in the rom but that's more waste than I feel comfortable with.
     
     
    *Addition*
     
    I have the Atarivox ordered and the money order (I don't have paypal) in the mail. Additionally I picked up Castlevania: Portrait of Ruin on the way to work. Of the series I essentially grew up on (Megaman, Castlevania, Super Mario Bros, Double Dragon, etc) the only one I really seem to have stayed interested in has been Castlevania.
     
    Megaman kicked the bucket with the move to the PS2. I still haven't done much with X7 and it's not very high on the priority list. Started to dislike Mario once it jumped to 3d. The others weren't that high, although Zelda is still pretty high. We'll see where it stands when I I play Twilight Princess, but that won't be for a while. (I lost interest in WindWaker fairly early. Maybe one day I'll go back to it.)
     
    Hm. When I think about it, the only game I considered to be improved with the jump to 3d has been Zelda.
     
    Oh well.
  25. Mord
    Of course, this means saving compared to how I use to do it. To maintain player movement while they're trying to push along a wall as they move in the collision tests I have to take into account wasted frames and on successive direction tests jump further to make up for lost time.
     
    Since horizontal tests are done first, to test movement in the horizontal direction I double the speed prior to moving. Originally I just went through the full 16-bit addition sequence twice. On average that would take up about 80 odd cycles due to the generalized functions I used in it. Those functions are still in the rom but I'm not using them for player movement/collision anymore. I can use those for moving less frequent movement. (monsters/items notably. For the rare couple of items that the player will actually be able to move around with I'll have the item refresh it's X/Y with an offset from the player's X/Y instead of calculating it's movement separately. That should be faster...)
     
    Anyway this is what I did for the Move-Right test. I tested it in the rom and it seems to work reliably. IE: Far more efficient than what I was doing.
     
    The subtraction routine (moving left) however is still a bit icky. Right now I just skipped out with putting the subtraction in a tiny 2-pass loop. Still more efficient than before but I'm hoping to think up something similar like the below.
     

    ; Horizontal Move Test ( Moving Right ) ; This forces a double-step in the right direction. clc ; 1, 2 ; This part handles double-addition of whole part. lda SpeedX ; 2, 3 ; Realistically "SpeedX" will never be very high, normally 0-4 at most.) asl ; 1, 2 ; so there's not going to be any carry flag to worry about. adc PlayerX ; 2, 3 ; sta PlayerX ; 2, 3 ; ; we can assume the carry is still cleared. lda SpeedXf ; 2, 3 ; asl ; 1, 2 ; bcc .MovePlayerHorizontal_Skip1; 2, 2/3; inc PlayerX ; 2, 5 ; clc ; 1, 2 ; .MovePlayerHorizontal_Skip1 adc PlayerXf ; 2, 3 ; sta PlayerXf ; 2, 3 ; lda #0 ; 2, 2 ; adc PlayerX ; 2, 3 ; adds any carry left over to PlayerX. sta PlayerX ; 2, 3 ; ; 35-41 cycles.
×
×
  • Create New...