Archive for February, 2014

Indie movie

Posted in Uncategorized on February 27, 2014 by pcedev

Outside of coding, I dabble in indie movie stuff. Of course, this is micro budget league here – but we make up for it with serious design talent. Most of my RL friends are actually part of this scene; micro budget indie movies.

What does this have to do with PCE dev? Well, we’re building a set that’s support to be the inside of an old space ship. The ship has been grounded and is falling apart; there’s a mixture of low tech and high tech through the movie – because it takes places in a post-collapse of world civilizations. Anyway, one of the parts of the sets has some old CRTs and I’m going to use my white PC-Engine to drive one of the displays. It’ll have some scrolling code, animated vector graphics, etc – running the CRT. Gonna use the SF2 mapper on the TE, for the software. We’re both old school gamers, so it’s more of an inside joke/thing. But I thought it was awesome that the PCE would get to run one of the displays.

For you Japanese folks, the main target distribution for this is going to be Japan. We’ve already released one movie there already (and one of my friends actually found a copy in a shop there, on a visit). I’m gonna see if I can get credit as ‘PC-Engine programmer’ – lol.

Advertisements

New category: Coding tips and tricks

Posted in Uncategorized on February 27, 2014 by pcedev

Just added a new category, for tricks and such for PCE design. I’ll post entries from time to time. Some complex and some fairly simple.

Ok, here’s the first entry: Extending vblank bandwidth.

