I shoulda posted here earlier (since the first episode was shown this past weekend) but it's never too late to get started.
Anyway, if anyone is into anime / cartoons / animation then you really should watch Skyland (Weekends @ 7:30 on Teletoon in Canada, also on one of the Nick stations, and probably also some over in Europe). The quality of the animation (particularly the backgrounds) is equivalent to the big screen anime of Studio Ghibli (Howls Moving Castle; Spirited Away) or Akira. No
Today the iPod I bought off eBay Tuesday night showed up at the door. It's only a 20G photo, but since my target model was a mono 4G model and I was able to get the color practically NIB for minimal additional cost, I'm not complaining. It's main use will be in the car alternating between my wife's playlist and my son's.
Anyway, I've also learned about iPodLinux. Now, normally I wouldn't be interested, but they've ported DOOM! There's also a GameBoy emulator, and some other ports of othe
My current challenge is rewriting the movement routine to use fractional positioning for both the player and enemies. (Well, the enemies already used fractional positioning, but now I'm giving them two speeds.) There are actually four different speeds:
falling speed - 20 pixels per second
fast player - 13.3 pixels per second
slow player / fast enemy - 10 pixels per second
slow enemy - 8 pixels per second
Weird numbers, but those are the integer movements which match up with the round-r
I just had an interesting thought. Typically with fractional positioning the fractional byte is treated as an unsigned value/256. So $10.10 = 16+16/256.
For Leprechaun I see that causing two problems. First when the sprite moves left, it will move one pixel left on the first frame (3+n/256), but it will take multiple frame to move right one pixel. Second, my collision detection only checks the integer bounding boxes, which is okay from a sprite perspective, but is a little sloppy numeri
For those of you who aren't techo-geeks let me give you a quick summary:The big electronics manufacturers have created the successors(!) to DVDs : HD DVD (arriving March 23rd) and Blu-Ray (arriving May 23rd). Both are CD-sized optical discs like DVDs and are capable of HDTV resolution. But, because the two camps couldn't work out their differences we're stuck at the moment with two incompatible formats. Which one is VHS and which one is Beta remains to be seen.Unfortunately, most studios have de
Leprechaun has gotten stalled unfortunately, but I came up with an idea which I'd like some comments on.One suggestion was to speed up the game. In the current WIP the player moves 1 pixel every 6 frames, while the enemies use fractional positioning to move at a slower rate. My initial idea was to change the player to use fractional positioning to move faster, but then change the enemies to 1 pixel every 6 frames (i.e. same as the current player).Anyway, it occurred to me that an interesting o
Okay, I've figured out how the clock for the 4 stage shifter is done and gone back through and reworked all of the equations now that I'm a little more used to keeping track of whether I'm changing a NOR to an OR or an AND (depending on whether I want the output or the inputs inverted). This isn't to say I couldn't get it wrong, just less chance.Q1-5 is the 5 stage shift registerQ6-9 is the 4 stage shift register
AUDC Q1in0000 1xx00 (Q5 XOR Q9) + !Q1*!Q2*!Q3*!Q4*!Q5*!Q6*!Q7*!Q8*!Q9yyxx (Q5 XOR
Continuing my adventure puzzling out the TIA schematic, I turn my attention to the AUDF section as a prelude to figuring out how the clock signal for the 4 stage shifter is generated.The Audio Frequency Divider takes two clock signals (A01 and A02)* and generates two clock signals (T01 and T02)* using AUDF[0..4]. So to start with we need to look back at page 1 of the schematic and Andrew Tower's TIA Hardware Notes to learn more about where A01 and A02 come from.A01 and A02 are based on the main
I have been looking at the TIA schematics to better understand how the "Audio Noise Generator" works. (The noise generator is on page 4, although there are details of the register blocks on page 1.) Really the ANG is three separate chunks. 1. AUDF - which divides down the 2 * HSYNC clock signal and creates the T01 and T02 clock signals. I haven't looked at this section in detail yet, although there may be some interesting bits around the timing of changing AUDF. I'm also going to assume that T
The Apple ][ was capable of "280x192 6 color hi-res graphics", but how it accomplished those graphics is bizzare to anyone familiar with modern memory mapped graphics (i.e. 256 color VGA). Even more amazing was the quality of games which were written for the Apple ][ series in spite of what the programmers must have gone through.In conventional memory mapped graphics there are two basic assumptions:
1. Each pixel is represented by a set number of bits, e.g. 1 for monochrome, 2 for 4 color, 4 f
Nothing new* to see here unless you're looking at the source. Hopefully this is the final kernel rewrite.1. reflected playfield2. (zp),y player sprites3. REFP = no separate left+right sprites4. blank sprite instead of repositioning to far leftWhat's interesting is even with this rewrite I effectively have no free cycles in the majority of the kernel. Or rather, there are free cycles, but they don't happen during the inactive portion of the display. There's even a minor color glitch on the far
Now that Christmas is over and I'm not trying to turn 700 slides into a DVD, I need to get back to working on Leprechaun.One item which is working (although I'm not going to post it since it doesn't affect gameplay) is the change to a reflected kernel. I wanted to get that working before the level editor sees the light of day. Kirk Israel has been working on the level editor, but the next challenge is implementing the save & load capability.My next update should include the corresponding l
It's not a game unless you can keep score.The base idea I have is to have a count down timer for the level which would start each level at 999.9s or 16 min 39.9 sec. You would have unlimitted men (restarts) but limitted time. Bonus time would be given for picking up gold. Once you completed the level, your time remaining would be added to your total score.There will probably be the ability to practice levels, but that wouldn't be scored.How does that sound to everyone?
The basic gameplay is now complete. Press the button and push the joystick right or left to dig. Comments, opinions & suggestions welcome.I also managed to trip myself up quite nicely as I was adding the new sprites. Basically I forgot that any access to $1FF8 aka $FFF8 on a SuperCharger will trigger a bankswitch. And I stuck the sprite data after the playfield bitmaps, which just happened to be on page $1F00. So the game would work quite nicely until it did the right blit and accessed
Yes, the WIP is almost done. I just need to add in the new digging sprites (and redo the old ones which I did by hand).Unfortunately, I'm going to have to find someplace to squeeze them in. I had this great idea about how to squeeze in the REFPn bit, but it didn't pan out. At one point I noticed that HMPn only uses the top 4 bits while REFPn uses bit 3. Ah-ha! I thought. If I multiply XPOS by two, change the SBC #15 in the repositioning routine to SBC #30, and double the HPOS table, I can m
I've been working on the digging code for leprechaun and have it working; mostly. Unfortunately there's a bug, or rather an unanticipated side effect. The problem is if an enemy falls in a hole and it starts to fill up, the bitmap for gold is momentarily displayed. But then the enemy picks up the "gold", but the fill continues, leaving the enemy stuck in a (top) half filled hole.The "easy" fix is to change the gold bitmap, i.e. remove the bottom white line, so it doesn't match half filled dirt.
Thanks to Ben Langberg, Leprechaun now has sprites.Thanks to Manuel & Thomas, I've managed to trim 13 whole lines of CPU time off the blit routine. I still need to work on their suggestion of changing the playfield to reflected. That will take some more effort. I also have plans to squeeze in REFP0/1 logic, which will reduce the ROM space needed to store the sprites (since right now I have to store both right & left versions).Other major to-dos (not necessarily in this order):1. Add t
Well, I mentally looked at the list to Leprechaun to-dos and decided that I needed to tackle the BLIT routine next. This is the code which copies the sprite graphics (running etc) from ROM to the strips of SuperCharger RAM that the kernel then uses. (Much like the 5200 & A8s.)And I'm glad I did, because I discovered (to my horror) that the routine barely fits in the time between the end of VSYNC and the start of the kernel. (Actually, I had to increase that time by a couple of lines even.
Okay, I've killed all of the player movement bugs. So you can now move around the screen. Hooray! No digging yet, though. (That's a whole different kettle of fish.)I was working on getting the enemy movement working, but there's a glitch with moving left and they just slide off the edge of the screen. Ooops. I've bypassed that code in this build, but I'll work more on it tonight. <EDIT> Fixed! New binary! I've also made the enemies white when they are hunting, and green when they
I am slowly tracking down the bugs in Leprechaun, primarily using the Stella debugger, with some z26 tracing.Anyway, just for laughs, I've found the following glitches so far:- used a BCS instead of a BNE which caused the player to climb off the top of the screen- forgot that the sprite positions are already shifted 2 pixels by the positioning routine, removed the redundant shift. (Although my first attempt to do so caused more problems because I over-optimized.)- logic glitch in translating th
I hate it when I stop working on a programming project for too long. I forget stuff, except for the problem I couldn't figure out or solve. Which doesn't provide me with much incentive to pick it back up. Thus I forget more & it's even more difficult to actually fix whatever roadblock I hit.Leprechaun has a problem. What should be a static display isn't. Enemies are moving (although they may be simply falling, although I didn't think I had added that subroutine into their logic yet) and
Okay, I've finally managed to get everything (back) into something which I can assemble into a 8448 byte bin. I haven't attached it because I haven't flushed out, what will probably end up being obvious, bugs. One of the problems with the code is I've started & stopped so many times I've forgotten dependencies and made some errors. It's also been a long while since I've had something which I could run and debug.One bonus is it appears I should be able to fit the game code into 4K, althoug
I was thinking yesterday about the various differences between Leprechaun and Lode Runner and came up with the following list (subject to change):- no end of level ladder- no hidden pits / traps- enemies pick up, but don't drop, gold- multiple enemies can fall into the same hole- can't run over enemies in the hole (player falls in the hole & dies)- enemies can't climb out of holes (they "die" and reappear at the top)- enemies can fall & run through holes, same as player (until the hole s
More of the same. I think I've got almost everything in one file, though I haven't worked up the courage to see how many bytes it assembles to. I think I'm going to try to put the enemy movement into this version too, though maybe I should turn off the collision detection if I do.Hmm, one item I rediscovered was the sprite color is handled on a per-sprite basis. I think my original plan was to use that to mark whether enemies were carrying gold or not. I've since abandoned that idea (or at l
Time, she be precious and in scarce supply. I'm trying to put together all of the various bits & pieces I've written or thought about and make something a little closer to a playable version. My current goal is to get most of the player logic done so you'll be able to move the little block around with the joystick.Most recently I've been working on player joystick handling for when the player isn't "on grid". I want to allow the player to reverse direction in "mid stride" as it were. Hop
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord