GUI library (WIP)

rrraptor · November 2019

I thought, it woud be good to create a separate thread to post progress or bugs/issues.
Progress for now:

So, I had a bit of free time, and I was trying to fix some bugs, and some buttons (and even just a single pixel object) start flashing... I have no idea why that happend, but seems like a gideros BUG. Its ok on my home PC and on my phone (via wifi preview), but on my PC at work...its something crazy

These flash effects completely random, sometimes everything ok, sometimes it is not.

GIF:

talis · November 2019

Progress for now seems really impressive. Wish you success, and if you can find time tell us about the progress in time. Again congratulations.

keszegh · November 2019

at some point i should redo the gui of my animation app and at that time i will check out all these impressive gui options that appeared recently for gideros.

antix · November 2019

@rrraptor apart from the funky flashing thing, that looks very cool. I must say it's looing much better than my effort currently is LOL.

are you using 9-patches for border drawing or something else?

rrraptor · November 2019

@antix Path2D

Shoud I use to use 9patch for better performance? Generate texture with Path2D and then use pixel.

EDIT:

On the left is generated 9patch, on the right - Path2D. They are 100x100 pixels

So, I made a function that generates rounded rect using Pixel 9patch.
Pros:

The size is 100% correct (you can see white rectangles behind each object, and because Path2D stroke is enlarging in both direction (inside AND outside), it looks bigger).
Probably better performance since its not a vector image.
Can be easily resized uisng "setDimensions"

Cons:

Impossible to change fill and stroke color
Impossible to change stroke width and feather

SinisterSoft · November 2019

The cons can be got rid of by first generating your 9-patch image to a rendertexture, then if you need to change a colour or width, just regenerate the rendertexture.

rrraptor · November 2019

Well, honestly, I dont realy need to change colors "on the fly". I can use setColorTransform.
Instead of forcing user to use Path2D, I'll let him deside which option to use.

Buitin gfx (Path2D, different shapes (triangle, rectangle, rounded rectangle, pentagon, hexagon, circle and etc) )
9patch (requires Pixel object)
Image (requires Bitmap object)

antix · November 2019

@rrraptor Great stuff. I had no idea that Pixel had 9-patch abilities. I looked for documentation but the main website has nothing! The wiki has some information but not enough to actually be useful.

I suppose I could mess about for a while to figure it but really... it should be well documented already.

As far as performance goes I'll have to try it to see how it works versus a RenderTarget with manually drawn corners and edges.

rrraptor · November 2019

antix said:
I could mess about for a while to figure

Its easy

local tex = Texture.new("myImage.png", true) -- can be RenderTarget
local px = Pixel.new(0xffffff, 1, 480, 800)
px:setTexture(tex)
px:setNinePatch(8)
stage:addChild(px)

Round rect nine patch generator:

function rrect(t)
	local r = t.r or 12
	local w = t.w
	local h = t.h
 
	local shape = Path2D.new()
	local ms="MALALALAZ"
	local mp = {0,r, 
		r,r,0,0,1,r,0, w-r,0, 
		r,r,0,0,1,w,r, w,h-r, 
		r,r,0,0,1,w-r,h, r,h, 
		r,r,0,0,1,0,h-r
	}
	shape:setPath(ms,mp)
	shape:setFillColor(t.fill, 1)
	shape:setLineColor(t.stroke, 1)
	shape:setLineThickness(t.strokeW, t.strokeF)
	return shape
end
--
function gen9patch(t)
	local r = t.r or 12
	local w = t.w
	local h = t.h
	local sw = t.strokeW
 
 
	t.w = sw+r*2
	t.h = sw+r*2
	local rt = RenderTarget.new(t.w + sw, t.h + sw, true)
	local shape = rrect(t)
 
	local px = Pixel.new(0xffffff, 1, w, h)
	rt:draw(shape, sw/2,sw/2)
	px:setTexture(rt)
	px:setNinePatch(r+sw/2)
 
	return px
end
--
 
local params = {
	w = 200, h = 100, r = 24, 
	fill = 0x000040, stroke = 0xf00000, strokeW = 4, strokeF = 0.3,
}
 
local sh = rrect(params)
sh:setPosition(20, 20)
stage:addChild(sh)
 
local ninePatch = gen9patch(params)
ninePatch:setPosition(20, 200)
stage:addChild(ninePatch)

antix · November 2019

@rrraptor thanks. I already figured out how it works, but had to update my Gideros which was still 2019.2

That sure does make creating these patches very easy. Since they will be used for user interfaces I don't think performance is a big issue. The biggest issue with interfaces seems to be the event listening, that can seriously suck the CPU

One issue with the patches is that if you have a patch size of say 16, but make your pixel smaller than 32 in either axis, it stretches the pixel in a strange manner and looks bad. This is of course overcome by not making the pixel too small

Now that I see how this works I will just use this method in my interface editor since this lets you use very small textures.

Ughhh... can anyone tell me why the Pixel cannot use a texture from a TexturePack? does that not seem retarded to anyone else?

EDIT: But I can get a TextureRegion from a TexturePack... create a RenderTarget with the same dimensions as the TextureRegion, create a BitMap from the TextureRegion, draw the Bitmap to the RenderTarget... and that is accepted by the Pixel as a Texture!!! Crazyness

Could Pixel pretty please work with a TextureRegion as fetched from a TexturePack?

rrraptor · November 2019

