Share your Theme and ART - OPLv0.9 beta

**JNABK** · 02-24-2011,01:19 AM

I made a new Theme for our 0.9 Beta Testers.....

This is a little bit easier to use than the previous one i just made, as these are only Beta Test Themes and not to be considered as 'Final' for the 0.9 Release. I'll make brand new ones for 0.9 when the time comes.

This time i took in consideration that volca is implimenting word-wrap, so i'll have to wait to see how we can use it for custom description area layouts. This one allows using BG Art for both the Main screen and the Info screen. The idea is to be able to make Themes that people can change without having to keep editing their SLUS_xxx.xx.cfg files for the info to display properly in all themes. I made the text area for Categories/Description to make use of the full width of the Info screen.

So here ya go, check it out, edit it , experiment with it, learn from it. Thats what its made for.

**JNABK** · 02-24-2011,02:03 AM

I just noticed i am no longer able to change the colors in the GUI, only by editing the conf_opl.cfg can i change them.

When in Display settings the cursor just skips over Text color, Dialog color, Selected color and Background color.

This a bug or something that is yet to be implimented with new options?

**izdubar** · 02-24-2011,05:02 AM

Originally Posted by JNABK

I just noticed i am no longer able to change the colors in the GUI, only by editing the conf_opl.cfg can i change them.

When in Display settings the cursor just skips over Text color, Dialog color, Selected color and Background color.

This a bug or something that is yet to be implimented with new options?

This is a "correction" (or disambiguation) of the previous state in OPL. Before you had the two main color available in the settings: "text" and "selected text". Both were modifiable when no theme were applied, and when a theme was selected.

