Archive for the Game 2014 Category


Posted in Game 2014, life on September 22, 2014 by pcedev

Not dead, not dead. This is my first semester, so it’s taking quite a bit to get used to being efficient with my time (studying/homework/etc). That, and I took accelerated Spanish. I will NOT make that mistake again. That Spanish class is actually eating most of my time (too much to remember and learn in a short period of time), but it ends early – medio octubre. Should have more free time then. I’m gonna continue taking Spanish as far as it will go. I’m hoping to get a grant to study abroad when I transfer to a larger university. Voy a viajar a España! También, a mí me gusta mucha la PC-Engine. And some Latin American countries too.

But yeah, Black Tiger is working out some ideas for the story for the game project. Things will be slow, for a little bit – but should pick up in October. And full force for winter break.


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

I added some more functionality to the queue processor. I ran into a bug that would add a process, and reorder the queue – but it was called inside another running process. This caused and infinite loop. Now, I added a process manager at the end of the queue. You push a process request on the process manager queue, and it’ll perform the actions needed, outside the queue itself.

For instance, in-game (player) controls is a process in the queue. It runs when in game engine is running (there are other control/input processes for different ‘windows’ or other parts of the game). The process reads the input of the buttons. For certain button action, a new process might be pushed onto the queue. Processes can remove themselves, and they do. If the player pushes a certain direction, and a screen edge, or stairs, etc is encountered – it’ll call a scroll or warp process as needed.

I do the same for action events. I’m implementing the basic attack process this week. The button detection logic ran inside the game control process. It would push the attack process into the queue, but I did this with a priority level request (rather than just anywhere in the queue). This just happened to be above the current process (game controls). Causing the game controls process to be re-run on the exit of that process. No good. Instead, and much better design, I implemented at request system that happens outside the queue. Much safer.

Now back to working on attack code..

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

Some show-off stuffs:

It’s not for showing off the graphics, but the map/area system. I can scroll between screens inside of areas, but also to scroll/link to screens inside other area maps with other assets (the fade in/out to load new assets). And of course, warp points (stairs/doors/etc).

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

Hah – doing a major rebuild of the area:screen system. An area has a specific tileset and palette for up to 256 screens (16×16 screen block). I could, in theory, have 256 areas (1million pixels by 0.720million pixels).

I needed more flexibility in the design of things. I needed a way to better organize map data too. Warps/stairs/etc can trigger load of near area blocks – which requires a screen fade out and in. Of course, edge screen exits can do this now, too. So, transitioning from a forest to a desert – is a fade transition allowing new tiles to be loaded, instead of the normal screen scroll.

The down side; I’m rebuilding a lot code screen fetching code. School starts this Tuesday (full time), so I’m trying to bang out some code over the weekend. I have some new test maps/tiles that I want to try out, but they require this new code.

Composting tiles

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

I was looking at a lot of graphic tiles sets and such. If you done anything with new 2D engines (especially top-down), you’ll notice that a map will reference objects instead of tiles. PCs and such and limited to square tiles. Basically the objects are composited/overlaid on top of the map.

Normally, you hard-composite all these kinds of stuffs into regular tiles on these older system. This wastes a lot of space in rom, and eats up vram. For system that have more than 1 BG layer, you kind of do a half process and let the system composite the layers in realtime (saves on vram and rom). Not only does the PCE not have this, it also lacks flipping modes for tiles (instead, it got more subpalettes – only so many bits can fit into a tilemap entry).

My game scrolls screen-to-screen. This lends to the advantage that I could do real time compositing for a full frame before the screen starts to load. This would allows more unique looking detail (less pattern-y), and it wouldn’t stress the cpu since nothing is going on during screen scroll and a full frame or two is pretty decent amount of time to throw at this. There is a down side; I ~do~ scroll between screens instead of just snapping to the next. This means I need room for two screens of unique tiles. I do not have enough room for that. The compromise would be: use a base set of tiles for the ‘area’, but allow a two small buffers for unique tiles for the screen. Two buffers, because I still need to scroll between the two.

An example would be field grass. The grass would be the base, and I could overlay other objects on top – small rocks, or different patterns of flowers, unique edge transitions into other material, etc. The grass could take up 4-5 colors and the rest of the color slots in the 16 color pool would be set for the composite material. This is where the PCE’s huge amount of subpalettes comes in. You could probably apply this idea to actually scrolling maps, but the implementation is more complex, but still do able.


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.