pattern table based shadowing has tile granularity, whole tile and everything underneath gets shadowed.
pattern table based shadowing has tile granularity, whole tile and everything underneath gets shadowed.
Death To MP3,
:3
Mida sa loed ? Nagunii aru ei saa"Gnirts test is a shit" New and growing website of total jawusumness !
Pretty much, since it's based on the priority of each tile.
Basically, for each pixel on screen:
- If all layers are low priority, pixel is shadowed by default, otherwise it's normal by default
- Sprite palette 3 color 14 goes transparent and makes pixel brighter
- Sprite palette 3 color 15 goes transparent and makes pixel shadowed
Tilemaps fall under the first rule, and since priority is specified on a per-tile basis, this means that tilemap-based shadowing has tile granurality. This also means tilemaps can't do highlight, only sprites can.
OK, I knew how sprite SH/HL was used (though I'd forgotten about it obscuring other sprites until you addressed that a few posts back), but I hadn't realized tilemap shadow was limited to a per-cell basis. (for some reason I'd thought it was more like sprite SH -or Amiga halfbright- except also tied to priority -ie still with pixel granularity tied to one of the 16 tile colors, but having additional relation to tile priority)
That also means some of my comments of using dual tilemap layers for more colors with shadow were incorrect (I assumed you could get a 46 color pseudo bitmap that way -16 colors plus another 16 shadowed colors plus 14 colors from the palette on the upper layer), though that could still be done using sprites for a 61 color/shade pseudo bitmap layer. (and the simpler/more limited idea of using shadow on a per-cell basis would still work -including the context of using that for FMV . . . similar to the existing schemes using multiple palettes on a per-tile basis -with virtually no increase in bandwidth/VRAM usage)
And for high detail static screens you could always use overlaid BGs and sprites with SH+HL (and all 4 palettes) with up to 106 colors/shades per tile, like Toy Story does for splash screens. (I think Earthworm Jim 2 may as well)
Oh, and of course, that means tile based shadow is much more limited than halfbright on the Amiga. (though shprite based shadow is somewhat closer -except with the problem of obscuring other sprites vs not shading at all for Amiga sprites)
@ 4:30 in the video
The game uses dynamic tiles for parts here and there, but what made me take notice was the one particular level with the trees in the background. They're dynamic tiles; no surprise there. But what is surprising is the size of the dynamic tiled image: 128x128 pixels. The largest I've seen so far in a console game from that era.
It's interesting how much of a difference parallax scrolling makes. The levels in that game repeat so much that probably the ROM is all wasted on that animation XD.
Still need to come up with a way to do bidirectional parallax scrolling that doesn't require a bidrectional pattern or crazy stuff with sprites.
This thread needs more...ENGINEERS
Are you sure about the dynamic tiles ?
What i see is a simple background plan + some sprites used on the first plan when it overloads the tree part. It's much more simpler to do this way.
Yup, I checked the game out in mednafen debugger as well as a tile editor. It's a 128x128 pixel image in 8x8 tiles. There are 8 frames total, which is all that's needed since it doesn't scroll vertically (at a different speed).
Well, since they already used dynamic tiles for that - they could have added some additional foreground layer detail/scroll in conjunction with it.If they did that then this game is an even bigger fail. If you can scroll freely why limit yourself to a pattern like that?
Specially considering just how few locations there are in the game.
Software scrolling? Has been done before, though only at 4×4 tiles =/
Pretty sure it's a tilemap just because some parts of the foreground do indeed clash with the background (e.g. the sloped rooftop in the building at the end of that part, the background goes invisible in those tiles).
That'd make it 64×64 pixels (that explains why it looked so small for 128×128 =P).
Or just open the rom up in tilemolester and look at the tiles directly. They're uncompressed.
Err, it's 8x10 setup actually or 64x80 pixels. I must have confused it with my Rtype 2 demo I was doing at the same time I looked at this game, but it's still the largest I've seen for such a thing commercial wise (outside of small home computers).That'd make it 64×64 pixels (that explains why it looked so small for 128×128 =P).
Have you guys seen the Neo Geo homebrew game Gun Lord?, its a pretty cool Turrican clone. Its nice to see the Neo get a game of this type. Heres is the trailer:
http://www.youtube.com/watch?v=HohDE...eature=related
You mean 4 pixel scrolling? How was that scrolling done? "Brute force" drawing onto the tiles?
Not good enough.
The best scrolling I can come up with for the PC Engine:
- Far background cannot contain any repeated tiles.
- Requires a special image encoder.
- For each color on the image on an 15x15 (wrapping) block (these blocks are stepped in 8 pixel increments):
-- See the colors below and to the left of it.
-- Encode that "3 color" combination as a single color on a global palette (if the color in the middle is repeated elsewhere, that's treated as "another color", and takes another spot on the palette)
-- Store the color on an external table as: [col, below, left]
-- If there are too many colors (and there will be), go over the image finding similar colors and replacing them with a "close enough" combination that fits all.
-- Analyze the tiles and global palette, and find a good way to make everything fit in like... 8..12 palettes.
-- Do another "close enough" replacement pass if needed.
- Every frame, replace the colors on the palettes by their "below" color (if scrolled vertically) and then by that color's "left" color (if scrolled horizontally).
-- Repeat if moved by more than 1 pixel.
- In case an 8 pixel movement has occurred, change the tilemap instead.
There you go, bi-directional scrolling on the PCE.
Now I need to find a way to do line scrolling.
I really want to play that...
This thread needs more...ENGINEERS
You forgot the 5-layer demo, right? Two of the layers were software scrolled. Because simply scrolling a 32×32 pixel area wasn't enough, so I've put a layer inside your layer so you can scroll while you scroll [/yodawg] :v
I wonder how much VRAM would something like this eat up ;P
You'd need that in any devkit anyways.
I don't think programmers would be happy with 15×15 blocks. 16×16 would be nicer since 16 is a power of two.
Also, analyzing your idea... You've just replicated what Traveller Tales did for the 1bpp FMVs in Sonic 3D =/ (Sega logo and Game Over screen, those two use palette trickeries to store four frames into a single image)
There are currently 1 users browsing this thread. (0 members and 1 guests)