sprites: request to devs

[paradoxharbinger]

i believe there was an image file a while ago which had the sprites used for the dom2 maps, i was wondering if we could get a similar image containing the dom3 sprites?

[Edi]

Kristoffer has made some posts to the effect that he would be willing to release the sprites. I'll let him confirm that, though.

Edi

[Kristoffer O]

I'm willing. Just need to focus http://forum.shrapnelgames.com/images/smilies/happy.gif

[paradoxharbinger]

excellent thanks.

i'd like to package them in with my map generator, so people don't have to try and find their own, if you wouldn't mind that is?

[paradoxharbinger]

Kristoffer, any new info on getting those sprites?

[Aristander]

Just a friendly bump.

[Kristoffer O]

Ah. thanks for the bump. JK has shown me how it's done. We are making a zip now.

Sprites are just dumped from the army files and thus unsorted and unedited, meaning you will find old and ugly sprites that are not used any longer. THere is no way of knowing which sprite is which until you open it. In short, a renaming project is probably needed if they are to be useful for most modders.

Still it's a beginning.

[Kristoffer O]

3550 unsorted sprites http://forum.shrapnelgames.com/images/smilies/happy.gif

[Foodstamp]

THANK YOU!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

[Gandalf Parker]

Wow, if you look at them in full screen mode its really easy to see which ones have been updated from the old days, and which ones havent.

Thank you for this. Maybe we can get the online library updated with them now that we have the attack sprites also.

[Ballbarian]

Thank you Aristander for bumping this!
and a big THANK YOU! to KO for sharing these with us! http://forum.shrapnelgames.com/images/smilies/happy.gif http://forum.shrapnelgames.com/images/smilies/happy.gif http://forum.shrapnelgames.com/images/smilies/happy.gif

[paradoxharbinger]

thanks Kristoffer and Aristander

to all, expect a quicky update for the MapGen with sprites added sometime soon

[BandarLover]

You have made countless modders very, VERY happy.

[HoneyBadger]

I'm happy

[DrPraetorious]

I'm ecstatic.

Anyone know of a good (prefereably free) program for previewing .tga files? Opening them one at a time in GIMP is actually kinda a pain.

Do we want to split this up and coordinate renaming efforts? If we split it ten ways, each of will only have to rename 355 sprite files.

To get the ball rolling, I'll volunteer (and start working on) army5_*.

For ease of book-keeping, I propose the following renaming scheme:
army5_-0.tga
is a picture of a brown bear, so I will rename it:
army5_-0-BrownBear1.tga

army5_-1.tga
is, unsurprisingly, the other sprite for the same unit.
army5_-0-BrownBear2.tga

Note the additional "-" and the BouncingCaps.

So I'm going to start renaming army5, I'll post it as an attachment when I'm done, and if everyone claims a subset of files here and then keeps to my arbitrary conventions we should have a more useful archive post-haste.

[DrPraetorious]

One more suggestion - if you don't know what a sprite is (exactly), put double parens () at the end of the filename.

e.g.:
army5_-3-BlueCloud().tga

Some of these will probably be unused sprites. This way we can work out details (which Pan is which, etc.) later.

[paradoxharbinger]

