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

[Boaster]

Not to sound snarky in anyway, but I have figured some/most of this already.

I didn't go into the proof part like you did, so definitely you did your homework and deserve credit.


When I compiled my "red" Dwarf fighter, it worked basically the way it was supposed to, but the attack animations seemed wonky (not the way they're supposed to be). But with the information you provided about LOMUT showing the actual frame sizes for each sprite, may lend itself to closing the gap and getting the problem I experienced to a resolution... perhaps.

The "hotspot" issue as I first described it was when I first compiled a sprite as a 512x512 file. The unit was selectable in that entire area.

From some tests I did myself on compiling, the selectable issue could be resolved by cropping to the minimum size (or as you described a polynomial of 512x512). That corrected the selectable area, but the last problem I encountered before putting it to a rest was the attack animation of the compiled red dwarf: he looked like he was jumping up as he attacked, not as natural looking as the original sprites.

The mirroring issue, if that were fixed, would reduce the file size.

Sounds like these two issues (mirrioring and original frame sizes) may be solved, or close to being so?


[Oh my God!]… I just realized I was responding to an OLD post, [Laugh out Loud].

This post:

Sept 24, 2014 12:28:36 GMT -6 eyesodilated said:

Hey!
I totally understand if you are not convinced at the veracity of my solution... You are the boss so if you are not convinced then it is my duty to provide proofs on my theory... They are a lot of ways to test it and they will take some time to perform but I am already having good results with an initial test...

Here is my theory:
LOMUT is a powerful utility that extracts sprites from the game and packs them back in...
Maybe it is too powerful and blanket extracts all pcx images as 512X512 because I believe that this is the largest of image dimension in the game (title screen with dragon and other PANEL images maybe 512X512) and perhaps something to do with the 512 kb VGA graphic cards used at the time(I think not sure)
the other original sprites automatically get extracted with these dimensions...although there non-extracted file size suggest they should be smaller...

The main question of my theory is this:
Is LOMUT arbitrarily adding extra transparent areas to sprites?
I really think so... here is my 'proof' for this theory...

video link to proof test:
youtu.be/QDQ1RMAbnCs

I take an original Valkyrie sprite extracted with LOMUT... it is 512X512
I crop said sprite to 40X88 (just found out that polynomials of 512 work too!)
I use LOMUT to compile this single 40X88 image into a IMP file...
I place this new IMP file in a 'units' folder...
I use LOMUT to unpack my new sprite...
LOMUT extracts my new sprite as a 512X512!!!

So even if my new sprite was 40X88 when I compiled it into an IMP, LOMUT still unpacks as a 512X512 image... 
this 'extra' transparent area may just be that, extra... and what I hope an arbitrary convention as well...
So my theory postulates that we may never know the true sprite sizes as LOMUT will extract any IMP file into 512X512 images...
We could start calculating memory which I plan to further test my hypothesis... 
My belief is that every sprite in the game has its own unique dimensions and that LOMUT tries its best to extract them uniformly...

Also I dont know if I was clear about this but I maintain the size of the sprite image, I just crop out the extra transparent area... So I am not making the sprite smaller only minimizing the transparent area thus meaning the original proportions of the important part of the sprite are intact ? 
If having a smaller dimension size (40X88) really matters LOMUT certainly does not care... It adds in the area I cropped out anyway when I compiled it and when I extract it... So we dont need to worry about making the transparent area 512X512 as LOMUT can and will do it for us...

For however broken this hotpot fix may be I will try to provide more proof that it indeed functions as the original sprites do.
As you can see in the video this is just one of my proofs, the question is how can this be refuted?
If one makes a IMP file that has image dimensions that reduce transparent area of sprites while leaving the sprite itself in proportion and intact and LOMUT accepts this, compiles it into an IMP but upon LOMSE loading the sprite or LOMUT unpacking it- it behaves normal (LOMSE has no hotspot bug... LOMUT unpacks it as 512X512 regardless of initial image dimesions) then how can we tell the difference between a newly compiled sprite and an original one?
If it looks like a duck, walks like a duck and sounds like a duck?

Of course this is my initial test to my theory,, and I will do more until we can say something for certain. It just seems like we are simultaneously giving too much and too little credit to LOMUT... We expect that 512X512 is written in stone, but what if LOMUT was trying its best and different null areas were both read as transparent areas... Then again LOMUT places images of different dimensions in the center as opposed to a corner, so maybe it was designed powerful on purpose...

I have a few other ideas of other test I can do, maybe a memory test requiring me to crop all the frames of the Valkyrie unit and recompiling etc..
     
If the sprites in the game are originally 512X512 I dont think that LOMUT can tell us...
All it can tell us in this regard is that:
Original sprites are extracted as 512X512
Any new sprites are extracted as 512X512

The memory usage in the MPQ viewer would suggest that original sprites were not compiled as 512X512
So maybe just maybe our new sprites need to be different than 512X512?

What do yall think about this?



EDIT: UPDATE!
I was looking at the output dialog as LOMUT unpacked watf1a.imp...
It actually tells us that sprite images are all different sizes!!!
512X512 must be the default size it extracts too...
I am now 99% sure we need to crop out the extra transparent area, not only to eliminate the hotspot bug and to keep the file sizes from getting to large but to make it like the original sprites in the game!!! According to LOMUT each frame has a different dimension!! Look for yourselves it is all right there in the LOMUT output dialog...

The 10th library frame of the Valkyrie 00 angle library and frame 00 extracts with the following information, among that info is that original sprite at this frame has a width of 68 and length of 78... if you crop out the most transparent area you can on the 10-xx-00-000 frame you get 68X78!!!



If you think that compiling images other than 512X512 is a broken way of using LOMUT please consider that LOMUT itself indicates frames come in all sizes... unless that is not what you meant- then what makes it broken?

So what do yall think??? 

[Boaster]

Aug 25, 2015 18:20:13 GMT -6 eyesodilated said:

Please forgive me for my absence, I have moved eight times this year, and now that I got my computer out of storage I find my hard drive burned out!
Im starting all over...
I hope to have your fire dwarf complete for round two of testing, I was so close then boom, life...

Anyway how are you these days?
Looks like you guys are making progress modifying LOMUT ?

The method I use does solve selectable area bug and sprite mirrorring, however it appears crude compared with what Ozz is doing now, as I am manually constructing the IMP whereas if LOMUT can be completed then it may make my way obselete...
Or they could be two sides of the same coin...

Hope to contact you soon

Thanks!
-EyeS

I'm doing well... sorry I responded to an old post of yours. The forum tricked me!

I haven't made any progress modifying the LOMUT tool. That's been in the dominion of others more capable in the area of coding.

However in my reply to your post, if I were to get the dimensions of all the frames proper especially for the Dwarf attack, I could recompile it (even without the true mirroring) and maybe have it right then.

It has been long since I tried using the LOMUT tool. I knew how to work it before, but time has lapsed and so has my brain with that.

Will be working on a GS6 beta in spare time, which is very little even today!

[eyesodilated]

Hey, I have been working on red dwarf animation all day, and i have come to realize that it would be way easier and more accurate if you could upload the fire dwarf UNCROPPED frames
…
I know I told you cropping helps, which it does, but the animation frames can be aligned perfectly with the 512x512 images and then I could use some batch image processing I have been tinkering with to crop it in such a way they stay relative to themselves...
It would be faster and better than trying to do it by eye

So how you crop is important as LOMUT centers the frame

Its actually less work too

So, yes could you upload fild1a Frames uncropped please, that will fix the wobble.

Did you want fire dwarf to have green outline like earth , right?


Health bar still giving me trouble

On the note of mirroring...
By compiling an IMP with mirrorred frames, the memory problem is not an issue if the mirrored frames are cropped before compiling with LOMUT...
We do that anyway to avoid the selectable area bug, however it allows the IMP to be safely packed via MPQeditor...

Its wierd, almost everytime I extract the pcx files of units using LOMUT, i get no mirrorred frames (e.g. 00-move-00-000 through 00-move-04-000 only)
Lately I have been extracting all the frames, including the mirrored ones, from the original sprites...
This leads me to believe that original IMPs have mirrorred frames packed in them...
What do you think?
-Eyes

[Boaster]

Are you suggesting that... like the animation I have of the Red Dwarf, the unit should be cropped to the smallest area in which all of the frames fit? Would that be an idea?

Attached as RAR.


Bear in mind, this is only the combat sprite (A), and not the overland sprite (B).

Attachments:

fild1a_512.rar (455.96 KB)

[Boaster]

Aug 26, 2015 6:27:29 GMT -6 eyesodilated said:

On the note of mirroring...
By compiling an IMP with mirrorred frames, the memory problem is not an issue if the mirrored frames are cropped before compiling with LOMUT...
We do that anyway to avoid the selectable area bug, however it allows the IMP to be safely packed via MPQeditor...

Its wierd, almost everytime I extract the pcx files of units using LOMUT, i get no mirrorred frames (e.g. 00-move-00-000 through 00-move-04-000 only)
Lately I have been extracting all the frames, including the mirrored ones, from the original sprites...
This leads me to believe that original IMPs have mirrorred frames packed in them...
What do you think?
-Eyes

It may be possible that mirrored frames are packed within. I wouldn't know off hand.

And yes, the wobble was just about the last piece of the puzzle on my part, other than the manual mirroring of sprites.


It may be to your advantage to use the palette from the Red Dwarf and apply it to the original Dwarf Warlord freshly extracted. Maybe.

Do all the frames larger than the original need to have the same bottom right corner to not have a wobble?

[eyesodilated]

Hey all! Everytime I come here its hard to believe how long it takes before I can get back to you guys! I had a new baby a month after my last post and then my computer crashed and I lost all my files basically. Now I do have some backups on my mother's computer, but I will need to purchase a new computer as soon as my tax return comes in, nothing fancy just a dell maybe with windows XP.
Until then I am powerless.

But an update:

- solved outline and shadow bug on new IMP files (actually already fixed that before via using the correct palette , I had just forgotten!)

-solved the health bar bug (it was a similar problem with the 'wobble' frames on the dwarf attack where the frames are not aligned properly. By cropping a certain way leaving more alpha "green" under the "red" shadow of the sprite. In other words the health bar is proportional to the bottom of the sprite cell. When I told you to crop as small as possible your dawrf frames I inadvertently caused more issues, namely losing the frames true reference and proportion. This caused not only wobbling frames but the smaller the frames were also made the health bar out of wack)

I have proof for all this of course, however without my computer I cannot demonstrate fully.


Also Boaster, I tried switching in your red dwarf palette onto newly extracted earth warrior sprite frames however the LOMSE engine is pretty versatile so I only end up with a dwarf that is half way between an original sprite and the new red one.

If you still have the old 512*512 frame sprites I can finish it better than before, hopefully with so much precision we could have a sprite that is cannonical to the game.

Hopefully you have the 512*512 sprites still and didnt overwrite them with the cropped versions!

I have a batch file I was using in conjuction with an image processing program, however untill the file is fully automated I recommend using the batch processor that comes with the program.
Again I cannot say enough about this free program, its called IrfanView.
My batch file mostly changes palettes and frame sizes, which is very useful for quickly compiling images into a viable IMP.
I also use the batch processor to rename all files, and it follows command line patterns.
I almost have automated the IMP making process, well the automatble parts anyway.

So that is my answer to your question of cropping, instead of making the frames as small as possible while simultaneously keeping them relative to each other and trying to manually adjust for healthbar concerns the batch processor can crop hundreds of frames perfectly in seconds. The setting when you crop needs to be set to :
Crop Center from Top
In Irfanview that is, should work on other image software like Photoshop, although I havent checked but Irfanview definitely lets you account for all cropping parameters.

If I had those 512*512 frames of your red dwarf, uncropped like you originally sent me plus a computer I could have what took me weeks done in mere minutes.

Again when I set up my lab I will come with the proof, as for now all I have are signs. Good signs , great signs even.

I have a lot of novel stuff too, for instance I took the frames of Golgoth's iconic cloud spiraling animation from in-game and mapped it to a simple geosphere in a free 3d rendering program and was able to make a prototype Golgoth IMP. I used Smacker program to extract the .SMK opening file into .PNG or some other format to cheese out the animation. It was pretty hefty like hundreds of frames of animation... Another great program I use is called FragMotion. It took my Golgoth animated model(simple geosphere with Golgoth animated frames as texture), and the program has an automatic feature to make a sprite library(very useful) from all 8 angels around the 3d model. You can even set the transparent "green' as background and even has built in lighting letting you select " red" as the shadow !
Since I dont know how to cycle textures I had to use hundreds of models to simulate Golgoth. I used Irfanview's batch processor to automatically change the black sky around Golgoth to transparent "green" so it didnt look too blocky (solid square or round Golgoth). The result was pretty cool, again novel and the prototype had only the southfacing directions programmed due to my limitations, mental in terms of the tedious nature.

Other novel "achievements" of note:

-Made brand new IMPs from scratch using 3d models and rendering them digitally (possible this is how LOMSE was originally created?)
•Some new sprites I made with extra aniamtion frames. So if this new sprite has to attack 'grind' a enemy with high HP it appears to do combos and chain attacks! On downside sprite appears stuck attacking the dead body of lowered level enemies that died too quick, only being hit or manually selecting a new target does the extra animation attack stops or adjust to new targets, kind of berserker like

-Utilizing brand new IMPs
•Instead of sacrificing an old original IMP and replacing it with a new modded one by modding a few GS files I was able to call new IMPs into the game without losing or swapping out old IMPs
•Used the same technique to create brand new mount IMPs and attach them to new or old calavry\champions
•Modded some grass tiles that were static tiles to have more cycles to and give illusion of movement overland, want to try same with water, lava, etc.
•Modded the building sprites in a similar way to have more overland cycles and give effects, for instance I made some seagulls flutter about Water Theif Guild.
•Made huge weather sprites that looked cool overland and different during battle (i.e. hurricane)

Basically it seems that one could have an infinite amount of new sprites.
I have the proof on my backup and also in my head , which is why I felt the need to share and perhaps I could chronicle a few tutorials with proofs on here if you dont mind? Maybe in another post ?

I know its a lot too say but I have seen the promise land. GS scripting is my weakness and those last ideas need fine tuning, but I have definitely had working variations of everything I said.

Also on another lofty note, I have one more idea , something I messed with but maybe you could help? As it haunts me with its potential and also the amount of work required to achieve it.
While messing with some files and reading some posts on here about changing the resolution of the game I had what looked like LOMSE with a blank dark black around it. My understanding was that by manually changing the resolution you could add larger more detailed sprites, the problem was the original sprites remain the size they always are hence the empty black screen border.
But what if, as in my lost experiment, you were able to enlarge not just only a test sprite, but rather all the sprites in the game?

Of course they may look crappy enlarged, maybe not?


Anyway that's just a pipe dream and first thing is first, I must get my files and a new computer.

I would rather focus on another pipe dream too: new faiths

Maybe it could be as straight foward as making all new sprites. I have an idea and some experiements where I was trying to add four new faiths but the units were only attainable through villages.
The way I tried was like this where even new capitals could be raised.

•Water/Life -Greek style units Olympus or Atlantis capital
•Fire/Death -Persian/Egyptian style units Babylonian capital
•Earth/Chaos -Native American/Aztec style units El Dorado capital
•Air/Order -Samaurai/Oriental style units Shangri-La capital


Of course those are my personal choices on how I think the format could be done to bring in new faiths.
What do you think about new faiths being pseudo LOMSE-Civilization-esque
But like I said my GS is weak and I made it work with trial and error for the most part.

I want to make special forge buildings too, where you could customize artifacts in game(another lofty goal)

But what I really want is a forge building that works kind of like Death's special building where one unit or units go in and a different one comes out. In other words I would love a feature where you could "breed" units.
Maybe even another building that allows you to customizecustomize sprites in-game via a set of generic sprites.
For instance an artifact that adds a beard or a hat via the mount system in conjunction with brand new sprites to pull it off. I made an mount IMP that looks like a shield when equipped it appears as if your sprite is now holding a new shield for example.
It is all novel but I see no reason other than time that these quirky discoveries could be utilized into new features.

I had lots of problems though, so many its not for this post. Like new champions I add to the GS with corresponding new IMPs appear at random spots on Lord Editor mode and rarely with the new *__icons.imp I make for them.
Also brand new IMPs have been hard for me to make available at certain building, I pretty much have to call them via spells or cheat menu if they are not on the LE.
Also I made animated iface IMPs however if you do for one you have to do with all as all the interface icon sprites are packed in one IMP.


Hope to post more soon

[Boaster]

Attached to this message is the fild1a_512.rar file.

Also, you would have to come up with a fild1b_512.rar version for the overland sprites.

I'm glad to see you still have an interest in this. I've been too bogged down with work life and home life.

Lately, I've been doing test runs of games, re-observing what I've done with a fresher eye, in hopes that I might make some progress on a GS6 Beta in time.

I have not read through your entire post, but I might be able to do that... from work?

Attachments:

fild1a_512.rar (455.96 KB)

[Boaster]

The weapon/armor attachments as a mount is a brilliant new idea.

Yes, new IMP sprites can be incorporated into the game. It can get quite complicated, but it's possible for sure.

I do have colorized sprites for Shadow Goblins, which would fall under death's umbrella.

The Red Dwarf would fall under Fire.

These would be the ones I have created thus far.



I'd also like to create some "Fire Lizards" from Water models, to create some additional Fire units. Or perhaps even replace Fire Infantry altogether.

The extraneous sprite files would have to incorporate the codes: LD1, LD2, LD3, TF1, FT2, WMF, WMI, WMC, WMM, WM1, WM2, WM3.

I.E. FILD1 for the Fire Dwarf Lord.
I.e. WALD1 for the Valkyrie Lord.
I.E. DEWMI for the Shadow Goblin Infantry.
I.E. DEWMM for the Shadow Goblin Archers.

However, on the flip side of adding all of these extraneous Champion-types, it will further complicate Artifact scripts to prevent a Fire Dwarf from wielding a Burning Blade, etc.

[eyesodilated]

Just got my new computer today! I dont have all my files but I hobbled together your fire dwarf somehow... I am E-mailing you the results today...
No overland sprites just yet, but let me know what you think. For some reason my laptop shows LOMSE running small and in the center so its too hard to see it perfectly.
•Wobble frames look smooth and no longer wobble especially during attack
•Shadow has no selection outline
•Health Bar closer to normal if not pixel for pixel identical
•Unit Name Box now also smaller and closer to original sprites, less cluttered
•And of course hotspot selection bug and sprite mirroring issues still averted

I think some test runs are in order to check for any other unforseen problems. But Im hopeful this worked to bring a functioning new unit into the game, I used a file similar to ealdfa.h to test it in place of earth warrior, let me know what you think about this new iteration.


Also once we establish that the new IMP is in fact working up to par I could definitely try and compile your other colorized sprites for you.
I was able to do the red dwarf from work without my batch files so I am confident I could use the same method.

I'm glad you like the idea of artifact/weapon mounts, I think having the ability to futher 'customize' your champions adds more gameplay life . It does seem to give me headaches the GS for mounts but I feel its worth it.

Perhaps before adding new faiths we could try a simpler goal which is eliminating clone units.
•Water/Order Calvary
•Earth/Death Calvary
•Air/Life Calvary
•Fire/Chaos Calvary and Infantry

Just off the top of my head they always bothered me in a way however the book mentions how this shows the interconnected nature of some of Urak's people so then again kind of built into the game.
Im going to try and get this IMP to you, I'll post more soon

[Boaster]

Sounds good. I haven't received anything by email yet.

Not sure what I'd come up with for "unique" new units to replace existing "cloned" units.

For Fire, what I would do would be is create "Fire Lizards" (Water Missile ones) as a WMI (Wild Man Infantry) type. Or it may be more effective to use the Fire Lizards as infantry replacement, but... it would still be a clone unit, as would the Shadow Goblins would be.

For Earth Cavalry, I imagine Halflings riding miniature horses, wielding flails, perhaps. Or perhaps dwarven Boar riders. Or maybe Death could use Spider Riders instead?

Maybe for Fire Cavalry, Barbarian mini-dragon Riders. Or Scorpion riders.

Air Cavalry... Elven Polar Bear Riders. Or maybe the Life Cavalry could be riding smaller Unicorns?

Water could have Snake Riders for cavalry, or King Crab riders, or Snail Riders.…


Who knows. I know I won't be able to accomplish any of these.

[Boaster]

After testing the sprite, it is visually flawless as far as I could tell. However, the selection area of the unit itself is larger than it should be.

The unit with this sprite is selectable far outside of the visual sprite.

[tempest747]

Mar 4, 2016 7:59:58 GMT -6 Boaster said:

Not sure what I'd come up with for "unique" new units to replace existing "cloned" units.

For Fire, what I would do would be is create "Fire Lizards" (Water Missile ones) as a WMI (Wild Man Infantry) type. Or it may be more effective to use the Fire Lizards as infantry replacement, but... it would still be a clone unit, as would the Shadow Goblins would be.

For Earth Cavalry, I imagine Halflings riding miniature horses, wielding flails, perhaps. Or perhaps dwarven Boar riders. Or maybe Death could use Spider Riders instead?

Maybe for Fire Cavalry, Barbarian mini-dragon Riders. Or Scorpion riders.

Air Cavalry... Elven Polar Bear Riders. Or maybe the Life Cavalry could be riding smaller Unicorns?

Water could have Snake Riders for cavalry, or King Crab riders, or Snail Riders.?

Eliminating clone units was something I had marked down as a bucket list mod way back when I first started playing, I'd never understood why Water had Order's knights, or how to distinguish Chaos and Fire's infantry. I mocked up some sprites (mostly basic copy/paste creations, and not very high quality at that), but never knew how to go about implementing them. The list I'd compiled, among other things, gave Fire a set of Komodo Dragon like infantry and was going to replace Water's lizards with a female hoplite and slinger to match the Amazon theme. Water's Cavalry was switched with a Water Warrior riding an armored War Turtle instead of an ostrich. I also thought about giving Death a skeleton horse, but that was far beyond my art skills at the time.

[Boaster]

Mar 5, 2016 3:18:44 GMT -6 tempest747 said:

Mar 4, 2016 7:59:58 GMT -6 Boaster said:

Not sure what I'd come up with for "unique" new units to replace existing "cloned" units.

For Fire, what I would do would be is create "Fire Lizards" (Water Missile ones) as a WMI (Wild Man Infantry) type. Or it may be more effective to use the Fire Lizards as infantry replacement, but... it would still be a clone unit, as would the Shadow Goblins would be.

For Earth Cavalry, I imagine Halflings riding miniature horses, wielding flails, perhaps. Or perhaps dwarven Boar riders. Or maybe Death could use Spider Riders instead?

Maybe for Fire Cavalry, Barbarian mini-dragon Riders. Or Scorpion riders.

Air Cavalry... Elven Polar Bear Riders. Or maybe the Life Cavalry could be riding smaller Unicorns?

Water could have Snake Riders for cavalry, or King Crab riders, or Snail Riders.?

Eliminating clone units was something I had marked down as a bucket list mod way back when I first started playing, I'd never understood why Water had Order's knights, or how to distinguish Chaos and Fire's infantry. I mocked up some sprites (mostly basic copy/paste creations, and not very high quality at that), but never knew how to go about implementing them. The list I'd compiled, among other things, gave Fire a set of Komodo Dragon like infantry and was going to replace Water's lizards with a female hoplite and slinger to match the Amazon theme. Water's Cavalry was switched with a Water Warrior riding an armored War Turtle instead of an ostrich. I also thought about giving Death a skeleton horse, but that was far beyond my art skills at the time.

I thought about the Death horse.… but as actually a skeleton riding a horse. I nixed that, because then with Skeletons being "creatures" and the Skeleton Cavalry riding horses would be cavalry.… is like the situation with the Goblins being creatures and Goblin Archers being Missile Military.

Great idea on the turtle. I think I was trying to say that, but I went for a snail or crab instead. Kudos on that idea.

I think the Lizards for Water work great, but the Heavy Cavalry that were put in was a bit of a cop out by the creators.… possibly due to time constraints.

Also, I found out that both Lizards of water have ranged attack animations.

[eyesodilated]

Mar 4, 2016 21:23:28 GMT -6 Boaster said:

After testing the sprite, it is visually flawless as far as I could tell. However, the selection area of the unit itself is larger than it should be.

The unit with this sprite is selectable far outside of the visual sprite.

You are absolutely correct, the selection area was indeed too large. In the face of the 'wobble' issue I had forgot the most crucial point of this whole 'fix'. Sure enough I did not pay attention paid a price. The last 'solution' I used alleviated the 'wobble' but was regressive in regards to the original solution to the hotspot issue.

The sequence of issues is as follows:

• Cropping the raw 512x512 images to make a smaller selection area fixes the 'hotspot' bug however it creates a 'wobble' issue
• The 'Wobble' is fixed by keeping all frames of the new IMP relative to each other in terms of size (all animation libraries "move,stand,melee_attack..." have intra-proportional frames) however it regresses the 'hotspot' issue by the nature of the 'fix'.In other words the smaller frames were made bigger so as to be centered with frames where the sprite is larger. This had the desired effect of eliminating the 'wobble' but the consequence was amplified by the sheer amount of frames. That plus LOMUT's aversion to odd numbered frame sizes caused unavoidable disruption in both 'wobble' and 'hotspot' fields.
• Attempting several combinations to try and figure where and when to give priority to what I found a clue. By combining the 'hotspot' fix with the 'wobble' fix I kept coming close but finding it was hard to fit, like an arch stone. I could solve both issues almost fully only to find the axe or helmet or foot cropped off and trying to compensate for this small errors caused a chain reaction and either or perhaps both issues to emerge.

The clue was in LOMUT's output dialog all this time! When using Pikol's Batch file to unpack and extract an IMP into PCX files use the command:

>"C:\info.txt"


After the batch command (I explained this earlier in the post) or use a batch program alongside Pikol's like I did to capture all that data as your sprite unpacks.
Among the minefield of data is the name of each frame and its proper size as I noted before. But what I failed to notice is that the hotspot has its own axis' values for center when LOMUT unpacked the frames. They are represented by the DX and DY values.

Now I can crop in regards to the 'hotspot' issue (minimum frame sizes) and the 'wobble' issue (proportional frame sizes) without new mistakes appearing. The extra information I plug into my cropping procedure, whereas before I left default. I take this into account and prioritize solving the 'hotspot' issue first and use the extra values (DX,DY) to smooth out the wobble without adding extra selection area.


I use many batch files and although I lost my original batch programs, the last few weeks have been put into developing new batch tools. Theoretically one could do it without the batch files but it would take HOURS. My batch programs are pretty standalone however some crucial ones use freeware Irfanview as a workhorse.

• datacap.bat captures the output dialog of Pikol's batch (LOMUT's output dialog) as C:\LOMUT\info.txt 
• 
  parser.bat/parsecap.bat parses through the info.txt captured from LOMUT's output dialog as Pikol's batch runs and creates a Comma Separated Values file with frame name,dx,dy,width,height,origin for each frame, C:\LOMUT\odd.csv
  

