Great Masters of the Necropian Abyss: I SUMMON THEE!!!

[eyesodilated]

UPDATE:



I am closer than I have ever been to completing this, hopefully I can send you a finalized imp file soon.

The problem of the HOTSPOT selection area was solved but only to cause a WOBBLE problem. The WOBBLE problem is where I have been stuck for years now. The solution I came up with sounds a lot simpler than it was to implement. What I know recap:



I know the frames must be the minimum size possible to avoid the HOTSPOT issues

I know the frames all being cropped different sizes to fix the HOTSPOT issue cause the WOBBLE issue

I NOW know that I must CENTER all the frames to the STAND frame in reference to the original sprite frame's center and NOT the cropped frames' center



By taking note of the ORGINAL center of each frame (@ 256px,256px) into account rather than the mathematical center of the cropped frames the WOBBLE issue appears gone!

This is painstakingly tedious but the hardest part was getting down the workflow. Now that I have a pipeline I can finish the whole sprite. Also important, it seems LOMUT cannot compile an imp file if you have any of the images you are compiling open or running in another program pretty much confirmed.



I use GIMP, which is a free version of photoshop basically, to create layers. GIMP is really good at letting me crop a set of frames together at the same time, preserving the original centering. Then I have notes of each frame's TRUE CENTER which is at (256,256) and for the most part is on the bottom pixel of the dwarf's right boot give or take a pixel depending on the action. Since I am trying to be precise and not estimate I take note of each action's center, ex: melee_attack, rally, etc. for every frame. I then combine this knowledge with the CROPPED frames to TRULY CENTER the frames as close to the original sprites. GIMP allows me to change the CANVAS size and RE-CENTER each frame to adjust for the discrepancy created when I CROPPED the frames down to minimal sizes.



For instance, when take the single 00-STAND frame it is 38*54 but when we take the MELEE_ATTACK-00 frames as whole, the dimensions' extreme are 48*84 because the axe and its shadow are very large. By layering these frames on top of each other in GIMP, I can then adjust the MELEE_ATTACK original CENTER PIXEL to line up with the STAND original CENTER PIXEL by adjusting the canvas size a few pixels, in this case it was about five pixels on the X-Axis.

I should also state that I am cropping each action library to a frame size that is the smallest possible area that fits all the frames of that specific library. The MELEE_ATTACK action library for the angle 00 consists of the following frames:

02-melee_attack-00-000

02-melee_attack-00-001

02-melee_attack-00-002

02-melee_attack-00-003

02-melee_attack-00-004



To keep an internal consistency amongst the FRAMES within an ACTION library, I cropped all five frames into the smallest possible frames that can fit ALL of them for that library alone. In this case it was 48*84 pixels for melee attacks. Then comparing these frame's ORIGINAL CENTER pixel with the action STAND frame's ORIGINAL CENTER pixel, I find that it is indeed a few pixels OFF CENTER.



Then I go back into GIMP and adjust the CANVAS size of the melee_attack frames to be the calculated pixel difference. Then I translate the frame again so that it is CENTER relative to the ORIGINAL CENTER PIXEL. This has usually involved moving the frames over only on the X-axis but I have also adjusted it on the Y-axis a pixel up or down. It all depends, but the important part is I have a viable strategy to overcome the WOBBLE issue. So far I have only completed the angle 00 which is the back facing sprites. Since I have to do it all by hand it could take a while but not as long as before. My trial and failure era is over for now. I am going back to producing and lets see if I can finish the fire dwarf soon. Then hopefully that is the last issue and you can approve it.
It's been crazy but I have light at the end of the tunnel. I was trying to do it all at once when doing it frame by frame is the better strategy.

I linked a youtube of the sprite in action. Since it only has the back facing sprite frames it is just a rough draft and he is able to kill without turning because he is only programmed to be back facing for now...only 194 frames to go for the combat sprite to be finished. The video is just check out the WOBBLE fix.




Talk to you soon. 

[Boaster]

Very nice work!

[juscurt]

Very coool. Looking forward to this 

[eyesodilated]

