UFO:Alien Invasion

Development => Coding => Topic started by: bayo on September 10, 2008, 03:04:06 pm

Title: GUIs
Post by: bayo on September 10, 2008, 03:04:06 pm
Hello,

I just finish UFO:AI last week. I play it few years ago, and i am globally impressed by the evolution of the game. But, i dont see (or i missed that) an improvement of the GUIs (base management...), it seems to me, nothing have change.

Currently, I work on the web, so a think a lot about GUIs, how to improve it... If someone interesting by, i think i can work on this aspect of the projet, and i hope it can improve some elements. I do not think i have time yet to code something, but i can create prototype, or maquettes (last week, i already take a little time for that).

So, is there any discussion about GUIs (or part of GUI), or persons interesting by thinking about this question ? Have you see some lack on part of the game ? A GUI to improve (for example the geoscape have maybe some little problems, i can explain) ?

I am new here, so i realy dont know how this projet work, and if you need help ?

Thanks a lot for your comments.
Title: Re: GUIs
Post by: ghosta on September 10, 2008, 04:16:36 pm
We need any help, that is available :)

Maybe you can take a look at
http://ufoai.ninex.info/wiki/index.php/Main_Page

Especially http://ufoai.ninex.info/wiki/index.php/Proposals/New_UI
Title: Re: GUIs
Post by: Destructavator on September 10, 2008, 05:02:11 pm
One quick thing - if someone designs a new GUI, would it be possible to make it more compatible than the current one with widescreen displays?  With the present one in the SVN, everything is stretched out / scaled horizontally on my new computer (which has a widescreen display) out-of-proportion.
Title: Re: GUIs
Post by: bayo on September 10, 2008, 06:03:52 pm
Thanks a lot ghosta, maybe i can talk with BTAxis on the wiki.

Destructavator: generally, for simple GUIs without a lot of controls, it's something easy (geoscape). Else, it needs sometime to have more than one version of the controls (position and size), to optimise the space. But sure, it can be a constraint for the developpement, because more and more users have widescreen.
Title: Re: GUIs
Post by: BTAxis on September 10, 2008, 06:10:02 pm
The new GUI mockup was made centered around the concept of draggable components. So depending on the implementation, it should work great with widescreen resolutions. You'd just have a bigger area in which to drag the components.
Title: Re: GUIs
Post by: bayo on September 22, 2008, 02:47:09 pm
Well, i post some comment into the wiki without any reaction. Maybe you dont work a lot with this wiki, or i say unused thing. MediaWiki is a very nice tool for collaborative work, anyway i can't talk alone.

To not spend my time for nothing (because i dont know if my work is usefull) i upload all i do in this PNG. (Technical problem to upload something bigger than 1 MB into the forum, or something not an image into the wiki (PDF or ZIP can help, maybe)).

http://ufoai.ninex.info/wiki/images/2.2.1_comment_and_proposal.png

If someone is interested by that, i can move it as a real text into the wiki (but its some hours of upload, a lot of images :), and continue to work on.
Title: Re: GUIs
Post by: Mattn on September 22, 2008, 07:05:21 pm
hi,

some nice ideas - but i must say that i haven't seen all those in the forum or the wiki until you posted it here, sorry

the images you posted are a little bit too small to get anything out of them. where are the original posts?
Title: Re: GUIs
Post by: ghosta on September 22, 2008, 11:03:13 pm
I really like it :)
Title: Re: GUIs
Post by: bayo on September 23, 2008, 10:29:16 am
Its an HTML document converted into PNG. Little images are just thumbnail, but original one are 1024/xxx (4/3). Ok, i will move it into the wiki today (or in few days), if iv got the time.

I look at the code yesterday, and iv got a little question. Everything is in C (src/client/cl_). I am not sure, but if i test to change something, maybe i am more interesting by C++ to create complex GUI. There are maybe no technical problems with using both C and C++, but is your project allow C++?
Title: Re: GUIs
Post by: Mattn on September 23, 2008, 08:40:15 pm
Quote from: bayo on September 23, 2008, 10:29:16 am
but is your project allow C++?

sorry, no, the game itself will stay c

but if you know c++ and wanna contribute with gui - have a look at the mapeditor (could need some tweaks, too)

