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

https://www.pcengine-fx.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.

PC Engine Graphics Summary

The PC Engine can generate up to 64 sprites and a background layer.

Colors
There are 512 available colors, which you can see here:
/pcenginecolourpalette.png

Note: With this color selection you can't use rgb(255,255,255) for white, which is slightly annoying.  If it's important to you to use actual white, then use it in lieu of the available "white" in that file--but then you have to remember that white is out-of-step with the other 9-bit colors!

Palettes
32 color palettes are available at a given time:

Palettes 0-15 are for background tiles

Palettes 16-31 are for sprites


Each palette has 16 colors, but for sprites the first color is used for transparent pixels--so you only actually have 15 colors available for a given sprite.  Background tiles have all 16 colors available.


Note: For sprites and tiles that share palettes, please make sure that all colors are in a consistent order!

Sprites
Each sprite can have one of the following sizes: 16x16, 16x32, 16x64, 32x16, 32x32, 32x64.  Larger objects can be built with multiple sprites.


A maximum of 256 pixels per scanline (horizontal row of pixels) can be displayed simultaneously.  If that limit is exceeded then the lowest-priority sprites start getting dropped.  [I think this pixel limit includes transparent pixels but I'm not 100% sure about that, I'll fact check this.]

Background
The background is built using either 8x8 tiles or 16x16 tiles (but not both).  Each background can use up to 256 unique tiles, and each individual tile has its own "palette" index attached to it--which refers to one of the 16 available background tiles.


Tiles are arranged in a "map" that is a maximum of 256 tiles wide and 256 tiles tall, the viewable portion of which is the background visible on-screen.  Speaking of which, the viewable area of the PCE's "normal" resolution is 256x224.  The PC Engine will output more pixels into the overscan area, 282x242 in its low-resolution mode, but we will only make use of 256x224.  (There is also a high-res mode of 565x242.)


The background can have up to four independently-scrolling areas (this is a HuC limitation).


Apparently you can also have an additional "background layer" made of the background color.  (http://www.pcengine-fx.com/forums/index.php?msg=370401)

[pixeljunkie]

cool! thanks!

[NecroPhile]

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?

[OldMan]

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: https://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.

[OldMan]

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.

[OldMan]

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.

[CrackTiger]

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.

[TurboXray]

 WALL OF TEXT!

Yeah, the BG color #0 trick can scroll vertically (or expand/scale/shrink/etc). You consider it as its own layer because not even low priority set sprites can show behind it. So you have 4 planes; BG color 0, low priority sprite, BG plane pixels (except #0), high priority sprites.

 Like Chris mentioned, you can do copper bars. These can appear as vertical bars instead of just gradients. And you can make many layers of these scrolling up to down. You can even 'connect' them with small sprites vertical sprites to make 'grid' layers. On that note, you can do the same for a layer 'above' or front of all layers (turn off sprites for that part, repositioning the BG to 'row' graphics). Again, still using vertical sprite columns to connect them (skinny vertical sprite columns don't really eat into the sprite pixel scanline bandwidth). You've got to think outside the box ;)


 I took CCovells screen demo and did a capture card measurement of the screen resolutions. I was able to get ~286 for low res. Mid res is about ~379, and 572 for high res. Of course, this doesn't actually change the pixel width (256 vs 286). It just allows more pixels in overscan area. To me, this is about useless. And there's also a down side to this; if you shorten hblank width (the total of it), it will start dropping sprites for the scanline - because it doesn't have enough time to finish grabbing all the sprite pixels for that line.

 As far as 'scrolls' or dividing the screen into sections: every scanline can have a new X and Y update, as well as updating BG/SPR colors, and other registers of the VDC and VCE (sprites on/off, bg on/off, change resolution for that line, etc). The scroll number listed in this thread, is just a limitation of HuC's library.

 
 On the extreme end, you can make the PCE show 50% shrunk sprites. That is to say, 16pixels wide, but in increments of 8pixel tall (so XXby8, XXby16, XXby32). The screen will have slight offset to one side and will be smaller than 256 pixels (I think 240), but the advantage is better use/optimization of vram for small sprites. And better sprite pixel scanline optimization. The trick works because the PCE VDC setups up the BG and sprite lines at different phases of hblank - you basically cause the VCE to interrupt the VDC after it sets up the next Sprite line but before it sets up the next BG line. This is done every other line, so the BG shows fine but every other sprite line is skipped. This also has the side effect that vertical position of the sprite needs to be in powers of 2, and that the first bit (D0) in the Y position is a 'bank' selection as to what 'interleaved' sprite data to show (because now a 16x16 cell is actually two interleaved 16x8 cells). Like I said, extreme. I have a video showing it off on the real system, but nothing impressive visually (sorry).

 I think everyone knows about dynamic tiles. But Ninja Sprite (2nd level) does something that no other game on the console does (that I know of) ;)

 A lesser known trick, gradient transition layers on the BG map. This works because you have such a huge set of subpalettes for the BG layer. If you reserved 4 sets of 4 subpalettes, you can do a 3 level gradient transition. If you do 2 for main, that's 7 levels. And if you do 1, that's 15 levels of gradient areas. All depends on how you set it up. You apply this with an H-interrupt. Basically you copy an 8 pixel tall strip of the desired tilemap section, and update it when the alt set of subpalettes. Then, during active display - you swap to the alternate map position. There are other ticks like this, that you can do with maps and subpalettes (Sapphire light effect BG in one of the stages).

 And another trick, for doing multilayer scrolling stuff (overlapping) with sprites - is to set the resolution of the window from 256 to 240 pixels wide. This allows you to scroll infinite amount of sprites in a row across the screen (since any odd number in a row will be will be the row width+1; 240 is 15 segments of 16 pixels and the sprite limit is 16, so 15+1 = 16). Usable for cinemas, but also in game stuffs too.

 There's probably quite a bit more that I can't remember.

