Page 4 of 14

Re: New GUI scripting concepts and foundation

Posted: Fri Dec 28, 2012 3:32 am
by thomson
I've just added hooks to handle events (i.e. dialogs that happen in specific location only). Changes are in git. This is almost direct copy of the code from EOB1 mod. Most of the code is temporary and will be rewritten once we have the capability to draw buttons, rectangles, images and text.

One thing that I'd like to show and ask for comments is how events are defined. The idea here is to have the ability to make it easy to write, using just the grimrock editor, without the need to modify any scripts. The current event (see gw_event_1 at 16,16) looks as follows:

Code: Select all

-- is this event enabled?
enabled = true

-- name of the imeage to show
image = "mod_assets/images/example-image.dds"

-- todo: the following x,y coords are temporary.
--       They should be calculated automatically.

-- image position
image_x = 40
image_y = 60

-- text description position
text_x = 220
text_y = 60

-- buttons position
buttons_x = 220
buttons_y = 160
buttons_width = 200

-- initial state
state = 1

-- functions called after specific buttons being pressed
function onHeal()
    hudPrint("Healing!")
    state = 2
end

function onTalk()
    hudPrint("Dwarf is in too much pain to talk.")
end

function onLeave()
    enabled = false
end

function onHealed()
    hudPrint("He is healed already!")
end

-- defines states. Each entry must have exactly two columns:
-- first is state number, the second is description shown.
states = {
  { 1, "An injured dwarf lies on the ground before you,\n" ..
       "nearly unconscious from his wounds." },
  { 2, "The healed dwarf is happy." }
}

-- defines possible actions in each state. Each entry has
-- 3 values. First is state number. Second is action name
-- (will be printed on a button). The third is a function
-- that will be called when action is taken (i.e. button
-- is pressed).
actions = {
  { 1, "tend his wounds", onHeal },
  { 1, "talk", onTalk },
  { 1, "leave", onLeave},
  { 2, "healed", onHealed}
}
I hope the absolute coordinates will go away once we have high level API (as JKos proposed) implemented. I was thinking if image should be defined once for the whole event (or perhaps defined separately for each state). The former is simpler, but the latter is more flexible. What do you think?

Re: New GUI scripting concepts and foundation

Posted: Fri Dec 28, 2012 10:24 pm
by Xanathar
Ok, today I was able to at least think of something and I'm working on the definition of the base object and a sample rectangle object so that later we can test containers, drawing order and the structure. If I'm overlapping with work someone else is doing, tell me and I change topics :)

BTW if anyone wants to participate in the project but does not feel like scripting, a very useful and long job to do is to calculate how many pixels each letter - in both upper case and lowercase - number, space and punctuation sign takes in width so that we can try to implement a "measureString" kind of function.

Re: New GUI scripting concepts and foundation

Posted: Fri Dec 28, 2012 10:25 pm
by JKos
Thanks for comments thomson, I guess we go to that direction with the api then because both of you seem to think that it's reasonable?
We can possibly implement createElement() with one extra optional parameter "parent". It would simplify creating events (no need to call addElement, no need to store leaf buttons)
Yes we could, but as I suggested in high level api example the addElement-function could also be used to create elements directly to the parent.

Code: Select all

-- create 200x200 rectangle to postion 20,20  
local dialog = gw.createElement('rect','my_dialog',20,20,200,200)
-- create button as a child of dialog. All coordinates become relative to parent
dialog.addElement('button','my_button',20,150,20,100)
These are little details of course but IMO this is bit more descriptive syntax.

Code: Select all

Why do we need to set dialog.class to any specific value? In what context that would be useful? That's an honest question.
I don't know if we need it or not :) I just put it there by intuition. It can be useful if we want to do something with certain type of gui objects. But we can leave it out add it later if we need it.

I checked your events script and it looks good and works nicely. But I think that the event script scanning (function processEvents(ctx)) could be implemented by using a timer with 0.2 second interval or something because it's just waste of cpu cycles to scan them on every frame, of course that can be fixed later if we need to optimize our code. But if we just keep adding scripts which are executed on every frame, it will show on performance some day/slower hardware. Fortunately my computer is few(i think 4) years old so if our scripts work on my machine they should work on the majority of the computers.

Re: New GUI scripting concepts and foundation

