Home » SIRTECH CLASSICS » Jagged Alliance: Unfinished Business » Tools and Guides Repository (Archive) » Improving Original JA2 graphics
Re: Improving Original JA2 graphics [message #183609]
|
Thu, 01 May 2008 00:24
|
|
the scorpion |
|
Messages:1834
Registered:September 2004 Location: CH |
|
|
pfm
think of it: there are many weapon classes and there are 3 bodytypes
we can do at least 3 different sets of animations before anything is redundant (truly needs to be added by code)
e.g. big male --> shotgun , female ---> submachinegun , Normal male --> sniper
(just examples)
then there are shooting stances, brth stances and running stances, 3 times, standing, crouched, prone... there could be a lot of work done before any coding is involved to "add" things.
(assuming we're ready to overwrite the default anims for the time being)
yes, one question was raised, seeing much of a difference at higher resolutions:
to be honest, only the frames where the weapon is shown straight (see my above examples) allow for a lot of detail to clearly show what weapon class we use.
but difference between submachinegun and sniper rifles for example will be nicely visible in 800x600
let's assume that work is done without layers first because no coder has expressed interest in adding it yet. If layers would be added later, maybe the "non-weapon" part of the pictures that were made without layer system could still be erased?
i mean the new weapons must be drawn anyway, whether there's a merc around it or not... doesn't seem to be that important at first sight...
Report message to a moderator
|
Sergeant Major
|
|
|
Re: Improving Original JA2 graphics [message #183611]
|
Thu, 01 May 2008 00:31
|
|
lisac |
|
Messages:92
Registered:July 2006 Location: Austria |
|
|
the scorpioni think you shouldn't think about "all" animations necessary for new weapon classes. If you think of a typical battle, there is only a few animations that are used often and that focus on the gun, these are limited to basicly shooting, standing idle and running/ walking.
The weapons in most other animations are not very prominent and wouldn't be shown much in battles so for a long time, placholder could be used there.
Right, exactly my thoughts... However, adding a few armor variations to each merc (F,S,M) could cause the ANIMS directory to get really heavy.
Luckily for us, we don't need to add those right away. A few variations with weapons (like those you've shown in your previous post) would be a step forward and a definite improvement over the current system.
Now, we need a coder to answer a few simple questions...
1) 8-char filenames?
2) Switching the animation sets according to the currently equipped weapon?
P.S.
I'm about to make a female character next week and try to rig it (prepare it for animations). The next goal would be remaking the original female sprites using the current "sprite colored by palette" system... Let's see what can be done with it
Report message to a moderator
|
Corporal 1st Class
|
|
|
Re: Improving Original JA2 graphics [message #183613]
|
Thu, 01 May 2008 00:35
|
|
PFM |
|
Messages:22
Registered:July 2006 Location: Czech Republic |
|
|
the scorpionpfm
think of it: there are many weapon classes and there are 3 bodytypes
we can do at least 3 different sets of animations before anything is redundant (truly needs to be added by code)
e.g. big male --> shotgun , female ---> submachinegun , Normal male --> sniper
I am aware of that. there are pistols, SMG, shotguns, rifles(assualt and normal), sniper rifles and LMG. That's 6 times (stand, crounch, lie) times (idle, walk, run(only stand), hit, shoot, jump, climb, water etc) So we come with 6 x 3 x 6 for the begining and in 8 directions = 6 x 3 x 6 x 8 equals 864 animations. Am I right? :gaga: Or am I crazy? :crazy:
probably both :placard:
Report message to a moderator
|
Private 1st Class
|
|
|
Re: Improving Original JA2 graphics [message #183616]
|
Thu, 01 May 2008 01:00
|
|
the scorpion |
|
Messages:1834
Registered:September 2004 Location: CH |
|
|
that's discouraging PFM ;-/
now mulltiply this 864 with 13 average animation frame number and you get an approximation of what the workload would look like ;-D
but then, it has to be taken with a grain of salt: "getting hit" doesn't show a weapon, jumping doesn't show a weapon, swimming doesn't show a weapon, climbing and dying (these anims are sometimes over 200 very detailed frames long) don't use a weapon etc.
this is why doing a complete set of weapons is easier than a complete set of armour
yet armour, as well as weapons, doesn't matter in each and every situation.
e.g. when your character sleeps, when your character dies, climbs or falls from a roof, there's little need to show armour.
maybe we could up some examples. Like in my screenshot, it's a black hat and a coat ;-D
Lisac:
i see good potential in using palettes. Do you remember my suggestion to have palettes from armour only apply to the bodypart where they are worn?
e.g. pants to the "pants" part, vests to the "vest/ shirt" part and headgear on the haircolor (lacking anything better)
this would allow to combine 4 camo patterns with 3 bodypart in many different ways.
armour class could also be shown by camouflage pattern/ colour ;-D
i mean every char has colors defined for bodyparts, so i should not be sooo tricky to have camo defined by the bodypart as well. it would in fact even make a lot of sense.
Report message to a moderator
|
Sergeant Major
|
|
|
|
|
|
Re: Improving Original JA2 graphics [message #183669]
|
Thu, 01 May 2008 17:03
|
|
the scorpion |
|
Messages:1834
Registered:September 2004 Location: CH |
|
|
for how long has the thread been active before?
how much coder feedback did it get?
i think whoever has the lead on the idea (Lisac i think) would have to individually contact the coders.
i only know that bugmonster managed to implement custom animations in ja2005 and 1.13. if he's not around, there's probably nobody who has taken a lot of research into the animation engine.
Report message to a moderator
|
Sergeant Major
|
|
|
|
|
|
|
|
|
Re: Improving Original JA2 graphics [message #183768]
|
Fri, 02 May 2008 11:00
|
|
PFM |
|
Messages:22
Registered:July 2006 Location: Czech Republic |
|
|
Berserk00644maybe we should work on other anims for starters, like maybe one new death animation for a knife attack to neck... if we did it from all 8 directions at lets say 13 frames or so thats 8x3x13 = 312 thats alot less then the 800 or so above... then if its easy to add into the game, then we could work on adding all the guns...
imho it seems like to much work to make all these gun animations if nobody wants to even see if they can add them.
dont get me wrong i think it would be great to add them and armor, but maybe baby steps is the way to go with this project.
do you know how to make those animations? OR can you make them? Making them IS ENDLESS AMOUNT OF WORK!!! doing them pixel-by-pixel is worthless because you will spend weeks maybe months by making one animation in one direction.
other problem is implementation. adding NEW types of animation is a trisky one! (what the hell is trisky???? :gaga: maybe RISKY and TRICKY in the same time ) you need to define new animation and conditions which must be meet to use NEW animation. For example new "death-to-wall" animation. conditions:
1. must be played instead of "back death" animation
2. must be played only when WALL is behind the merc
3. I DON'T KNOW how is wall defined in the source code - is it the same as any "obstacle"?
3a. is WALL equal to ROCK? you don't want to play "bouncing of the wall" animation when merc hit rocks behind him with his legs, do you?
4. are death animations played random? (well they are played in right direction, but any other conditions?) I DON'T KNOW
and so on - more questions than answers
adding guns animations is easier!
1. we have all the animations we need - the only thing we need to do is "swap" M4/M16 style weapon with different one (AK style like Scorpion)
2. engine is already testing what kind of weapon merc holds in his hands. ADDing another types of "weapons"(I should say items, binoculars aren't a weapon, right? ) should be easy - I can try it by "watch and learn plus trials&errors" approach but I won't have much time next 1 or 2 months - university studies...
so I vote for additional weapon animations(ONE or TWO for the beginning - we can use scorpions BIG_MALE_AK and test it) unless we FIND A CODER who will take a look at animation part. I haven't found him yet!
binoculars...I was thinking about it. BUT(!!!!): how you will make those animations? lisac is trying to make animation by 2D->3D->2D approach(we need to have the same animation, not different one for weapons, differrent one for binoculars, different one for death etc) but I don't know how far he is. We can even change whole animations for new one, BUT WHO WILL MAKE THEM?
EDIT: grammar...
[Updated on: Fri, 02 May 2008 11:06] by Moderator Report message to a moderator
|
Private 1st Class
|
|
|
Re: Improving Original JA2 graphics [message #183772]
|
Fri, 02 May 2008 11:32
|
|
the scorpion |
|
Messages:1834
Registered:September 2004 Location: CH |
|
|
interestingly, there is a dilemma between
a) adding single new movements/ actions to the game that need new anims
like suggested in several threads e.g. here
http://www.ja-galaxy-forum.com/board/ubbthreads.php?ubb=showflat&Number=127403&page=1#Post182314
which would require a lot of unique new code
and
b) what is suggested in this thread where in similar ways as the existing code works just new anims, not new functionality should be added (where tons of new anims and still a lot of new, but not-so-specially-unique code is required)
personally i think either option provides quite some cool stuff. Either option seems hard to do.
--> dilemma
disadvantages
bloating filesize itself doesn't seem big an issue these days... but imagine we actually did the new weapon stuff. If then, a new movement is added, if it is with a gun, it would require 8 times as much work as it would now to completely add it.
so this is actually a very tricky issue overall, game-development wise.
maybe we should comfort ourselves to offering alternative animations first before we want to have them added to the game and see what we can come up with.
i'm especially curious as to the detail level that good artists like Lisac can achieve, especially for the smaller bodytpye animations. (you've seen my examples, a mediocre artist like myself can't achieve a lot of detail very easily there... and it is only one of usually 112 frames there)
Report message to a moderator
|
Sergeant Major
|
|
|
|
|
|
|
Re: Improving Original JA2 graphics – Sprite[message #183800]
|
Fri, 02 May 2008 16:47
|
|
Lt.Havoc |
|
Messages:34
Registered:April 2006 Location: Germany |
|
|
Well, what I trying to say was, that it is talked about how to improve the orginal, current graphics of JA2, wihch I think will take the same amount, if not more time then totally replacing the engine. I mean, every 2 or 3 posts I read how difficult it is to add new animations and whatnot and how the filesizes gets increased etc. and then wehn I say "People, why not use XYZ instead?" there is either no answer, or short answers like "No human resources avalibe". The whole thing wanst even discussed, no one of the devs even looked into the FIFE forums at all nor did anyone of the contacted the FIFE guys.
If you really dont like that idea, then just say it, say that my idea sucks ass and that I should go to hell, its that simple. There are more graphic artists and coders out there then you think, there are lots of forums where somone can ask around and get intrest in this project and whatnot, C and C+ are the standarts of game coding for years now, so you cant tell me there isnt a coder out there that dosent know about it.
I know they also have jobs and real life occupations, but thats typical for all modders out there and all mods. I dont know any single mod where the people are jobless bums that work 24h on it, so that isnt really the problem. With proper organisation and planning, the time issue can be sloved and no one says the coders and graphic artist have to work like slaves on it everyday in thier free time.
Yes, promotion of this project is a nessecary thing toi attract more people to it that can help imrpove the mod.
Report message to a moderator
|
Private 1st Class
|
|
|
|
|
|
Re: Improving Original JA2 graphics [message #183810]
|
Fri, 02 May 2008 17:20
|
|
the scorpion |
|
Messages:1834
Registered:September 2004 Location: CH |
|
|
discussing is fun, but moving a finger isn't huh?
meh, i can't code for shit, but i can tell you guys, modding gta4-to ja2 would solve all our problems forevah
i would be one thing if people that seriously can port ja2 to the FIFE engine would be suggesting and starting to do it, but looking as it is just the wet dream of a single forum person...
...what real chances are there?
Report message to a moderator
|
Sergeant Major
|
|
|
Re: Improving Original JA2 graphics – Sprite[message #183811]
|
Fri, 02 May 2008 17:25
|
|
Mauser |
|
Messages:756
Registered:August 2006 Location: Bavaria - Germany |
|
|
guys, just think how much work and time have gone into 1.13 project until now just that we got to the point we are now.
what do you think will it take in terms of worktime to port over the comnplete 1.13 projet to another engine and then redoing most of the graphics and animations, so we get a real visible enhancement out of it?
can you imagine, how long that might take and how many people would have to work on this, which all need to be coordinated?
i just sincerely doubt, that this can be done with the ressources we have now at our disposal.
but if someone could find and assemble another dedicated coding and graphics team from somewhere...
i really think we should restrain ourselves to things that can be realistically done with our current resources.
and concerning FIFe engine, please also remember that FIFe itself is a project in developement status and far from being a complete and stable base to build a game on. could you imagine the chaos of 2 projects in constant change to be merged together?
also we
[Updated on: Fri, 02 May 2008 17:42] by Moderator Report message to a moderator
|
First Sergeant
|
|
|
|
|
Re: Improving Original JA2 graphics [message #183818]
|
Fri, 02 May 2008 17:37
|
|
the scorpion |
|
Messages:1834
Registered:September 2004 Location: CH |
|
|
the "not moving a finger" comment was not aimed at you khor. i know you do/ did may things. The comment was aimed at people interrupting our custom animation discussions with their ideas of a "wet-dream-game", the crysis engine or whatever...
Report message to a moderator
|
Sergeant Major
|
|
|
|
|
|
|
Re: Improving Original JA2 graphics [message #183852]
|
Fri, 02 May 2008 19:52
|
|
the scorpion |
|
Messages:1834
Registered:September 2004 Location: CH |
|
|
guess different people are talking different issues here...
i think the one(s) who actually care for the fife engine should be pursuing this very promising approach as well as they can.
The others migth still do things to which they can contribute. Me, i can't and thus i won't contribute to the entire "let's port ja2 to engine xy" issue. So when i discuss a different issue, i'd like to be left in peace about the engine discussion.
it is adifferent matter and i think it has it's own thread, doesn't it?
Report message to a moderator
|
Sergeant Major
|
|
|
|
Re: Improving Original JA2 graphics [message #183877]
|
Fri, 02 May 2008 22:52
|
|
BirdFlu |
|
Messages:438
Registered:September 2007 Location: Lampukistan |
|
|
Quote:Yeah, but you people didnt even looked into FIFE at all. No one of you guys seemd to have posted a question in the FIFE forums and the thread link was posted more then once here.
Really?
mvBarracuda, FIFE ForumNo ja 1.13 devs contacted us directly AFAIK
Is a question on the forum not direct enough?
Quote:No human resources available.
Was there anyone else working on this, besides me. And since i am busy with another project right now, this one has to fall short.
I can't work on two projects at the same time. So, when i'm done with the other project i can start to work an this one again, unless someone else start before.
---
Anyway, i can tell you something about the graphics system. Basically speaking, there are video objects that represent video memory and hold
data like images or framebuffers. When you draw something you have to do three steps
1. Load image data
2. Blit (copy) that data into the framebuffer.
2. Delete image data.
Our image data is stored in sti files and every sti file can contain multiple subimages. An animation is such a sti file. So, an animation consists
of a number of images, but it has also some timing information attached to it, i.e. when a certain subimage has to be drawn.
The timing information for every animation is hardcoded and all image data for ane animation is in one file only. Thus the animation data structure in
the code only references this one file (or the loaded image data from that file). When you render an animation, you know which subimage you need
(because of the timing information) and you just blit that image into the framebuffer.
Now, if you would want to draw multiple layers, you would need a list or vector of "sti files" (ideally with an equal number of subimages).
And where you drew one subimage before, now you have to draw a subimage from all "sti files" in your list. When you change your weapon in the
game you also change one (or more) "sti files" in the list. Changing other animation control structures should not be necessary. And if your
datastructures can hold multiple image files they can hold only one file too, i.e. the one layer case is a special case of the multiple layer case.
So, we have to initialize an animation properly, i.e. find image files that belong together. Rendering should be straight forward. Changing weapons
and armor and stuff like that could be a little tricky, since these changes are executed somewhere outside the animation or rendering code.
Another tricky part is to ensure that you can work with one AND with multiple layers at the same time, otherwise you would have to redo all animations
(and then find out that there was a misconception somewhere and you have to redo all animations again after that misconception was fixed).
The determination which files "belong together" or are part a of a multilayer image is important too and we have to decide what the filenames should be
and where these files should be located in our directory structure.
---
So, on the one hand not thaaaaat hard, but still requires some (a lot) of work and some problem solving abilities when something doesn't work as described.
Report message to a moderator
|
|
|
|
|
|
|
|
Pages (12): [ 8 ] |
|
Goto Forum:
Current Time: Fri Mar 29 09:33:55 GMT+2 2024
Total time taken to generate the page: 0.02909 seconds
|