[BETA] Danimator - Beta2 is L I V E (p. 4)

Any utility that assists in the creation of mods, assets, etc, go here.
Forum rules
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.

Got a cool project idea but nothing else? Put it in the project ideas thread instead!

Projects for any Doom-based engine (especially 3DGE) are perfectly acceptable here too.

Please read the full rules for more details.

Re: [BETA] Danimator -- "A friggin' animation program!"

Postby Theshooter7 » Sun Dec 27, 2015 4:20 pm

Spoiler:

I hope every one had a Merry Christmas/Happy holidays! I apologize that this release took like 4 months to produce, but it's with good reason: it is HUGE. But enough with excuses right? Let's get to the damn changelog (without a spoiler, cuz it deserves to be looked at)

(Items in BOLD are major features/changes)

  • Fixed opening Project didn't set timeline max value of state correctly
  • Fixed some rendering artifacts in the sprite view
  • Fixed play/stop animation tooltip showing "play animation" when it should read "stop animation"
  • Fixed being able to use the editor controls after deleting a state, causing possible crashes
  • Fixed bug where an embedding option was not saving to config file
  • Fixed some text alignments
  • Fixed bug where you could delete the default blank sprite/sound options in the resource lists
  • Fixed allowing one to open multiple code view windows
  • Fixed potential bug where sprite offsets could be adjusted during animation playback
  • Fixed size of File menu bitmaps being larger than intended
  • Fixed adding sprite or sound resources of the same name not replacing already loaded ones (instead they are silently ignored; might revisit this in the future)
  • Fixed allowing spaces in state names; all white space is now cleared from states when entered
  • Fixed the "play sounds" option checkbox not actually working
  • Project name now shows up in the titlebar when saved or loaded
  • Slight change to DECORATE code formatting (one less tab indent)
  • Reduced size of Code window a bit to accomodate (less screen cluttering)
  • Lots of code refactoring for cleanliness (still not perfect though)
  • Added bilinear filtering option to the Settings menu
  • Removed the minimum 2-frame requirement; states can now be created with just 1 frame (if it is meant to be an empty state with just a flow control: add it into your code manually)
  • Added mouse scroll wheel zooming and zooming capability
  • Added data columns to state and resource lists indicating additional information like frame count, dimensions, etc.
  • Added Undo/Redo system for most editing actions
  • Added Stencil option to hide parts of the sprite frame that go outside of the visible area
  • Added a current frame display in the status bar, indicating the current frame number in the timeline
  • Replaced +/- icons for add/remove frame with new custom ones
  • Increased range of X/Y offset spinners from +/-1024 to +/-65535 (kinda overkill but hey, it's allowed!)
  • Added notification in status bar for when a save occurs
  • Added TEXTUAL, a visual TEXTURES editor/compositor (see information below)
  • Allowed access to Resource controls without states, due to the new save format accepting this and the introduction of TEXTUAL
  • Added "Apply Sprite/Sound" buttons to the resource panels to remove the obscure method of utilizing them (though the old double-click ability is still present)
  • Added an application icon (wowie!)
  • Added a number of warnings for when potential errors or permanent actions are being taken. These warnings can be disabled in the Settings dialog
  • Added a sprite previewer that displays above the resource list (can be disabled in the Settings dialog)
  • Added drag and drop capability for sprites; one can now drop sprite images onto the appropriate resource list to load them
  • Added a Batch Action dialog which allows (off)setting of sprite offsets or tics across multiple frames at once
  • Added Copy and Paste actions for single animation frames
  • Added the ability to export animation states to an animated GIF image via the right-click context menu (with some limitations; see below)
  • Added an Import and Export options to the menu bar. Users can export loaded resources and custom textures to a .danres file which can then be imported into other projects as embedded data.
  • Added the ability to import SNDINFO lumps. Danimator will ask for the lump, and then a base directory to search for sound files, then it will parse the SNDINFO and load appropriate sounds with matching SNDINFO entries.
Spoiler: Shortcut keys

Spoiler: What is textual?

Spoiler: GIF Export limits


Apply pressure to this link to download Beta 2!
For 32bit or 64bit Windows Operating systems, requires an OpenGL-capable graphics card

I have also put together a small package containing 2 samples (at current): the pistol example from the screenshot, and an atlas example with a hand sheet set.
The package also contains a simple documentation guide going over the basic usage of the program and how to navigate it.
Click here to download the sample and documentation package

===================================================

Feel free to leave comments, feedback, bug reports, etc. Or if you'd like to submit a sample to include in the sample package, feel free to post it! :D
Last edited by Theshooter7 on Fri Jan 15, 2016 12:38 pm, edited 1 time in total.
User avatar
Theshooter7
Don't talk about Fight Club
 
Joined: 06 Mar 2006

Re: [BETA] Danimator - Beta2 is L I V E (p. 4)

Postby Nash » Sun Dec 27, 2015 4:46 pm

O_____O

I've said this before but I'll say it again; Shooter, this is literally a fucking game changer for ZDoom modding. It's up there with the likes of GZDoom Builder and SLADE in my opinion; must-haves for a modern ZDoom development environment. Ten thumbs up!

Will report back if I find any problems.
User avatar
Nash
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Github ID: nashmuhandes

Re: [BETA] Danimator - Beta2 is L I V E (p. 4)

Postby Henix_Aurorus » Mon Dec 28, 2015 7:44 pm

Sounds awesome. I'll see about fiddling with the new version later- I've been meaning to fix my minigun animation, so this is the perfect excuse to do exactly that.
User avatar
Henix_Aurorus
Destroyer of Worlds. I guess.
 
Joined: 27 Aug 2013
Location: The Endless Void
Discord: #6038

Re: [BETA] Danimator - Beta2 is L I V E (p. 4)

Postby wildweasel » Tue Dec 29, 2015 11:34 pm

congratulations on your new home paul

(by which i mean i moved the thread and stickied it to Editing)

[EDIT] Actually I have a bug report; I crashed the program by double-clicking on the title bar. I wanted to maximize it but didn't realize I wasn't supposed to do that.

[edit edit] Actually hmm. It works fine now, which pisses me off because dammit I thought I had a reproducible bug and it turns out I didn't.
User avatar
wildweasel
change o' pace.
Moderator Team Lead
 
Joined: 16 Jul 2003

Re: [BETA] Danimator - Beta2 is L I V E (p. 4)

Postby Nash » Fri Jan 01, 2016 2:32 pm

My old .danproj project seems to be openable without problems in the latest beta, so thumbs up to that. :D

Now, some feedback (as usual):

1) Minor nitpick: would be cool for the DECORATE code viewer to use a monospaced font
2) Recently opened projects in the File menu
3) Tooltips for the Options checkboxes that explains what each option does would be useful
4) CRASH when trying to turn off bilinear filtering. Consistently reproducible
5) (Minor) Zoom percent max only goes up to 175%... can you make it 200%?
6) TEXTUAL does not show zoom percent
7) TEXTUAL can't use mouse to drag a layer's X/Y position actually it's possible, but the red hitbox seems to be really small and is not influenced by the sprite content (for a sprite I was working on, the draggable hitbox only appears waaaay to the left off the actual gun sprite, in the empty void!)
User avatar
Nash
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Github ID: nashmuhandes

