d3scride's Feed

I like where you are going with this, but how would the system know to exclude in the case where there is NOT a dual region version of a particular game?

Do mean like the speedrun leaderboard?

Originally Posted by sdwyer138

I like where you are going with this, but how would the system know to exclude in the case where there is NOT a dual region version of a particular game?

Well you'd only have to know the regional codings for the consoles themselves not for each individual game. Once that is determined then any games being added to that platform (console) would by default have the regional codings that correspond to it.

Originally Posted by nads

Do mean like the speedrun leaderboard?

Assuming you're referring to speedrun.com then yes, but this regional coding would also apply to points based tracks as well.

Originally Posted by d3scride

Assuming you're referring to speedrun.com then yes, but this regional coding would also apply to points based tracks as well.

Yep Speedrun.com is what I was referring to.

It is a great idea but here's two cases where a generic situation doesn't work (and there are plenty of these already on the scoreboard):

* A platform that is normally split where the regional variations require different rule sets or titles.
* A platform that is not normally split but there are regional variations that requires a split.

I'm also a proponent of this concept. A dropdown at the game-level to quickly filter down tracks to the relevant category, and reduce need for effectively duplicate track creation.

Some people are pointing out issue that it could cause, so I'd love to see some brainstorming on ways that those issues could be dealt with.

Also, if we ignore the NTSC/PAL thing, would just "automagically" adding EMU versions of games/tracks for relevant systems be an improvement, if it allows filtering in this manner? Where any system that has at least one solid emulator gets EMU versions of all tracks added without people needing to manually create them?

"Just brainstorming..."

Originally Posted by GibGirl

Also, if we ignore the NTSC/PAL thing, would just "automagically" adding EMU versions of games/tracks for relevant systems be an improvement, if it allows filtering in this manner? Where any system that has at least one solid emulator gets EMU versions of all tracks added without people needing to manually create them?

Behind the scenes, each track is a separate entity in the database. For these to automagically be created, it would mean some intensive DB activity to create them (in the initial phase) and additional programming into their auto-creation upon the inception of a new NTSC or PAL track. Such an NTSC or PAL track could be written with rules that fail under emulated terms and so make for a nonsensical addition.

As it stands now, the human is the element of duplication (derivative tracks) and can exercise that most human of tasks: assessing whether other humans might make sense of something as abstract as rules.

MyOwnWorstEnemy thanked this post

IMO Well EMU should be a separate platform, Just like Arcade and MAME are. It only makes logical sense. Look at the latest dispute!

That would help with filtering by 50%

Originally Posted by timmell

IMO Well EMU should be a separate platform, Just like Arcade and MAME are. It only makes logical sense. Look at the latest dispute!

That would help with filtering by 50%

One platform? That covers every system? If so, why should MAME be separate, since it's just an emulator itself?

Or one EMU system per platform emulated? That would be a lot of platforms.

I feel that the ideal would offer some sort of logical connection between the emulated version of a game, and the original. The ideal emulated game would play identical to the non-emulated, and even if never merged together should at least offer a way to easily find and compare the scores between the two.

Originally Posted by GibGirl

One platform? That covers every system? If so, why should MAME be separate, since it's just an emulator itself?

Or one EMU system per platform emulated? That would be a lot of platforms.

I feel that the ideal would offer some sort of logical connection between the emulated version of a game, and the original. The ideal emulated game would play identical to the non-emulated, and even if never merged together should at least offer a way to easily find and compare the scores between the two.

I think speed run.com does it well were you can see all runs, EMU and Original, but then you can filter one of them out.

Well that's my issue with the current formatting of the site/platforms. When searching the database, I will be looking for a score and based on random or not so random order of the tracks, I will realize after the fact, I'm looking at a EMU track instead of the Original platform track I was looking for in the 1st place. And get frustration as I was only look for original hardware. That is why I'm for the spitting and making separate platforms. Cause when I go into the Arcade platform there won't be a EMU track in there. I won't make that mistake while browsing.

