Share your Theme and ART - OPLv0.9 beta

[wazup640]

The V2.4 is here.

Some new graphx and an external font included.

Cool!

About the rating stuff I see a problem. Multi Language Discs for example. Same game id, but different rating. For example German version with german cover and FSK18 while the brittish version has their eseb18 logo. So using the number and tieing it to the OPL language setup would to the job.

If the user sets german, than he gets FSK for all games, while if he sets other languages he gets their rating systems icon. By default (image missing), it could be the english one.

This would IMHO solve all problems

What do you think?

wazup

[hominem.te.esse]

Ok back on this topic

I fear I didn't explained clearly what OPL do (or will do) concerning language support.

;genre will be translated by OPLs internal string table
Genre=[SPORTS, RACING, ROLEPLAY, ADVENTURE, JUMPNRUN, PUZZLE, ACTION, ARCADE, PARTY, BOARD, FIGHT]

In the per-game config file we have our set of key=value pair.

OPL translation will only occur on the key part.

Using some translation file, you will map for example, the key "Description" to "Beschreibung", and that's all. The values won't be translated by OPL. OPL will use directly the values stored in the per-game settings files, that's why I told it is the role of the tool to extract the correct language from the database to create the per-game settings files according to the language of the user.

Thus we need a multi entry database/csv, ex:

LANGUAGE,ID,RATING,ESRB,TYPE,TITLE,DESCRIPTION ...
english,SCES_213.12,5,10,Roleplay,Final Fantasy XII,This is a great game ....
german,SCES_213.12,5,10,Rollenspiel,Final Fantasy XII,Das ist ein tolles Speil ...
french,SCES_213.12,5,10,Jeu de rôle,Final Fantasy XII,C'est un jeu super ...

[wazup640]

Ok back on this topic
LANGUAGE,ID,RATING,ESRB,TYPE,TITLE,DESCRIPTION
english,SCES_213.12,5,10,Roleplay,Final Fantasy XII,This is a great game
german,SCES_213.12,5,10,Rollenspiel,Final Fantasy XII,Das ist ein tolles Speil
french,SCES_213.12,5,10,Jeu de rôle,Final Fantasy XII,C'est un jeu super

No, that is a very bad idea. It is the first rule of a system developer. Never store translated data in preferences.

Just imagine you want to add a "sort by type" feature and the user has mixed "Roleplay" "Rollenspiel" what ever.

My suggestions is to simply compare the game type value with a static array in code to specify the string a use that to access the translation.

So all game files (even for non english countries) contain "RACING", sorting can be added without any problem. For display you "convert" the english name into a multi language name, so it shows "Rollenspiel" in germany and even your "sort by type" feature can use the name as mode.

For title etc. Simply check for "title*language" if the string is missing use "title". Thats all. Title= is required Title*german is optional. So we keep the database clean and simple without having multiple files for the same game.

Title=Ape Escape 2
Rating=4
Esrb=0
Develeoper=Sony Computer Entertainment
Description=Catch apes with a net
Description*German=Fange Affen mit dem Netz

Do not think about the CSV stuff. I figure that out. We first need a proper standard for game config files.

Translating the KEY string is a bad idea, as you never know if a language has the same name as some other language. Also the config file is not readable to anyone anymore using a translation. I dont know what "title" and "description" means in turky or spain, but I simply can read "title*turk" and know what is defined there. Better do it clean and simple.

Wazup

[hominem.te.esse]

No, that is a very bad idea. It is the first rule of a system developer. Never store translated data in preferences.

Just imagine you want to add a "sort by type" feature and the user has mixed "Roleplay" "Rollenspiel" what ever.

My suggestions is to simply compare the game type value with a static array in code to specify the string a use that to access the translation.

So all game files (even for non english countries) contain "RACING", sorting can be added without any problem. For display you "convert" the english name into a multi language name, so it shows "Rollenspiel" in germany and even your "sort by type" feature can use the name as mode.

I know a lot about i18n dev good practices, but OPL have not the same requirements than a J2EE app for example. We don't have extra resources or unlimited memory available. We must do things the most efficient possible, with the less lines of codes, etc ...

About the string comparison, that is simply not possible, as these per-game attributes are "generic". We don't have any specific code for the title/genre/description. They are all the same, i.e attributes, that are referenced by their key. No special processing we'll be added for genre or any other.

Title=Ape Escape 2
Rating=4
Esrb=0
Develeoper=Sony Computer Entertainment
Description=Catch apes with a net
Description*German=Fange Affen mit dem Netz