Re: [BETA] Danimator - Beta2 is L I V E (p. 4)

Postby Theshooter7 » Fri Jan 01, 2016 4:31 pm

Nash wrote:My old .danproj project seems to be openable without problems in the latest beta, so thumbs up to that. :D

:wink:
Nash wrote:1) Minor nitpick: would be cool for the DECORATE code viewer to use a monospaced font

I'll see about changing font settings, hopefully wxWidgets can allow this without too much fuss (without a custom wxTextCtrl). Might even implement an option in there somewhere for it.
Nash wrote:2) Recently opened projects in the File menu

Certainly doable. I can probably get it in for the next beta (I suppose from here on out, updates will simply be more incremental with bugfixes and smaller feature additions, rather than the massive overhaul that beta1 -> beta2 was)
Nash wrote:3) Tooltips for the Options checkboxes that explains what each option does would be useful

I actually forgot to do this. :o Consider it done!
Nash wrote:4) CRASH when trying to turn off bilinear filtering. Consistently reproducible

Proooooobably forgot to add a check somewhere or something. <_< I'll look it over and fix it.
[EDIT] Found the problem: it was caused when applying setting changes, so any settings change would actually cause the crash. The problem was that I forgot to remove two CVAR changes that were trying to access invalid pointers, causing the crash. Fixed.
Nash wrote:5) (Minor) Zoom percent max only goes up to 175%... can you make it 200%?