A filter system would work, but this goes back to a old debate. If you care about ESI rankings for a specific platform and want to see the ranks to filter the original vs platform performances.
I prefer to keep that ESI calculation separate. I want to know who has the highest ranking for original hardware on NES. But with the current of mixing EMU in the mix, that data is not as accurate or filter to my query.

Originally Posted by timmell

I think speed run.com does it well were you can see all runs, EMU and Original, but then you can filter one of them out.

Well that's my issue with the current formatting of the site/platforms. When searching the database, I will be looking for a score and based on random or not so random order of the tracks, I will realize after the fact, I'm looking at a EMU track instead of the Original platform track I was looking for in the 1st place. And get frustration as I was only look for original hardware. That is why I'm for the spitting and making separate platforms. Cause when I go into the Arcade platform there won't be a EMU track in there. I won't make that mistake while browsing.

A filter system would work, but this goes back to a old debate. If you care about ESI rankings for a specific platform and want to see the ranks to filter the original vs platform performances.
I prefer to keep that ESI calculation separate. I want to know who has the highest ranking for original hardware on NES. But with the current of mixing EMU in the mix, that data is not as accurate or filter to my query.

I am totally on board with separating ESI in that manner. Or at least having the option to filter through it. And I would NOT support combining NTSC/PAL/EMU in this manner if it meant mixing all the ESIs together.

It would be ideal to be able to see a top NTSC ESI, top PAL ESI, and top EMU ESI. And I do think that connecting the tracks up like this would would better to enable this than the current method, as it could be just as simple as one additional parameter on the SQL query used to get the top ESI.

MyOwnWorstEnemy thanked this post

MyOwnWorstEnemy liked this post

Originally Posted by GibGirl

I am totally on board with separating ESI in that manner. Or at least having the option to filter through it. And I would NOT support combining NTSC/PAL/EMU in this manner if it meant mixing all the ESIs together.

It would be ideal to be able to see a top NTSC ESI, top PAL ESI, and top EMU ESI. And I do think that connecting the tracks up like this would would better to enable this than the current method, as it could be just as simple as one additional parameter on the SQL query used to get the top ESI.

The ESIs are clearly not calculated on the fly for each page request and are stored separately. So, if I read correctly, a platform-per-technology ESI (i.e., "PS2 NTSC ESI") would be an entirely different ESI calculation in addition to the current ESIs already being calculated and wouldn't be a simple query. You'd want to see both that and the whole-platform ESI? (Just trying to clarify - your first and second paragraphs seem at odds with each other.)

Originally Posted by Barthax

The ESIs are clearly not calculated on the fly for each page request and are stored separately. So, if I read correctly, a platform-per-technology ESI (i.e., "PS2 NTSC ESI") would be an entirely different ESI calculation in addition to the current ESIs already being calculated and wouldn't be a simple query. You'd want to see both that and the whole-platform ESI? (Just trying to clarify - your first and second paragraphs seem at odds with each other.)

My understanding is that ESI for a platform is just a sum of a player's ESI over each track. If each track now has a "NTSC"/"PAL"/"EMU" field attached to it, then with a decently defined DB, it doesn't seem like it would be much more complicated than just filtering on one more field. But it would also mean 3x the total calculations to make separate ESI charts for each version.

And yes, I'd think we'd want separate ESI charts for NTSC/PAL/EMU. Though I'm happy to hear arguments about why it might be done in other ways.

To back up a step, a few thoughts on why I like this and what benefits I hope could come out of it. First, by the system actually treating NTSC/PAL/EMU as a special attribute, it would allow easy filtering down of tracks. I wouldn't have to wade through PAL tracks for a game, since I'm only touching NTSC. Or @timmell wouldn't accidentally look at EMU tracks instead. Second, it could offer up the ability to more easily compare between these categories. Where an "ALL" on a drop-down would show NTSC, PAL, and EMU scores in the same chart to see where they all lie. I think it also offers a clean resolution to the debate over where EMU tracks should live for consoles.

It gives the system an understanding that the tracks are meant to be "the same thing", just in slightly different versions.