antix said:
Ughhh... can anyone tell me why the Pixel cannot use a texture from a TexturePack? does that not seem retarded to anyone else?

Well, it kinda works

The texture is moved, so you cant see it. Try to play around with Pixel:setTextureScale and Pixel:setTexturePosition. You will see the results

hgy29 · November 2019

antix said:

Ughhh... can anyone tell me why the Pixel cannot use a texture from a TexturePack? does that not seem retarded to anyone else?

I keep falling into that trap myself, so I end up working around the issue and in the end forget about it... until I start another project and hit the issue again. Yes Pixel needs to support TextureRegion, I'll try to find time to fix that.

antix · November 2019

@hgy29 that would be fantastic...Pixel really needs that ability, well for the purposes of my GUI library at least LOL. I can still keep working on my editor in the meanwhile.

SinisterSoft · November 2019

Point to a square wrapped texture is handy though, if you change the texture position then you can do nice effects like those in the background of this game:

oleg · November 2019

SinisterSoft said:
Point to a square wrapped texture is handy though, if you change the texture position then you can do nice effects like those in the background of this game:

And not better to make such a background with tiles?

hgy29 · November 2019

oleg said:

SinisterSoft said:
Point to a square wrapped texture is handy though, if you change the texture position then you can do nice effects like those in the background of this game:

And not better to make such a background with tiles?

Or do it all on gpu with instanced rendering

MoKaLux · November 2019

tutorials guys

SinisterSoft · November 2019

That is just one 'pixel' sprite set to the size of the screen, with a wraparound texture that has been scaled. I then just change the do a set texture position to scroll the texture. Works great.

SinisterSoft · November 2019

	border=Pixel.new(mytexture,1,1)
	border:setScale(1/bgndScale)

then each interrupt...

	border:setTexturePosition((sin(frameCounter/600)*256)%256,-frameCounter%256)
	border:setDimensions(bgndScale*maxWidth,bgndScale*maxHeight)
	border:setAnchorPoint(0.5,0.5)
	border:setPosition(screenWH2,screenWH2)

SinisterSoft · November 2019

Easier + probably faster than tiles.

rrraptor · November 2019

I don't know why but I thought that groups would be interesting to code, so I did this:

Project attached.

P.S. Sorry for messy code in main file ¯\_(ツ)_/¯

rrraptor · November 2019

Ok, I made a magic load function, to simplify group initialization.
Example from GIF:

local master = Group.new("Master")
master:load{
	"test1", {
		px, 
		tf("whatever2"), 
		"test2", {
			tf("lol1"),
			tf("lol2"),
			tf("lol3"),
			"test4", {
				tf("lmao1"),
				tf("lmao2"),
				btm,
				tf("lmao3"),
				tf("lmao3"),
			},
			tf("lol4"),
		},
		tf("whatever3"), 
	},
	"test3", {
		tf("lol1"),
		tf("lol2"),
		tf("lol3"),
		tf("lol4"),
	}
}

Also, fold, unfold and switch functions now separated, added "queryName" function that return a group with given name.

antix · November 2019

@rrraptor pretty neat... I've always struggled with lists

oleg · November 2019

Many accordion variants can be borrowed from JS

https://www.cssscript.com/top-10-javascript-css-accordion-components/

rrraptor · November 2019

@oleg in js+css+html its easy. But gideros is game engine, so imagine you are using js+canvas. How hard it will be?

oleg · November 2019

rrraptor said:
@oleg in js+css+html its easy. But gideros is game engine, so imagine you are using js+canvas. How hard it will be?

It's still easier in the game engine

antix · November 2019

Indeed, in the world of HTML, CSS, and JavaScript those things are almost trivial

I was thinking about things just the other day and I realized that I could have just used absolutely placed HTML elements in my editor, instead of redrawing every shape into an HTML5 canvas LOL. It's been good JavaScript practice however

rrraptor · November 2019

Is there anyone who used ECS (Entity Component Systems)? I though that it would be easier to make whole GUI using ECS (tiny-ecs for example), but I already stacked before coding on prototyping Entities, Components and Systems

Im thinking about something like this:

-- Systems:
-- touchSystem
-- eventSystem ?
 
-- Components (holds ONLY data):
-- cpanel (base component?)
-- cbutton
-- clist
-- ctree
-- cslider
 
-- Entities (UI elements itself):
-- button (cbutton)
-- list (cbutton + clist)
-- group (cbutton + ctree)
-- tab (cbutton + cpanel)
-- slider (cbutton + cslider)
-- etc

But maybe you guys have better ideas?) Or maybe ECS is bad idea?

hgy29 · November 2019

In the GUI I am making, I used a similar approach: data is not part of the UI component, and it can be virtually any lua value. I used the ‘adapter’ approach, like in android native layouts: the UI element takes a developer supplied adapter function to map the data to whatever the UI element needs.

antix · November 2019

I don't think ECS is a bad idea but I feel its better to keep things as simple as possible behind the scenes. If a user wants to extend the system or make some small changes, they should be able to do that with relative ease.

I didn't really understand anything you said @hgy29 but it sounds funky

rrraptor · November 2019

So I was playing around with ECS, but decided to stick with original idea, and as @antix mentioned, keep thing as simple as possible.
Currently Im working on a window component that allows you to easily create forms from code. But today I decided to add textured buttons

Howdy, Stranger!

Categories

In this Discussion

Top Posters

GUI library (WIP)

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

Top Posters

GUI library (WIP)

Comments