Sure, I can set it to whatever. Might as well max at 250%? 175% was just even for the zoom meter (which looked nicer at the time), and during testing on my 1080p monitor at fullscreen, seemed to be enough to give a good level of zoom with the viewport maximized. Nothing wrong with raising it though :D
[EDIT] Actually just did some testing, and at 200%, the near clipping plane of the viewport is hit, and beyond that, the image becomes inverted due to projection transformations becoming inaccurate, so would 195% being the cap be enough?
[EDIT 2] Actually one way to resolve this is to scale the sprite image instead of moving the camera, but that could get a bit complex. Might be something to do later or for someone to do when the source is made available.
Nash wrote:6) TEXTUAL does not show zoom percent

Do you mean the view zoom or the Texture scaling? For the former, it shares zoom level with the animation editor, but if it's not reflecting the amount properly, then that would indeed be a problem. I'll test it out myself though as well until there is some clarification :p
Nash wrote:7) TEXTUAL can't use mouse to drag a layer's X/Y position actually it's possible, but the red hitbox seems to be really small and is not influenced by the sprite content (for a sprite I was working on, the draggable hitbox only appears waaaay to the left off the actual gun sprite, in the empty void!)

Any particular steps to reproduce? Do you have a sample project I can open and test against? The tiny hitbox issue should only happen if an invalid texture is being accessed during drawing (and hence draws an empty texture instead). It is possible this could happen in the event a resource is deleted, although there are checks against this, but I admit that with just one guy doing whitebox testing and another friend doing limited blackbox testing, there is only so many cases that end up being covered.
User avatar
Theshooter7
Don't talk about Fight Club
 
Joined: 06 Mar 2006

Re: [BETA] Danimator - Beta2 is L I V E (p. 4)

Postby Crudux Cruo » Mon Jan 18, 2016 8:25 pm

Hey, i tried this out and it's pretty nifty, but i have two gripes about the program so far.

1.) it does not center at the middle when calculating frames at 0,0. the crosshair is way off.

2.) it does not accurately portray a hud enviroment, so im never sure where center is, even if the crosshair is correct.

suggestions:
-grid option that zeroes in on the center of the screen
-hud bar marker so i know where the hud bar is and near accurate replication of game screen dimentions.
-possibly a screenshot background of map01 as an optional background?

the reason i found this out is i'm working on a project. at first, i moved things to the crosshair, thinking that was center, but realized that 0,0 was at the corner. no biggie. but then i made animations that looked objectively good to me and found that they were way over the top, because i couldn't gauge the impact.

regrettably, i ended up having to resort to traditional methods.

I do like everything so far, and it has not crashed on me so far. Thanks for your work on this, hopefully these issues are addressed so i can enjoy your program.
User avatar
Crudux Cruo
"It's howdy doody time kiddies, the bad man is here."
 
Joined: 11 Apr 2006
Location: California

Re: [BETA] Danimator - Beta2 is L I V E (p. 4)

Postby Theshooter7 » Wed Jan 20, 2016 2:43 pm

Crudux Cruo wrote:1.) it does not center at the middle when calculating frames at 0,0. the crosshair is way off.

Can you provide screenshots of what you mean? I know on the wiki that there is a mention that Offset(0, 0) has different behavior and Offset(0, 32) is actually supposed to be the default sprite location, but in my testing this behavior did not seem to be the case. I could have been mistaken though, especially as I only tested it on a 16:9 aspect ratio. On that note, what resolution are you playing/testing at?
Crudux Cruo wrote:2.) it does not accurately portray a hud enviroment, so im never sure where center is, even if the crosshair is correct.