drP, use irfanview (http://www.irfanview.com/)

[DrPraetorious]

One more change. The 1 and 2 after the unit description are redundant since the two poses are always adjacent, so I've stopped adding them.

[DrPraetorious]

PB, thanks! Irfanview works great.

Here's army 5 with preliminary labels.

I think, actually, that labels reflecting the armament and description of the unit are probably going to be more useful to modders, rather than the name of the corresponding in game unit, especially for humanoid troops.

[Gandalf Parker]

Irfanview also has a module you can download for it which will let you view RGB files. That way you can easily view ALL of the maps in the maps directory.

[Ballbarian]

Just got home... Is there an easy way that anyone has seen to tie a unit number(s) to a sprite set? I am just a day or two from completing my province editor. It currently includes data filtering for units, items and magic sites (thanks to Edi's fantastic db!) and links to the online unit list graphics, but I would like to include the sprites in a preview of some sort. http://forum.shrapnelgames.com/images/smilies/wink.gif

[Gandalf Parker]

They might be kindof in order but I didnt verify that

[Ballbarian]

I gotta say that complaints about the graphics of dom3 really sell the beauty of all of these unit sprites short. Just browsing them en masse like this truly makes me appreciate the beauty of them. The time and care that has gone into making graphics with such detail and character while at the same time keeping the canvas and memory use so small deserves praise. Not to mention how this format makes it much more user friendly for modders and tinkerers. (Is tinkerers a word? http://forum.shrapnelgames.com/images/smilies/happy.gif )

Thanks again KO. http://forum.shrapnelgames.com/images/smilies/smile.gif

[DrPraetorious]

They really expose the crassness of what you get in a lot of videogames nowadays.

Certainly, it's nice to have a lot of pixels and polygons to work with, but if someone can actually draw (disclaimer - I cannot) they can convey the character of something with a simple line or, in this case, with a relatively tiny number of pixels.

From a la-de-da hoity-toity artistic standpoint, the ability to do good pixel art (as we see in dom3) is really quite refined.

I can do this pretty quickly so I'll just go ahead and label all the sprites myself. I'm not going to have time to match them to unit #s, I'm afraid, but I'll at least include a useful description of each sprite.

[Sombre]

If we didn't already have perfect sprite extraction (minus the attack sprites) this would be more of a big deal, but it's still pretty huge.

Hopefully this will encourage people to have a go at their own graphics for mods.

[paradoxharbinger]

i think that i might finish up a mod of my own now that i have unit sprites

[Kristoffer O]

Thank you! http://forum.shrapnelgames.com/images/smilies/heart.gif

[Kristoffer O]

Here comes some mapstuff.

[paradoxharbinger]

thank you tha
nk you thank you thank you

[DrPraetorious]

I can't find the clockwork horror. Has anyone seen it? I must just not be seeing it for some reason 'cause I've scrolled through the list a couple times.

[lch]

army7_-274 and 275

[Ballbarian]

KO,
Is there any way we could get a cross index of some kind matching sprite files with unit numbers? I did a quick program to rename sprite sets to a unit number format in the hopes that the sprites would appear in a 0 based order, but the results are mixed. Many match, but many are out of sorts. Any help would be very much appreciated. http://forum.shrapnelgames.com/images/smilies/happy.gif

[DrPraetorious]

If you've got even a partially-correct list, go ahead and post it. We can fix the errors as we find them.

Actually, I think a list indexed by sprite-description might be more useful than one indexed by unit-#.

I was thinking of this hierarchy:
nation / type (cavalry, infantry, etc.) / armament-type / sprite

[Kristoffer O]

Unfortunately no such luck. Units are more or less given sprites in order, but some units share sprites and some sprites have been replaced by later sprites making it all very unorganized.

[Gandalf Parker]

It does however make it interesting to see the growth of the game. The order that nations, pretenders and summons were created in.

[Kristoffer O]

More or less. Some remakes are made as overwrites, others are added last (unit data changed to point at a new sprite).

[Ballbarian]

DrPraetorious said:
If you've got even a partially-correct list, go ahead and post it. We can fix the errors as we find them.

Actually, I think a list indexed by sprite-description might be more useful than one indexed by unit-#.

I was thinking of this hierarchy:
nation / type (cavalry, infantry, etc.) / armament-type / sprite



Oh, I agree that your project will prove very useful to modders looking for sprites to match their creations. My hope was to match sprites with unit numbers for use in tools like my province editor that I am working on.

As far as a list goes, my program only pulled out the base unit sprites (leaving the attack sprites behind) and did a simple renaming of the tga to a "00001.tga" format. I started a spreadsheet, but didn't get far enough to justify uploading it. If/when I go back to it, I will refine it a little to get as close as I can with minimal work and then I will share it with you and anyone else interested.


KO,
Ah well, thanks anyhow. http://forum.shrapnelgames.com/images/smilies/happy.gif
I didn't want to spend a lot of time reinventing an index that you might already have available.

[Gabriella]

This is a collage with all (or well at least almost, I might have missed a few) the sprites. (Excluding attack poses)

Not organized in any way but just nice too look at. http://forum.shrapnelgames.com/images/smilies/happy.gif

http://www.mediafire.com/?2g1dojxibrs

[llamabeast]

Gabriella - that is absolutely fantastic! Thanks so much. That's really great for finding sprites to use/modify for mod units.

May I ask, how did you do it?

[lch]

Dunno how Gabriella did it, but Imagemagick is quite useful for stuff like that.

P.S.: Some of those sprites are attack sprites, but it's nonetheless a nice collage to look at.

[Gandalf Parker]

ImageMagick will also generate a handy thumbnail-to-file page. But I couldnt figure out what file I would want a thumbnail to click to. Maybe the old sprite library which was made with screenshots of the units info screen? Or a zip of just that units sprites? (but that seemed to make the ripping off of the game images too easy)

[Gandalf Parker]

They are viewable online here...
http://www.dom3minions.com/sprites/

[chrispedersen]

Hey, with all due respect.. I think this is the wrong way to go about it.

Why not dump each .tga into a database entry, (web enabled) with columns for searchinng, and description.
But the neat thing would be that then people could update the info a few at a time whenever they wanted...

like 307 - Sphinx...
5-105 Large Air Elemental2
With everyone working on it a few at a time we'd be done in no time....

Chris

[llamabeast]

If you have any idea how to do that chris, please go ahead and set it up. I'm sure we would all help complete it.

[Gandalf Parker]

Sure. A SQL file. Relational Database.
One index key would be the unit number as is used in maps and mods.
Another index key would be the text name of the unit.
And another for the .tga file since the other two keys wont cover all of the images (some are partial, old images no longer in use, new images not yet in the game, or after being attacked like mount without rider).

A web interface, probably PHP, could be written to allow updating. Kindof like a WIKI interface. It should allow for sprite #1, sprite #2, other sprites for that unit, and "also see" links for variations of the same unit. Also a spot to link to the screen capture of the info screen on a unit. And the text of that screen typed in so that it can be cut-and-pasted into peoples projects. And a tie-in to Edi's unit database.

[Edi]

If somebody wants to tie it into the Unit DB, go right ahead. You're likely going to have to use the BaseU sheet from that, because only the Base<X> sheets contain purely elemental data. The display pages use spreadsheet function to produce the final results.

It'd actually be easier to get the display results with a SQL DB, but my skills in that department are sadly lacking. Having a reference for the sprites would be awesome. If anyone feels like taking it up and has questions about the unit DB, post them here or in the Dom3DB Discussion thread or send them by PM.

[DrPraetorious]

A tie in to display, and even better search on, weapons, size+flight+animal+native protection value (a stand-in for race), and mounted-ness would be much awesome.

[Wikd Thots]

Gandalf Parker said:
Sure. A SQL file. Relational Database.
One index key would be the unit number as is used in maps and mods.
Another index key would be the text name of the unit.
And another for the .tga file since the other two keys wont cover all of the images (some are partial, old images no longer in use, new images not yet in the game, or after being attacked like mount without rider).

A web interface, probably PHP, could be written to allow updating. Kindof like a WIKI interface. It should allow for sprite #1, sprite #2, other sprites for that unit, and "also see" links for variations of the same unit. Also a spot to link to the screen capture of the info screen on a unit. And the text of that screen typed in so that it can be cut-and-pasted into peoples projects. And a tie-in to Edi's unit database.


I guess I get to play Sombre this time.
OK Gandalf, why don't you go ahead and DO it?

[Sombre]

Ah but this time Gandalf hasn't said he wants it done, just talked about how it could be done. Can't expect people to do things they're not actually interesting in seeing. I only say 'DIY' when someone is asking others to do something they want when they could just as easily do it themself.

[Gandalf Parker]

Actually I did my part. Thats what Ive been doing for decades at work. Initial layout, MAYBE up to the point of Psuedo Code if thats what is needed to make it clear. I only code something up to the point of proving it can be done. The hacking part is fun, after thats its just work. I pass it on for someone else to make pretty. For instance, if I was really interested in getting this then I would outsource it to India for a few bills.

Its like moderating. I dont have to come up with answers. I just have to keep the conversations going. If I DIY'd all my ideas it wouldnt be nearly as good as spurring community effort. Many major projects here have me credited in the readme for the idea that are MUCH better than I would have made. http://forum.shrapnelgames.com/images/smilies/happy.gif

[paradoxharbinger]

well i'm pretty handy with the sql scripting, and the scripts for this project would probably be relatively simple compared to some of the stuff i do at work, so if someone provided the actual database, i could write the scripts for it

[Edi]

All that needs to be done is for somebody to match the sprites to units (can be a separate table, and in fact, should be). For the rest of it (armor, weapons, unit base stats), the download link is in my sig. The spreadsheet is in both Excel and OpenOffice format and if you take the BaseA, BaseW and BaseU sheets, those are the elemental statistics and can be directly imported as DB tables.

The queries would be fairly simple and only need the formulas to calculate stuff based on that data. If you want, I can spare the time to give you the formulas, it was squeezing those formulas into spreadsheet function format that was the biggest b*tch when making the Dom3DB.

[paradoxharbinger]

the first thing that really ought to be done is decide on the structure of the database. we ought to have one table, call it tbUnitSprite, with one row for each unit, and a column for the unit number and two blob columns, one for each of the units sprites. this table would be populated from the start and would for the most part be finallized from the start. other tables would link off of it and those would be the tables that would be incrementally updated by the community to get this thing finished.

just my two cents on the direction to take it

[Edi]

Actually, what you should use as the base tables are the BaseU, BaseW and BaseA tables from the Dom3DB (name them whatever you want, though), because those are complete and accurate, barring the known issue of Firelord not having magic (F2) listed.

Alternatively, do the tbUnitSprite table in a spreadsheet and then copypaste the contents of the BaseU table so that the sprite columns are either right after the unit number column or the unit name column and use that as base.

OR, list unit sprites on a separate table with sprite number column being from 0 to wherever and add spr1 and spr2 columns to the BaseU table and then fill those with the appropriate entries.

The Dom3DB was designed with basic DB design principles in mind so that if desired, it could be ported to SQL almost as is. Besides, not all of the sprites are used and some have been changed, so having them in a separate table and having each unit have two columns for the normal and attack sprites that reference the sprite table would make for a more structurally sound database.

However, bear in mind that I do NOT do database work at my job, so if you can take those suggestions and improve on them, feel free to do so. I'm coming at it from the angle that since the unit database itself is basically complete already except for the sprite information, it would be a complete and utter waste of effort to duplicate that from the ground up when just a minor tweak would get the whole thing going.

[paradoxharbinger]

i'd forgotten about there being sprites in there that arent in the game. basing the db off of edis tables and then having them reference another table with the sprites in it sounds like a good plan. i cant remember how you handled special abilities (ie regenration). special consideration might have to be given to them since not every unit even has them let alone the same number of them.

[Gandalf Parker]

Keep in mind the headache that will be caused by units with more than one form. 2 forms, 3 forms, whats the max? 5?

[paradoxharbinger]

so we'll have an intermediary table between the actual units and the sprite table. this new table point to a unit and to any sprites associated with it. no problem.

[Edi]

Paradox, take a look at the Dom3DB. Once you take a look at the BaseU page and the glossary, the structure should be fairly clear for you. It'll be a lot easier to also plan the rest of the SQL DB that way.

The way regeneration works is a percentage of hit points, rounded up (so HP 10 is regen 1 and HP 11 is regen 2 etc). The percentages weren't too difficult to figure out from the units. Resistances, forge bonuses and other such are also percentages, which means they are between 0 and 1 after you strip the spreadsheet formatting out. All special abilities that are either on or off (like forest, mountain and swamp survival or flying) are 1 or 0.

Not quite all abilities are listed (such as Belial's corrupt commander, those would be in the Special column, which has all sorts of things that did not warrant their own category.

Awe values should default to -1 (unit does not have it) in the SQL DB and fear should default to null.

[paradoxharbinger]

from a database perspective, i dont like that baseu table WAAAAY too much wasted memory for the abilities, though i will admit that it would be fast to run a query against. that's often the trade off that has to made with this sort of stuff. i don't know how to make a decision on that trade off, as my experience is with a corporate database that is just in the other room, so speed is not something that i am too terribly concerned with when writing queries. if i were to design it myself, and didnt have the speed of the internet to factor in, i would probably do something similar to what i suggested for the sprites. one table has a row for each skill (this would allow for descriptions to be stored for each skill as well without taking up a horrendous amount of memory) and a second table is a map between units and the skills.

it could be queried like this
<font class="small">Code:</font><hr /><pre>

select UnitID
from tbUnit
inner join tbUnitSkillMap
on tbUnit.UnitID = tbUnitSkillMap.UnitID
inner join tbSkill
on tbUnitSkillMap.SkillID = tbSkill.SkillID
where SkillName = "some skill name here";
</pre><hr />

[Edi]

If you want to do it that way, is it possible to chop the BaseU table up to get the required tables? I can also ask my friend Kaljamaha to pitch in on this, he works with SQL stuff all the time, perhaps he could come up with some ideas.

[paradoxharbinger]

all im suggesting is that taking this sort of approach might save alot of space in a database, and since space = $ on the internets...

it probably would not be too difficult to extract the data we'd need to do it.

by all means, go ahead and talk to your friend, any extra incite in how we should proceed with this would be welcome

[paradoxharbinger]

well this went dead....

so i went ahead and started to design the dom unit db, i'll have some more on it in a bit

[Gandalf Parker]

Ummm I ended up with a file of them. Unfortunately now I dont remember how I got it and what the stipulations were. Let me bounce a note off of Kristoffer

[paradoxharbinger]

well, here's how i would lay out the db. common stats, those that all units, armor or weapons have in common, would be in thier respective tables (tbUnit, tbArmor, tbWeapon) though uncommon abilities, such as flaming or poison, would be in tbAbility and linked to through the various ability bridge tables. ultimately, each unit is linked to weapons, armor, sprites and miscellaneous abilities through various bridges so that units which have similar abilities need not have duplicate records of that ability, thus saving a lot of space.

i think i may work on incorporating this into the unit maker, but i haven't quite figured out how the databases work in c# yet.