The problem was that a theme can override the default general color settings of OPL. Thus the user was seeing the main colors in the settings and not those of the theme. Modifying them would maybe change the colors for the current "session" (I don't remember exactly), but at the next restart that would be lost and the colors of the theme were applied back.

To avoid this odd behavior and not confuse the user that would think the changes are not saved (which is the case, we don't want the user to be able to change the theme color), we only let the colors to be modifiable when no theme are selected, as here you are changing the default OPL colors.

One "exception" is when you have already loaded a theme (selecting a theme, loading it, returning to the settings), then we know the theme colors, and so here we display them without enabling to change them. Whereas when you navigate through the themes (via the combo), the theme are not loaded, so we don't know the colors, and in that case no colors are displayed at all.

Ah finally, if you really want to change a theme color (involving you have better taste as the original themer

), then you have to modify directly the conf_theme.cfg.

**JNABK** · 02-24-2011,07:23 AM

Thanks for the explaination, i don't generally use OPL without themes, so i wasn't aware of this. I understand i have to change them from the theme config file manually and the GUI can't save to theme files.

I thought if the colors were not defined in the conf_theme, then the colors used by the conf_opl would and therefore be saved to it from the GUI. Its all good either way, i just have to keep that in mind when writing the OPLv0.9 User Guides to inform users they need to define any changes from default colors in the theme and cant be changed otherwise. Same for the Theme users, i'll have to note they are stuck with whatever the Theme designer used, unless they manually edit it themselves.

**izdubar** · 02-24-2011,07:48 AM

Hum ... the case you mention here is an exception. If the theme doesn't define one of the 4 "general" colors then the theme will use of course the default from the general settings.

In that case we could allow the user to modify it even if a/the theme is selected. But that require that OPL keep track of what exact color is overridden or not by the theme, which is not done for the moment.

**JNABK** · 02-24-2011,08:55 AM

Well in either circumstance, a user will question it as to why they cant save or why they cant change anything.

So my opinion is to leave it so users can change the colors in the GUI, but a Theme color will over ride it as it does now. The difference is we can simply explain to users a theme's color will over ride the GUI settings and can only be changed in the Theme's conf_theme.cfg manually if a color has been defined. The same thing we would have to do now if left unchanged, the only difference is it would be only if the Theme defined the colors.

But its a matter for you guys to decide which is better.

Leave it as and explain why they cant change colors at all or put it back and explain why it doesn't save when a theme is used. Seems either method will have some users still ask why.

Originally Posted by izdubar

But that require that OPL keep track of what exact color is overridden or not by the theme, which is not done for the moment.

If its possible to do that, then that would solve that issue on either question having to be asked.

Another solution would be to only allow the 4 "general" colors be defined by the GUI, not really necessary for it to be defined in the Themes for those 4. Allowing specific Elements could be the only color defining in the Themes. Theme designers can simply add a ReadMe to the Theme zips and give instructions to change them if required for a theme. Which ever is best overall for the OPL program to run bug-free is the method i'd recommend to use.

**MonkeyGlue** · 02-25-2011,09:55 AM

@izdubar great update! I look forward to experimenting with the new flexibility for theme creation. Do you think this is going to be the finalized way to create themes (disregarding tweeks and small changes of course)?

@JNABK both your themes look good, excellent examples/guides to start with

Do you think we should add a page to the website to host individual game configs for information screens? Has this already been thought of? Perhaps a selection of different backgrounds per game and also game screen shots could be hosted too....

**No.47** · 02-25-2011,10:54 AM

Originally Posted by MonkeyGlue

Do you think we should add a page to the website to host individual game configs for information screens? Has this already been thought of? Perhaps a selection of different backgrounds per game and also game screen shots could be hosted too....

I thought about that, too. Of course it's useful to collect images like screen shots and especially cover art (already done on a large scale), but I think it would also be a good idea to collect game informations.
We could run a brainstorming and put together a list of useful game attributes like

- Genre
- Releasedate
- Developer
- PS2-exclusive / other platforms
- Number of players
- offers Co-op gameplay?
- offers 16:9 mode?
- offers Native 480p mode?
- ...

and then create a thread, where everybody can contribute and post the specific attributes of their games. The good thing is, we can choose only attributes which aren't a matter of preference/opinion so they don't have to be discussed...

**MonkeyGlue** · 02-25-2011,11:27 AM

Originally Posted by No.47

We could run a brainstorming and put together a list of useful game attributes like

- Genre
- Releasedate
- Developer
- PS2-exclusive / other platforms
- Number of players
- offers Co-op gameplay?
- offers 16:9 mode?
- offers Native 480p mode?
- ...

and then create a thread, where everybody can contribute and post the specific attributes of their games. The good thing is, we can choose only attributes which aren't a matter of preference/opinion so they don't have to be discussed...

Maybe also:

- Size of game saves taken on memory card
- Game sequels/prequels/run offs
- Language (s)
- VMC Supported?
- Revision dependent (e.g. Capcom Classics is only fully functional in revision 522 at the moment as a full fix is yet to be implemented (if possible))

**No.47** · 02-25-2011,01:36 PM

Originally Posted by MonkeyGlue

Maybe also:

- Size of game saves taken on memory card
- Game sequels/prequels/run offs
- Language (s)

Agreed! The idea 'size of savegame' is nice, I know there are some games wasting 2mb of memory space

- VMC Supported?
- Revision dependent (e.g. Capcom Classics is only fully functional in revision 522 at the moment as a full fix is yet to be implemented (if possible))

Of course these informations are important, but they should be left aside since they will change from time to time. Besides, there are already compatibility lists covering these topics.

I really think it would be the best to keep compatibility and such things aside (in their own threads) and only collect informations, that will not change over time and are not a matter of personal preference/opinion (such as game description/rating etc.).
However, when speaking about rating, another interesting (?) attribute comes to my mind:

- Metascore of the game (e.g. 91/100 for MGS3: Snake Eater)

AFAIK the Metascore is the best measurement for the average rating of a game (at the time of its release).

User Tag List

Thread: Share your Theme and ART - OPLv0.9 beta

Tweet

LinkBack

Thread Tools

Display


	Would you like to get all the new info from PSX-Scene in your email each day? Subscribe to our Daily Digest! Want to learn more about the team keeping you up to date with the latest scene news? Read about them now! Check out our Developer bios, too!