Posted: Fri Dec 28, 2012 10:31 pm
by JKos
Xanathar wrote:Ok, today I was able to at least think of something and I'm working on the definition of the base object and a sample rectangle object so that later we can test containers, drawing order and the structure. If I'm overlapping with work someone else is doing, tell me and I change topics :)

BTW if anyone wants to participate in the project but does not feel like scripting, a very useful and long job to do is to calculate how many pixels each letter - in both upper case and lowercase - number, space and punctuation sign takes in width so that we can try to implement a "measureString" kind of function.
Great, I haven't started anything related to those topics. Good luck.

Re: New GUI scripting concepts and foundation

Posted: Sat Dec 29, 2012 4:14 am
by Diarmuid
Hi guys,

I just wished to say I'm following daily your discussions, but at this stage it's too low-level for me - after all I'm a composer, not a professional programmer, and I'd best leave the core design to you, trying to concentrate meanwhile on developping my spells framework and my dungeon.

I'm still interested to help at some point however, if you need testing, developping higher-level functions, methods, etc., don't hesitate to contact me.

Good luck meanwhile... :)

Re: New GUI scripting concepts and foundation

Posted: Sat Dec 29, 2012 1:40 pm
by thomson
Xanathar wrote:BTW if anyone wants to participate in the project but does not feel like scripting, a very useful and long job to do is to calculate how many pixels each letter - in both upper case and lowercase - number, space and punctuation sign takes in width so that we can try to implement a "measureString" kind of function.
I'm not sure if that is feasible. Calculating how much space a given text will take is actually non-trivial problem. Fonts may use kerning or ligatures. This may vary between supported systems (Windows, Linux and Mac OS so far, but iOS is likely to join the list). Also, I'm not sure if the same font is used everywhere. Furthermore, some systems may allow you to tweak things like kerning. It was possible to change it in Gnome 2 on Linux. On the other hand I'm not sure if Grimrock uses font rendering provided by system or does it on its own.

I think the way to go here would be to use estimated length, using average width multiplied by number of letters. This should then be slightly adjusted for wide (e.g. w,m) and narrow (e.g. l,j,i etc.) letters. That will give us an estimate.

Related question: how do we want to handle different resolutions? I suppose the simplest answer would be "we don't". What's the smallest resolution that is supported by Grimrock itself? I was thinking that once ipad version will appear, it may be reasonable for AH to also support iphone. We can further assume that iphone 4 will be the oldest supported, so this gives us lower estimate on supported resolution: 960x640. Regarding regular PCs, the smallest netbook I was able to find was the first Eee PC with resolution was 800x480 (yikes, that's small). I'm not sure if it is able to handle Grimrock.

Given all those above, I think we should not do any scaling and use absolute dimensions. Sure, grimwidgets will look different on iphone and on 2560x1600 30' monitor, but I can live with that. What do you think?

Re: New GUI scripting concepts and foundation

Posted: Sat Dec 29, 2012 3:13 pm
by Hellriegel
Where do I find the documentation of those new incredible GUI features?

Re: New GUI scripting concepts and foundation

Posted: Sat Dec 29, 2012 3:30 pm
by Neikun
I would also like to know.

Petri will likely update the docs after the holidays.

Re: New GUI scripting concepts and foundation

Posted: Sat Dec 29, 2012 3:39 pm
by Xanathar
Grimrock uses font rendering provided by system or does it on its own
Of course I can't be 100% sure (only God.. err Petri knows), but I'm 99.9% confident that Grimrock uses its own text rendering engine which is a simple bitmap copy of characters from some texture by parsing the string char after char; that's the fundamental reason it doesn't support accents and why it has beautiful multicolored characters. So, no ligatures, kerning etc if this theory is correct.

EDIT: I just noticed the in-game font used by the GUI and hudPrint is monochrome.. so maybe it's the 0.01% and you are right :( Which would mean no algnments on texts, as using an average might be ok for word wrapping but not for center or right alignment of strings imho :(

EDIT2: checking if the typical ligature between f and i exists and it doesn't.. I guess the only way to know for sure is take the OS/X version of strings and compare.

Image

Re: New GUI scripting concepts and foundation

Posted: Sat Dec 29, 2012 5:30 pm
by petri
The font rendering system is the same on all platforms and does not do kerning.

Also, I updated the asset definition and script references with the new stuff before the holidays. The documentation is quite brief but it should mention all the new features.