Archive for August, 2014

ProcessQueue

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..

Advertisements

Posted in Uncategorized on August 27, 2014 by pcedev

Just finished my first day of school. Little bit stress full, but excited as well. Gonna take me a bit to transition into academic mode.

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.

Palettes

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).

Game-2014

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.