Font size and style
Moderators: winston, another_commander
But changing the size? Will that break the formatting?
What happens then to the STATUS_SCREEN (and all other native oolite screens and mission screens)? I've always a bad feeling about changing global settings, because we only have one fixed point - Oolite. And what happens if more than one OXP tries to change it?
So (*suggestion ON*) if the changes would only affect missionscreens and the font could be selected before displaying the screen, then I'd say nice idea.
What happens then to the STATUS_SCREEN (and all other native oolite screens and mission screens)? I've always a bad feeling about changing global settings, because we only have one fixed point - Oolite. And what happens if more than one OXP tries to change it?
So (*suggestion ON*) if the changes would only affect missionscreens and the font could be selected before displaying the screen, then I'd say nice idea.
Sure, the formatting is going to be different, and possibly broken, for any font with average width different to the normal Oolite font.Svengali wrote:But changing the size? Will that break the formatting?
Oolite is clever enough to go to the next line with the wider font, however all mission screens are tested to fit properly on a screen only with the standard width font. Any difference in (average) width will mess up things one way or another. In Screet's case, Oolite ran out of space, in other cases a mission screen might well be misaligned & very difficult to read...
Unfortunately, as things are, Oolite only expects one font at a time, without the ability to switch between fonts.So (*suggestion ON*) if the changes would only affect missionscreens and the font could be selected before displaying the screen, then I'd say nice idea.
Probably the best thing to do for the moment is to make sure that the average width of a font is much closer to Oolite's standard font than the tty font I chose. I'll see if I can find an easy way to squeeze tty.oxp to a more decent size (otherwise it's hand resizing & positioning times 30 - a slower process), & then will update tty.oxp, so that it doesn't break anything!
Hey, free OXPs: farsun v1.05 & tty v0.5! :0)
- Lestradae
- ---- E L I T E ----
- Posts: 3095
- Joined: Tue Apr 17, 2007 10:30 pm
- Location: Vienna, Austria
..
@Kaks: I would find a new font that was much narrower, so that, say as a completely coincidential example, longer ship names would fit into the shipyard, really good.
Mission texts then would also not be broken as there would be more space left on screen, not less.
Just saying, coincidentally
L
Mission texts then would also not be broken as there would be more space left on screen, not less.
Just saying, coincidentally
L
Hmmm. I see the point of changing the font (and I'd like to get more options for screens), but this way it would go wrong .-)
If you've got a screen like this then the spacing would look very weird by using a narrow font (or a wider font).
The Vector is also using a combination of pics and text and OXPConfig needs a fixed spacing, so everything would be affected. And the new Localhero uses combinations of pics, models and texts.
So we could need a clue how to avoid these problems before everybody uses his own font :-)
If you've got a screen like this then the spacing would look very weird by using a narrow font (or a wider font).
The Vector is also using a combination of pics and text and OXPConfig needs a fixed spacing, so everything would be affected. And the new Localhero uses combinations of pics, models and texts.
So we could need a clue how to avoid these problems before everybody uses his own font :-)
Last edited by Svengali on Tue Feb 24, 2009 6:12 pm, edited 1 time in total.
- Lestradae
- ---- E L I T E ----
- Posts: 3095
- Joined: Tue Apr 17, 2007 10:30 pm
- Location: Vienna, Austria
..
Huh, it seems the new fonts craze has opened a can of worms for the devs here ...
Svengali, have you tried Kaks' new font with a mission screen like that shown? Is there an actual problem with another font size or is it a speculation?
No criticism, just asking
Cheers
L
Svengali, have you tried Kaks' new font with a mission screen like that shown? Is there an actual problem with another font size or is it a speculation?
No criticism, just asking
Cheers
L
Re: ..
No, I haven't tried it, but the main question is if we want to open the door for a lot more possible clashes or not, so we should think about it before we'll do it :-)Lestradae wrote:Svengali, have you tried Kaks' new font with a mission screen like that shown? Is there an actual problem with another font size or is it a speculation?
And please think about that not only paagrove or you will implement fonts then - and maybe so different fonts (one very narrow, one totally wide,...), so we should discuss it a bit.
EDIT: I'll give you another example. Just wait a few minutes and you'll see.
Last edited by Svengali on Tue Feb 24, 2009 8:21 pm, edited 1 time in total.
- pagroove
- ---- E L I T E ----
- Posts: 3035
- Joined: Wed Feb 21, 2007 11:52 pm
- Location: On a famous planet
Wow, indeed much action. What a simple suggestion can do.
For P.A. Groove's music check
https://soundcloud.com/p-a-groove
Famous Planets v 2.7. (for Povray)
https://bb.oolite.space/viewtopic.php?f=4&t=13709
https://soundcloud.com/p-a-groove
Famous Planets v 2.7. (for Povray)
https://bb.oolite.space/viewtopic.php?f=4&t=13709
- KZ9999
- Deadly
- Posts: 225
- Joined: Fri Jan 23, 2009 8:55 pm
- Location: Lost in Witchspace being hunted by a Thargoid Swam.
Perhaps only two fonts are needed.
I though it was the case of speed over style in this case. I don't blame you for the choice one bit, I need every FPS I can get for my little laptop. <sigh>
What we do need is a narrow version of the standard front for areas where the is going to be a lot of text. Case in point see the picture bellow...
While this ship is a part of Realistic Shipyards, I have seen it also occurs with other OXPs . I set the screen for 640 x 480 pixels for image size but it does occurs in all resolutions. If the game set to a narrow typeface for ship details, mission screens and the current mission/contract details on the manifests screens. It should fix the overrun problems and minimise the needs for multiple fonts.
A second minor, but really annoying, issue that really should be fixed is the alignment of the ship price, again see the above image. Left alignment of the price column will make easer to compare ships.
What we do need is a narrow version of the standard front for areas where the is going to be a lot of text. Case in point see the picture bellow...
While this ship is a part of Realistic Shipyards, I have seen it also occurs with other OXPs . I set the screen for 640 x 480 pixels for image size but it does occurs in all resolutions. If the game set to a narrow typeface for ship details, mission screens and the current mission/contract details on the manifests screens. It should fix the overrun problems and minimise the needs for multiple fonts.
A second minor, but really annoying, issue that really should be fixed is the alignment of the ship price, again see the above image. Left alignment of the price column will make easer to compare ships.
KZ999's Oolite documents, including the new draft Oolite Game Manual, can be found at www.box.net
Re: ...
The funny thing is that the game did not check for the player to have enough money and then tried to set it to a negative amount, creating an immense account as the variable to store it is unsigned - and then the player cannot switch ships to a cheaper model, because otherwise he would have more money than the variable could hold and the game saves the player from losing all this money by forbidding to buy that shipLestradae wrote:Just noted the "Total available"
I've also created a new commander and refuelled his ship in the previous version which had that bug in. Used it for test-flying ships without the requirement to edit the save game. It's easier to edit, though, thus I only used it to give a few ships a test.
Screet
- Lestradae
- ---- E L I T E ----
- Posts: 3095
- Joined: Tue Apr 17, 2007 10:30 pm
- Location: Vienna, Austria
**
Just to be clear about that:
If someone has fun cheating the game, I have no problem with that. It's a game, and it should be fun. I don't derive fun from cheating, but that's my thing entirely.
So no offense meant and I hope none taken
If someone has fun cheating the game, I have no problem with that. It's a game, and it should be fun. I don't derive fun from cheating, but that's my thing entirely.
So no offense meant and I hope none taken
Yes, no offense meant too - what a screenie can ever tell us :-)
If I get this right OpenGL has no support for strings, so displaying texts in OpenGL is a pain for every developer and it is slow when it has to be calculated. That's why so many OpenGL-Applications are using bitmaps for this case. No complex calculations, just a x,y table and a bit scaling/blurring if necessary.
Using two font-sets (nice idea) would solve some of these things, but I'm not sure that this will be enough to be prepared for the future (and future requests). And even two sets would need altering of a lot of internal code, because the spacing of signs is only variable in width - not in height. Every bit in Oolite is depending on the 'normal' line-height (with some variants like the commsMessageBox) and would have to be changed to match the new situation.
Maybe I'm wrong, but the dev-team is not far away and can tell us about it.
BTW: I really would like to get more options for the screens and a flexible handling of fonts and positions for texts would be a dream - but probably the wishlist is already longer than a bards tale and christmas is far away :-)
If I get this right OpenGL has no support for strings, so displaying texts in OpenGL is a pain for every developer and it is slow when it has to be calculated. That's why so many OpenGL-Applications are using bitmaps for this case. No complex calculations, just a x,y table and a bit scaling/blurring if necessary.
Using two font-sets (nice idea) would solve some of these things, but I'm not sure that this will be enough to be prepared for the future (and future requests). And even two sets would need altering of a lot of internal code, because the spacing of signs is only variable in width - not in height. Every bit in Oolite is depending on the 'normal' line-height (with some variants like the commsMessageBox) and would have to be changed to match the new situation.
Maybe I'm wrong, but the dev-team is not far away and can tell us about it.
BTW: I really would like to get more options for the screens and a flexible handling of fonts and positions for texts would be a dream - but probably the wishlist is already longer than a bards tale and christmas is far away :-)
-
- Quite Grand Sub-Admiral
- Posts: 6683
- Joined: Wed Feb 28, 2007 7:54 am
Multiple font support has never been declared officially as a feature of Oolite. The user controllable kerning was developed at the time of making Oolite multilingual because it was needed for the extended character sets. The fact that one can take an arbitrary font file, play with the kerning and use it as an alternative font (and have it working more or less acceptably) is a quite welcome side effect. Trying to support multiple fonts any further at this point though falls in the "feature creep" category for me. We don't really need it at this point. It takes more work than it's worth to support it fully.