Lemma Soft Forums

This isn't going to be in the first OpenGL release. Before we could have something like this, I'd want to have the ability to tell Ren'Py to run in OpenGL-only mode. The first OpenGL-enabled release will be automatically falling back to software rendering if OpenGL works. Once I have confidence that an OpenGL-mode is okay, then I'll think about adding OpenGL-only features.

PyTom wrote:The first OpenGL-enabled release will be automatically falling back to software rendering if OpenGL works.

I suppose you mean "The first OpenGL-enabled release will be automatically falling back to software rendering if OpenGL doesn't works." ?
that's a good idea

Been a while since I posted here, so I thought I would bring people up to date.

Development of 6.11 is proceeding, if somewhat slowly due to a lot of work piling up.

OpenGL support is implemented, and I've been testing it by playing games with it as it's released. It's stable enough that I use it as my main version of Ren'Py for playing games, even though there are still a couple of bugs I need to track down before release.

The other big new feature is the new Scene Language, which will be a new way of defining interface screens. I've implemented the basics of the Scene Language parser, and I'm about to start work on improving the ui functions so they fit in with SL a bit better.

A new thing I just added is a few "composite style properties". These provide shortcuts for setting multiple style properties at the same time. For example, I can now write:
That will create a textbutton at (100, 50) that is 300 pixels wide and 40 pixels tall.

Glad to hear everything is going smoothly, PyTom

Take your time, I'll wait as long as you need everything to be done. The scene language seems a perfect addition and may help to improve overall programming and make everything simpler for those, who lack more advanced knowledge.

The other big new feature is the new Scene Language, which will be a new way of defining interface screens.

Do you mean it will enable users to customize the menus , kind of like image maps do ? Or is it for in-game interfaces, or both ? Is there a place where you wrote about this before ?

composite style properties

Ha , that's cool, makes it all more compact.

PyTom wrote:

Code: Select all

$ ui.textbutton("Hello, World", area=(100, 50, 300, 40), clicked=ui.returns(True))

That will create a textbutton at (100, 50) that is 300 pixels wide and 40 pixels tall.

Does this mean a button that stretches from (100, 50) to (400, 90), or a button which is positioned at (100, 50) with whatever part of it is specified in its own x/yanchor?

(I ask 'cause the first interpretation is the most obvious one to me from the notation, and if you mean the second one I'd suggest you think very carefully about it...)

electric wrote:Do you mean it will enable users to customize the menus , kind of like image maps do ? Or is it for in-game interfaces, or both ?

Both. The goal of the screen system is to provide an enhanced replacement for imagemaps. A big problem with imagemaps is that, right now, there's a strict division as to what goes on what screen. The screen system will fix that.

Jake wrote:Does this mean a button that stretches from (100, 50) to (400, 90), or a button which is positioned at (100, 50) with whatever part of it is specified in its own x/yanchor?

The former. Area implies that xanchor and yanchor are set to 0.

If people could post their imagemaps, or mail them to me at pytom@bishoujo.us, I'd appreciate it. I'm getting close to the point where I'll be testing the screen language, and it will make my life easier if I can just use the imagemaps people have already made. I'll need both the complete set of image files, and the .rpy file with the calls to layout.imagemap_* in it.

Thanks!

I've split a side-discussion on default backgrounds to http://lemmasoft.renai.us/forums/viewto ... =32&t=7077 , since it isn't on the table for 6.11.

I'd also like to reiterate my call for imagemaps in the post above. I'd like to get imagemap-screens buttoned up in the next few days, and I desperately need a few imagemaps to test on.

PyTom wrote:I'd also like to reiterate my call for imagemaps in the post above. I'd like to get imagemap-screens buttoned up in the next few days, and I desperately need a few imagemaps to test on.

I suppose you're not interested in dynamically-generated ones? I could probably separate out the way the command menus are done in the battle demo, for example, if it would help? Would that kind of thing be doable using your new stuff anyway, or would it be fixed-positioning only? (I'm guessing no, in the same way ATL isn't directly usable from code?)

Yes, I'm mostly focusing on static imagemaps for now. The new stuff will be usable from python, but the focus is on the new language.

PyTom wrote:If people could post their imagemaps, or mail them to me at pytom@bishoujo.us, I'd appreciate it. I'm getting close to the point where I'll be testing the screen language, and it will make my life easier if I can just use the imagemaps people have already made. I'll need both the complete set of image files, and the .rpy file with the calls to layout.imagemap_* in it.

Thanks!

I'm behind the curve even with the current way of handling imagemaps. Do you have a syntax guide already for all things Screen Language? I want to start working on the tiles in my game but still await more guidance on the proper way to code things. I'm hoping the ATL way will make sprite movements so fast it will seem almost arcade-like or real-time in execution.

The screen language hasn't been released yet. It will have documentation by the time it's released.

Fundamentally, it will be like:

Do you still need imagemaps? If it'll help and I can figure out the programming I could make some.

Oke, I know it's totally off-topic, but I have to say this:
Ixis, awesome picture!!

Now, on topic:
PyTom, you're a genius.