Discussion: texture of UI entities

[ChrisEt]

Hi guys, hi Rob,

I'm currently working on the UI part of my game. I came across an issue when I wanted to place all UI images in a cell sheet. I'll describe my findings below and would be happy to discuss the optimal solution with you.

Initial situation:
My UI consists of many different graphical elements like buttons, sliders, windows, separators, etc. Each of these is a separate image. Instead of having many image files which must be loaded separately I want to use a cell sheet. In a cell sheet all images are in one file and the IgeCellSheet._cells[] array contains the coordinates of every single image.

1) I used the program TexturePacker to create the cell sheet and Stuart's TexturePacker Atlas loader (thanks Stuart btw!) to load the cell data. So far everything worked fine.

2) My problems started when I tried to use IgeEntity.cellById() to reference a specific cell image from the cell sheet. It doesn't work because IgeUiEntity stores the texture in ._patternTexture and not in ._texture as is required by cellById().

3) When digging further to find the reason for that I realized that IgeUiEntity is duplicating quite a lot from IgeEntity, for example the pattern fill code, but is missing other things from IgeEntity such as the caching functionality.


Now I see the following possible solutions:

a) I could extend IgeEntity and write my own UI classes. I would more or less duplicate Rob's work, especially the part with applying different styles.

b) I could change the IgeUiEntity implementation to use IgeEntity's texture rendering code. I would probably have to extend it (or IgeTexture's rendering code respectively) to provide for the other rendering features currently present in IgeUiEntity. As there is already a TON of dependencies on IgeEntity I'm a bit worried I might break some functionality.

c) I could write my own cellById() implementation that works with IgeUiEntity._patternTexture.


What do you guys think? From an architectural perspective it doesn't make much sense that the rendering code is duplicated in IgeUiEntity, right? Would you create a feature branch in Git and adapt this whole part?

Looking forward to reading your comments,
Christian

[ChrisEt]

Hi guys,

I investigated and found out IgeUiEntity duplicates quite some functionality from IgeEntity, namely background drawing code. At the same time it's not permitting to cache the rendered graphics.

I implemented the "solution" in https://github.com/coolbloke1324/ige/co ... 93d996a931. It's not 100% complete as it breaks two features currently present in IgeUiEntity- My question to you is whether anybody is using or needing these features or if we could just remove them?

Here is what I did in more detail:

• Before, background image and border were being drawn in IgeUiEntity.tick(). These were always drawn to the on-screen canvas, so no caching was possible.
• I moved this code to the overriding method _renderEntity(). This is called by IgeEntity in tick() to draw to an on-screen canvas, or, in case of caching enabled, to an off-screen canvas.
• On the plus side this makes it possible to use caching for UI entities, which should give a good performance boost.
• Also, I could remove the background painting code in IgeUiEntity because this is now handled by long-existing code in IgeEntity. So instead of setting a background image or pattern with IgeUiEntity.backgroundImage() one should now use IgeEntity.backgroundPattern() or, even better, IgeEntity.texture().
• On the negative side we have the fact that the two methods backgroundSize() and backgroundPosition() are not implemented in IgeEntity and therefore stopped working. The solution would be to simply add them there, but the question is if anybody needs them.
• Also, using a single cell from a cell sheet for building a background pattern doesn't work (and probably never has). Is this a use case for anybody?

What do you think? The code is almost ready to be merged to master, I have tested it with the example 5.1-ui and tried many variations. I reckon the UI code is still in beta phase, so perhaps it's not that critical to lose the two features mentioned above?

I'd be happy to read your thoughts!

Cheers,
Christian