Author Topic: Working on intrface style...  (Read 383 times)

Offline adumbperson

  • Turn around in orbit!
Working on intrface style...
« on: May 05, 2019, 03:11:52 pm »



Actually I'm working on intrface style and features...

This post is for sharing and inspiration...

I'll edit this post adding stuff I do...

So.

To make flat 2d style you can use GIMP which is free software.

To make flat 3d style you can use BLENDER which is free software.

ofc you can find other softwares that'll just do the job... (share them if u want)

Interface rendering can use bmp, png and frm file formats.
- bmp are very light if you don't need an alpha channel (transparency)
- png are nice and handling well transparency but file resulting from gimp are lil big...
- frm NEEDS A LONG DESCRIPTION...

All the graphic assets is into ./data and also inside fallout.dat,
you'll need to unpack to pick up stuff...
(engine loads first the dat files then walk ./data file tree. )

Interface is defined inside ./data/art/intrface/default.ini
Hardcoded screens handling is defined inside fonline's ClientInterface.cpp

::feature ideas::
- fingerprint assets... so user cannot change stuff...

If you have questions or Ideas don't hesitate.

Happy hacking.
« Last Edit: May 17, 2019, 10:41:02 am by adumbperson »
Dumb or right... ez.

Offline Slowhand

  • Go for the eyes, Boo! Go for the eyes!
Re: Working on intrface style...
« Reply #1 on: May 07, 2019, 12:25:43 pm »
Looks good.

Offline adumbperson

  • Turn around in orbit!
Re: Working on intrface style...
« Reply #2 on: May 07, 2019, 05:52:26 pm »
Thanks.

Actually it's just some freestyle easily done using gimp...

I'm not hidding the fact I would prefer to have someone like Olympus designer to help me with that...

Dumb or right... ez.

Offline Wipe

  • Rotator
  • Random is god
Re: Working on intrface style...
« Reply #3 on: May 12, 2019, 01:42:40 am »
Reminds me my debug/fun interface i made once; unlike the regular one, it was drawn 100% from scripts and was displaying only if normal iface was hidden. Good times.

Games are meant to be created, not played...

Offline Slowhand

  • Go for the eyes, Boo! Go for the eyes!
Re: Working on intrface style...
« Reply #4 on: May 12, 2019, 01:23:56 pm »
A minimap would be nice, but it would need to be rotated to match map. Nothing worse that Fallout pipboy minimaps.

Offline Wipe

  • Rotator
  • Random is god
Re: Working on intrface style...
« Reply #5 on: May 13, 2019, 10:49:10 pm »
A minimap would be nice, but it would need to be rotated to match map
Kinda right, but you get used to it pretty fast i think, even without rotation. Worst part of minimap is that you cannot move when it's open :(

Anyway, i like the simple style of OP's iface. Player gets what's needed, dev doesn't have to be art school student to create a new screen; win-win. If it wouldn't block interaction with map (movement, combat, containers, etc.) while it's open, it would be perfect.
Games are meant to be created, not played...

Offline adumbperson

  • Turn around in orbit!
Re: Working on intrface style...
« Reply #6 on: May 14, 2019, 03:44:47 am »
A minimap would be nice, but it would need to be rotated to match map. Nothing worse that Fallout pipboy minimaps.

Very interesting idea.

Kinda right, but you get used to it pretty fast i think, even without rotation. Worst part of minimap is that you cannot move when it's open :(

Anyway, i like the simple style of OP's iface. Player gets what's needed, dev doesn't have to be art school student to create a new screen; win-win. If it wouldn't block interaction with map (movement, combat, containers, etc.) while it's open, it would be perfect.

Interesting to know. Now that we have engine's source, everything is possible.

I think I'm gonna look/dig around this minimap idea, I find it very interesting.
Dumb or right... ez.

Offline Wipe

  • Rotator
  • Random is god
Re: Working on intrface style...
« Reply #7 on: June 07, 2019, 11:12:06 am »
;D
« Last Edit: June 07, 2019, 11:33:40 am by Wipe »
Games are meant to be created, not played...

