Jump to content
  • entries
    295
  • comments
    862
  • views
    242,365

About this blog

Geeky things I'm up to

Entries in this blog

 

Whoops part 2

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

Guest

Guest

 

Whoops

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.

Guest

Guest

 

Now with sprites!

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

Guest

Guest

 

Time, it is precious

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.

Guest

Guest

 

Player & enemy movement working

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

Guest

Guest

 

working binary attached

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

Guest

Guest

 

banging my head

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

Guest

Guest

 

Leprechaun update

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

Guest

Guest

 

Leprechaun versus Lode Runner

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

Guest

Guest

 

Leprechaun status update

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

Guest

Guest

 

Leprechaun goo

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

Guest

Guest

 

Leprechaun movement musings, part 2

Ah-ha! I've got it!Currently, the code is set up for six sprites - the player and five enemies. Each frame one sprite moves one pixel. So it takes 24 frames for a sprite to move horizontally from one PF block to the next.Now, what if I change this to fractional positioning for the enemies. The player I'll leave be because he can change direction in mid-move. What if I want to still limit myself to one full sprite movement update per frame. Okay, so let's make it take 30 frames for the enem

Guest

Guest

 

Leprechaun movement musings

In Leprechaun my plans are to only go through the full movement routine for one sprite each frame. Although I haven't cycle counted the routine, I have a sneaking suspicion it will take too long to do more than one sprite per frame. (As it is, I think I'll end up having to shove it in before VSYNC so I can leave after VSYNC for setting up the sprite bitmaps.Anyway, I have two alternatives for sprite movement. I can either move only one sprite one pixel per frame (with a hack for making fallin

Guest

Guest

 

chewing through codespace

Ugh. Leprechaun's movement routine chews up 637 bytes; over half the free space (1133 bytes) I have in BANK 3. Sigh, I'm sure I can juggle some stuff around, but fewer free bytes means fewer features.

Guest

Guest

 

status updates

Made some minor revisions to my tracker code and posted it to [stella]; no feedback yet (whine). One thing I'm not happy with is the byte to note ratio being 2+. This chews up ROM space much faster than I imagined. Certainly with a lot of repeated sequences, the total bytes per song will come down, but even my demo takes 168 bytes. Which kinda puts my idea of dedicating a page of ROM in Leprechaun for music to be woefully inadequate. I could probably come up with a data format which would lo

Guest

Guest

 

VCS music tracker!

Ta-da! This is something I've been wanting to do for a long while - a VCS music tracker format. Forgive the tacky Fuji logo, it's the first VCS program I did years ago. I re-used it so I didn't have to spend too much time putting together something which would generate a stable screen.Format details:Two layer list format: top layer is a a song which is a list of 16 bit pointers to seqences (note lists); bottom layer are sequences which are a list of 1-n byte lengths, volume, notes and escape

Guest

Guest

 

Leprechaun enemy AI

Following on with my idea to re-use the player movement logic with the enemy "AI", I've been doing some thinking. Basically, the enemies will have two modes: chase & hunt (each enemy working independently). In chase mode the enemies move in the direction of the player, i.e their virtual joystick is pointed towards the player. However, if they get blocked, they flip into hunt mode. In hunt mode their virtual joystick changes direction (clockwise or counter clockwise, randomly, mirror?).

Guest

Guest

 

player movement continued

I've been working on & off changing my if logic into 6502 ASM. Most of it is straight-forward CMP / BNE stuff. Not very complex, but a big whack of code. There is some optimization (folding & combining endpoints), but nothing major. I've pushed a couple of things down into the GRID subroutines, but I'm really starting to worry about how much code space this will require. Especially since I haven't even started thinking about the enemy logic.Which got me to thinking. How difficult w

Guest

Guest

 

Leprechaun, player movement progress

A good example of top down design and bottom up programming. The spreadsheet method made designing the player movement truth table much easier than trying to figure out the if cases from scratch. From that I could then do a pseudo code version of the if statement logic (see 20050823.txt). Since it was in a spreadsheet I could do different sorts to see whether there was any benefit to doing the tests in different orders (e.g. check the button down cases before checking the different grid cases

Guest

Guest

 

Leprechaun, player movement musings

So, I've reviewed the source code and re-aquainted myself with it. Since the kernel and the sort routines are working, my next focus is on player movement. From a code perspective this will turn into a bunch of IF statements, but first I need to come up with the truth table to ensure no conditions get missed. I'm doing this in a spreadsheet. Each row is one set of conditions. I take a generic condition (e.g. Grid = open) and break it into two conditions (Grid = open & Grid_Down = {Gold,

Guest

Guest

 

Leprechaun 2004-04-27 edition

Features:- 6K SC binary w/ header (8448 bytes total)- performs both bankswitching and SC RAM writes- tested on an actual 2600+SC (back in 2004) (although I now have a 7800+CC2 as well)- functional kernel w/ sprite repositioning- semi-intelligent flicker / partial sort routineLEPRCHN.ASM : wrapper- includes, equates, ZP variables, SC headerLEPBANK1.ASM : level data- background playfield bitmaps- SC RAM space for forground player/leprechaun sprite bitmaps- SC RAM space for player color / XPOS arra

Guest

Guest

 

Leprechaun, dusting off the files

I think I've found the most recent source code. I need to do some re-assemblies and diffs to make sure I know which is what. Then comes the big challenge, making head & tails out of the code.

Guest

Guest

 

BeOS 5 Personal Edition

A recent ArsTechnica entry about Zeta brought back memories of BeOS, and my mostly failed attempts to get it running on the hardware I had access to. Hey! I've got a "new" PC, might it be compatible? Most assuraddly so. Cool. Of course, it's the one hooked up to my Tempest cabinet, so the monitor is rotated, which makes it a little difficult to use. But it's BeOS!

Guest

Guest

 

Tempest & Leprechaun

I'm getting ever closer to completion of my Tempest cabinet. The rear door has been completed (although I might sand down the length, it's a might bit tight). I've been working on getting Atomic FE set up. I think the next step is getting the software on the PC and the game-specific configs done. I've soldered some speaker wire to the on/off button, now I need to find a SPMT switch to put at the other end. I also need to hack up my extension cord and connect the main on/off switch and the d

Guest

Guest

 

Tempest cab update

Yeah! Finally found a cam lock for the coin door at a local hardware store. So now my cabinet has a door (no mechs though). I also bought a sheet of MDF and had it cut (thanks Home Depot) for the back door. So, current to-dos:Woodworking: Cut the MDF to length (easy work with a circular saw), add the notch & cover for the monitor, add top & bottom "latches", paint.Software: Play around some more with AtomicFE, try out the patched version, create a layout / background I'm happy with,

Guest

Guest

×
×
  • Create New...