This is fair; currently it best supports fullscreen HUD modes and does not consider a status bar. I could add support for setting one in the future since people may have custom statusbar heights and may want to adjust for them, although I feel animating your sprites for fullscreen is the most flexible.
Crudux Cruo wrote:suggestions:
-grid option that zeroes in on the center of the screen
-hud bar marker so i know where the hud bar is and near accurate replication of game screen dimentions.
-possibly a screenshot background of map01 as an optional background?

#1 I'm not certain what you mean precisely. (0, 0) will always be the upper left corner of the screen, though it should also be noted that ZDoom itself makes (0, 0) the same positioning no matter the aspect, so for example (0, 0) will appear a distance away from the left edge of the screen on widescreen aspect ratios because of this. This has the obvious benefit of various sprites staying aligned properly at all times.
#2 As mentioned above, I can probably implement this sometime in the near future.
#3 This was already planned. :) You would be able to set a custom background color, or set a picture graphic to use for visualization (of which Danimator would come with a handful of presets, including Map01).
Crudux Cruo wrote:the reason i found this out is i'm working on a project. at first, i moved things to the crosshair, thinking that was center, but realized that 0,0 was at the corner. no biggie. but then i made animations that looked objectively good to me and found that they were way over the top, because i couldn't gauge the impact.

regrettably, i ended up having to resort to traditional methods.

I do like everything so far, and it has not crashed on me so far. Thanks for your work on this, hopefully these issues are addressed so i can enjoy your program.

The only thing I can say is that you should make sure your sprites have no internal offsets. This means going into SLADE with all your graphics loaded in, and setting the GFX offsets to (0, 0). If needed (i.e. you are building a pk3), then re-export the images with the fixed offsets back to your graphics folder(s). It takes only a moment and should fix any alignment issues that I suspect would crop up. Take a look at the PistolExample.wad in the samples package to get an idea of how the sprites are setup (if you want to see it in-game, load it up and use the console command "give PistolExample" and it should auto-switch to it). I say this in particular because I have used this program myself many times in testing to make sure things come out correctly, and the PistolExample is one simple example wad that was produced almost entirely from code generated by Danimator (the only exception is the idle frame, which I plan to add a solution for handling that in a future update). And the end result matches up perfectly.

I don't deny however that there needs to be some better handling for this, as it seems to be a rather frequent error. I'll be including tools in the future to allow stripping offsets of entire directories for convenience, as well as a way of showing and handling internal offsets within the program.

Now, if you've already done this, then I would appreciate additional screenshots, a project file, and/or a sample wad/pk3 to test against (you may post them here or PM them to me if you'd like). I don't doubt your concerns, but most often the case with alignment inaccuracies are due to a misunderstanding of something or a user error. If there ends up being an actual problem, I need things to test with so I can step through the code with the project open to figure out what went wrong. :)


On that note, still waiting on Nash for further comment on some things. :lol:
User avatar
Theshooter7
Don't talk about Fight Club
 
Joined: 06 Mar 2006

Re: [BETA] Danimator - Beta2 is L I V E (p. 4)

Postby ZzZombo » Wed Jan 20, 2016 8:56 pm

Holy shit! Nice work!
ZzZombo
 
Joined: 16 Jul 2012

Re: [BETA] Danimator - Beta2 is L I V E (p. 4)

Postby Crudux Cruo » Tue Jan 26, 2016 11:32 pm

So the issue i described is that the center of the screen is not the actual crosshaired center (0,32) and that there is no guides or markers to let you know where you are except the x,y enter box at the bottom left. I play/work at 16:9 ratio

I do realize that the game interprets the sprite at the top left as 0,0. HOWEVER, when animating this does not replicate the center of the screen; the actual numbering is useful in two different scenarios: Items and weapon placement. Animating is done by offsets from the orginal sprite positions, however, so then i'd think it'd be more practical to have the crosshair zero in on the exact middle of the sprite you add.

This can be solved in a few ways:

1.) Be able to set sprite orientation to 0,32 each frame for animation purposes. So say i have it at -120,63 or something to get the gun to point at the crosshair, i set the sprite at that level (and subsequent sprites), then set them as the absolute 0,32 for the purposes of animating. easy to implement, but more work to use