fildfa.imp (261.47 KB)fildfb.imp (36.55 KB)

I have compiled the Fire Dwarf completely, this is a rough draft of what I have. I lost your email so I uploaded these directly here to the impz.proboards...
You can remove them if you need to or maybe you can also message me your email again. I have an idea dan san hotmail not sure the exact email though.

What this contains:

This fildfa and fildfb imp files contain your recolored fire dwarf sprites in imp format. They are calibrated to the ealdfa and ealdfb units respectively. Since I didn't have a fildfa.h or fildfb.h files I just used the ealdfa unit since that sprite contained .h files that matched the sprite animations perfectly.

HOTSPOT transparent area is mathematically as small as it can possibly be while keeping the frame of reference consistent to the center of the original sprites which also fixes the WOBBLE bug. To implement both solutions I used a linear regression equation and my TI-84 calculator to find image sizes that are as close to satisfying the data for both the HOTSPOT and WOBBLE criteria and then which sizes correlate to the a size that solves both. But correlation does not guarantee causation although it is as pixel perfect as I can get it. Yet the math allows for a few variations...which may or ma not come in handy...


Why I say this is a rough draft:
It is close to my final draft however in fixing the HOTSPOT and WOBBLE issues my old friend the HEALTHBAR issue has popped up again. I did a quick experiment regarding the HEALTHBAR bug. It seems LOMUT will place the the imp file HEALTHBAR as high as the highest frame IF the frames are different sizes. So when we use 512X512 .pcx images then it takes an average height for all frames. But when inserting frames of different sizes LOMUT seems to place the HEALTHBAR at the HIGHEST or TALLEST frame, in this case it seems to be certainly the melee_attack-00-003 or so when his axe is high above his head. When I eliminate these frames the HEALTHBAR lowers pretty significantly.


POSSIBLE SOLUTIONS for HEALTHBAR bug considering all these constants and variables in play:

I saw a variation on frame sizes that may fix both HOTSPOT and WOBBLE bugs but it is suboptimal in that it sacrifices the minimization of the HOTSPOT frame size a bit but it may solve the HEALTHBAR bug or make it worse. I will experiment more. It basically adds a few transparent pixels on the bottom on either all frames or just the 00 and 04 angles (north and south facing sprites) … It may just work but again at the expense of the HOTSPOT getting larger slightly... I'll find out soon hopefully you can try this fire dwarf imp out and see what you think in regards to the WOBBLE fix.

Another radical fix to HEALTHBAR would be to merge two .imp files together without LOMUT, not sure how possible that would be just a random idea to get around this HEALTHBAR issue.

Hope it is up to your standards however we may be bumping up against the true limits of LOMUT and this could be as close as we get, an approximation.

On another note I was trying to add an iface.imp frame for your firedwarf but don't know how to call it. I can replace iface sprites and have them show up but making brand new iface frame sprites although they successfully accept new frame information, I just don't know how to call it. I thought maybe in the units.gs scripts for instance if I made a brand new wacr6.imp unit I can call it and it shows up in the game but the iface doesnt match the frame in the waicons.imp. Again an example, for wacr6 I have a wacr6a.imp and a wacr6.gs that has the line /impfile_proc{"wacr6"unittype_imp_filename}def  . But the interface sprite is just a lizard man.
For your firedwarf the only way I could add an iface frame was to replace the ealdfa frame in the decompiled eaicons.imp. But now all earth dwarfs have the Fire Dwarf iface image in game. Anyway I figure you would know away around this as I am probably missing something in the .gs scripts...

hope to hear from you soon take care
 

[Boaster]

In my mods, I use the unit stat called 'portrait_doodad' or maybe it is 'small_doodad'. Within that unit stat, I assign the value for the unit CODE (i.e. LDF) and this is what can redirect the 'iface' roster sprites to something different than which it would be by default. So if you had 'fild1' and it has a code of 'LD1' but there was no LD1 associated 'iface' roster sprite, I could set 'small_doodad' to /small_doodad LDF def and it would register the sprite accordingly.

Test this, and see for yourself. Take the Frozen Shade as an example.

