Game design with regards to resolution

[Bonknuts]

More could have been done with the VCE though. It's already getting the digital pixel bus from the VDC, it itself could have had a small non scrolling tilemap layer with 256 tiles; a fixed layer that could be set above all the display or behind all the display.

[elmer]

More could have been done with the VCE though.

There are lots of things that are technically possible, but not economically feasible.

Just look at the Genesis and the SNES ... both of those consoles have a very similar sprite capability to the PCE. That's just a function of what was affordable to design into a consumer-level system at the time.

Hudson had a long working-relationship with Sharp on the MZ80 and the X68000.

They would have been well-aware of what it would have taken to double the sprites-per-line processing (i.e. the X68000 hardware).

As a commerical-reality, you'll see that it was only multi-thousand-dollar arcade boards and the multi-thousand-dollar X68000 that could actually afford to do that back in the mid-80s when the PCE was designed.

Costs came down dramatically in the late-80s/early-90s ... leading first to things like the Neo Geo arcade hardware, and then to the 5th-generation consoles. 

It's already getting the digital pixel bus from the VDC, it itself could have had a small non scrolling tilemap layer with 256 tiles; a fixed layer that could be set above all the display or behind all the display.

If you think about it, the VCE doesn't have any access to VRAM ... so you'd either be adding a lot of extra pins to it in order to access the existing (or separate) VRAM, or you'd have to build SRAM into the chip itself. Both of those would be a huge expense.

It would probably have been much cheaper to modify the VDC to add extra capabilities ... but then you'd have required fast VRAM ... which IMHO seems to go against the VDC's original design.

I think that they did the best that they could with the limits that they were probably working under.

Actually, I think that they went well above-and-beyond. The custom capabilities that they added to the 6502 to make the 6280 were a stroke-of-genius.

If you look at Sega and Nintendo, they both just bought off-the-shelf processors and then tried to work-around their limits with DMA or mindbogglingly stupid memory maps.

AFAIK, it's only the 6280 where someone took a look at the basic CPU itself and modified it to improve it's processing capabilities for the kind of tasks that 2D sprite-games do.

[Aladar]

Are you going to run out of SAT entries doing this? At a 208x160 viewable window, it's 7x5 entries if the ENTIRE screen was filled with 32x32 sprites. That's 35 sprite entries of the 64. So I think we're in a pretty safe zone. If even that max was pushed to 48 entries, for whatever reason, that still leaves 16 entries open for the character and enemies. More than enough for considering sprite objects can be quite large. Do the sprites for the pseudo layer have to be 32x32 in size? No. I would do a 32x32 tilemap system, with a meta tile lookup table that would be capable of displaying any size and combination of multiple sprites inside that definition (including fine pixel offsets).   

With a screen of 208 pixels you have 52 sprites not 64...

[Bonknuts]

With a screen of 208 pixels you have 52 sprites not 64...

 How do you figure 52?

 The total SAT length never gets smaller, even if the scanline amount of cell shrank - which it doesn't in this case. It only shrinks of you increase the visible width of the scanline to the point where hblank is too small to fetch all the required sprite cells for that line.

[Aladar]

Here's proof(each dot is a sprite):

[Bonknuts]

That makes absolutely zero sense. Unless some pre-processing to the SAT is happening in the first handful of active scanlines. But why would that be dependent on the active part of the scanline, of all things.

 What if HDE is shorter and HDS is longer? Or if the first 8 or so scanlines are full length and the rest are clipped? Dammit I can't test anything until after finals..

[elmer]

How do you figure 52?

The total SAT length never gets smaller, even if the scanline amount of cell shrank - which it doesn't in this case. It only shrinks of you increase the visible width of the scanline to the point where hblank is too small to fetch all the required sprite cells for that line.

I think that you'll find that Aladar is correct, and that you may need to take a look at the docs again
(page H7-19).

The hsync time is used to fetch the actual sprite pixel data for the next line (up to 16 max), but the display width limits the amount of SATB entries that can be searched to determine which sprite data needs to be fetched in the next hsync.

So with a 208 pixel wide display, HDW is set to 25 ... and the docs say that only 53 SATB entries can be processed. The actual calculation is (2 * (HDW+1) + 1).

That processing happens on every line that's displayed ... it doesn't happen in vsync time like you may to be thinking.

[Bonknuts]

So with a 208 pixel wide display, HDW is set to 25 ... and the docs say that only 53 SATB entries can be processed. The actual calculation is (2 * (HDW+1) + 1).

Wow, that's pretty retarded; they had all of HDE to continue that process. That means my 16x8 cell trick has the same 52 limit. Oh well, at least 52 is still usable. 