also please upload the images - some ideas are looking interesting.
Title: Re: GUIs
Post by: bayo on September 24, 2008, 09:40:09 am
I move it in a new page http://ufoai.ninex.info/wiki/index.php/Proposals/GUI_comment
I link the page nowhere, if it need to rename it? I am very interesting
by any little review, every comment can help to understand how think the UFO:AI user,
what he need, how to improve thing...

Is there any "tutorial" or documentation about the src/client/menu (nodes...)? I
begin to understand a little the software architecture, but a good documentation help a lot.
I dont find any high level explaination in the Doxygen (a global view of how this thing work).

I will take a look at the mapeditor, but yet, i am not very interesting by GUI out of the game.
Title: Re: GUIs
Post by: Mattn on September 24, 2008, 06:59:55 pm
sorry, there is no other docu than the doxygen generated.

i had a discussion with geever a few days ago and we finally thought that the best would be the introduction of a third party (GPL + C) lib - but this would result in a shitload of work. and that's why we didn't do it yet - we first have to focus on stabilizing things for the next release (no, no date given yet - still a long way to go .. ;) )

so if you know a good C + GPL lib that is doing menu stuff via openGL and is cross-plattform (at least *nix (linux, windows, bsd, solaris), windows) then please let us know and we can talk about this topic again.

It would also be an option to rewrite our menu system to support moving windows and so on.
Title: Re: GUIs
Post by: ghosta on September 24, 2008, 08:06:52 pm
I have thought about the soldier assignment to the dropship:
Currently you just assign them to the craft. This is more or less boring...

You know that I dont like the starting positions being outside the craft. And I also dont like the thoughts about assigning UGVs to weaponslots. In my opinion every starting position should be inside the craft. And the assignment screen is also part of it:

Basically there should be the aircraft in the background and the available starting positions inside the dropship as slots for adding soldiers and ugvs. The soldiers need a 1x1 square and the ugvs a 2x2 square. The assignment works more or less the same way as equipping your soldiers with weapons. Maybe there also can be a "eqip soldier" button and some information about the soldier and the equipment he is wearing.
Title: Re: GUIs
Post by: Kildor on September 25, 2008, 04:27:01 am
bayo, you should look to current 2.3 version, it has some improvements in GUIs, i/e/ remove single aircraft buysell/production
Title: Re: GUIs
Post by: bayo on September 25, 2008, 10:53:44 am
Mattn> i never use any library like that else GLUI, but maybe its not helpfull for your projet. I search C lib and i only find http://libagar.org ; but you also need a skinable GUI?, and i dont think it is. To improve your own "src/client/menu" maybe the more important thing is to provid a generic scrollbar.

ghosta> Its a good idea to use the aircraft like that to assign soldiers, i can create a preview to see. Starting positions outside the craft create sometime strange situation, specially when you already show an alien near your soldiers at the first round. Maybe authors do it to have a faster gameplay? I also never know why alien dont shoot down the aircraft at landing :)

Kildor> i compile and use the 2.3.dev, but yet, i dont take the time to look at it very well. But i see a lot of improvment.
Title: Re: GUIs
Post by: bayo on September 30, 2008, 03:31:03 pm
I look at more specifically the "src/client/menu" code last weekend and i think i understand it sufficiently to know how to clean up; to allow next time the possibility to expand it. I propose only a code restructuration for the first time, because currently this code look to me very hard to maintain.

If you think you will continue to use your "menu" code, without changing it for a third party, maybe i can help you by working a little on it.

This aim to create "real" componants by removing dependancy from the core (mn_input, mn_display...) to the nodes. All this steps can be done transparentelly for the global architecture, i think.


The core can now work with only a node description, without special case (no use of MN_...).
Its more easy to add new component, and to change beavious. We can easilly create new componants, more complex, or adding new events (mouseover?)... and thinking as an OO program.

Are you interested by that? I dont think its a too much long work, but i realy think it's
a need (if i dont missed a big thing). But its important to understand its only a code
restructuration. At the end of all this thing, there are no more functionality, but, i hope
a more extenssible code. I can work on this part of the code if you want... but i am very slow and i dont have access to the svn (access restricted).
Title: Re: GUIs
Post by: geever on September 30, 2008, 04:09:56 pm
Thanks for offering help, it's always appreciated.