[eyesodilated]

Ok thanks! I'll check it out once I get some time.
Still a bit confused where to start. Say I created a brand new Sprite imp file called ficr7.imp and made a frame in ficons.imp and adjusted the ficons.h

which files would I mess with with to manipulate the doodad unit stat ?:
gs\unittype.gs
units\ficr7.gs
units\imps\filcr7a.h

or some other gs files.


Also more importantly while looking through various GS files I noticed what looked like a healthbar positioning script maybe in the gs\imp.gs file. It is set at -75 but I'm not by my computer so not certain. Maybe we could set a custom health bar position for the fildfa.imp recompiled fire dwarf? That would take some GS scripting wizardry which by my admission I am still a novice at. Because that script seems to set the healthbar position for ALL sprites maybe it's not possible to set a value for just a single imp file.
Thanks again for the advice I'm going to check out the frost shade see if I get a better idea. 

[Boaster]

You would need to use existing codes in the game. FIT THF WIZ CAV INF MIS CR1-5, etc. etc.

So, if you wanted new Lords, LDR/LD1/LD2/LD3 would be useful. New creatures, then WM1, WM2, WM3. New INF/CAV/MIS, then use WMI, WMC, WMM.

Frozen Shade is basically Death Shade with a palette effect. Instead though, Frozen Shade is DEWM2, and uses CR2 for small_doodad.

If you want to really add more sprites, then yes, you would need to add them to an IFACE file specifically for those sprites.

[eyesodilated]

Ok cool! I was using the code CR7 which doesn't naturally occur. I will try to see if I can call the fildf iface sprite using this method. I suppose if I have more trouble I will start another thread as it is really it's own topic.

Regarding the HEALTHBAR bug I have indeed found a solution in the gs scripting. By lowering the value of "/health_bar_y" to "-35" on the y axis in the fildf.gs (ealdf.gs) I was able to get the HEALTHBAR lowered to where it normally is one the earth dwarf using just paint to count pixels off of screenshots. This works around LOMUT's tallest frame reference for the HEALTHBAR. Now it is manually tweaked in the .gs files for the unit. The only issue is it would effect the earth leader warrior if he was still in the game but since I replaced him to test the fire dwarf it is not a problem. If we can just use the actual imp fildfa JUST for the fire dwarf then we can just adjust the HEALTHBAR in the gs file for the unit: fildf.gs.

Here is a video example of the HOTSPOT, WOBBLE and HEALTHBAR fix on your fire dwarf.

Have you been able to stress test the imp files I uploaded?

Take Care

[Boaster]

I haven't been able to test or do anything with LOMSE in a while. School, work and family has me bound for a time.

[lemminkainen]

Nice work eyesodilated, seeing this red dwarf in action is like seeing Boaster himself on the battlefield.

[Boaster]

Nov 9, 2021 7:31:55 GMT -6 lemminkainen said:

Nice work eyesodilated, seeing this red dwarf in action is like seeing Boaster himself on the battlefield.

haha, love it. How about just the idea of me being on the battlefield? [Laugh out Loud]

[eyesodilated]

Nov 9, 2021 7:21:10 GMT -6 Boaster said:

I haven't been able to test or do anything with LOMSE in a while. School, work and family has me bound for a time.

Yeah I totally understand! I'm working on a windows application that may automate some of the things I'm doing, which will also help with testing. Maybe just an interface to load all the Sprite frames, a function to select/note the center(s) without actually changing the image, a crop and canvas feature to export all the frames out. I been experimenting with some batch programs for importing palette and renaming multiple files at once as well. I might combine these all into one program.

But yes take as much time as you need, your approval is what matters as the foremost expert on LOMSE worldwide! I'll be waiting for whatever steps comes next. Thankyou once again for maintaining this forum and always answering any questions we have- See you soon!

[Boaster]

Nov 9, 2021 14:22:07 GMT -6 eyesodilated said:

Nov 9, 2021 7:21:10 GMT -6 Boaster said:

I haven't been able to test or do anything with LOMSE in a while. School, work and family has me bound for a time.