2.) have a scrollable grid enviroment in which you can focus the center on 0,0, rather than having to move coordinates. harder to implement, but infinitely more user friendly

As it is now, unless i have my sprites at 0,0 exactly and use NOTHING BUT OFFSETS, which is very inconvenient, your program calculates frame differential in absolute terms, as if placing an item or weapon sprite, not in offsets, which is what the game code actually registers.

for those reasons im having issues using this program effectively.

ALSO, its absolutely imperative that the following be understood in either system...
The hud cut off for sprites. i cant tell where they get cut off or not in your program, so on top of the other stuff, i really have no clue what looks good or not till i boot up.
The absolute center of the ingame screen. the crosshair is too general when working with pixels, this needs a grid outline or a dead center solid crosshair to mark it
Attachments
PIC1.PNG
User avatar
Crudux Cruo
"It's howdy doody time kiddies, the bad man is here."
 
Joined: 11 Apr 2006
Location: California

Re: [BETA] Danimator - Beta2 is L I V E (p. 4)

Postby Jeimuzu73 » Sat Mar 05, 2016 10:52 pm

Can there be a duplicate button which copies the previous frame? I don't want to manually copy the offsets of the previous frame so many times.
Also, can there be a rotation button to rotate the sprite (by 1 degree instead of just 90-degree angles) and maybe a resize button?
User avatar
Jeimuzu73
Name's Odd. James Odd.
 
Joined: 04 Jul 2011
Location: Dropping today in Station Square.

Re: [BETA] Danimator - Beta2 is L I V E (p. 4)

Postby Theshooter7 » Wed Mar 23, 2016 10:10 pm

MJ79 wrote:Can there be a duplicate button which copies the previous frame? I don't want to manually copy the offsets of the previous frame so many times.
Also, can there be a rotation button to rotate the sprite (by 1 degree instead of just 90-degree angles) and maybe a resize button?

Perhaps I could add a shortcut in for such a function, but right now it's as easy as just Ctrl+C -> Insert Frame -> Ctrl+V to paste the previous frame. From there you can just change the sprite or whatever you need.

As for rotations: it's in 90-degree intervals because it's meant to stay in line with ZDoom's limitations. Singular degrees do not work in ZDoom so there would be no use putting that into the program either.

And finally, what exactly do you mean for a "resize button"?
User avatar
Theshooter7
Don't talk about Fight Club
 
Joined: 06 Mar 2006

Re: [BETA] Danimator - Beta2 is L I V E (p. 4)

Postby Jeimuzu73 » Thu Mar 24, 2016 11:23 pm

Resizing the sprites per frame to make them bigger/smaller. Maybe I'm asking for the wrong thing here, or I should just have all the rotated/redrawn sprites beforehand. :oops:
User avatar
Jeimuzu73
Name's Odd. James Odd.
 
Joined: 04 Jul 2011
Location: Dropping today in Station Square.

Re: [BETA] Danimator - Beta2 is L I V E (p. 4)

Postby arookas » Fri Mar 25, 2016 3:35 pm

This program is simply amazing. I don't know how I've made it before without something like this. I've already made a pretty sweet weapon reload animation with it using TEXTURES. Besides the usual grid/crosshair suggestions, I'd like to suggest a few things:

  • Making the arrow keys move te sprite offset on the current layer/frame, or maybe some lock X/Y toggle. This could make it easier fine tuning offsets of sprites without moving the mouse too much.
  • The ability to bake/export the sprites made in the TEXTURES editor to a png
Keep up the great work!
User avatar
arookas
...but only sometimes.
 
Joined: 25 Jan 2011

Re: [BETA] Danimator - Beta2 is L I V E (p. 4)

Postby enderkevin13 » Wed May 11, 2016 8:24 pm

A couple questions:

1. Can I add A_Raise states and such through here?
2. Am I able to make smooth animations through this?
3. What type of file do projects save as?
User avatar
enderkevin13
Official abbadon of ZDoom
Banned User
 
Joined: 07 Jul 2015
Location: :noiƚɒɔo⅃

PreviousNext

Return to Editors / Asset Manipulation

Who is online

Users browsing this forum: ZZYZX and 1 guest