I don't want to have duplicate entries in the per-games config files. That will slow down their loading. And for me it is useless. The user have to manage its config file, that's all. If he want english, he puts english values in the config file. If he wants german/french he put the corresponding content. We don't need to provide dynamic language selection.

I don't want to add a 'try - fallback" process for each attribute we are displaying. Seeking for keys in the config file is done sequentially (yeah no hashmap in OPL), so the more lines you add, the more time you add to draw the info page.

Doing what you propose is adding more time to load files, more time to display the info page. I want to keep it simple and the faster as possible.

Translating the KEY string is a bad idea, as you never know if a language has the same name as some other language. Also the config file is not readable to anyone anymore using a translation. I dont know what "title" and "description" means in turky or spain, but I simply can read "title*turk" and know what is defined there

You don't have to know how "title" or "description" is translated in other languages. People provide you the translated values, not the keys:

LANGUAGE,ID,RATING,ESRB,TYPE,TITLE,DESCRIPTION
english,SCES_213.12,5,10,Roleplay,Final Fantasy XII,This is a great game
german,SCES_213.12,5,10,Rollenspiel,Final Fantasy XII,Das ist ein tolles Speil


As you can see, the header remain the same.

[wazup640]

I don't want to have duplicate entries in the per-games config files. That will slow down their loading. And for me it is useless.

Slowing down? We are talking about bytes here. Its not a png or jpg which needs big decoding. Just a plain text file. Its not a C64. It is a PS2 which can parse 1000s of lines a second. And we are talking about around 10 additional lines in multi language game files. Which I would assume will be less than 500 bytes total.

Reading 100 or 500 bytes from usb doesn´t matter, as the block size is 512 bytes small and the speed is 1MB/s.

english,SCES_213.12,5,10,Roleplay,Final Fantasy XII,This is a great game
german,SCES_213.12,5,10,Rollenspiel,Final Fantasy XII,Das ist ein tolles Speil

As you can see, the header remain the same.

I am talking about config files. How the input from users can be done doesn matter, as those lines could be easly merged in.

It just sucks. How you want to maintain a database, when a european game with 5 languages and 5 diverent covers and 5 different game titles using the same GAME ID
drops in?

Creating a data base for each language? So instead of one SLES_121*12 file we now are talking about 5 or more for the very same game. And the user needs to pick the right one. This only works for 10 or 20 games, but it starts to get annoying. With a single game ID you get around 4000 files, once a database if complete. In your solution you get 10 times more.

Sorry, but if you want to create such a mess, you are on your own.

Wazup

[hominem.te.esse]

Slowing down? We war talking about bytes here. Its not a png or jpg which needs big decoding. Just a plain text file.

When navigating through the info page, you are jumping over files very quickly. I don't want this to be slown down. And anyway, I'm perfectionist, I don't want to add something that is useless (read below).

It just sucks. How you want to maintain a database, when a european game with 5 languages and 5 diverent covers and 5 different game titles using the same GAME ID
drops in?

It is already the case currently for ART (covers/icon/screenshot/background). We have one single set of ART for all declination of language, and people live with it.

What I propose is already better, as the above limitation won't happen for info page using my solution.

Creating a data base for each language? So instead of one SLES_121*12 file we now are talking about 5 or more for the very same game. And the user needs to pick the right one. This only works for 10 or 20 games, but it starts to get annoying. With a single game ID you get around 4000 files, once a database if complete. In your solution you get 10 times more.

You don't get it. Your asking me to not bother about the CSV content, but if you were listening to what I'm explaining, you'll see it doesn't sound that silly.

The database (or CSV, or whatever) is the only place where the entries are "duplicated". In fact not duplicated, we're just adding the "LANGUAGE" criteria/column in the table. And when generating the per-game config files, it is the TOOL that will select the correct content (according to the language the user selected) to put into.

There is nothing complicated, annoying, messy, silly in that ! That's plain database usage ... inserts and "select * where language=?".

I give a solution to do it (which is pretty fine), I won't change OPL code when it is not necessary.

[wazup640]

I give a solution to do it (which is pretty fine), I won't change OPL code when it is not necessary.

I know that one can create those multiple files for multiple languages from one csv database. Thats not my point.

The point is that a peoper package of database files would contain all files at once. The point is that overwriting the wrong file causes the stuff hard to handle. Users want to download and use and not download and pick their game colection piece by piece from a gigant pool of files and when installing more files they may even install wrong languages again.

USB users already need that, ETH or HDD users do not need.

