News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

Encapsulate display_xxx in a class...

Started by Max-Max, August 21, 2013, 12:28:09 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Max-Max

A reflection on display routines...
Imho I think all display_xxx should be encapsulated into a class where the pixel buffer (for example textur) is a member. In this way each instance acts more or less as a canvas with its own pixel buffer so we can use the display routines not only on the screen, but also on images and even create new images (which I need for the fallback theming).

If we make a base class with hidden constructor and then derive a screeen object as a singelton with its screen picel buffer and additional screen functions. Then a canvas class that can be created dynamically. The constructor could accept an image (bild_t) for image manipulation or a void for a non initialised pixel buffer pointer. A member function create_image could create a new bild_t, allocate a the pixel buffer and return an bild_t pointer.

The screen can actually be described as an bild_t object.

It looks quite "easy" to do this, putting the functions in a class accepting a bild_t object to operate on.
- My code doesn't have bugs. It develops random features...

Ters

I still don't see a need for fallback theming. If the images aren't there, just die. Simutrans does that for everything else. If anything, just have default images bundled with the game. It is after all much easier to just draw the default images than it is to programmatically create them.

Describing the screen as a bild_t object is certainly out of the question, as bild_t is RLE-encoded and semi-indexed, whereas the screen is just a simple pixel buffer. In other words, bild_t is the format for persisting image data, not for using/manipulating images.

Max-Max

Okay, I thought all images where decompressed during PAK load.
As I said, it was merely a reflection...

For fallback GUI, well If you where "just" a gamer with no computer skills, wouldn't it be frustrating if the game just didn't start?
My intention is not to draw the fallback every screen update (as it is now). I intend to create these images during theme loading to fill in missing GUI components.

With fallback images, we can still use old PAK files when we add more and more theme images, instead of just throwing out the player from his favorite game ;)

Since all elements now have fallback (yes I added the missing ones) the game can run without a skin.
- My code doesn't have bugs. It develops random features...

Ters

Quote from: Max-Max on August 21, 2013, 05:58:46 PM
For fallback GUI, well If you where "just" a gamer with no computer skills, wouldn't it be frustrating if the game just didn't start?

If you don't have computer skills, how did you manage to delete the default theme? The default theme would be located in the application directory, where most OSes limit access to non-admins. Even if new themes must be put in the application directory and not the user directory, it should perhaps be as different directories, just like pak sets. And then the problem with themes is no different than pak sets, and new users are more likely to fiddle with that than themes.

Max-Max

You really hate the idea of fallback graphics, don't you  ;D
If the theme or skin PAK isn't complete (gui elements missing), maybe for the reason that the fallback looks nice. It would be good to at least get up the theme selector to select another one. For that you need gui controls, hence fallback...
- My code doesn't have bugs. It develops random features...

Ters

I "hate" the idea of lots of complicated work that starts affecting every part of the game when I believe there are simpler solutions, and which postpones the completion of a new GUI system. And I'm OK with fallback graphics, but just draw it in an image editor and put it in a pak that ships with the game, just like what is done with the current skin. That seems a lot simpler to me, and much easier to maintain.

kierongreen

If you include a default skin then why not include a set of default translations and pak graphics in the executable too just in case. And music, and sound etc etc. No, I agree with Ters, perfectly sensible to just have some (more) files which required as part of the default data.

Max-Max

But the fallback graphics is already there and it isn't complicated at all. It will even be less complicated when it moves in to the theme manager. The GUI system even don't need to know there is a fallback... the Theme manager handles it all.

How can you be so negative to something you don't know? You have no idea how this will be implemented or how it will work, hence you don't know if it will be complex or not.

Anyway, we are way off topic here and I understand that you think this is stupid... so point taken.
- My code doesn't have bugs. It develops random features...

Ters

Ugh, I feel I've been doing lots of negative posts lately.

Another issue here is that if we ever get hardware accelerated rendering working, all the display_xxx functions that draw primitives will likely have to go for performance reasons, leaving only functions for drawing images and text. Direct access to the screen pixel buffer will also have to go.

There is also the issue that my current OpenGL renderer uploads all images (bild_t) to a texture atlas in VRAM during initialization. After that, the texture atlas can't be modified. markohs has expressed interest in changing that to some form of streaming texture atlas, however. Especially since a static texture atlas also makes it impossible to have more than 64k images. My OpenGL renderer has however hit a major obstacle.

One aspect of this idea can however carry over to my hardware accelerated ideas, and that is that perhaps windows should render to their own render target, but only when they have changed. These render targets would then used as textures when rendering the GUI layer onto the screen for each frame. I don't know if that will be more efficient that simply rendering all windows directly to the screen, since having to switch textures is expensive. These per window textures would be distinct from textures for images, though.

Max-Max

Thank you Ters, now I know the roadmap for the display_xxx routines and understand your concerns better.

As I understand, OpenGL have support for drawing primitives. It would be possible to use some of the current display_xxx function names as an interface to the OpenGL native functions (if this would be relevant).
- My code doesn't have bugs. It develops random features...

Ters

OpenGL does support drawing primitives, but drawing a line here, drawing an image there, then a line again might be slower than doing a thousand images from a texture atlas. So it is likely better to draw a line in GIMP and draw that image as a textured quad among all the other textured quads.

Max-Max

What can we expect from your new GL interface (replacement for display_xxx)? Antialiasing? 32bit images with alpha plane?

If everything are images, hod does Font handling work? Do you plan to use GL Font handling or bitblitting as we do now?
- My code doesn't have bugs. It develops random features...

Ters

Quote from: Max-Max on August 22, 2013, 05:57:58 PM
What can we expect from your new GL interface (replacement for display_xxx)? Antialiasing? 32bit images with alpha plane?
Initially nothing. Hopefully less use of CPU and system bus. I have found that antialiasing works poorly with the special colors. 32-bit with alpha would also require complete rethinking of the way graphics are, which is way outside the scope of what I'm doing.

Quote from: Max-Max on August 22, 2013, 05:57:58 PM
If everything are images, hod does Font handling work? Do you plan to use GL Font handling or bitblitting as we do now?

My plans are that fonts are rendered into a texture atlas, but likely a different texture atlas.

But at the moment, I'm completely stuck on how to do depth sorting without ruining the performance.

Max-Max

QuoteBut at the moment, I'm completely stuck on how to do depth sorting without ruining the performance.
Do you men Z-buffering in GL? This can be turned off glDisable(GL_DEPTH_TEST)

Now you only work with X,Y coordinates.
- My code doesn't have bugs. It develops random features...

Ters

That won't work. Vehicles would appear in front of all buildings. Overhead wires would be visible through the bridges above (this is what I'm stuck on anyway).