Yeah I totally understand! I'm working on a windows application that may automate some of the things I'm doing, which will also help with testing. Maybe just an interface to load all the Sprite frames, a function to select/note the center(s) without actually changing the image, a crop and canvas feature to export all the frames out. I been experimenting with some batch programs for importing palette and renaming multiple files at once as well. I might combine these all into one program.

But yes take as much time as you need, your approval is what matters as the foremost expert on LOMSE worldwide! I'll be waiting for whatever steps comes next. Thankyou once again for maintaining this forum and always answering any questions we have- See you soon!

I do appreciate your kind words.

If you made a program that did all that you said, I would reward you for it.

[ozz]

The issue is that LOMUT doesn't have hotspots implemented at all (and I can see why - it would need user input for those), so the hotspot data is completely missing from the .imp it generates.

You could add it manually, though it is quite a lot of work.

Edit:
To add to the above, hotspot type seems to refer to amount XY pairs. 2 will have 2 pairs, 3 will have 3, 4 will have 4 etc. The extras seem to be used for ranged attacks and spellcasting, so I guess they are for projectile origin point. For enchantress from the above example, it goes up to 5 in minor spell, facing south final frame (what is special about that one?).

[eyesodilated]

Mar 15, 2023 18:50:07 GMT -6 ozz said:

The issue is that LOMUT doesn't have hotspots implemented at all (and I can see why - it would need user input for those), so the hotspot data is completely missing from the .imp it generates.

You could add it manually, though it is quite a lot of work.

Edit:
To add to the above, hotspot type seems to refer to amount XY pairs. 2 will have 2 pairs, 3 will have 3, 4 will have 4 etc. The extras seem to be used for ranged attacks and spellcasting, so I guess they are for projectile origin point. For enchantress from the above example, it goes up to 5 in minor spell, facing south final frame (what is special about that one?).

Excellent insight into this problem, I cannot believe I never thought to check the imp file's hex data much less compare the original with recomplied imps!!! 
First off, sorry I have not responded sooner but as soon as I saw your post I Liked It but have been really busy since. It is hard to believe its been two weeks. I was so anxious to check it out myself and I can already see this as the final steps towards the ultimate solution.

There is a reason I have not posted here in a while because I was thinking which route to commit towards. The method I have been using with .pcx files that are not the standard 512 X 512 dimensions to avoid the fact that the hotspot data was no longer in the .imp file. This was always a bandage I just never knew to what extent.

Being able to compare and now edit .imp files in hex will allow us to have a more real solution. Whether that be creating some sort of LOMUT 2.0 that would let us manually enter the hotspot data for each frame or doing by manually in hex. Which, doing by hand, as you mentioned would be alot of work. However, it is far better than cropping frames (hotspot issue), then calculating center points (wobble issue) and adjusting imps GS files to lower the health bar (Health bar issue). Why? -because my solution created more problems that while able to be alleviated were NOT a true 100% best solution.
In fact, while creating brand new imps that I could crop isometrically to avoid any wobble issues I found that my new sprites seemed to walk behind other sprites, like they were almost NEVER on top or in the foreground. Kind of like the Mario world White Hill glitch where you fall behind the background. But in this case I didnt fall behind the background just every other sprite even non unit sprite map graphics like fountains and rocks! Eventually I discovered that if I add a certain amount of transparent pixels at the bottom of EACH frame (that is a lot of editing) that my unit's sprite was able to "rise" up in front of other sprites like the normal units do, this also solved the healthbar issue as they were related. HOWEVER the hotspot area is not as MINIMAL as it used to be, there is an area under the sprites feet where I added pixels to compensate for the background falling issue, that is now kind of extra. It is not as bad as the whole screen a hotspot area issue however it was and is a bootleg solution if we can take the next step.
I have been working on several solutions for this. For instance, Pegasus Riders have an interesting mechanic that lets me go back and add shadows to any unit. The creators added some impfile procedures like alpha/shadow AS and Wingfront AWFA and Wingback AWBA. Even impfile procedure for death animations and corpse are usable. The creators did this maybe to save time. You could add shadows and then the death/corpse animations separately so different people could work on parts of the whole. 
Shadow procedure lets me add shadows to unit even after I create a unit without shadows (good for all the ones I previously made)
the wingfront ALWAYS is in front (foreground) of other parts of the WHOLE sprite and other sprites it seems. Wingback is ALWAYS in the back (background) of the WHOLE sprite but not other sprites. Because LOMSE is not a true 3D game, hence the pre rendered 2.5D sprites, this enables the illusion of depth. So, the Pegasus Riders are literally 5 different imp files running at the SAME time as ONE WHOLE single unit. That is how on the select your leader screen the sprite is able to walk through the arches, as each half of the arch (foreground/background) is either in front or behind the normal plane.

