2D graphics assets?

lindsay40k

Emperor
Joined
Mar 13, 2009
Messages
1,696
Location
England
So, there's a fair few mods that use static portraits for leaderheads. I was wondering, is it possible to give these frame of animation? To have different faces that appear in place of the various 3D animations?

And further from that, is it possible to have unit and even building & resource assets that are made up of 2D images - effectively, sprites on the map field, like a 90s game? Think Powermonger, Dungeon Keeper, Mario Kart 64...
 
So, there's a fair few mods that use static portraits for leaderheads. I was wondering, is it possible to give these frame of animation? To have different faces that appear in place of the various 3D animations?
I don't know enough about leaderheads to tell if multiple still images are possible. However I do know that stills use way less memory and because of that would be preferable if you have lots of leaders. Also leader graphics are loaded from disk when needed. Pak files are loaded into memory at startup. This means if leader graphics are packed, they are loaded into memory and never used because they are read again when needed. This means leaderhead graphics should never be in pak files.

And further from that, is it possible to have unit and even building & resource assets that are made up of 2D images - effectively, sprites on the map field, like a 90s game? Think Powermonger, Dungeon Keeper, Mario Kart 64...
Why not mention the ultimate game using 2D sprites on the map, which would be Civilization, later known as Civilization 1?

As for the question: No, it was to be 3D. However nothing prevents you from making a unit, which is just a cube, or even just the top plate of the cube and then use a 2D image as texture for that one, which would result in looking like a 2D image being put on the map.

I know when civ4 first came out, some games used this approach to make a few polygons to make a flat object to fill the entire screen and then draw texture on that one. The idea was that a game could have no GPU code whatsoever and use the CPU to generate the 2D screen, yet openGL helped to make it cross platform and allowed the GPU to resize to match monitor resolution, hence removing the CPU intensive resizing task from the CPU. It worked quite well, but there are better tools for that purpose today.
 
I didn't mention Civ 1 as that has a 2D field made of bitmaps. The other games have sprites on a 3D polygonal field. (Settlers would be an interesting example of a 3D field made of bitmaps, but that's a digression too far.)

I would have thought it was possible to make sprite units and buildings? Sprites are already used for unhealth miasma, smoke, resource icons, city info bars, and - as far as I can tell - promotion blue glue? The game engine knows how to use a 2D asset in 3D space, including one on the map surface, and presumably there's mods which add more for flames and such.
 
The main screen is a mix of 2D and 3D. The bottom panel and the buttons on top are 2D widgets and buttons coded in python. They are put on top of the 3D rendered map. What you are asking is something 2D to be stuck to the 3D map, meaning it moves with the map as you scroll. The city billboards (that's the name in the source code) are stuck to the map and are viewed as 2D. Since the exe handles this, we will never know for sure how it's done, but the most likely solution is to make an invisible planet to put 2D textures on. The icons on the billboard would be part of this because it's just made bigger than you can see with 100% transparent top and bottom. The icons (riot etc) are actually GameFont, meaning they are viewed as text and when certain characters are written, it will use art from GameFont instead. In other words it's just a string. There is the yield icons on the plots, though that too is handled by the exe and presumably in the same way.

I really don't think you can place anything on the map, which you don't make in 3D, even if you can make a flat 3D model to look 2D.
 
That's helpful information, thanks.

How about this: units can have a glowing blue aura when they promote, right? GPs have an aura as well. This aura seems to be a sprite. So, the game engine can apparently display a mobile sprite that the player can move around the map. What if the unit 3D model were stripped down to the bare minimum needed to be functional, it's polygons given invisible texture, and a sprite pegged onto it using the existing system?

If there is no need for the sprites to themselves have an 'aura', then we don't need to worry about what happens when two sprites are pegged on the point. It would just need a single asset for a 'ghost' 3D model, used by all the units; and then, each unit - instead of adding the blue aura sprite if it has a promotion ready or is a GP - has a specific 'aura' sprite that is actually a pixel art Warrior or Settler or Ivan The Terrible or whatever?

Does this sound workable?
 
I have created a leaderhead using variable 2d images some time ago:

https://forums.civfanatics.com/resources/variable-static-leaderhead.17343/

There might be something already build into Civ4 for this already as well. Later I notice that in the "Beyond the Sword\Assets\Art\Leaderheads\Charlemagne_Scenario" folder, there are two dds files "Pope_Angry" and "Pope_Happy". But never went deeper into that.

For the 2d units, I just slapped together a simple unit using the nif billboard funtion, which is for example also used by the arrow sprites so that they are always seen from the side. Looks okay so far:
Spoiler :

2dunit-jpg.478339


Of course there is no combat animation or other fancy stuff. The xml code for the unit looks like this (it replaces the lion at the moment):
Code:
        <UnitArtInfo>
            <Type>ART_DEF_UNIT_LION</Type>
            <Button>,Art/Interface/Buttons/Units/Lion.dds,Art/Interface/Buttons/Unit_Resource_Atlas.dds,6,5</Button>
            <fScale>0.8</fScale>
            <fInterfaceScale>1.3</fInterfaceScale>
            <bActAsLand>0</bActAsLand>
            <bActAsAir>0</bActAsAir>
            <NIF>Art/Units/2dunit/2dunit.nif</NIF>
            <KFM/>
            <SHADERNIF>Art/Units/2dunit/2dunit.nif</SHADERNIF>
            <ShadowDef>
                <ShadowNIF>Art/Units/01_UnitShadows/UnitShadow.nif</ShadowNIF>
                <ShadowAttachNode>BIP Pelvis</ShadowAttachNode>
                <fShadowScale>0.0</fShadowScale>
            </ShadowDef>
            <fBattleDistance>0.35</fBattleDistance>
            <fRangedDeathTime>0.31</fRangedDeathTime>
            <bActAsRanged>0</bActAsRanged>
            <TrainSound>AS2D_UNIT_BUILD_UNIT</TrainSound>
            <AudioRunSounds>
                <AudioRunTypeLoop/>
                <AudioRunTypeEnd/>
            </AudioRunSounds>
        </UnitArtInfo>
The fScale is set to 0.8 since the 2d texture is not covering the whole 2dunit_texture.dds file. If a pixel art is used that is covering the whole file, something like 0.45 should work best.

I have used a 64*64 dds file, since it fits the Civ2 sprite best. But there should be no problem using bigger sizes like 128*128, 256*256 and so on. The invisible parts are defined in the Alpha channel as usually.

Enjoy. :)
 

