6.12.2: Text Handling

In this forum we discuss the future of Ren'Py, both bug fixes and longer-term development. Pre-releases are announced and discussed here.
Message
Author
User avatar
0ion9
Regular
Posts: 79
Joined: Thu Jun 16, 2011 9:17 am
Contact:

Re: 6.12.2: Text Handling

#31 Post by 0ion9 » Sat Jul 16, 2011 11:57 pm

"It's dark. You might be eaten by an [enemy[name]]."
Cool that we don't have to quote the string indice. Isn't that ambiguous though?
For example: (this uses actual Python formatting, so it looks a little different)

Code: Select all

>>> d2 = {'str' : {'me': 22, 1: 44}, 'me':1}
>>> "{str[me]}".format(**d2)
'22'
As a point of fact, in '{indexable[XXX]}' ('[indexable[XXX]' in renpy), XXX is always a literal string key.
(whereas in my example, you might be expecting '44' as your output -- the result of looking up 'me' in the toplevel dictionary, and indexing str by that value; in the context of RenPy, 'me' would correspond to a global variable)

My point? The documentation needs to be clear on this fact, and how to deal with it.

BTW, while I was looking for a good explanation of the intention behind that behaviour, I found this: http://stackoverflow.com/questions/1012 ... -of-python
Which is quite fascinating.

EDIT: Ah, here's an explanation:
Unlike some other programming languages, you cannot embed arbitrary
expressions in format strings. This is by design - the types of
expressions that you can use is deliberately limited. Only two operators
are supported: the '.' (getattr) operator, and the '[]' (getitem)
operator. The reason for allowing these operators is that they don't
normally have side effects in non-pathological code.
...
It should be noted that the use of 'getitem' within a format string
is much more limited than its conventional usage. In the above example,
the string 'name' really is the literal string 'name', not a variable
named 'name'. The rules for parsing an item key are very simple.
If it starts with a digit, then it is treated as a number, otherwise
it is used as a string.
-- http://www.python.org/dev/peps/pep-3101/

User avatar
jack_norton
Lemma-Class Veteran
Posts: 4067
Joined: Mon Jul 21, 2008 5:41 pm
Completed: Too many! See my homepage
Projects: A lot! See www.winterwolves.com
Tumblr: winterwolvesgames
Contact:

Re: 6.12.2: Text Handling

#32 Post by jack_norton » Sun Jul 17, 2011 4:23 am

Since you're working on texts, I have a suggestion (forgive me if you already have done/planned but I'm lost with lots of work recently): it would be nice if when going fullscreen the texts (when using TTF fonts) would scale using higher points. A bit like what happens with sprites, that if you have them setup at higher resolution, when you go fullscreen they're displayed using the best fit.
Right now in fullscreen the texts are just scaled up with zoom and are a bit blurry, instead if you could use a higher pt it would look much much better on people playing at high resolution screens (1280+ and up). Hope I managed to express myself :D
follow me on Image Image Image
computer games

User avatar
0ion9
Regular
Posts: 79
Joined: Thu Jun 16, 2011 9:17 am
Contact:

Re: 6.12.2: Text Handling

#33 Post by 0ion9 » Sun Jul 17, 2011 5:05 am

Well, IMO a non-blurry scale would also be good, when the scale factor is an integer. And it would save on texture memory if needed.

User avatar
PyTom
Ren'Py Creator
Posts: 15893
Joined: Mon Feb 02, 2004 10:58 am
Completed: Moonlight Walks
Projects: Ren'Py
IRC Nick: renpytom
Github: renpytom
itch: renpytom
Location: Kings Park, NY
Contact:

Re: 6.12.2: Text Handling

#34 Post by PyTom » Sun Jul 17, 2011 8:09 am

The scaling of text is something I've considered, but it's more appropriate for Glitz (the GL improvements) than Meat (the newtext work).
Supporting creators since 2004
(When was the last time you backed up your game?)
"Do good work." - Virgil Ivan "Gus" Grissom
"Silly and fun things are important." - Elon Musk
Software > Drama • https://www.patreon.com/renpytom

Post Reply

Who is online

Users browsing this forum: No registered users