Offline Lexx

  • Rotator
  • Mexican Apple Thief
Re: Working on intrface style...
« Reply #8 on: June 07, 2019, 02:53:42 pm »
Bit small, but nice.

Offline Wipe

  • Rotator
  • Random is god
Re: Working on intrface style...
« Reply #9 on: June 07, 2019, 06:00:12 pm »

Zoom level is just an argument to one of engine's draw functions, so scaling minimap up/down is trivial and doesn't need rebuilding/caching different data for different zoom levels. For a first version, it's good enough i think.
« Last Edit: June 07, 2019, 06:03:11 pm by Wipe »
Games are meant to be created, not played...

Re: Working on intrface style...
« Reply #10 on: June 08, 2019, 01:19:02 am »
<a href="https://www.youtube.com/watch?v=iFOfSlDCwYw" target="_blank">https://www.youtube.com/watch?v=iFOfSlDCwYw</a>
The sky above the port was the color of television, tuned to a dead channel.
irc V_guessWho

Offline adumbperson

  • Turn around in orbit!
Re: Working on intrface style...
« Reply #11 on: June 08, 2019, 10:44:55 am »

Zoom level is just an argument to one of engine's draw functions, so scaling minimap up/down is trivial and doesn't need rebuilding/caching different data for different zoom levels. For a first version, it's good enough i think.

Impressive! where do I find this nice prototype?

<a href="https://www.youtube.com/watch?v=iFOfSlDCwYw" target="_blank">https://www.youtube.com/watch?v=iFOfSlDCwYw</a>

WHY?
Dumb or right... ez.

Offline Wipe

  • Rotator
  • Random is god
Re: Working on intrface style...
« Reply #12 on: June 09, 2019, 04:38:21 am »
where do I find this nice prototype?

On my HDD only at the moment ;D
I'll throw a link here some rainy day (need to fix/finish few things first)... but i'm honestly not sure if it would be that useful. It's easy to get lost in UI stuff and comments barely exists at this moment, so better to extract the essence of a whole thing if anyone wants. While everything below is in C++, it should be possible to recreate everything in r412 dlls (and maaany older revs), or even ported to scripts.



TL;DR:
- GetCoords() (FOHexMap.cs)
- GetField() (FOClassic.h/FOnline.h/HexManager.h)
- PrepPoint, PointVec (SpriteManager.h)
- DrawPoints() (SpriteManager.cpp)



We start with small function to deal with hexes. It's simplified version of GetCoords() - converts hx,hy to 2d space resizing each hex to 2x1, where left part is a place for pixel, and right part is a null space for hexes above/below.

Code: [Select]
H H H H H
 H H H H
H H H H H
Code: (c++) [Select]
void FOC::Hex2D( uint16& hexX, uint16& hexY, uint16 mapWidth )
{
    const uint16 hx = hexX, hy = hexY;

    Hex2D( hx, hy, hexX, hexY, mapWidth );
}

void FOC::Hex2D( uint16 hexX, uint16 hexY, uint16& x2d, uint16& y2d, uint16 mapWidth )
{
    int x = hexY - hexX * 2;
    int y = hexY + hexX / 2;
    if( hexX > 1 )
        x += hexX / 2;
    x += mapWidth;

    x2d = x;
    y2d = y;
}

As any FOnline map should look like this, after conversion to 2d we have a huge area outside scrollblockers which we need to get rid of.

Code: (c++) [Select]
    // define minimap bounds

    uint16 minPX = uint16( -1 ), maxPX = 0, minPY = uint16( -1 ), maxPY = 0;
    for( uint16 hexX = 0; hexX < mapWidth; hexX++ )
    {
        for( uint16 hexY = 0; hexY < mapHeight; hexY++ )
        {
            bool show = false;
            uint dummy = 0;

            // check if current hex is going to be part of minimap
            if( GetHex( hexX, hexY, show, dummy ) && show )
            {
                // convert hex position to 2d position
                uint16 px = hexX, py = hexY;
                Hex2D( px, py, mapWidth );

                // update bounds
                minPX = std::min( minPX, px );
                maxPX = std::max( maxPX, px );
                minPY = std::min( minPY, py );
                maxPY = std::max( maxPY, py );
            }
        }
    }