If you code for the PCE, you know that the two fastest ways to get graphics to the VDC – is to use either Txx block move instructions or embedded your graphics as opcodes (ST1 #xx/ST2 #xx). The latter is faster and doesn’t stall interrupts, but has the downside of doubling the size of your graphics. Txx instructions are easy to use and fast, but it stalls interrupts. This is a problem if you use this during active display (in which it’s normal to update vram during active display on the PCE). Especially if you need to do stuff like H-interrupts.

If your game has a ‘status’ bar, move it to the bottom of the screen instead of the top. You can either build it with all sprites, making it highest priority so that nothing shows above it (easiest method). Or use a part of the tilemap repositioned at that part of the screen, and turn off sprites. The latter has the additional complexity in that you’ll need to ‘sew’ the tilemap height to avoid showing this bar, if the screen scrolls vertically at all. The earlier method eats up a little bit of the SAT entries, but makes it easier in the long run (no calculated special H-int to sew/fix the tilemap).

But here’s the reason to put the bar at the bottom; extending vlbank time. Not really, but since you don’t need H-ints at that part of the screen – you can include the height of the status bar into vblank time. That means it’s safe to use Txx block move instructions. I guess you could put the bar at the top as well, and think of it as extending vblank time as well – but either way, make it out of sprites. You now have that much more time to update vram

Of course, if you’re using the Timer interrupt, or ‘all scanlines’ interrupt, to drive sample playback – then this won’t help you (since they’ll be called during vblank anyway). This would be more for CD projects that use ADPCM for sample playback.

Apothecary

Posted in homebrew with tags , , , , , , , , , , on February 26, 2014 by pcedev

A game that was in development for the PC-Engine..
http://chunkypixels.blogspot.co.uk/2014/02/death-of-pc-engine-game.html

All the artwork and design is done, but the creator (sunteam_paul) doesn’t have someone to code the game for him. So he cancelled the project. But he did offer this..

OK, I’ll make you all a deal. Anyone who can get a fully working prototype (including character movement, screen flipping, basic enemy patterns) in the next 6 months can have all the art and my full cooperation in completing the project.

Anyone up for the challenge? Write it in Small C for the PCE, too.

Posted in hacks, Megaman, NES2PCE on February 23, 2014 by pcedev

I’ve been thinking about the map format for Megaman. I really don’t like the idea of 32×32 with a huge LUT to draw from. Not because it’s hard to write the decoder, quite the opposite. But more of because writing the encoder means writing a whole new app.

So that got me thinking. 8×8 is out of the question for all room data, but 16×16 is a good compromise. 16×16 with WORD entries (4bits for subpalette and 9bits for tile). The ’tile’ could simply just be the base number<<4 and each tile following tile is +1 (for whatever layout I want). Typical stuffs for meta tiles, but 16×16 format is small enough; only 512bytes per 256×256 pixel res room. It also makes use of existing tilemap tools. And, if I ~really~ need more precision than that, I can reserve anything between the 10th bit to indicate a look up value, rather than an actual straight block reference. That way, if I really need 8×8 with each subpalette reference for small specific parts of the room map, I’ll have it. Done and done.

Been busy this weekend though (I’m replacing the cylinder head of my 1993 4.0L 4×4 jeep. Old head cracked, so I bought a new one. I’m reassembling the engine, slowly). Gonna try to do some test runs on new BG stuff tonight though.

Small C on the PC-Engine

Posted in Uncategorized on February 22, 2014 by pcedev

HuC has a lot to be desired; it’s no secret. People that know how to get around its short comings, deal with it.

As much as I like assembler, I do like C. I’ve been wanting to code a small game for the PCE in C, for a while now. The past couple of days, I had a short conversation with Chilly Willy over at TE forums. CC65 to be exact. Looking over some of the stuff that you can do with it – it looks pretty decent, and most importantly – full manual page/bank control! That is a VERY important feature for optimization reasons alone. That was thee biggest gripe I had with HuC, over everything else that could be fixed with support code. Even some talk about how to optimize use for SuperGrafx extra ram with CC65.

I’m going to take a serious look at it this year. I don’t know if anyone else is interested in C for PCE, but I’ll be sure to make notes about my experiences. A lot of lib stuff can be ported over to CC65, from HuC. Since HuC is no longer being supported/worked on, I think it’s time to move over to CC65 for the PCE. At least there’s a muuuucchh bigger user base for CC65 (and not just for C64 either). The compiler supports 65C02 code, and to be honest (with C) 6280 isn’t really an improvement over it opcode wise. I doubt you’d see much of any improvement with the added instructions over 6280. They’re more convenient than anything else. And when they are faster, it’s for hand tuned assembly. Excluding the block transfer instructions. And supposedly CA65 supports 6280, so inline assembly should be fine.

SDCC looked decent as well, but there’s no support for 65x based processors (MCU version of 6800 was the closet thing). Too much work to add a new processor. CC65 it is.

Posted in Megaman, NES2PCE, Uncategorized on February 20, 2014 by pcedev

Working on changing the tilemap format, for the room/screens. Originally, the game uses a 32×32 meta tile format. IIRC, it’s one byte per 32×32 block. So that’s 64 bytes per 256×256 pixel screen. That’s pretty small. A 256×256 pixel screen with 8×8 tiles (and subpalette per tile) is 2048 bytes. Quite a bit bigger. Cutman’s level has 22 rooms. If I made each room unique, than that’s 45k just for that level. Not a big deal if this was strictly just a hucard/rom project, but that’s pushing it a bit for the CD project. I’ve already decided that I’m gonna break the levels into ‘loads’, and certain things can be loaded directly into vram from the CD track at the start of a level, but even then – I still need to keep the space requirements down.

I figured that I can build upon the 32×32 block system. I could double the map entry with a parallel map, so that each block is two bytes instead of 1 byte. That gives me 65,536 blocks; too much for a look up table. But I don’t need to use all the bits. I figured, with 16k, I can get about ~630 32×32 blocks in the decode table. That would decode the 32×32 block into 16 8×8 tiles. Each tile would be 9bit addressing (access up to 512 tiles in vram), and each tile would have access to its own unique subpalette. I’d bitpack everything to cram it into 16k table. I think the original game uses something like 64 32×32 blocks? This would be a big improvement, in just that alone. I could even use the unused bits for collision stuffs. For the backend PPU emulation, I’ll add a special ‘reg’ that the code reads from – to get the additional subpalette and MSbit. It’ll clear it after reading from it, too.

Posted in Megaman, NES2PCE on February 19, 2014 by pcedev

Power meter replacement design/code is finished. I’m pretty happy with the way it works. In regular weapon mode, the whole meter width is the health. In weapon mode, the meter is divided by half – one side for health and one side for weapon energy (well, one more pixel for health width than weapon energy). Next will be to do a version for the boss as well. I still need to make some ‘weapon’ icons for below/base of MM power meter, since I’m keeping Megaman blue regardless of the weapon picked. Though I might have a setting in the options to change this (retro look). It’s not that it’s more difficult, it’s just that I like the original megaman colors for the more modern looking sprite.

I also got rid of the score at the top, as well as the sprite ‘flicker’ routine. The routine is automatic, and cycles/staggers the sprite order depending on even/odd frames. This is primarily to reduce blank out (induce flicker) for the NES sprite line width problems. Since I’ve upgraded the sprites to new sizes and less of them, this isn’t an issue anymore. Plus, it’ll make sprite layers for parallax less of an issue to deal with (I want specific sprite priorities).