The PS2 has so much CPU power and can parse these textfiles quite fast. I don´t think it would be even visible unless the search code is brain dead. We are talking about .01 or less seconds here. Compared to the time the user wastes to install the right files this is nothing.

I understand you want to keep the code clean, but adding a second search for the language key is simply nothing and if the key is available, its even exact as fast as before.
The ps2 is able to render complex 3d scenes, but is not able to search a 1000 bytes text file within 10ms? Come on. Thats insane.

And about the ART you mentioned. Yes. I know there is only one cover for all files, but I was taking about the text used for decription. If there are five languages you have five lines of description per file.

Wazup

[hominem.te.esse]

I understand you want to keep the code clean, but adding a second search for the language key is simply nothing and if the key is available, its even exact as fast as before.

That is not correct.

The whole content of the per-game settings file is loaded into a linked-list, a single chain for everything. So you may end with that (I only put the key):

#Name -> #Size -> #Format -> #Media -> #Startup -> Title.english -> Title.german -> Title.french -> ... whole 14 languages ... -> Description.english -> Description.french -> Description.german -> ... whole 14 languages ... -> Genre.english ......................

You see that the more you go, the more iteration you add. According to the 14 languages we currently have in our translation base, for each attribute you add 13 more steps to seek over. We are far away from the initial assumption "exact as fast as before".

However, you may be right, the PS2 may still have enough processing power so that the difference will not be noticeable. But again, I'm perfectionist, and I do care of principle. If there is a way to be faster and achieve the same result (or an acceptable result), then do it faster and cleaner.

Users want to download and use and not download and pick their game colection piece by piece from a gigant pool of files

It won't be the user who do the selection. It is the tool. There will be an application that use the database to generate those config file. Remember what I said at the very beginning, we need a tool, as we don't want to generate the whole config file but only those required according to the user owned games. So the user launch the tool, he provide it's ul.cfg, or point to the share/usb device (I don't know how to do it for internal HDD, but that device was always a pure mess to manage its content), he give its language preference, and the tool extract the correct values and generate the needed per-game files.

I know that one can create those multiple files for multiple languages from one csv database. Thats not my point.
If there are five languages you have five lines of description per file.

See above. One single fixed line per attribute in the per game config file. Multiple line in the database.

[wazup640]

That is not correct.

The whole content of the per-game settings file is loaded into a linked-list, a single chain for everything. So you may end with that (I only put the key):

#Name -> #Size -> #Format -> #Media -> #Startup -> Title.english -> Title.german -> Title.french -> ... whole 14 languages ... -> Description.english -> Description.french -> Description.german -> ... whole 14 languages ... -> Genre.english ......................

You see that the more you go, the more iteration you add. According to the 14 languages we currently have in our translation base, for each attribute you add 13 more steps to seek over. We are far away from the initial assumption "exact as fast as before".

Parsing a linked list is cheasy, so we have in worst case 50 items to parse. uhh. You´re right. We need a ps3 or better wait for a ps4 for it. /sarcasm

So 500 games already result in 7000 files. Not to mention that compatibly flags for one game are also split to multiple files and of course such games are not propery of the person who sets up the data base.

Assuming you have a FindItem() function, the additional code looks like this:

char *FindLocalizedItem( void *list, char *name, char *language )
{
result text;
char itemname[ 0x40 ];

   strcpy( itemname, name );
   strcat( itemname, ".")
   strcat( itemname, language );

   if( !(result = FindItem( list, itemname ) ) ) {
       result = FindItem( list, name );
    }
   return( result );
}

As you can see, it is just one additional function required to find those keys. All you need it to change the points in code for title and description from FindItem() to FindLocalizedItem() + the code above and you can test how slow it really gets. I don´t even think you will even notice.

This little code compared to dealing with thousands of useless files with dupe information which even may be wrong for several languages, beause of e.g. inconsistant compatibly modes.

Wazup

[fresh]

If the user sets german, than he gets FSK for all games, while if he sets other languages he gets their rating systems icon. By default (image missing), it could be the english one.

This would IMHO solve all problems

What do you think?

wazup

Hi!

Have you tried the 2.4 with the font for special chars?

The language switch for the esrb/fsk/etc. seems to be the right way.


And for the game-cfg-discussion:
Would it be a good solution to have the region in the file name?

PBPX_952.01.cfg - is in english
PBPX_952.01.fre.cfg - is french
PBPX_952.01.de.cfg - is german

and so on...


@hominem.te.esse
No comment to the request of changing file names (esrb and rating)?



Rgds.