Here GetHex() function is checking if there's anything interesting at specified position - will there be pixel placed for current hex or not? At this point it doesn't matter what it's going to be. For test purposes i checked for scrollblockers, as seen in previous post.

Code: (c++) [Select]
    Field* mapField = (Field*)(GameOpt.ClientMap);
    // ...
    Field& field = mapField[hexY * mapWidth + hexX];

    if( field.ScrollBlock )
        // ...

Once bounds are set, we process the map one more time and prepare draw data.

Code: (c++) [Select]
    // process map

    PointVec minimap;

    for( uint16 hexX = 0; hexX < mapWidth; hexX++ )
    {
        for( uint16 hexY = 0; hexY < mapHeight; hexY++ )
        {
            // convert hex position to 2d position
            uint16 px = hexX, py = hexY;
            Hex2D( px, py, mapWidth );

            // ignore everything outside bounds
            if( px < minPX || px > maxPX || py < minPY || py > maxPY )
                continue;

            bool show = false;
            uint color = 0;

            if( !GetHex( hexX, hexY, show, color ) || !show )
                continue;

            // adjust position
            px -= minPX;
            py -= minPY;

            minimap.push_back( PrepPoint( px, py, color ) );
        }
    }

Here, GetHex() is used fully and tells if given hex is part of minimap, and if it is - what color should be used for a pixel. In hardcoded minimap, it's done by FOClient::LmapPrepareMap(); GetHex() does similiar thing, except it works with single hex, and returns info only, without changing anything.
Anyway, once we process whole map, all what's left is to finally draw a whole thing.

Our BFF now is SpriteManager::DrawPoint(), which is also used internally after calling DrawPrimitive() from scripts. DrawPoints() accepts two tasty arguments, which sadly are not available for scripts in clean r412 - offset and zoom. That plus minimap bounds calculated earlier, allows to easily get pixel-size of minimap, resize, and move it around/stick to corner/etc without rebuilding whole thing.

Code: (c++) [Select]
SprMngr.DrawPoints( DRAW_PRIMITIVE_POINTLIST, minimap );

tada.wav

Obviously, doing all above every cycle is waste of CPU time, as majority of minimap does not change as long sceneries/walls doesn't. So if minimap should include critters/items/any other dynamic elements, they can be put into separate PointVec (updated every time) which will be drawn after the one with walls.



...wrote waaay more than i initially planned, but oh well. Majority is probably boring/obvious stuff, but maybe some detail would push someone in right direction.
« Last Edit: June 09, 2019, 05:11:59 am by Wipe »
Games are meant to be created, not played...

Offline adumbperson

  • Turn around in orbit!
Re: Working on intrface style...
« Reply #13 on: June 10, 2019, 06:44:33 am »
On my HDD only at the moment ;D
I'll throw a link here some rainy day (need to fix/finish few things first)... but i'm honestly not sure if it would be that useful. It's easy to get lost in UI stuff and comments barely exists at this moment, so better to extract the essence of a whole thing if anyone wants. While everything below is in C++, it should be possible to recreate everything in r412 dlls (and maaany older revs), or even ported to scripts.

To be sincere with you, my skill doesn't make me able to do advanced UI authoring. I'm mainly grinding (hardly) the mechanism by examples...
Can't wait to read your proto!

TL;DR:
- GetCoords() (FOHexMap.cs)
- GetField() (FOClassic.h/FOnline.h/HexManager.h)
- PrepPoint, PointVec (SpriteManager.h)
- DrawPoints() (SpriteManager.cpp)



We start with small function to deal with hexes. It's simplified version of GetCoords() - converts hx,hy to 2d space resizing each hex to 2x1, where left part is a place for pixel, and right part is a null space for hexes above/below.

...

...wrote waaay more than i initially planned, but oh well. Majority is probably boring/obvious stuff, but maybe some detail would push someone in right direction.

Thanks a lot for instructions.
Dumb or right... ez.