[libretro] No sprite limiter option support for 8 bits systems games?

[FeRcHuLeS]

Is there any chance to implement this feature?? So the 8 bits systems games could be played nice and soft.

[ekeeke]

No, as I stated in the other issue (#75) you previously created

There is no plan to add an option to remove that limitation because it would add too much overhead in the sprite processing emulation code and can cause inaccurate behavior (some games use this limitation as a "feature" to hide sprites).

I also personally think that 8-bit system games play nice the way they are and these limitations are parts of their identity, removing them would not be emulating the system I have memory of but a virtual "enhanced" system that never existed and will never exist, hence why I don't think such "feature" is needed by the emulator.

[FeRcHuLeS]

We talket before about this related to the Wii's hardware and its limitations but is not the case for libretro, besides the essential of emulation is not only what you exposed but also improving the exprerience we had in the original systems, as for the Sega Genesis the feature I requested is implemented by default, this doesnt have to be by default for 8-bits systems, just a switch on/off.

For me as a big fan of Genesis Plus GX this feature is the only left for the emulator to be perfect, please consider it in the future though as experimental :)

[ekeeke]

We talket before about this related to the Wii's hardware and its limitations but is not the case for libretro,

No, that comment was not specific to a platform but a generic one. I don't want to bloat the VDP core with features that do not exist on real hardware and those limitations were actually used in some games to hide things voluntarly.

besides the essential of emulation is not only what you exposed but also improving the exprerience we had in the original systems,

Except we are not talking about adding savestate or filters here to make experience nicer, we are talking about fundamentally changing the way the original system worked by increasing the number of sprites that its video processor could internally process per line and making it limitless.

What would be next? Doubling the internal RAM or adding feature to CPU because games are too simple or too slow compared to 16-bit games? Increasing or changing the color palette because some other systems look nicer? Adding a sound channel because NES sound is better?

Again, this limitation is part of Master System hardware specification and the games were programmed to deal with it and so should we.

as for the Sega Genesis the feature I requested is implemented by default,

No, the Genesis hardware used an enhanced version of the Master System VDP. It can process more sprites per line but still has its own limitation which appear to be slightly higher than Master System ones. There is actually sprite flickering in a few Genesis games that hit that limit too. So it's not "implemented by default" but accurately emulated in regard to original Genesis hardware spec, just like Master System is. Therefore, the argument that says "well, the Genesis can do it so it should be possible on Master System" does not make much sense. Sure it can do, it's a more powerful system with better looking games. If you don't like how 8-bit games looked, well yeah you maybe should just stick to 16-bit games ;-)

this doesnt have to be by default for 8-bits systems, just a switch on/off.

This is not as simple as you imply it is, it's not "just a switch", still require to bloat the VDP core code with optionnal stuff that are non-existent in original hardware implementation, which I don't want to do to keep the core clean and as close as original hardware as possible.

For me as a big fan of Genesis Plus GX this feature is the only left for the emulator to be perfect,

Yeah, if I had received $1 everytime I have read this, I would be rich by now ;-) Fact is people always want more, so there will always be something "cooler" to "make the emulator finally perfect". That's why I'm not driven by what "fans" want and I am more concerned about perfect emulation than making the games look different that they originally were.

please consider it in the future though as experimental :)

Well, let's say it has been considered already and it won't happen for aforementionned reasons...

[FeRcHuLeS]

I see, that's the way you think I respect that but tell me it's said the Master System has 24KB of ram but as segaretro.org some models had 40KB almost twice ram, so could this be emulated in order to fix the sprites. As off-topic never say never since the Sega Mega Drive 2 was released as emulator for the 3DS as part of the SEGA 3D classics for the Master System I'm not sure if they made something similar :)

[GerbilSoft]

I'm not sure where the "40 KB" reference came from (the two sources on Sega Retro don't say anything about it, unless you count paging in 16 KB of RAM from a cartridge), but the Master System VDP definitely can't use more than 16 KB. This is mostly a limitation of the VDP command protocol, which is limited to 14-bit addresses (inherited from the TMS9918). I also suspect there's only 14 address lines, though I can't find a pinout of the SMS VDP right now.

The Mega Drive VDP does have a little-used 128 KB VRAM mode, but AFAIK the only platform that had 128 KB available was the Sega Tera Drive. The 128 KB mode doesn't improve the sprite limit, since that's entirely dependent on the temporary RAM built into the VDP.

[ekeeke]

it's said the Master System has 24KB of ram but as segaretro.org some models had 40KB almost twice ram, so could this be emulated in order to fix the sprites.

You read it wrong, all Master System models have the same amount of VRAM (16 KB) and internal RAM (8 KB).

Anyway, it has nothing to do with RAM size, the sprite limit is directly related to the number of possible VDP access to VRAM on each raster line, which determine the max number of sprite pixels that can be fetched and therefore displayed by line.

Genesis VDP used faster internal clock & improved VRAM bandwidth to increase the number of access per line but also an internal sprite cache to reduce number of VRAM access for sprite prefetch so the limit went higher.

Adding more RAM therefore won't help, both VDP being internally designed and sized for their own specific timings.

As off-topic never say never since the Sega Mega Drive 2 was released as emulator for the 3DS as part of the SEGA 3D classics for the Master System I'm not sure if they made something similar :)

You are mixing things, it's called the Gigadrive (not Mega Drive 2) and it's an imaginary Megadrive model with an enhanced VDP supporting extra stuff to render layers with 3D depth. As far I know, it's not used for the 3D Master System games since they already render basic stereoscopic 3D but only 2D Genesis games.

[FeRcHuLeS]

This feature was actually made for the SMSplus-gx emulator, so I'm begging you to keep your word and add it again since you posted the following:

Thank you.

I've implemented all SMS Plus GX features (and more) in Genesis Plus GX so I'm not going to update this project anymore, takes too much time to handle muti projects.

Original comment by ekeeke31@gmail.com on 13 Jul 2011 at 11:06

https://github.com/ekeeke/smsplus-gx/issues/16

I wasnt aware of this before I created this issue, I dont know how much work is to implement it but you have proved you are talented and this emulator is the best by far compared to another ones as today, pleeeease dont keep breaking my heart! :)

[ekeeke]

Being pushy or flattery is not going to give you anything, I already stated my opinion on this matter and think I was very clear as to why this won't happen.

If it was not copied back from smsplus-gx (it wasn't the only ditched feature by the way so I guess I was wrong back then), I likely had my reasons.

So you better start accepting it and stop being so obsessed because you are becoming kinda annoying.