Why did the NES have its 8-sprite-per-scanline limitation? Why,

>>4037789
Each scanline the Picture Processing Unit (PPU) has to enumerate a list of objects (the technical word for what you call sprites) to draw. There is a limited amount of memory (like you say, I think 8 objects) for this compared to the total amount of objects the NES can keep track of simultaneously (I think 64). It was a compromise that kept costs down.

>>4037789
It's only weird to you because you are clueless about how tile-based hardware worked. The reason is simply PPU die size limitation combined with limited VRAM bandwidth and limited PPU clock speed.

>use FCEU X emulator
>turn on "allow more than 8 sprites per scanlined"
>???
>Profit!!

Or if you're a rich fucker by one of these NES clones with this feature.

>>4037789
NES had a MOS Technology 6502 under the hood, the processor was not multitasking, had like no pipelining. the data bus was 8 bits, anything larger means another cycle to complete the computation(s). scan lines need to be fast - they need to be guaranteed fast. adding a cycle to a simple computation can end up being very expensive in certain edge cases.

>>4038752
why would u suggest that

>>4037789
what do you mean by flicker? im not sure that increasing sprite per scan line would make any difference to that.

>>4038752
Does that affect gameplay

>>4038804
Because in some cases it does wonders.

>>4038810
No. If there is lag, it may reduce the lag a LITTLE bit because the game doesn't have to go through the routine that alternates which sprites are visible and which aren't.

Something I wondered: was flickering really caused by the sprite limit itself? From what I understood, some games employed flickering to compensate for supernumerary sprites, cycling between the sprites drawn every frame to allow all of them to be shown. This however was executed deliberately by the game code itself. Without this code, all sprites beyond the limit (both per line and total) would simply not be drawn at all by the PPU as they will not even be loaded into VRAM. Is this correct?

>>4038752
It breaks some games, though, I've heard. I wonder how and why.

>>4038802
Sprite flickering was a PPU issue, though.

>>4038862
>From what I understood, some games employed flickering
That had to be implemented by the programmer on software level, it's not done by hardware.

>>4038862
>Is this correct?

I think so, yes, which makes me wonder exactly how the "no sprite limit" works but that could also explain why it does nothing to some games

>It breaks some games, though, I've heard. I wonder how and why.

Well it does wonders to MM games at least and I never noticed any issue.

https://www.youtube.com/watch?v=5ivvu9R66bg

The video recording make things worse, half of the bullet completrely disappearing rather than flicker. Normally you'd see flicker alternating between one of MM's sprites, the bullet, and one of the enemy's sprite

>>4038802
Nah, it was all the PPU. Nothing to do with the CPU.

>>4038895
>>4038862

actually it has everything to do with the CPU.
data is taken from CPU registers. 8 bit data bus. PPU gets data cirectly from CPU registers - its the exact same bottleneck. 2 cycles to pass more than 8 pointers. can't get around it. DOUBLES your clock latency for busy scan line processing.

what a nightmare that would be to sync up if you didn't just go to 16 bit data bus or live with half as fast scan line processing.

>>4038912
The NES could DMA into VRAM though so that's absolute bullshit.

File: Overclock FCEU.webm (3MB, 1280x560px) Image search: [Google]

3MB, 1280x560px

>>4038752

I love emulation.

>>4038959
Wait, that actually works too? That's awesome.

>>4038924
>DMA into VRAM
DMA doesn't negate the use of registers to do calculations.

sprite data isn't stored in vram, its in its own special table. PPU and CPU are on seperate buses, so data bus is used when the CPU fills the PPU memory which happens whenever a sprite changes.

>>4038973
and im pretty sure cpu and ppu use the same registers. ppu is just a set of memory systems and maybe execution units im thinking. hard to get info like this however.

>>4038959
Been using FCEU X a lot and I had no idea this worked. Coupled with the "no sprite limit" it's glorious.

Can it break anything?

>>4038959
Congratulations. You made the game harder for yourself.

>>4039172
You mean he made the game playable.

>>4038959
Wow nice

>>4038807
The 8 sprite limit is literally the entire reason sprite flickering is a thing.

File: file.png (414KB, 489x400px) Image search: [Google]

414KB, 489x400px

>>4039172

>>4038912
Holy fuck you're stupid. The PPU has it's own registers. You don't pass a pointer in a bit. How it really works is all well documented. You haven't got a clue.

>>4039709
all memory addresses are pointers. the ppu has its own registers in cpu namespace.

How do you explain summer carnival 92 then?

>>4039737
Have you even played it? The game has a ton of sprite flicker.

>>4039716
>cpu namespace
You're just putting random words together shitrooster.

many computer didn't even have sprites at the time

>>4040241
ppu and cpu registers are the same.
>R/W, CPU D0-D7, and CPU A0-A2, are signals from the CPU. CPU A2-A0 are tied to the corresponding CPU address pins and select the PPU register (0-7).
>/CS is generated by the 74139 (address decoder) on the mainboard to map the PPU regs in the CPU memory range from $2000 to $3FFF.
>The PPU is controlled via eight registers visible in the CPU's address space in the addresses $2000 through $2007.

maybe YOU could offer an answer to OP question instead of just saying im wrong.

>>4039737
Clever use of the hardware

>>4040404
Or scrolling.
Many people forget Famicom was released in 1983.

>>4038973
>DMA doesn't negate the use of registers to do calculations.

It doesn't, but DMA circumvents the CPU bottleneck you described by transferring object attributes directly from RAM to the PPU. Flicker is not a CPU issue and you are baka for believing otherwise senpai.

>>4040686
You're an ignorant tool kid. The CPU registers are well documented. AXY being the ones you usually work with. The PPU registers are different. They're memory mapped so the CPU can write to them. If you knew fuck all about the subject you'd understand that the stuff you're quoting proves you wrong.

Maybe you could just stop shitposting

>>4040686
That doesn't make it the CPUs fault that the PPU can only do 8 sprites. They could've made the PPU be able to handle 1280 sprites, all stored on onboard registers stored on the PPU if they wanted to. But it would've made the machine more expensive, so obviously they made it as simple as possible.

>>4040695
>>4040404
C64 had both.

>>4040818
>but DMA circumvents the CPU bottleneck
8 bit data bus. what bus do you think the DMA is using?
DMA just repeats I/O in sequence on the same data bus as the registers.

>>4040874
>They're memory mapped so the CPU can write to them.
so how are they different? cpu namespace i said. data bus is still 8 bit.

>>4041862
DMA frees the CPU of the tedious task of reading memory addresses, fetching the data into a register, and pushing it to the PPU, which wastes an awful lot of cycles for 64 sprites and constitutes the the exact bottleneck you described. Even with an 8-bit data bus, DMA is faster because the PPU reads directly from RAM. That's what DMA does. What's your point?

Again, if you're the same guy, explain to me how flickering is a CPU issue because it's not. It has nothing to do with the data bus being 8-bit.

>>4041862
I know you said cpu namespace. That's not a thing. It's some random words you put together shitrooster. I already explained how they're different. You just don't understand because you don't know anything about the subject.

Fuck. It's going to be like this all summer isn't it.