I'm really not sure what I'll use this blog for so I should probably leave this blank, but that would require backspacing. Much easier to just hit a period and stop typing.
I had something done for this week's Action RPG (version 0.008) but upon finally getting to test it, it failed spectacularly. It was so mucked up I didn't even know where to begin to debug it (all semantic/timing bugs) so I'm scrapping it and I'll start over. Perhaps the problem was trying to get too much done. I tried looping the kernel up some, modifying a position-a-sprite routine so it would execute all in one line, and adding the second bar.
Also, I'm starting to feel a bit under t
So the idea I had for adding the playfield is quite a bit more complicated than I originally thought. But then I'm also working on an actual usable system that'll be kept from version to version from this point on instead of a simplified test case. It does use up quite a bit of the ram, but then I'm writing this with the superchip in mind. Not going to use the extended bytes of ram until the rom itself gets more complicated at any rate.
I'm more surprised that I'm still working on thi
Now, I didn't RTFA or anything, so let's go by the summary on slashdot. Apparently the Copyright Board of Canada is proposing a tax/surcharge on legally downloaded music to the tune (ha ha.) of 2 cents per mp3, with 1.5 cents extra for an album download. If passed, this would also be retroactively applied to EVERY legally bought mp3 since 1996.
I'm pretty sure this isn't something that has passed. It's just the Copyright Board looking to lobby government.
What I can't understand is th
Beta 2. Second mini-goal done. Added in the second bar as planned, and set it so that the item-equipped displays properly. Also took a few seconds to replace the horrible looking sword with a horrible looking chalice.
I've pondered the idea of minor animations (2-4 frames) for the items, although where they're single color I don't know if that's really worth it. I am pondering allowing the item's color to change each scanline if I find I have time for it. That'll probably be a touch up
I mentioned what had happened with version 0.009 prior to my scrapping the code and starting to work on the Real Deal. Due to running out of cycles the WSYNC in the player-draw lines were generating 2 lines instead of 1 since it would overrun the normal wait point then sit and wait for a full line. This generated an interesting, if shakey and in the end unusable, magnifying effect. You'll notice the glitch in the status bar as well - that part confused the heck out of me as I don't think I d
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
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
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
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.
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 pro
Got a raise at work recently. While I have some things to catch up on first, this means I may be able to start ordering from the Atari Age store again! We'll see how it goes I guess. I'll likely get something when my tax refund is processed (A reward for getting the damned thing done on time!) but after that we'll see how things go through the summer. Might be better to save up some cash to get a nice christmas order.
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.. co
Ahahaha. I suck goat eggs.
I had a little bit of time to work on the rom today so I decided to try to fix the bgcolor so that it wouldn't start a scanline late at the very top of the game screen. (you'd notice the playfield drawn 1 line over what looked to be the menu still, but it was really the menu dipping into the game screen.)
I've already fixed what's going on in the rom and moved on but thought I'd share the odd reaction to my code.
And as I was unhappy with how the bgc
What say we sue pac man for the current state of growing obesity in north america? The subliminal messages of "eat until you burst" through the last generation is just unforgivable!
Now at Version 0.009 Beta 2. Beta 1 I'll release a bit later when I have more time (Going to bed!) this is just a screen shot of what the new display kernal is capable of. I'm surprised I got it working to this point from the initial stab at it this morning, there wasn't recognizable object displayed at first besides the status bar!
There's still a problem with the bottom of the screen's boundary clipping. I can have the player touch and press against it, and it won't cause a problem, but
Just a random thought I had while procrastinating on the display half-asleep. (I will work on the kernel again this weekend darnit!!)
The halt line controlled by Maria on the 7800 extends out to the cartridge. So what if that line was tied to the highest address line on a 17-address-line rom? Since the HALT line effectively identifies which CPU is in control, it would automate the task of changing between a rom that Sally saw (filled with data tables, sound info, and algorithms/routines) an
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 r
I've been trying to build up the scanline pairs for the first stage, the rest of it after that is generally an issue of copy/paste with a few modifications. I was topping out in cycles again so looked for ways to remove things from the kernel without removing anything from the kernel. I think I managed to do that although it cost a couple bytes of ram. By doing this it also freed up a lot of color selection choices for the playfield alterations.
As a result, hopefully I'll have version
On an earlier version I was describing some of the bugs that I ran up against but ended up forgetting what I did to fix some of them. This time I wrote them down!
After I put in the initial code for the new Display kernel, and fixed the common typo-syntax errors (you'd be surprised how important "#" can be.) the displayed screen was... unrecognizable. The player was back as a pillar (wasn't turning itself off) and I had a display consisting of the status bar (lookin' normal) with just mult
Looking at what I want the screen to be able to do, there is a problem with trying to update sprites. There's just no time left in the hblank. A sane person would just say "Ok, let's just pull out the playfield color update. All you need is that one extra command in there."
But I don't wanna.
So if you can't do the update in hblank. You'd have to do it during the visible screen. The obvious problems with this would be what if you try updating it when it's being displayed? Are yo
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,
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
Below is a map I had designed for a forest kingdom in Action RPG back in... I think it was 2005. It was well before I started on the current codebase which is why it doesn't even reflect the ability for alternating playfield colors. (I made a few attempts at starting this game in the past, but always got seriously distracted or had a harddrive failure, etc. )
I'm likely going to modify it before I ever get around to adding it to the actual rom, perhaps even start from scratch, so a looksee
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/
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 the