wf
What's a PC Engine?
Posts: 3
|
Post by wf on Jan 23, 2024 10:02:57 GMT
I've read through various documentation found online, and have a few questions:
1) Because of the SATB being on-chip and only reloaded at vsync, does that mean it's impossible to perform raster effects on sprites?
2) Is there any reason to change the access timings in VDC register 9 from their fastest settings on PCE hardware?
3) Where does BAT addressing read from when you scroll past the end of the defined screen size? I've only read that it wraps, but it didn't specify how.
Thanks!
|
|
|
Post by elmer on Jan 24, 2024 1:57:05 GMT
I've read through various documentation found online, and have a few questions: Good for you, that seems to be a rare achievement for newcomers! 1) Because of the SATB being on-chip and only reloaded at vsync, does that mean it's impossible to perform raster effects on sprites? Well, you can still change the sprite palettes in realtime, but no, you can't apply swirly x-shift or y-shift effects to the sprite hardware coordinates, you've got to actually manipulate the sprite data itself in the VRAM, which is read line-by-line as it is used, a much slower process. turboxray or ccovell are probably the best people to talk to here about realtime effects. 2) Is there any reason to change the access timings in VDC register 9 from their fastest settings on PCE hardware? Yes, because you can overclock the VRAM. In practical terms, it is only at 10MHz clock (high resolution) where you should really use the lower setting. See this thread for more information. 3) Where does BAT addressing read from when you scroll past the end of the defined screen size? I've only read that it wraps, but it didn't specify how. It wraps on X and on Y seperately, just like other consoles with true hardware-scrolling (SNES/Genesis/etc). If you're used to old computers with 6845 VDC chips, or other ancient hardware with linear frame buffers, then no, the PCE implements proper hardware wrapping. Welcome!
|
|
|
Post by turboxray on Jan 25, 2024 14:37:23 GMT
I've read through various documentation found online, and have a few questions:
1) Because of the SATB being on-chip and only reloaded at vsync, does that mean it's impossible to perform raster effects on sprites?
Thanks!
Pretty much. You can do something similar to the SNES.. and "force blank" to reload sprites for active display.. but it's gonna cost you like 2-3 scanlines since it has to reload all SAT entries. You can control the color of the force blank display (sprite color #0) per line.. so you could make some "graphics" to hide the sprite reloading. This isn't easy to do though, because it's basically re-defining the active frame for the VDC multiple times during the VCE NTSC display frame. A more advance technique, and limited, is the force full sprite fetch (using off screen sprites) to happen in hblank and use that to sync the cpu to the VDC in the ISR, and then use fast resolution changes to offset (shift the screen left).. but compensate for this on the BG side by setting X reg. So you could, do a little wobbly-sine-whatever effects on sprite layer like this. Pretty advance technique tho haha. Also also pretty limited. You can turn on/off sprite layer for any given scanline. I guess sort of related.. ish.. is that you can have the VDC skip every other BG and SPRITE line.. causes it to show sprites had half height. Basically the VDC skips every other line of sprites. You can show even or odd lines by the least bit in the Y position. The downside is that display is clipped a little shorter horizontally, and BG tiles are affected in the same way (tiles are 8x4 with as every other line is skipped). FYSA - Rondo does sprite "raster" effects on the Giant three-eye'd skull for the graveyard level, to make it wobbly. It's a brute force effect on 16 line sections (the minimal height of a sprite). Not really "raster" but has that appearance.
|
|
wf
What's a PC Engine?
Posts: 3
|
Post by wf on Jan 27, 2024 8:46:31 GMT
Thanks for the info, fills in a few gaps of the docs. I looked up that Rondo boss, that's actually pretty effective, given the size of the boss, and I don't think any of those "splits" displaced more than 1px each. I'm a bit surprised at the drop-out of sprites during the death animation, doesn't seem like it's 256px of sprite, but it is probably hitting the sprite count limit if each of those individual flames is its own sprite? youtu.be/1vs8aP5lV18?t=964 So with sprites using standard features, there's raster palette changes, removing individual lines from display without affecting height, and pixel data updating (which doesn't really have to happen realtime, if there's only 1 instance or they're all on the same Y coord). The other more complex ones, yeah I'd do stuff like that on C64, but doesn't sound very introductory for a new platform, assuming that takes some cycle precision. No vertical sprite stretching/squashing, but I presume BG graphics do that with just the y scroll register as I've seen something like that. With the force blank reload, does that mean that you could multiplex 2 full sets of sprites between different sections of the display, assuming a hard break between those sections?
|
|
|
Post by turboxray on Jan 28, 2024 0:42:59 GMT
Thanks for the info, fills in a few gaps of the docs. I looked up that Rondo boss, that's actually pretty effective, given the size of the boss, and I don't think any of those "splits" displaced more than 1px each. I'm a bit surprised at the drop-out of sprites during the death animation, doesn't seem like it's 256px of sprite, but it is probably hitting the sprite count limit if each of those individual flames is its own sprite? youtu.be/1vs8aP5lV18?t=964 Yeah, if you load it up in Mesen 2, you can see the sprites exceed the 256 pixel limit with all the layers (eye-balls, flames, etc). Rondo tends to layer sprites on top of each other because it's cheaper than compositing them as pure pixels in realtime and much less storage space than compile time animation. Yup. Normally sprite multiplexing wasn't needed because of the shear screen coverage you can get with just the existing sprite sizes. Here's a demo that uses sprites as a full front layer on the PCE: www.youtube.com/watch?v=1iq8nQ2Bd80Note it only uses up to 32x32 sprite sizes, but can easily do 16x64 and 32x64 if needed if wanted to keep the total number down. The sprite limit is 256 pixels. Which means with a 256 pixel wide display you can't "scroll" a solid line of sprites in. But the VDC lets you define the resolution in horizontal segments of 8 pixels. In that demo, I have the VDC clip the display a little so that I can scroll in sprites without break up. The pre-equal to Samuri Ghost does this, and for the same reason. Yeah. Basically it works like this: VCE supplies h-sync and v-sync signals to the VDC. And these trigger the correct synchronizations for the VDC to change to the next line, or next frame. But the VDC was also designed to run without external signals.. and just define the display itself (it's the same design as the sharp X68000). H-int and V-int themselves aren't driven directly by the VCE. As in, the VDC is assert H-int when the active display ends.. not when VCE asserts h-sync pulse (which happens near-ish in the end of hblank). V-int happens at the end if the last visible displayable "VDC" scanline.. again, not the VCE v-sync pulse. So you can define a vertical that's only like 10 scanlines tall on the VDC. the VDC has two registers were it "waits" for these sync pulses, but if it times out, it just goes on as if there were a trigger that happened. Likewise, if you're in the middle of something.. and a VCE asserts a sync.. then the VDC (even though it didn't expect it).. snaps to the next "func". If this is a h-sync, then it's the next scanline. If this is v-sync, then the start the next "frame". So with that logic, every time the VDC expires a frame, and auto-satb-dma is enabled, it will reload the internal SAT registers. You can have this happen multiple times in a single NTSC VCE frame. But like I said, during this time BG and SPR are not show.. and sprite color #0 is show. You could change the colors of those lines to draw like a pipe or something (amiga "color bars") that would appear in "front" of the BG and Sprites.. so to speak. If you ever seen PCE games that have cheat codes that put the game in "four screens mode"... this is what is happening. But like I said, this is a pretty advanced trick. And example of doing a single reload of all sprites.. is like the lake level in Bloodlines where the sprites are up-side-down in the lake reflection, and clip at the waters edge - for both the regular ones and the upside down ones, You could have a 2-3 line break right at the waters edge for this effect. The reloaded sprites would have alt palettes (for water reflections), flipped, and modified Y positions.
|
|