[elmer]

Wow, that's pretty retarded; they had all of HDE to continue that process. That means my 16x8 cell trick has the same 52 limit. Oh well, at least 52 is still usable.

Yeah, but the HDE is used for fetching the sprite data.

It's just the kind of little detail that gives you a good idea of exactly how they're implementing the sprite logic in the silicon.

At the end-of-the-day ... the system just wasn't really designed to be "abused" in the way that you're planning.

53 sprites should, at least, be fine for what you want to do ... I suspect that you'll hit other design limits before you hit that one.

[Bonknuts]

If the VDC is fetching sprite data during HDE, then that means it has different behavior for when the VCE generates an interrupt. As in, during HSW the VCE interrupt simply triggers the VDC to go to the next phase. But when the VDC is setup in a way that the VCE hsync happens outside of HSW, the VDC would end the current line and to start the next line with HDE first.

[ccovell]

I knew there was some kind of dropout related to narrower screens.  Aladar, thanks for demonstrating that with your sprite grid.

Incidentally, I had updated my Screen Dimension test earlier, but the sprite dropout display is a good reason for actually uploading it.  (I've added in a grid of sprites too.)  Looks like (especially at low resolution) sprites drop out (not merely glitch) if you make the display too narrow or too wide.


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

So, for games with narrow screens (Like 1941), I'm wondering if the programmers kept these limitations in mind with their sprite logic...

[Bonknuts]

Ahh I see it in the docs now: 2d+1 and 2(e-2),max 16.

[elmer]

Ahh I see it in the docs now: 2d+1 and 2(e-2),max 16.

Yep, that's it! 

If the VDC is fetching sprite data during HDE, then that means it has different behavior for when the VCE generates an interrupt.

I'm not sure exactly when the fecthing starts ... the doc just says that the timing for fetching the sprite data is (HDE + HSW + HDS + 3).

The top line of the visible display is much lower down than the actual start of the NTSC frame ... so there is plenty of time to prime the first line of sprite data.

I'm not sure exactly what you mean with the exact HDE/HSW/VCE timings ... but I don't see why there would be much of a link between the VCE interrupt to the CPU and the VDC's actual internal pixel processing ... the VDC has it's own set of cycles to access the VRAM, and the SATB is internal to the VDC, anyway???

What am I missing?

[Bonknuts]

Well, the low res mode has scanline width of ~341 pixels. That doesn't fit nicely into any of the VDC pixel reg layouts, so that's what HSW is for. It waits for VCE interrupt and as soon as that happens, the VDC moves into HDS phase (HSW window ends early). It's a time out window. This is how it works with external sync. It's the same way for vertical sync.

 But what happens if the VCE doesn't generate a hsync signal to the VDC when it's waiting for it? HSW times out and it goes into HDS phase anyway. But when the VCE asserts hsync to the VDC, regardless of what phase it's in, the VDC automatically starts the next line process.

 So this is what I meant, that if HDE is a big part of sprite fetching pixel data, then the VDC line actually starts at HDE, HSW, HDS, and then HDW. In that order. And not HSW, HDS, HDW, and finally HDE. Because if it did, and HDE is part of that sprite pixel fetch process, then my 16x8 sprite cell trick wouldn't work at all. As in, it wouldn't show all 16 cells. But in fact it does. It's hard to make out those sprites,

, but those are eight 32 wide sprites - just half height. Not to mention other games that do "4 window mode" via cheat codes (useless, but looks cool).

 The 16x8 cell trick is different than full scanline/sprite line skip method (with similar timings), but I discovered that VDC preps for sprite lines and BG lines at different parts of the hblank area. If the spite line prep starts (some internal counter), but the VCE sends hsync to the VDC before it begins BG line prep, then only the sprite line is skipped and the BG is show normally. This has the effect of sprites showing with every other line missing. It also has the effect the D0 of the Y position selects whether to show even or odd lives of a sprite; basically meaning sprite data in vram is now interleaved.

 So, this begs the question.. where in the VDC scanline is the cpu triggered from the interrupt on the VDC side? Because it's the VDC that sends the interrupt to the processor. In my above example, you could do double interrupts per scanline. I suspect when HDE starts, is when the processor receives the interrupt. Visually though, the VCE delays the VDC's output (I think it's by 8 or 16 pixels). So trying to do visual tests probably won't work. It needs dual channel scope.

[Aladar]

you may need to take a look at the docs again(page H7-19).

Ahh I see it in the docs now: 2d+1 and 2(e-2),max 16.

Which document? I don't remember an explicit and detailed reference to sprites dropout.