But back to your idea. Now I can see the imp files offsets in Hex and follow pretty closely with the RLE. I am almost to where I can think about manually edit the imp file this way to make the solution as near to perfect as it can be. Once I learn to manual edit it this way, I can write a bot or utility to help us with this. I am a little rusty with Hex editing but I was able to follow your example with liwiza.imp and I can almost visualize the runs on the run length encoding.
I might make a LOMUT 2.0 since SNV was kind enough to leave all this source code available with the help of my brother. This way we can add hotspots more intrinsically with box selection tool for example that would also rewrite the .imp file simultaneously- all of which is more possible now because this hex data will allow us to do something LOMUT has not been doing. Just an idea.

What this ultimately means is we can possibly NOT crop anything eliminating all wobble, background falling issue and health bar issue and just upload 512 X 512 pcx files AND THEN assign the hotspot data later!!! This will allow for faster creation of sprites, theoretically. But also, the creation of BETTER sprites that don't suffer from previous issues. Screw doing all that math for it to potentially come out with a wobble or somehow "behind" everything. 

What encoding are you using in your hex editor for decoded text? I am also following INT8 Bit for decoding, should I be using something else? Do I need to create a custom Hex ASCII table? Guess I better dust my HEX editing googles off as there is a lot of work.

Thanks for the suggestion, this really could be the final technical solution. I have a lot to think about. Cheers!

[ozz]

I'm pretty certain the original sprites aren't 512*512, it's just LOMUT making everything 512*512 and then placing it in 512*512 box. When you crop the individual frames and pack it into imp, the size LOMUT sets in the header is still 512*512, when it only needs to be large enough for any of the frames to fit in.
My guess is that the wobble issues are caused by the difference between size specified in the header and the size of the individual frames. It seems the anchoring point for the sprite box and the placing of the frames inside the box are not the same.

I see two ways to go about fixing it:
First would be to unpack the sprites without the extra padding, and when packing into imp use extra hotspot data provided by user.

Second is to keep unpacking as is and when packing have LOMUT crop the padding and generate hotspot data based on that (not ideal - would only work for visual alignment but not for cursor interaction, projectiles, spell effects...).

Another unsolved issue is the mirroring. I know which bytes are responsible for mirroring, but can't make much sense out of it without thorough testing.

[Ozz (forgot to log in)]

Mar 28, 2023 10:23:10 GMT -6 eyesodilated said:

What encoding are you using in your hex editor for decoded text? I am also following INT8 Bit for decoding, should I be using something else? Do I need to create a custom Hex ASCII table? Guess I better dust my HEX editing googles off as there is a lot of work.

You need to know the variable type, use snv's comments as reference.
u1 is 8bit, u2 is 16bit, u4 is 32bit. s1, s2, etc are same but signed (hotspots are signed for example).

This here is the width of a sprite, and as you can see it's 2 bytes(16bits):


Now as for mirroring...
Any value equal or above 128 in the 2nd byte of sequence data will result in mirroring. From what I can see, all original imps use 128 there if they are mirrored, 0 if not. 4th byte is always 1, 3rd can have a handful of different values (no idea what they do), 1st is either 0 or 4, again, not sure what it does.
Another thing I can't quite figure out is how the game knows how to assign the different sets of frames to directions. While units have 5 facing groups (N, NE, E, SE, S), other sprites can have a different amount. Arrows for example have 33 different facings, going clockwise from north to south, with the rest being mirrored for 64 directions in total. But from what I've seen you managed to get non-mirrored frames to face west? Does it by default split them between the full circle if mirroring is disabled, and half circle if it is on?

