[Enchcment] dimgconv --offsetter : Add a way to export offsets to a dimgconv.txt control file + animation play button.
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
Start by locating dimgconv’s --offsetter GUI editor and command-line entry points; the issue names no source files or tests. The request spans offset import/export, command-line embedding and extraction, and animation playback, so first clarify scope with maintainers. Done would mean implementing an agreed subset and verifying the requested offset-file behavior or GUI playback.
Written by the indexing model from the issue text.
Description
Background Info
Been using the new (to me) dimgconv --offsetter GUI Editor. So far it is very cool, but I think 2 additions to dimgconv may be handy for people to help keep the "sift editable" systems of doomtools working.
At the moment, as far as I can tell, offset chunks are embedded into the files themselves by the GUI tool. So most sRGB apps will destroy those chunks when editing and resaving the files, and they will absolutely be lost if you are saving over the file from a master document that you are doing your editing in or from a backup pre-chunkSaving.
DoomTools already has a way to make this much cleaner. Using the dimgconv.txt file to set the offset chunks. Now the actual source images can be modified in anyway, and the offset data is read fro ma perma txt file, not form the image. Meaning the open formate and always editable design style of doomtools is preserved.
A "simple" set of command line functions and import / export functions in the editor could make the GUI much more aligned with what I belive the design goals of doomtools is... having your project in a malleable and editable state, ready for building.
Preposed Edditions
1a) After setting offsets in the editor. Have a way to "extract" those offsets and save them into a dimgconv.txt that contains all the offsets as instructions to the image converter part of a doommake build. This way we can get the offsets working, visually in the editor, save them out as build instructions and then if during project course the offset chunks in the images are destroy somehow, it will not matter, for they are being read at build time from the txt file.
Example Output TXT file.
HD3XA0 graphic 31 66
HD3XB0 graphic 34 66
HD3XC0 graphic 37 66
HD3XD0 graphic 41 69
1b) In addition, if there is an export, might be cool to have a import button. So you can load the offset chunks into the visual editor, and then continue editing.
2a) This extracting of offset chunks, to a working dimgconv.txt offset file, would make a cool command line function. dimgconv -extractOffset a command line that simply reads the current directory of images, and outputs the dimgconv.txt offset file for those images. Allowing the conversion of decades of embedded offset chunk data to be used be doomtools.
2b) As with the gui a commandline utility to embed the dimgconv.txt offset data would also be cool. dimgconv -embedOffset . Where it simply reads the textfile, matches the filenames, edits or adds the offset chunks, producing image files that now contain the offset chunks.
- Those are the real suggestions, but a "that would be super nice" would be a play button in the GUI. It would need a play button, and a place to enter a value, like 8 for 8 tics, for example. Pressing the button then cycles and loops through the selected images. This would already be an enhancement to just pressing up and down arrow... but it would also allow you to select images not in a sequential line. For example to see all the front frames of a missile ball, and how they are aligned to each other.
For your Consideration
All the offset stuff is achievable via python scripts (I can share if you like), but I think it might be very cool to have this as part of dimgconv.exe itself.
The animation button would be very cool, but I would say not as important as a dimgconv.txt exporter.
For your consideration
--aJynks
- Dominant language
- Java
- Stars
- 78
- Forks
- 6
- Avg merge
- 17h 32m
- Merged PRs (30d)
- 1
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from MTrop/DoomTools
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
enhancement
Difficulty 3/5 Half a day Newbie friendliness 62/100
-
help wanted
Difficulty 3/5 1-2 days Newbie friendliness 50/100
-
enhancement low priority
Difficulty 4/5 3-5 days Newbie friendliness 43/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
apache/rocketmq-dashboard#7250 ·
Maintainers usually reply within 3 days
-
Bug
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
ignatov/intellij-erlang#1093 ·
-
HttpMaxFrameSizeTest.sendOversizedMessageTest() passes silently when maxFrameSize is not enforcedOpen
Difficulty 1/5 Under an hour Newbie friendliness 90/100
apache/activemq#2706 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
federicoiosue/Omni-Notes#1032 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
unitycatalog/unitycatalog#2025 ·
Maintainers usually reply within 4 days