• The file odd.csv when opened in notepad will have a bunch of jibberish at the end you have to delete, once that is done run even.bat to make sure LOMUT likes are frame values. This will create a file, C:\LOMUT\even.csv
• mirror.bat will simultaneously add in new data for the missing mirrored sprite angles, rename the data and find the absolute value of DX and reverse it, creating C:\LOMUT\mirrorred.txt
• Copy and paste mirrorred.txt into C:\LOMUT\temp folder (this folder contains all the frames you want to crop). Rename mirrorred.txt as info.txt.
• framecrop.bat will now use Irfanview to crop the frames! (some Windows errors occur) The cropped frames will appear in the C:\LOMUT\test folder
• Use LOMUT to turn the frames into an IMP!

This way is almost perfected (healthbar issue is not fully resolved), I will post the batch files for public use once I polish them.


I sent the new IMPS to your email
let me know what you think

Ill try to upload the cropping procedure using batch files to make fildb.imp (a.imp)




take care

[Boaster]

You're closer to perfecting the sprites, however the frames between standing and moving, or standing and attacking slide, or shift, to the side.

Also, the health bar still is high above the sprite.


You have almost perfected your method!

[Boaster]

I'm thinking, just based on my own experience, that you'll only need to really find hotspots for the attack animations, and not the standing or moving ones.

