request: PCE development 101?

[pixeljunkie]

Not so much from a coding side, but more from the art side of things. I am a professional illustrator and designer and want to experiment with doing some gfx that would theoretically be PCE compliant. Is there a thread I've missed that has a break down of the graphics specs that I could use somewhere?

Sprite size/format
Background size/format
etc

[SuperPlay]

You may find a few things of interest on my links thread under the 'Development' section

http://www.pcenginefx.com/forums/index.php?topic=9483.0

[Lochlan]

Here's a write-up I made for someone who was doing art for me:
https://docs.google.com/document/d/1CFBWZB21dJ3F2O4NBDC3eNpev_8QRBUHuSX6Fs8N4Y0/pub

There may be errors in this document (if anybody sees any please let me know!) but it should be at least mostly correct.

[pixeljunkie]

cool! thanks!

[Necromancer]

Line scrolls?  I don't know why those would be limited to four though.

[Sadler]

I vaguely recall that being a huc limitation for scan-line regions.

EDIT: I'm guessing most of the limitations in that document are based on huc, but honestly I haven't looked at huc in long enough that I don't remember. The resolution can be far higher than what's listed, and I want to say it's programmable in increments of 8 pixels for horizontal resolution and 1 pixel increments for vertical.

Also, I think I mention this in about 50% of my posts, but there are 3 independent layers supported in hardware: sprite, tile and background color. I don't think background color gets near enough mention either. Magical Chase is perhaps the most well known, but Metamor Jupiter is another example. I'm not smart enough to verify it, but I suspect the rainbows early in Star Parodier and the far layer at the end of Soldier Blade are other examples.

[Lochlan]

I vaguely recall that being a huc limitation for scan-line regions.

Yes.  I've updated the doc to reflect that this is a HuC limitation.

The resolution can be far higher than what's listed

To be fair, the document explicitly mentioned that 282x242 was "low-resolution mode" although I've updated it to reflect that there are higher (horizontal) resolutions available.

I want to say it's programmable in increments of 8 pixels for horizontal resolution and 1 pixel increments for vertical.

You can definitely use 565x242.  Wikipedia claims 377x242 is also available, but I haven't heard of such a thing.  I'm interested in your claim about "programmable increments" of resolution.  Do you have any citation for this, or maybe a link to a demo?

Also, I think I mention this in about 50% of my posts, but there are 3 independent layers supported in hardware: sprite, tile and background color.

Woah, interesting.  Are you referring to the overscan color?  (Which IIRC is also the transparent color of sprite #1, is that correct?)  I'm guessing you use a tile map with a "blank" tile or something?  How does this work in-practice?

[TheOldMan]

Line scrolls?  I don't know why those would be limited to four though.

Because the assembler code in HuC only reserves space for 4 regions. Arkhan and I have changed that, and have run up to 7 unique regions. After that, though, the variables start overwriting other things....

Wikipedia claims 377x242 is also available, but I haven't heard of such a thing.

Not sure about 377 - that's not a multiple of 8.  But 352x240 is definately doable.  I -think- you have change the screen size to do it.

I'm guessing you use a tile map with a "blank" tile or something?  How does this work in-practice?

You set your tiles up with color 0 where youwant the bg color to show through. Not sure why you would want to, though. Might as well just put the color in the tile.
What is neat, though, is to set the sprite priority based on the tile it is on.  Planned right, you can create the illusion of moving behind parts of the background, and in front of other parts.

[ccovell]

You can definitely use 565x242.  Wikipedia claims 377x242 is also available, but I haven't heard of such a thing.  I'm interested in your claim about "programmable increments" of resolution.  Do you have any citation for this, or maybe a link to a demo?

Link: http://www.chrismcovell.com/data/Screen_Dimension_Test.zip


You can run your own tests with this, as it should all be straightforward and self-explanatory.

You set your tiles up with color 0 where youwant the bg color to show through. Not sure why you would want to, though. Might as well just put the color in the tile.

Of course, for copper bars and gradients.  If you put the colours for a gradient directly in the BG tile, you'd quickly run out of spare colours.

[Sadler]

stuff

Hey man, I apologize, I think my message came across more critical than I intended. What little I know comes from attempting some PCE development several years ago and I never achieved more than a lame incorrectly colored side scroller demo. In short, I'm mostly talk and my talk is based on hazy memories so soaked in booze you can probably smell it from wherever you are right now.

You set your tiles up with color 0 where youwant the bg color to show through. Not sure why you would want to, though. Might as well just put the color in the tile.

Of course, for copper bars and gradients.  If you put the colours for a gradient directly in the BG tile, you'd quickly run out of spare colours.

With the caveat mentioned above (I'm full of shit), the reason why I think this is cool is because it allows for overlapping parallax without dynamic tiles or sprites. Yeah, you are limited to gradients, but that actually opens a lot of doors. The sky, pipes, ground, there are lots of choices and that can be behind the tile layer and scroll at a different speed than the tile layer.

[TheOldMan]

Of course, for copper bars and gradients

Ah. I could see that. Might be a pain changing the bg color every scan line, but I could see how it might work...

The sky, pipes, ground, there are lots of choices and that can be behind the tile layer and scroll at a different speed than the tile layer.

But this I don't understand. How would the background color 'scroll' ?
Maybe Bonknauts can weigh in on this, and outline how it might be done...

[Sadler]

Of course, for copper bars and gradients

Ah. I could see that. Might be a pain changing the bg color every scan line, but I could see how it might work...

The sky, pipes, ground, there are lots of choices and that can be behind the tile layer and scroll at a different speed than the tile layer.

But this I don't understand. How would the background color 'scroll' ?
Maybe Bonknauts can weigh in on this, and outline how it might be done...

By changing which scan-line the gradient begins. This only gives you vertical scrolling, but it still looks pretty nice.  Watch the gradient behind the castle, but below the clouds @1:20:



But yeah, we need Bonknuts to weigh in!

EDIT: Tried to clarify.

[TheOldMan]

Ah. Vertical movement never occured to me (duh). I was trying to figure out how you would time the color change in the middle of a scan line, without using most of the cpu

[spenoza]

Didn't Aero Blasters utilize a BG color trick to do the final boss? It seemed to fake some amount of vertical movement pretty well.

[Black Tiger]

Didn't Aero Blasters utilize a BG color trick to do the final boss? It seemed to fake some amount of vertical movement pretty well.

No, it just does the horizontal overlapping strips seen in many PCE games.