Here are some other things I think could also be gained from it, if desired. A way to separate the ESI gained from the NTSC and PAL versions of the same game - the current method can allow someone with the appropriate hardware to gain extra ESI from the same track, though I don't know how much that actually counts toward things. Also, and @Barthax pointed out it might be too complicated, would be a way to simplify adding multiple versions of the track. It would be nice to add a track and just have it show up for NTSC, PAL, and EMU, instead of having to do them piecemeal.

I do admit that I don't know if there should be just EMU, or EMU-NTSC and EMU-PAL - is there any value in that differentiation?

Also, I know that this would not be a simple thing to do. Besides the coding work of implementing such a thing into the system, there would be a significant amount of manual work to do to clean up the DB.

Barthax thanked this post

Barthax liked this post

I'm all for improving the site and making it more competitive, let's not forget that there are differences between PAL and NTSC besides it being a regional difference.

Below are just a few excerpts taken from Wikipedia.

Phase Alternating Line (PAL) is a colour encoding system for analogue television used in broadcast television systems in most countries broadcasting at 625-line / 50 field (25 frame) per second (576i).

Referenced from https://en.wikipedia.org/wiki/PAL

NTSC is named after the National Television System Committee. NTSC color encoding is used with the System M television signal, which consists of ​³⁰⁄_1.001 (approximately 29.97) interlaced frames of video per second. Each frame is composed of two fields, each consisting of 262.5 scan lines, for a total of 525 scan lines. 483 scan lines make up the visible raster. The remainder (the vertical blanking interval) allow for vertical synchronization and retrace.

Referenced from https://en.wikipedia.org/wiki/NTSC

Also, the website link below talks about it in some detail without having all of the history lessons attached.
https://www.lifewire.com/why-ntsc-an...matter-1847856

In the end, there is a reason why they were separated but if it could be simplified using filters it might be worth a look.

Originally Posted by GibGirl

One platform? That covers every system? If so, why should MAME be separate, since it's just an emulator itself?

Or one EMU system per platform emulated? That would be a lot of platforms.

I feel that the ideal would offer some sort of logical connection between the emulated version of a game, and the original. The ideal emulated game would play identical to the non-emulated, and even if never merged together should at least offer a way to easily find and compare the scores between the two.

I agree that MAME should not be a separate platform but coexist as an additional filter with Arcade/JROK

Originally Posted by Cyriss_Zeal

I'm all for improving the site and making it more competitive, let's not forget that there are differences between PAL and NTSC besides it being a regional difference.

Alas, what TG labels as an NTSC track and what TG labels as a PAL track does not match:

a) the base technology where those terms come from.
b) all possible variations of technology that match those base terms.

In more depth:

The split of NTSC and PAL on the scoreboard was done to ensure systems running at different speeds were segregated. At TG the NTSC and PAL monikers depict only the sync and refresh rate of the console - not the colour encoding used and not the region of the console/game.

Any native 60Hz system submits to the NTSC track at TG. For example, A Brazilian PAL-M system is 60Hz and submits to NTSC. Most modern European consoles have PAL-60 (60Hz) modes and submit to NTSC if run in that manner. Any native HDMI-60 system submits to NTSC.

Any native 50Hz system submits to the PAL track at TG. PAL-M and PAL-60 are not 50Hz and are not to be submitted to PAL tracks. If a console actually existed using NTSC-N, then that would submit to a PAL track here at TG. Should anyone choose to use HDMI-50, wait that hasn't been tested in a submission yet - that's open for debate.

Just to expand a little further: any EMU prefix is used to denote the 60Hz equivalent in emulation unless the original platform had no 60Hz equivalent (ZX Spectrum) or by legacy ruling 50Hz was deemed the norm for EMU on that platform (Commodore 64).

Confused? It's hardly a surprise anyone gets confused.... Especially when you consider there are also exceptions to the above where further splits happen due to regional variations in games (Donkey Konga springs to mind but is not the only one).

Cyriss_Zeal thanked this post

Cyriss_Zeal liked this post