[ozz]

So, hotspots have 3 variables each, type (0 to 9), x offset, y offset. From aura.gs comment (is it even in the original aura.gs file?), we know the hotspot types:

; CURSOR_HOTSPOT
; MISSILE_ORIGIN_HOTSPOT
; SPELL_ORIGIN1_HOTSPOT
; SPELL_ORIGIN2_HOTSPOT
; SPELL_ORIGIN3_HOTSPOT
; SPELL_ORIGIN4_HOTSPOT
; FLAP_OFFSET_HOTSPOT
; MISSILE_TARGET_HOTSPOT
; SPELL_TARGET_HOTSPOT
; STREAMER_HOTSPOT

Types 0 and 7 are present in all units, and I imagine type 0 is also used for aligning the frames. Missile origin (type 1) is for attacks only (not spells). Spell target is only used for some units (do the rest just use the default position?). No clue what streamer hotspot is.

Things to figure out:
What each individual hotspot does for spells?
How does the game decide whether to use the minor spell or the major spell sequence?

[eyesodilated]

Another great find! Ive been getting into missile and aura imps trying to make a medium range whip for my Bard.

Dude I am about to release LOMUT 2.0 because your idea to check .imp files in hex! I am moments away from a beta version. It is good timing because I just took a class on programming in C. Which is what lomut source code is. I got a few more things to run but I was having trouble getting a successful test.
If you look at the very beginning of this thread I mention HEX the games save data. I did it as a kid in this game. This whole week I have been forgetting to rehash the HEX when I edit. Because I could not get it to work for me. All I did was change a constant int the .IMP header for Width and Height. This caused it to crop all the extra transparent area inside of LOMSE the game because it is flagged as a 25 X 25. Alot of other errors popped up,new ones, but at least the sprite did not have a giant selectable area. So many variables (dozen?) get lost from decompile to recompile.

Im working on several versions of a new LOMUT:

• LOMUT 2.0 : rewriting lomut.c so that when it decompiles original sprites it saves the lost data into a CSV file which when recompiling a .imp will now call to the CSV file to pull the variables frame by frame while it packs the .imp- this is great for the original 1997 sprites but not new ones. Although they could use a comparable unit's .imp's CSV header file. Also making a default average template CSV for brand new creations.
• LOMUT 2.01 : Modify the pcx.c code so that lomut.c will decompile .imp files and produce .pcx files from .imp that already have the variables built in.
• LOMUT 3:00 : special project if my brother has time to help me 

There could be another way to solve this, I know ive been way too optimistic on this thread too many times. But everything was a work around bootleg. The sprite mirror issue is solved by manually flipping all sequences that have the NE E SE which is 01 02 03 facing. Manually means go into paint program your choice for example, and take 01-stand-01-000.pcx ( i have to use Irfanview with .lbm enabled plugin). Select all then select the Flip Horizontal option. Save as 01-stand-07-000.pcx file. This way force feeds LOMUT the already mirrored frames with the correct names. I dont see a work around because sprite mirroring was important back then for memory but i have no idea whats going on, somehow LOMSE itself mirrors certain frames. I WILL make a batch file to flip and rename all files, im tired of doing by hand although Irfanview has a built in batch mode that will let you flip and rename simultaneously. You got to watch your palette make sure you dont mess it up.

Im going to post LOMUT 2.0 beta if I can get it to at least replace the values that are lost. Wish me luck, I may drop that in a different post if I get it to work. Or even if I dont maybe if you know any C progmramming you can take a look. I have a bad habit of making parts that work fine seperate but together but I have to finesse them.

See yall soon!

[ozz]

The fix for mirroring is just changing one variable.
The first byte in sequence data is something used for animation looping I think (like how it repeats a few frames during long spell casts), while the second byte is for mirroring.