btw We don't wanna make it OO, AFAIK, notihng is OO in ufo (but It's rather for Mattn).

I'm working on "floating menus" so we'll have to coordinate it not messing eachother's work. I have only some (2-3) bugs left maybe you could help fixin' them. Join on IRC in the evening (CEST) if possible. :)

-geever
Title: Re: GUIs
Post by: bayo on September 30, 2008, 06:38:22 pm
I dont talk about C++.

Hard to me to explain that. You can architecture a C for something like OO (as i say, a struct for behavior of your "node"). I can say it with a draw if it need. struct behavior for your node is the same as an object for an instance in OO. Its just a code architecture.

The only need i understand is the use of C (i dont understand very well why, but its not a problem for me). Not spending time into a better architecture (reducing dependency) is a non sens (you think it slower? you think its over complex?). In this perspective, i am not interested, because while you will add thing into your code, more you will spend time in maintenance and repair.
Title: Re: GUIs
Post by: Mattn on October 01, 2008, 07:41:30 am
cleanup is always welcome. feel free to start it. in general you have to provide one or two patches in order to get write access to the svn.
Title: Re: GUIs
Post by: bayo on October 01, 2008, 11:26:58 am
Ok, i can test that.

I work a little on a tab header. I can send a little patch about it in a few day to test (because i never use sourceforge or diff), and why not, a bigger one next time. But, went it need a big work, I prefer talking, thinking about change, and problems with every body, instead of spend a long time for nothing.
Title: Re: GUIs
Post by: Mattn on October 01, 2008, 07:02:09 pm
for those cases you should join our irc channel at irc.freenode.org #ufo:ai
Title: Re: GUIs
Post by: bayo on October 03, 2008, 02:29:06 pm
unfortunaltly i surf throug an HTTP proxy, i dont think i can connect to IRC freenode :/
Title: Re: GUIs
Post by: bayo on October 06, 2008, 11:00:46 am
I send a patch about tab, but i v got a little question.

I use a png texture, it look to me the texture use something like a lossy based compression ?! When i change the texture resolution with the game option, some transparent effect, or stretching look strange. For a GUI, its very important to use a "pixel precision" (at least for the 1024x7xx version :D).

Anybody know how work the caching process of textures? Because I am not sure about what i say. And is it technically possible to force a loseless caching texture for loseless format of GUI (for example, all PNG/TGA of the /pics/menu directory)
Title: Re: GUIs
Post by: Mattn on October 06, 2008, 07:06:17 pm
have a look at r_image.c: R_UploadTexture, R_FindImage and R_LoadImageData
Title: Re: GUIs
Post by: Mattn on October 06, 2008, 07:09:08 pm
btw. i've applied your patch to trunk
Title: Re: GUIs
Post by: bayo on October 07, 2008, 10:34:55 am
I already look at that, but i dont understand very well all this thing :D

Now, i am working around the GUI code architecture. More i look at the code, more i think it need to change a lot of thing. I never contribute to an open source projet by sending patch, so i realy dont know. Do you want i send you often little patch, or a few big?

With little, its maybe easy to see that the code dont change at all, there are only "refactoring" (extract method, move code and method, change param...), it maybe more easy to apply it. With a big, it will not be so easy, maybe, but at the end, it the same result.
Title: Re: GUIs
Post by: Kildor on October 07, 2008, 04:00:53 pm
May be some small patches, and after it -- direct access to SVN?