[Sadler]

Can I just blast out a bunch of stupid question? Because I'm about to drop some serious ignorance on you.

Is there merit to OldMan's idea about switching background color mid scanline? Could simple, perhaps static, procedural patterns like checkerboards be done this way? While I don't think a static far layer looks that bad, what about dynamic? Could you feasibly scroll horizontally with such a pattern?

This (and probably all ideas I'm spouting) probably takes more CPU than you can realistically use, but what about multiple layers of background colors? How many gradients can I have moving about? Could I, say, have a pipe gradient that scrolls faster than a sky/ground gradient? You'd have two or more offsets to track, but it seems like this isn't completely impossible.

You touched on this in your ninja spirit post (and perhaps your above post which will take a long time to digest), but what about palette rotation? Everyone thinks "blinking lights" and "waterfalls" when palette rotation is talked about, but in an 8x8 tile with 15ish colors available, you can assign a unique color to every horizontal or vertical strip. For something like a brick wall, set most to red and one line to white for the grout. Change which color is white in the palette as the screen scrolls for something similar to dynamic tiles, but without the overhead of 8 different tiles for one-axis of scrolling. Hell, could you combine that with dynamic tiles to get multidirectional scrolling with only 8 tiles?

The sprite distortion you mention, there's a PCE game that I want to say is Sol Moonarge, but have reason to believe it might not be that might be doing this. I saw a video clip of a character walking being a jar of some fluid and becoming distorted while behind it. At the time I thought it was related to the DW Duck magnifying effect, but I *really* don't understand how that works.

Finally, and this is massively off topic, but how exactly are people doing line drawing with tile-based hardware? A set of precomputed tiles is the best I can think of but there has to be a better way.

EDIT: Dumbest question yet: Copper bars? Can be vertical? What's this all about?

[TurboXray]

Can I just blast out a bunch of stupid question? Because I'm about to drop some serious ignorance on you.

Is there merit to OldMan's idea about switching background color mid scanline? Could simple, perhaps static, procedural patterns like checkerboards be done this way? While I don't think a static far layer looks that bad, what about dynamic? Could you feasibly scroll horizontally with such a pattern?

Not really, and it's mainly because of one reason; whenever the cpu read/writes/accesses *any* VCE register (color port or otherwise), the VCE will stop reading from the VDCs pixel bus, and will continue to output the last color (well, value) that was on the pixel bus. For instance, you have a store instruction STA. It's 5 cycles long, of those five cycle - it will hold the VCE bus for probably 3 or 4 of those cycles (this is in cpu cycles, not pixel cycles). So if you did manage to time your code (and you would have to somehow re-sync the cpu inside the interrupt routine to the VCE or anything, because of interrupt jitter. Even 1 cycle makes it jitter. This is why the registers on the VDC are buffered and only accessed once per scanline - allowing code to update the regs through out the line without timing issues), you'll be stretching pixels for the position you want to change this. You can see the effect very clearly here:

In my case, I wanted that effect because I wanted to do screen distortion in specific areas. A series of read or writes, causes gaps were no pixels are stretched, allowing new pixels to be showed as stretched. On the plus side, if you wanted a very 'long' stretched pixel - you would use one of the Txx instructions since it holds the VCE bus active the whole time until it's finished - no gaps. But yea, see the checker board pattern on the left side? That gets changed mid scanline (well, more to the left because I positioned it there). Also, that video shows the 16x8 sprite mode I was talking about (like I said, nothing impressive to look at other than proof of concept).

This (and probably all ideas I'm spouting) probably takes more CPU than you can realistically use, but what about multiple layers of background colors? How many gradients can I have moving about? Could I, say, have a pipe gradient that scrolls faster than a sky/ground gradient? You'd have two or more offsets to track, but it seems like this isn't completely impossible.

It's very easy to do and very lite on cpu resource (excluding the h-int routine). Say you have a display that is 224 pixels tall (because of overscan issues) and say that there is a reserved part for status bar - 32 pixels. That leaves 192 pixels of 'game screen'. So you have two arrays; 192 bytes for the LSB color, and 192 bytes for the MSB color. To draw gradient background on the screen, you simply update Y only positions. That equivalent to manually writing 192 pixels (sequentially at that!). That's dead easy to do and doesn't take much time at all. So, you draw you gradient colors, then you draw your 'pipes'. The pipes are only y+offset and the number of pixel tall. That's it. Do as many as you want. You could have lots of layers of scrolling pipes and a gradient scrolling layer as well. And don't forget - any 'line' can use any of the 512 colors of the master palette.

You touched on this in your ninja spirit post (and perhaps your above post which will take a long time to digest), but what about palette rotation? Everyone thinks "blinking lights" and "waterfalls" when palette rotation is talked about, but in an 8x8 tile with 15ish colors available, you can assign a unique color to every horizontal or vertical strip. For something like a brick wall, set most to red and one line to white for the grout. Change which color is white in the palette as the screen scrolls for something similar to dynamic tiles, but without the overhead of 8 different tiles for one-axis of scrolling. Hell, could you combine that with dynamic tiles to get multidirectional scrolling with only 8 tiles?

That's right! There's a huge amount of subpalettes and you could easily reserve 'colors' in a subpalette or whole subpalettes to animate things (including simulating individual moving layers). Edit: I guess I'll give that as my second hint for the last part in this post.

The sprite distortion you mention, there's a PCE game that I want to say is Sol Moonarge, but have reason to believe it might not be that might be doing this. I saw a video clip of a character walking being a jar of some fluid and becoming distorted while behind it. At the time I thought it was related to the DW Duck magnifying effect, but I *really* don't understand how that works.

Looks like more of a brute force method - kinda. The edge of the jars are the transition to remove the old sprite and switch do a new sprite. The new sprite is probably pre-stretched or stretched at runtime (the start of the level) and cached as frames to access later. But yeah, not the same thing. that I was mentioning.

Finally, and this is massively off topic, but how exactly are people doing line drawing with tile-based hardware? A set of precomputed tiles is the best I can think of but there has to be a better way.

Usually brute force, but I had a trick for rasterizing multiple points in an array to a screen (in horizontal strips). Not so great for random pixel access, but very fast for solid runs of pixels (like for polygons). It also didn't use a pixel buffer, so you saved on not having to clear it (which can be expensive), and you don't need to upload it (which can also be expensive). I got the idea from watching an Amiga demo (spheres that overlapped and did transparency in the overlapping parts). Saving that for a demo.

EDIT: Dumbest question yet: Copper bars? Can be vertical? What's this all about?

It can be tricky if you're not using sprites. I have a demo that does them at unlimited 128 colors, but at half res (128 pixels for 256 pixel display). They have the same limitation as horizontal copper bars and also appear behind the BG layer, and has the same setup as the vertical method talked about (a single array of 'column' pixels) - except no H-int is needed. It's tricky to setup - I don't use sprites or BG tiles to do it ;) I don't want to give out my secret for it yet, because I was saving it for a PCE demo. But yeah, it's do able. If you really sit down and think about it - you'll probably figure it out (there's only one way to do it AFAIK without sprites; that's your hint).

[pixeljunkie]

I downloaded Image2PCE tonight but keep getting the "could not find or load main class" error. Anyone else have this problem? [On a PC]