Archive for the homebrew Category


Posted in Game 2014, homebrew on August 23, 2014 by pcedev

I broken down and allocated 1k of ram to palette work :/ At that moment, I had 6k free ram but I don’t want to squander it.

Anyway, I’m gonna make some play/example videos soon, so I want to polish up the game engine a little bit (some palette fade in/out, etc).


Posted in Game 2014, homebrew on August 21, 2014 by pcedev

Well, that’s the games code-name..ish.. thing.

The game engine is getting pretty close to complete (for the most part). I originally wanted to make this game with my son, but seems that has fallen through (his summer school vacation with me has ended). So, I’m gonna push the date to late September for release (or later, depending on how many people come on board).

I’m looking for people to help out. This is just a little/simple game (aka would be a Chapter in an RPG). I’m looking for sprite artists, BG artists, portrait/etc artists, map/area/enemy design artists, story/writer artist, sound FX artist, chiptune artists. Some beta testers too. Yes, I don’t want to design the story myself. I rather allocate my time where it would be most efficient; coding.

I’ll be honest, I’m gonna be reserved about choosing someone to fill the story/writer position. Everybody and their mother has a game idea, and while I’ll be overseeing/managing all of this – I am going to leave the game idea and story to the writer. I actually do have someone in mind for this (I’ll be contacting them first).

If you’re interested in any of these positions, shoot me an email.


Posted in homebrew with tags on August 20, 2014 by pcedev

Object-to-object collision is working. So all enemies move around the map, obey map collision, player obeys map collision, enemies coming in contact with player bounding box detected.

It’s almost a real game engine. Right now, the player and enemies move on a 16×16 pixel grid movement. When you press a direction, the player moves for 16 pixels in that direction. It’s quick. It doesn’t sound quite right for an action game, but Arkista’s Ring got away with it so I figured I could as well – for a mini game.

But I’m rethinking that approach. I might change it to 8×8 or 2×2. Something smaller than 16×16. I’ll have to change the map collision routines for the player, but that’s not hard. Object/Object collision works on a pixel basis, so that has no effect on the map/player movement.

Next is to add projectiles (and protruding weapons/swords/etc), to the object handing queue.

Posted in homebrew on August 17, 2014 by pcedev

Heh. I got the first iteration of ‘wanderer’ AI up and running. More like spastic/bug AI. But it’s cool to see it up and running (along with collision map detection). I need to add some bias into it; if at a far end screen/threshold, add a bias to towards the opposite end – so it doesn’t stay in one particular area.

I’ve been looking at the first Neutopia game enemy’s AI and I have a few ideas. Gonna need to look at a few more games as well.

I think I’ll get object to object collision working first, so the enemy can damage the player (and vice versa) – before I get too far into the enemy AI thing.


Posted in homebrew on August 17, 2014 by pcedev

Writing the AI (and the map collision detection for it) 😀

It’s challenging, but really fun. It’s not like simple side scrollers (walk back and fourth enemies), or scripted enemies in shmups. I never really thought about how to do AI for overhead maze/zelda/etc style designs.

Hopefully should have the NPC/enemies running around by the end of this week (they’re are on the map, have slots, etc – just no AI to control them). Well, at least one type of AI up and running for this week. I’m gonna have to make quite a few different ones for different enemy types.

Posted in homebrew on August 17, 2014 by pcedev

SXY/SAX/SAY aren’t the best instructions in the world. One 65x comparison doc in general, said they were a waste of opcode. While I agree that there could have been better opcodes added/upgraded to the 6280 from the W65C02S, they are not without their uses (albeit limited). I’ve used them on occasion; not so much as to save a cycle or three (I do that too), but as a convenient method of keeping code cut down/readable. Not unlike the BBR/BBS instructions.

Posted in homebrew on August 15, 2014 by pcedev


Hahahaha. It gets right to the point. I needed a quick title screen, because I need the human interface to ‘seed’ my random number generator routines. They also get reseeded on screen transitions (just in case).

But anyway… my spritesheet to SATB entry.. is amazingly slow ;_; 728 cycles per single entry (SATB entry)! Sure, I’m using macros and very unoptimized code, but still. I have a way to speed it up. Gonna try something I hadn’t thought of before.