Lemma Soft Forums

I think OpenGL is supposed to fix the aspect-ratio problem.

openGL will only accelerate reandering but won't fix any aspect ratio
Most games nowadays are full 3d so there isn't that problem anymore... but for us doing 2d games, is still there.

I didn't realize the engine was going to use OpenGL in a future release

I read someone thought that would allow Ren'Py to use multiple resolutions, I don't know if that's true.

It would make it possible, but that isn't necessarily generally true. If you used the OpenGL and had vector graphics, you could easily resize them to whatever screen size you wanted. But in the case of bitmap images, that advantage doesn't exist. You would have to resize the images anyway, or have separate image files for each resolution. That makes for big files, or poor image quality in the case of scaling images up. Since most VNs use bitmap images, i don't know...

number473 wrote:It would make it possible, but that isn't necessarily generally true. If you used the OpenGL and had vector graphics, you could easily resize them to whatever screen size you wanted. But in the case of bitmap images, that advantage doesn't exist. You would have to resize the images anyway, or have separate image files for each resolution. That makes for big files, or poor image quality in the case of scaling images up. Since most VNs use bitmap images, i don't know...

Actually, this is not true. The limitations of software rendering(2D) does not apply to hardware rendering(3D). They work entirely different. You are not painting/bliting bitmaps.

OpenGL and DirectX enables you to use a single image and have it automatically scale to whatever dimensions you need. Of course if the source image is small, it will look blurry when scaled up, but if the source image is larger it will look sharp in higher resolutions as well as lower resolutions (since it has more source pixels to work with).

The aspect ratio issue does not exist in 3D rendering either. 3D rendering is resolution agnostic by default. PyTom would have to specifically implement the limitation for that to be the case.

I'm curious to see how PyTom will implement OpenGL, as someone who's experienced the amount of work it requires first hand. (And I used DirectX, which arguably is the simpler API of the two)

Since people might be a little confused (or in the case of Eric, interested) in Ren'Py's upcoming OpenGL support, I thought I would open up this thread to answer questions and manage expectations.

Ren'Py is a 2D engine, like most visual novel engines. What GL Ren'Py will do is to shift a lot of the image processing to the system's GPU, which is capable of performing massively parallel processing of image-like data. Although I haven't totally characterized the result yet, preliminary tests show this giving a large speedup in the image primitives Ren'Py uses: blitting, blending, and image-controlled blending.

There are a couple of things I'm planning on doing with that speed. The first has to do with fullscreen modes. Right now, we command the system's screen to switch from it's native resolution to one close to what the game's resolution is. This is what causes the aspect ratio problems. Improved drawing speed will allow the screen to stay in its native resolution, while Ren'Py takes care of drawing letterbox bars as necessary.

Similarly, this will allow us to adjust the size of the game in windowed mode. While the game will have a default size, the user will be able to resize the window, and Ren'Py will begin using the new size, with letterboxes added as appropriate.

GL Ren'Py will also command a sync-to-vblank. This should prevent the tearing that is possible when moving something horizontally on the screen.

For the first release of GL Ren'Py, this is pretty much it for "new" features. Things should look nicer, but in a relatively subtle way. While, in the future, I might add some support for perspective transforms, that would come later. For

I'm not sure where this talk about vector graphics is coming from. I don't have any plans to support SVG or similar in Ren'Py. While I could be convinced to change that if there was a relatively small and open SVG library that's easy to use, I'm not sure this is a GL-related issue.


Technical side of things:

GL Ren'Py is based on texture grids. When we load an image, it gets chopped up into a series of textures. Each side of a texture is either 512, 256, 128, or 64 pixels wide (the textures do not have to be square: 64x512 is a valid size). Textures include a 1 pixel border when they overlap with other textures.

The maximum image size is limited only by available ram, rather than by GPU limits.

Texture grids can be drawn to the screen using one of three operations. Each operation takes a transformation matrix to use, and can also adjust the alpha of the result.) The three operations are:

- Blit: draw a single texgrid normally.
- Blend: draw two texgrids, using a blending factor to interpolate between them.
- Imageblend: draws two texgrids, using a blending factor to interpolated betwen them. A third image is used to adjust the blending factor.

Depending on the system, these can be implemented either using the fixed-function pipeline or fragment shaders (pixel shaders in DX).

There is (or rather is going it be) render to texgrid support, which is needed (along with the blends) for doing Dissolve and ImageDissolve properly. Simply doing an alpha-blit won't cut it.

There are a couple of things I'm still not sure about the design of, yet.

- I'd like to be able to do native-resolution text.
- I'm not sure if mipmapping is necessary.

I want to experiment with both before committing to a design.

Graphics Programming isn't my specialty. (Languages is.) So this has been quite the learning experience for me, and if people want to point out flaws in my design, please do.

PyTom wrote:This is what causes the aspect ratio problems. Improved drawing speed will allow the screen to stay in its native resolution, while Ren'Py takes care of drawing letterbox bars as necessary.

Similarly, this will allow us to adjust the size of the game in windowed mode.

Yuck.

I realize that this is just my subjective and somewhat controversial opinion, but it's one I feel very strongly about. OpenGL texture stretching look like shit. Bilinear filtering even more so than simple point scaling.

Does it look worse than the hardware scaling found in video cards, which gets the aspect ratio wrong quite often?

Ideally, there would be no scaling, but that doesn't seem to be practical anymore.

(I'll note that the scaling algorithm implemented in Ren'Py right now is the OpenGL one.)

PyTom wrote:Does it look worse than the hardware scaling found in video cards, which gets the aspect ratio wrong quite often?

No, but it looks worse than switching resolution on a CRT monitor, and it look looks worse than black bars on an LCD monitor.

To me, the ideal setup would be:

• Screen resolution set to the smallest aspect-ratio-preserving native resolution of the monitor that is equal or larger than the logical resolution of the game.
• Viewport set to the largest integer multiple of the logical screen resolution that is smaller or equal to the screen resolution.
• If the viewport is larger than the logical resolution of the game, use point scaling (GL_NEAREST) to scale up from the logical resolution to the viewport.
• If the viewport is smaller than the screen resolution, add a black border.
• When running in a window, only allow the window to be resized to integer multiples of the original resolution.

Alternately, create the game for a ridiculously huge logical resolution and downscale. OpenGL downscaling looks much better than OpenGL upscaling. The downside of this approach is huge graphics files, but since graphics generally take only a small fraction of the game download size, this may be an acceptable compromise.

A third alternative would be to perform scaling in software, before handing it over to OpenGL, or in a very clever pixel shader within OpenGL. This at least allows you to use a better scaling algorithm than bilinear filtering.

Just checking but is GL Ren'py implemented so that particles get the great performance increase from using a graphics card?

Hm...

There's no particle-specific acceleration, but our current particle framework will benefit from the improved rendering performance. I may consider adding a new particle system (or integrating something like lepton), but that would be another step.

I think I may have totally misunderstood >_<

I also didn't necessarily mean that you would necessarily have Ren'Py handle svg as a built in feature or something - I was just supposing that once it had OpenGL support it would be possible to set that up. I did a google search when the subject first came up (for svg OpenGl converters or stuff like that) and I got some hits, but I'll admit that I didn't research it very thoroughly.

Will it also enable the capability to record using a game recorder, like Fraps, for example?

Yes. But AFAIK that ability already exists. Certainly, I was able to make Ren'Py screencasts and post them on youtube.