StandardGame - Icon - Settings/Attributes

What is the suggested way to load the window icon and title before the display is actually shown?



When using StandardGame, the display is not created until start() is called. There is no way to access the display after it's 'gotten' (from the DisplaySystem.getDisplaySystem) but before it's created.



This means that if you are attaching an icon to the window frame you'll see the default one for a bit as things get going before you can replace it with your own. This happens with the title as well, even though it's passed in on the constructor.



I'd like to suggest another constructor signature that would allow for passing in the Image array for the window icons.



I'd also like to suggest changing the StandardGame such that both the setTitle and setIcon calls happen before createWindow.



Next, what was the reasoning with replacing the PropertiesIO that's in AbstractGame with GameSettings?

I don't have a problem changing StandardGame to add support for setting the icon and title, but I think in setter methods would be better than adding an additional parameter on the constructor (and/or additional constructor).  Feel free to add it.



The reasoning for using GameSettings is it is a much more abstract way to handle game settings and provides built-in persistence functionality as well as the ability to extend it to encapsulate things like controls and even serializable object storage.  For example, in the TestGameControlSettings (something like that…no code in front of me) I save the GameControls back to the GameSettings and don't have to worry about where it's stored.  Further, the default implementation uses Preferences instead of Properties so it doesn't write a props file to your desktop when you webstart a game. ;)  Finally, it doesn't lose the settings when you run it from another directory.

i want the extra constructor :smiley:



the default icon and title stays there for a sec b4 it changes to my own ones. this is some kind annoying actually~ XD

I had the code ready to commit… And, committed.



I had implemented a setter, obviously froggy knows his code.



I then moved the setIcon and setTitle to right above createWindow.



Enjoy.

thx, but im using basegame, can u change that as well~ :smiley:

It doesn't matter if it's in the constructor or not since the display window doesn't actually come up until you call start() on StandardGame.  As long as guurk's changes handle that in startup (which I'm sure it does) you shouldn't see any issues with the icon not showing up right.


neakor said:

thx, but im using basegame, can u change that as well~ :D


If you choose to stay in the stone-age, there's not much we can do to help you. ;)
If you choose to stay in the stone-age, there's not much we can do to help you. ;)


so...baseGame is stone-age? i should be using standard game? :?

Take it from me, StandardGame simplifies things no end and GameStates make a lot more sense, and are easier to implement.

Plus you dont have to worry about updating your BaseGame extension to take threads into consideration if you ever want to use them, darkfrog has done that and you'll reap any of his future optimisations.

To be fair here, GameStates existed long before I ever joined jME…I just made a system to support them and tried to implement what I thought seemed a more logical way to create games.

I'm sure they did, but I wasnt aware of them and didnt notice their potential until somebody made a fuss about them (darkfrog) - and im glad you did.