Attachments

  • 2dunit.jpg
    2dunit.jpg
    147.2 KB · Views: 902
  • 2dunit.zip
    2dunit.zip
    2.2 KB · Views: 131
AWESOME!

I grew up with Amiga and my CAAD course was 90% photoshop & drawn animation, 3D asset creation that's outside my skill set has been the main thing putting me off mod creation.

...could this also be done with trees, resources, and buildings? I have a dream of a 16bit styled mod...

Also are transparent elements workable, like for shadows and flames and ray guns?
 
In theory this nif should be able to replace any other nif, be it units, buildings or environmental things like trees and resources. The size might need adjustment though, but that should be possible using the fScale setting.

Transparent elements are certainly possible as well, just use a shade of grey in the Alpha Channel instead of black.

I guess it would also be possible and do animations using different sprites in one dds file.. I know that for example the Gravebringer in the Afterworld scenario scrolls in parts of its body through a dds file (Beyond the Sword\Assets\Art\Units\Afterworld_Gravebringer). Should be possible to change that to steps, but never looked deeper into that.
 
I have used a 64*64 dds file, since it fits the Civ2 sprite best. But there should be no problem using bigger sizes like 128*128, 256*256 and so on.
I would say the bigger the better unless you change all the graphics because in the screenshot the 2D unit looks blurred compared to the vanilla one. Having said that, what you provided is awesome even if the goal isn't 2D. It means you can use the button for graphics, which would work well as a placeholder during development. If the button is just some image you took from the internet, then you can try out a bunch of units, playtest and then add and remove as needed and not spend time on graphics until you are more certain you want to keep the units as they are.
 
Certainly, the Civ2 sprite was just the first thing that came to mind for testing. I think a fully used 128*128 file should be used as a minimum for acceptable quality.

Using it as a placeholder seems to be good idea as well.
 
Hmm. Blurring could be an issue. Guess there's not a lot can be done about that.

If, say, a 32x32 sprite were drawn with 8x8 pixel blocks and formatted as a 256x256 asset, might that give it crisper appearance?

The nearest thing I can think of to the aesthetic I'm thinking of is Advance Wars:

Spoiler :
advancewarsds.jpg


Also, the title screen to Yoshi's Island is a similar concept to what I have in mind:


But I'm pretty sure you've taught me what I need to know to start testing things out. Thanks a lot!
 
No worries.

Using 4x4 or 8x8 pixel blocks should solve the problem or at least reduce it quite a bit I think. Maybe using no MIP maps in the dds file might also be helpful.
 
Hmm. On the one hand, no MIP maps would increase graphical strain... BUT this is likely going to be offset by there being a lot fewer animated textured polygons.

I'm quite excited, can't wait to clear my schedule for some modding :D
 
Is there any reason why you couldn't have animations with this? Seems to me like it would be a simple case of having a key framed timeline that swaps between a number of sprites to form a short clip. I know that changing textures is used by various animations in the game already like damage textures. I can't experiment with it right now since I am too busy with other stuff but someone should give it a try.
 
Pretty sure you can, just would need some work to look into. Creating specific kf files would be the way forward I guess, one could also add sounds in that way.
 
It would certainly be nice to try. I'd do it but I don't have the skill to create custom .kfm files yet. I've barely mastered importing a single animation and than editing it.

This said, given how easy .kf files are to edit in nifscope the thing to do here would be to create a generic unit and .kfm file with the appropriate animation states that anyone could than edit for his units. They could in fact all be identical .kf's since all the art is in the graphic files and none is in the animation. But again, that is way beyond my skill grade.

Can't help but theorize due to being a programmer and like I literally live for designing things like this.
 
So it might be feasible, but wouldn't be a simple case of using an animated .gif?
 
So it might be feasible, but wouldn't be a simple case of using an animated .gif?
That wouldn't really be a solution for several reasons including but not limited to the fact that we don't know if CIV can handle gifs as it is a compressed data format AND the fact that it would set the animation onto an infinite loop which is undesirable.

Functionally the .kf I am describing would actually be quite easy to make. It's literally just a single modifier that changes the texture of the billboard at every X frames. I have worked with these on existing .kfs for existing units. I just don't know how to do it from scratch.
 
Back
Top Bottom