Then again, I haven't tested how missiles (like Curse) display on the Red Dwarf as recompiled.

[eyesodilated]

Greetings! How are you??
I cannot believe 7 years flew by so fast. I have been through 5 computers real bad luck never got to use them more than a week before something happened. But I am back online with a computer.

I have never stopped thinking of ways to get your red dwarf imp into the game. I have some fresh new ideas and ways to test to get the pixel perfect solution this game deserves. If you would be ever so kind to email me your filda and fildb frames please, UNCROPPED this time,  I think I can solve it from the beginning. I know  I last asked for them to be cropped last time but I just want to narrow down my variables. I've been using the imp mount system to have a full 512*512 grid color coded onto the sprite in game so I can measure. Would love to figure a way to make a dungeon map with a color coded grid layout so I can get real exact.

So yes if you could please send me to email that would save me alot of time. I am currently doing it by hand it may take to long just to have to crop it down again. Hope you're doing well! Thanks again for keeping this game community alive


[e-mail]

[Boaster]

I am having trouble finding the fire dwarf graphics on my computer.

I do have a GIF of all of the frames, but they're not at the 512x512 size, and, if you needed to, you can use the palette from the GIF file and do a direct swap to get colors in the right spots (I think).

[Boaster]

Akorse I find it after I post a substitution.

FireDwarf.rar (740.98 KB)

[eyesodilated]

THANKYOU!
I live in Texas and when the winter storm came through my laptop screen froze and actually expanded until it tore itself apart. We were totally unprepared down here and my house is designed to have heat flow out so it got crazy cold. I just got a new computer and will be working on this again. I have many new ideas how to fix the frame jumps and am eager to get started.

I was thinking if I could make the smallest map possible so I could isolate the Sprite better but I'm a little rusty. I was also working on a UV map grid that I would use as a mount to record the frame displacement using pixel math. That's assuming the mount stays in centered.

I keep having bad luck with my computers over the years, but I got a brand new laptop so that helps alot.

Hope everything is doing well with you!
Will be back soon!