PCEngineFans.com - The PC Engine and TurboGrafx-16 Community Forum
Tech and Homebrew => Turbo/PCE Game/Tool Development => Topic started by: pixeljunkie on September 08, 2014, 06:26:56 AM
-
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
-
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
-
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.
-
cool! thanks!
-
Line scrolls? I don't know why those would be limited to four though.
-
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.
-
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?
-
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.
-
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
(http://www.chrismcovell.com/images/DimTest.gif)
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.
-
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.
-
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...
-
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:
(http://i61.tinypic.com/27x1pcg.png)
But yeah, we need Bonknuts to weigh in! :D
EDIT: Tried to clarify.
-
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 :)
-
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.
-
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.
-
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?
-
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: https://www.youtube.com/watch?v=-xU9uuRzLwo
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).
-
I downloaded Image2PCE tonight but keep getting the "could not find or load main class" error. Anyone else have this problem? [On a PC]