But I`m not a coder and not a "power-SVN-user"
Title: Re: GUIs
Post by: Mattn on October 07, 2008, 05:04:21 pm
yes, what about svn access? if you want it, let me know.
Title: Re: GUIs
Post by: bayo on October 08, 2008, 11:08:53 am
Sure, it will be a nice help, but you are very confidant :o i hope i will not broke your trunk.
Title: Re: GUIs
Post by: BTAxis on October 08, 2008, 11:12:28 am
It's not like other people aren't breaking trunk all the time anyway, including mattn.
Title: Re: GUIs
Post by: Mattn on October 08, 2008, 06:02:52 pm
ok, you have write access now - but please re-read the coding guidelines in the wiki.

also - please do small commits - it's easier to track bugs down
Title: Re: GUIs
Post by: bayo on October 09, 2008, 03:40:48 pm
i will
Title: Re: GUIs
Post by: bayo on October 09, 2008, 03:47:23 pm
ho, is there exists a "coding guidelines" checker for C:B, something like that?
Title: Re: GUIs
Post by: BTAxis on October 09, 2008, 04:06:17 pm
It's called "mattn".
Title: Re: GUIs
Post by: bayo on October 10, 2008, 02:03:20 pm
But its very expenssive and not open source ;D
Title: Re: GUIs
Post by: Mattn on October 10, 2008, 05:28:02 pm
not sure - is it possible to create format templates for c::b? if yes - we should have a look at that
Title: Re: GUIs
Post by: bayo on October 10, 2008, 06:45:20 pm
I find on the web it exists a already installed plugin call AStyle, to auto format the code with predef format or customised one. I dont have Code::Blocks here, so i can't test. But its very strange, i find nothing about that on the official web page.

to use: Menu → Plugins → Source code formatter (AStyle)

to config: Menu → Settings → Editor... → Source formatter

(fr) http://formation.u-psud.fr/courses/PROGC/document/Tutoriel_CodeBlocks.pdf
Title: Re: GUIs
Post by: RudolfoWood on October 10, 2008, 07:44:06 pm
(only for records :-) ) Eclipse CDT has built-in code formatting (easily changeable)
Title: Re: GUIs
Post by: blondandy on October 10, 2008, 09:36:52 pm
I tried astyle, it did some very silly indenting. maybe i missed something.
Title: Re: GUIs
Post by: bayo on October 20, 2008, 01:56:04 pm
Hello. I v got problem to merge my branch into the trunk. I merge the last trunk into my branch and now, i want to apply this change into the trunk.

I create a diff like that:
svn diff --force http://ufoai.svn.sourceforge.net/svnroot/ufoai/ufoai/trunk http://ufoai.svn.sourceforge.net/svnroot/ufoai/ufoai/branches/ufoai_menu > a.patch


And i apply the patch into the trunk like that:
patch -p0 --dry-run < ..\ufoai-menu\a.patch

but every time the command crash.

I am under Windows, and I download the patch.exe from the "UnxUtils" package.

Do i something wrong? Thank for your help.
Title: Re: GUIs
Post by: Kildor on October 20, 2008, 03:01:00 pm
If you under win, you can try to use tortugesvn, for example, or other svn  patch util.
Title: Re: GUIs
Post by: bayo on October 21, 2008, 10:23:16 am
i learn a lot. i never find how to use patch.exe, i finally use the merge command. I hope there are no problem with my revision 19751.

I will now work on forcing only one node at a time under the mouse. It will simplify all the core function (draw and inputs). For that i will create a button node (specially to replace the couple background image + text, first GUIs of the game use a lot that).

I will maybe test .ufo with a script to catch graphical node overloading, but do you see more case like that where it exists two overloaded active nodes (active node: which catch mouse events) (for example two node at the same position uses both a click (or in or out) function)
Title: Re: GUIs
Post by: Kildor on October 22, 2008, 04:40:49 am
I try to play with last trunk, and found some regressions and glitches:

1. base miniatures in base summary screen looks overlaping.
2. mousewheel doesn`t work in eauipment|production screens, it doesn`t scroll throw categories.

3. Also, in debug version ufoconsole.log full
"MN_GetSafeReferenceString: Reference null or empty" warning.

4. I`m not sure about this bug, it can be not related to you last big commit, but there aren`t any models in production|buysell screens.

Can you look to this bugs?
Title: Re: GUIs
Post by: bayo on October 22, 2008, 11:12:57 am
Thank for the feedback. Maybe mattn patch the 3.

I will look at that, but, i dont realy understand the 2. mousewheel. Its not about scrolling the list, but the bottom right control with blue arrow ?
Title: Re: GUIs
Post by: Kildor on October 22, 2008, 12:11:43 pm
3 -- afaik no. He rename function and now I get bunch of warning with new name. I use debug version.

2 -- yes, exactly. In earlier versions mousewheel changed category on screen. Now it doesn`t do anything.
Title: Re: GUIs
Post by: Kildor on October 22, 2008, 03:43:14 pm
Some more bugs:

5. I also can`t scroll throw employes list in hiremenu.

6. I can`t open inventory when I in tacticsmode, game has just dropped to geoscape back. There is nothing in logs, and in rev19691 all worked correct.
Title: Re: GUIs
Post by: Kildor on October 23, 2008, 01:56:06 pm
4. Fixed, thanks :-)


7. I can`t select tab with item parameters in equipment screen.
http://fotki.yandex.ru/users/kildor/view/121055 — here is screenshot

8. Button "Save" in mainmenu should be gray if I don`t start a campaign. Currently it is green.
Here is little patch. Or
Code: [Select]
Index: menu_singleplayer.ufo
===================================================================
--- menu_singleplayer.ufo (revision 19786)
+++ menu_singleplayer.ufo (working copy)
@@ -84,7 +84,7 @@
  size "256 64"
  image menu/button_big
  font f_menubig
- color "0 0.5 0 1"
+ color "0.5 0.5 0.5 1"
  selectcolor "1 1 1 1"
  string "_Save"
  }
Title: Re: GUIs
Post by: bayo on October 23, 2008, 02:49:29 pm
8. For the button, i update the source with a hard fixed color. I think there are not only this button. When it possible, its maybe better to add another param on the script for this, like "disabledcolor". I am also very interesting to know if we can query a texture to know the color of a pixel, like that, we can embed all textcolor into the texture (a texture -> whole the style of the button).

1. 2. 3. 5. 6. 7. and more... I will no more refactoring the code while this regressions are not patched.
Title: Re: GUIs
Post by: Kildor on October 23, 2008, 03:19:20 pm
about 8.
disabledcolor is good idea, but method of handle buttons should be changed in this case. Now if button isn`t meeted the condition it just doesn`t draw. And, if it will be drawed with disablecolor, there should be 'disabletext' parameters. And, possible we should mark, will button be drawn with disable*, or it will not be drawn at all.

PS: btw, do you need in my bagreports in general, or it all is just WIP, and should not be checked right now?
Title: Re: GUIs
Post by: Mattn on October 23, 2008, 04:09:47 pm
Quote
<mattn2|home> bayo (if you read the logs) the geoscape controlls for rotating and zooming are no longer working (menu_geoscape.ufo)
<geever> bayo, and also both of "Back" And "Exit" is written in main menu when coming from geoscape ...
<mattn2|home> bayo also geoscape->options button - the appearing menu is back and exit
 ^^ hehe
<geever> I've found it's reason but not sure how he wanted to do
<mattn2|home> bayo - also Unknown command "0" at the game console
<geever> Exit is a custombutton, ans Back is a string maybe back should override Exit...
 s/ans/and/
Title: Re: GUIs
Post by: bayo on October 24, 2008, 10:57:31 am
1. I patch that by removing the padding out the node went we draw the common background (m_draw.c). All the content of a node must be into the bounded box (pos,size). I can explain why it important. As a result, i also move the background of all another nodes using bgcolor; but its only few pixels, maybe there are no big vissible change.

2. 5. 7. geoscape controll. The bug was create by uncatched events into zone node. I hack that very fast on m_nodes.c, but i will soon do the same cleaner.

6. I dont check it yet, maybe its the zone node bug?

3. I must check it more, maybe the better thing to do is deleting this "safe" function.
Title: Re: GUIs
Post by: Kildor on October 24, 2008, 05:08:27 pm
1,2,7 are fixed, thanks.

6 — is not fixed yet.
5 — is not fixed yet too.
Title: Re: GUIs
Post by: bayo on October 26, 2008, 09:35:49 am
geever and me fixe 5. and 6.
i hope no more bug :D
Title: Re: GUIs
Post by: bayo on November 05, 2008, 09:05:44 am
Hello,

I need a beta test into the trunk with the new mouse event handle code. I want to be sure it not exists blocking problems on that code before switching the code. Maybe it exists some regression (for example, the mouse click repeat), but we must/can continue to use the game.

To active the event handle code we can type on the console:

Code: [Select]
set mn_debugmenu 2
And to return to the classic code:

Code: [Select]
set mn_debugmenu 0