----------------------------------------
TO-DO LIST FOR YADEX
----------------------------------------
General
- Automatically adapt to level to edit; if it's a Doom level (ExMy),
reread doom.wad, if it's a Doom II level (MAPnn), reread doom2.wad.
what if it's a Heretic level ? It must be possible to tell a Heretic
level by the special sector & thing types.
Command line
- Add option -e like in sed and Perl. Auto quit at end or not ?
- Add option -f like in sed ?
Configuration file
- Add operator ".=" (E.G. "iwad_dir .= ,/foo/bar"). Perhaps implement
real lists. Perhaps not.
Variables
- Make variables objects instead of C++ variables. It should not be
necessary to recompile everything each time you want to add a
variable. Still be able to generate a list of all known variables...
- Better support for changing of configuration variables from the
editor.
- Add a way to set variables from the command line ("-sname=value" or
something like that).
- Setting options: add a "set name value" prompt command.
- Setting options: make "set" stop after each screenful.
- Setting options: modify the "Preferences" menu so that all options can
be changed from there and modifications are saved.
Game definitions
- Move thing groups colour from .ygd to .cfg.
- Generalize the principle of game by replacing iwad[123]= by iwad= in
different sections of the .cfg.
- Fix TranslateToDoomColor().
- -g should accept anything as long as <anything>.ygd exists.
- Have to think of how to handle different games : Doom, Doom II and
Boom all have a lot in common. Try not to duplicate all this, perhaps
by _include_ing a "generic_doom" block, which contains _if_s before
features not common to all versions.
- It is prob. possible to crash the program by entering weird things in
LoadGameDefs. For example, shortdesc is not truncated and the current
number of "raise floor" types will probably make the menu "overflow"
the screen. DisplayMenu() should fix the y-offset if necessary.
- It is possible to define the same group twice or use a non existing
group.
- LoadGameDefs: try to waste less memory if possible.
- FreeGameDefs(): apparently does not unallocate everything. It's
immaterial since it's only called just before exiting but I'll have to
fix it one day.
- Enter two iwad names for the same game (E.G. doom.wad and doom1.wad).
- Add list of animated flats and textures.
- Add "height" and "is_obstacle" fields to things definitions.
- Add flat width and height.
- Add min and max player and deathmatch starts.
- Add default level names.
- Move the definition of special sector tags out of the exe and into the
ygd files.
- Gadget: add level names (E.G. "E1M1" -> "Hangar").
- An attempt to define twice the same thing/linedef/sector type
should be detected and reported.
- The basename need not be in the configuration file; it should be in
the ygd (E.G. iwad_base = "doom.wad,doom1.wad")
- The .ygd collection has grown so large that it has become difficult to
maintain. For example, changes made to strife.ygd must be propagated
to strife10.ygd by hand. There is a lot of duplication : the 150 kB of
game definition data boil down to 30 kB after piping into sort | uniq.
I would like to implement an include directive and reorganize
accordingly :
_boom.ygd in Boom but not in Doom*
_doom.ygd in all versions of Doom >= 1.0
_doom16.ygd in Doom 1.666 and above (linedef types)
_doom2.ygd in Doom II (things)
_heretic.ygd in Heretic only (things, sector types)
_mbf.ygd in MBF but not in Boom
_strife.ygd in all versions of Strife
_tgroups.ygd all things groups ?
_zdoom.ygd in ZDoom but not in Boom
doom.ygd include _doom; include _doom16
doom04.ygd ?
doom04.ygd ?
doompr.ygd ?
doom2.ygd include _doom; include _doom16; include _doom2
hacx.ygd ??
heretic.ygd include _doom; include _doom16/_doom2 (?); include _heretic
hexen.ygd no change
plutonia.ygd include doom2: iwad_base plutonia.wad [solves Colin's pb]
strife.ygd include _strife; texture_format strife11
strife10.ygd include _strife; texture_format normal
tnt.ygd include doom2: iwad_base tnt.wad [solves Colin's pb]
The rules for locating of relative includes :
1. search the current directory,
2. search the directory where the parent ygd file is,
3. search the standard directories.
If an include has a bad magic, don't abort, just keep searching for
one that has the appropriate magic (but warn). If an include was not
found just print a warning and continue ?
- Allow overriding of a previous linedef type / thing type / sector type
definition (currently it just *adds*).
Game and wad support
- Some wads have sidedefs with a sector# of -1. Apparently, those are
always unused sidedefs but perhaps there is something to do about it.
dyst3, mm, mm2 map13,28, wads2/1kill (e2m2,6,7,8,9), wads2/adieu
wads2/ebola, wads2/requiem (map03,08,etc).
- Some wads generating a flurry of messages "updating entry ''" when
loaded (11fortko, 1_on_1, chase21). Fix that.
- Support Boom extensions, at least by allowing to enter hexadecimal
linedef types etc.
- Some working pwads are not pwads. 1sthell is an iwad.
- Some wads have a large number of unused vertices in the middle. base,
phobos, 2wad/dks_e1l1, 2wad/dks_e1l3, amanda2 (no tail !), atica,
badblu35, dmdv (tail 76% unused 45/469), drdeath (unused 69/1382),
spit e1m2 unused 661/816 tail 0
- Perhaps it would make sense to forget the directory completely when
it's not needed ? Each entry takes 16+4+4 = 24 bytes. Here are the
number of entries in the iwads' directories :
Iwad Total entries Level entries
Doom 2306 54 kB 36 9 kB
Doom II 2956 69 kB 32 8 kB
Heretic 2415 56 kB 28 7 kB
Hexen 4249 99 kB 32 9 kB
That's a lot. When do we use the directory ?
- During an editing session, to display the flats.
- During an editing session, to display the textures (TEXTURE1,
TEXTURE2, PNAMES, patches).
- During an editing session, to get the PLAYPAL.
- When loading or saving a level.
- At the prompt when saving or extracting a lump (not often).
All the levels are kept in memory all the time, even though they're
used only when saving and reading. The sounds, musics and graphics are
never unused (about 450 entries = 10 kB).
- The message "Use F_END instead" should be displayed only once, when
the pwad is loaded, not each time you open an edit window.
- Fix OpenPatchWad() so that, if a pwad contains FF_START ... FF_END
F_END (mm2.wad), the F_END does not replace the F_END from the iwad,
as this causes a spurious "this wad uses FF_END" warning.
- icarus.wad uses F_END + FF_END. Sigh.
- Gothic2 uses F_END but not F*_START. Therefore, the custom flats don't
show. FMH !
- When a pwad contains F_START F1_START ... F3_END F_END, the F_END
replaces the one from the iwad and this causes Yadex to think all
following lumps are flats (sod.wad).
- With hacxsw.wad, which replaces all patches and has P_START/P_END
labels, get a "No matching P_END for P_START in hacxsw.wad". Surely
the same problem as with F_END ; OpenPatchWad() uses the P_END from
the pwad to replace the P_END from the iwad.
- viewpat: mm.wad and mm2.wad put patches directly in the master
directory, without any surrounding P_START/P_END. viewpat sees the
replacement patches but not the new ones of course.
- Now that wad_read_i16() and wad_read_i32() don't abort anymore, check
the code that uses them.
- Add definition for sector tag 667 (MAP07).
- Colin wants to be able to use the Final Doom iwads without having to
type "yadex -iwad2 /foo/bar/tnt.wad". He suggests either (1) adding a
new game or (2) changing the code so that "yadex -iwad2 tnt.wad" looks
for tnt.wad in the iwad2 directory defined in the config file.
- Graphics: Yadex uses no COLORMAP, instead of COLORMAP 0. In practice
COLORMAP 0 is very close to no COLORMAP but...
- Be able to edit levels with silly names like "QD2" (cf. qdoomtst.wad).
This implies not replacing entries in the master directory anymore !
Doom alpha
- Fix wrong things definitions and add missing ones.
- When loading a pwad with several contiguous levels, every second level
is discarded. See wads2.cc.
Doom press release pre-beta
- Matt says there is a separate resource file named texture2.lmp.
Hexen
- Hexen has some flats with a size of 8 kB.
- Generate the "thing" directives by either parsing info.c or ripping
off the one in DETH.
Heretic
- Heretic has some flats with a size of 4160. Is this why DeuTex accepts
64x65 flats ?
Strife
- Extract the radii from the exe.
- Matt says sector tag 999 means "slam shut on alarm".
- Matt wonders what RIFLB0 is and what's the difference with RIFLA0.
- Incorporate what's only in the USS.
Messages and reports
The reason for emitting messages :
- Bug (internal error, unexpected condition in the program that
indicates the existence of a bug somewhere)
- Error in the iwad (something looks fishy)
- Environment error (not enough memory, failure to open a file for
writing, failure to create a subprocess, failure to allocate X
resources or to connect to the X server, etc.)
- Informational (to inform the user on what's happening)
- Verbose messages (like informational, except that they are not on by
default and are meant as an aid to debugging)
- Syntax error messages
- Usage message
- Copyright message
Certain messages could be prefixed by the name of the program
("yadex: "). I think this would be only useful for messages that are
issued while Yadex is not in interactive mode. For messages that are
meant to happen only in interactive mode, the prefix is a waste of
screen real estate.
Messages can be printed to stdout, stderr and on the window, or a
combination of these. Future versions of Yadex might have a GUI-only
interface and stdout/stderr messages might be lost, then. To print
messages on the window, it would be better to have a scrollable
message textbox at the bottom than alert boxes, that require constant
interaction and leave no trace.
Bug messages should come with a "THIS IS A BUG" notice and an
exhortation to go tell the maintainer.
If possible, the message printing function(s) should be
interface-independant.
There should be a smart handling of carriage returns. Instead of
inserting '\n' in the format string, one should be able to specify
whether the message should start on a new line and whether the message
should be followed by a newline.
There should be some handling of indent. One should be able to start
and end an indented block. The output routine would take care of the
printing of the indent whitespace.
If possible, it should be possible to write to several channels
(indent levels) asynchronously.
Confirmation
- Fine selection of automatic confirmations ("split linedef when
inserting new vertex", "split linedef when moving vertex", "merging
vertices", etc).
- When moving a bunch of vertices, do not check for vertex-on-linedef
condition if both vertices of the linedef were part of the vertices
that are being moved.
Old bugs to fix
- When splitting and merging sectors, some of the sidedefs in the split
sector are given the wrong sector number.
- When splitting a sector, sometimes get erroneous messages like
"vertices A and B not on the same sector" or "cannot find a closed
path", etc. I have already got "no sector between vertex A and vertex
B" ; save, quit, edit and try again : it works !
- Let RIGHT work after SPACE (works if no mouse driver!)
- DOS: understand why mouse pointer moves 8 pixels at a time and fix
that.
- I already got erroneous "sector not closed" messages. The last time I
remember, it was on a tiny triangular sector (base=16, height=2).
- When merging sectors, linedefs sometimes get only 1 sidedef...
- InputInteger limits numbers to [-32749,+32749].
- InputInteger doesn't accept hexadecimal numbers.
- If you do "delete linedef and merge sectors" when it's the same sector
on both sides of the linedef, the sector is deleted.
- Check that all sectors are closed : chokes on pseudo sectors (s1=s2).
I've verified that unclosed sectors, whether single ou double sided
don't disturb Doom. However, some look ugly. The checking function
should be modified so that only ugly unclosed sectors are reported.
- Create new sector from linedefs: should be smarter.
Editing in general
- Implement undo and redo.
- Move things along with vertexes
- Add a "global" or "everything" editing mode. In that mode, moving,
deleting, duplicating affects all objects (things, vertexes...)
- Move cursor : jump to next object in direction ...
- Move objects n grid steps in direction ...
- Move objects n Grid steps in direction ...
- Move object to nth next grid position in direction ...
- Move object to nth next Grid position in direction ...
- Flip info window on either side of the screen.
- Gadget: show level with different orientations, i.e. with logical
north not always being at the top. And rotate the sprite images
accordingly.
- Go to next/previous object in selection.
- Renumbering objects:
- Renumber the selected object by either exchanging numbers with the
object having the target number or bumping all numbers by one. The
former solution has the advantage of being faster. The second
solution has the advantage of not disturbing the relative numbering
of the other objects.
- Make the highlighted object the lowest-numbered (highest-numbered)
one of all the selected objects of the same kind.
- Bug: pasting repeatedly a large number of objects (all the linedefs of
Eternal MAP28, for instance) ends up triggering a segfault. Perhaps
we're overflowing/underflowing the objects arrays ?
- Bug: my tests indicate that out-of-memory conditions are badly handled
(E.G. segfault upon switching to sector mode).
- For very large levels, the lower limit on the zoom factor is too high
to allow showing the whole level.
- Bug: for very large levels, the automatic zoom factor setting is hosed
(instead of using the lowest allowed zoom factor, it falls back on a
rather high value).
- Bug: for very large levels (very low zoom factors), the upper limit on
the grid step is too restrictive.
- Strife's MAP29 is so much to the west (-23,000 or so) that the current
limit to -20,000 prevents from seeing the whole map.
- Cut and paste between wads. at least in a limited way: insert the
contents of a wad at the cursor. involves renumbering all items by
adding the number of such items already existing. E.G. if there are
already 50 vertices, increment the vertex numbers in all the linedefs
by 50. Same thing for sidedefs numbers in linedefs, sector tags (DON'T
increment those above 900!). increment sector# in sidedefs too. that's
all ?
Editing things:
- Thing info box:
- Eye candy: animate the sprites.
- Eye candy: show the sprites according to their angle.
- Numeric thing type : make it optional. Give choice of format between
signed decimal, unsigned decimal and hexadecimal. Default format is
specified by config parameter format_thing_type. Also have a key
binding to cycle between the three.
- String thing type : when unknown, use the format for numeric thing
type.
- Thing angle : when unknown, give choice between signed decimal,
unsigned decimal and hexadecimal.
- Thing flags : have an option to show the numeric value of the flags
field, with a format one of signed decimal, unsigned decimal and
hexadecimal.
- Flip/mirror: allow user to specify whether or not things should
be spinned.
- Thing properties -> type : on selecting group with 0 things, fatal
error PTD1.
- Maintain a list of all things on the level, sorted by increasing
radius. To determine which thing is under the pointer, scan that list
and highlight the first thing such that the pointer in inside the
square of half-side (scale x radius + slack). Possible refinement ; if
several things would be highlighted, highlight the one whose centre is
closest to the pointer.
- Check Doom's behaviour w.r.t. negative angles.
- On the map, if the thing has a root but no sprite by that root was
found, display the root ? (instead of the type)
- On the map, show things according to their angles ?
- On the map, switch between displaying the sprite, the type in decimal,
the type in hex, the root, etc.
- Option to show both the sprite and the square. Or maybe the sprite and
a cross, à la WinDEU ?
- Perhaps choose between sprite and square automatically depending on
zoom factor ?
Editing vertices:
- Change the highlighting algorithm so that it's more bearable at low
zoom factors.
Editing linedefs and sidedefs
- Linedef type : show long name.
- Paint linedef with colour depending on difference of floor height...
- Show several textures at a time ?
- Insert window/corridor/door between sectors. exactly 2 linedefs must
be selected and they must no belong to the same sector. select style;
low window, high window, small door (64x72), big door (128x128-),
user-defined.
- Function: split inner sector with channel:
+---------+ +---------+
| +-----+ | | +-----+ |
| | | | | | | |
| | | | ===> | +-----+ |
| | | | | +-----+ |
| | | | | | | |
| +-----+ | | +-----+ |
+---------+ +---------+
- Function: make plain embrasure:
---+----+--- ---+----+---
| | ===> |----|
| | | |
also "45° embrasure" and "fancy embrasure" (sides are L-shaped).
- Nooks and bosses: add a way to specify width and depth. Maybe have
several predefined dimensions plus user-defined dimensions (set in the
config file). Maybe set textures automatically (EG DOORSTOP and
LITE4). Provide for shapes other than rectangle. Difference with
"Make nook" is that it also splits the sector. Maybe set
automatically floor and ceiling height of new sector.
- Automatically set UTU/LTU when line becomes 2-sided ?
- Reset linedef as double-sided (sets 2S, unsets IM, clears normal
texture, set upper and lower textures, possibly set UTU and LTU).
- Frequent operations : copy upper texture -> lower texture or inverse
set texture. mostly on 1st sidedef set normal texture copy lower+upper
texture = normal texture of adjacent linedef, set lower+upper texture
unpegged, normaltx = -
- Select all linedefs that in same path as the highlighted one. This
can be hairy when the same vertex is shared by more than 2 sidedefs.
Ideas that come to mind :
- only single-sided linedefs,
- only linedefs that have as many sides as the reference linedef,
- called from sector mode: select all linedefs that form the boundary
of the sector and switch to linedef mode,
- only linedefs that form a chain (last (n-1) == first (n)).
- Duplicating/copying linedefs: fix the mess. The ideal would be to
duplicate sidedefs, but to be also able to share them (if asked
explicitly). Maybe by using a modifier when copying like [Alt]...
- Duplicating/copying linedefs: allow user to specify whether or not
sectors should be duplicated too.
- Function to substitute sidedef texture.
- Dragging linedefs is still slower than dragging vertices. But it might
be just because of the overhead of highlighting all those linedefs.
- Another function often needed : "split" a vertex shared between
several linedefs :
| |
--x-- ===> --x x--
| |
The way to use it could be : select one or more linedefs that have a
common vertex. That vertex is duplicated, moved aside a little bit (so
as to reduce the lengths of the linedefs and the vertex reference of
the concerned linedefs is changed. Instead of moving it, it could be
selected for dragging automatically... Could be called "unlink
vertex".
- Cut corner : must select a vertex shared by two linedefs. The linedefs
are shortened and the vertex is replaced by a linedef connecting the
two other linedefs, an forming the same angle with both of them
(typically, 45°)
x--- x--
| ===> /
| x
| |
It should be possible to set the length of the new linedef in an
interactive fashion. But I don't see how to do that without having a
modeful interface.
- Linedef type : give choice of format between signed decimal, unsigned
decimal, hexadecimal. Default format is specified by config parameter
format_thing_type. Also have a key binding to cycle between the three.
- Linedef tag : same thing.
- Linedef flags : give choice between string, signed decimal, unsigned
decimal and hexadecimal.
- If a linedef has a type that requires a tag but its tag is set to 0,
draw the linedef in red.
Editing sectors
- Set floor height to ceiling height - headroom.
- Set ceiling height to floor height + headroom.
- "Change sector reference" or "substitute sector" Change sector
reference for all the sidedefs that reference one of the selected
sectors.
- Paint sectors with colour depending on tallness, brightness,
texture...
- Function to substitute sector texture.
- Dragging sectors is still slower than dragging vertices. But it might
be because of the overhead incurred by highlighting all the linedefs.
- Sectors are sometimes mistakenly considered unclosed and don't
highlight properly. E.G. in ss27bet2.wad, sector #66.
- A DCK-like philosophy could be used when moving sectors :
| |
| +----+ +-+--+
| | | ==> | |
| | | | |
| +----+ +-+--+
| |
- Sector type : give choice of format between signed decimal, unsigned
decimal, hexadecimal. Default format is specified by config parameter
format_thing_type. Also have a key binding to cycle between the three.
- Sector tag : same thing.
- Eye candy: animate flats
- Bug: in sectors mode, [n], [p] and [<] sometimes loop over the same
sector forever because GoToObject() does not do quite the right thing
regarding subsectors. [>] is not subject to this problem because then
[Shift] is on. [If you're confused by this entry, look at the layout
for a french PC keyboard in xkeycaps.]
- Place the sector number correctly. Account for convex sectors
and fractioned sectors. Avoid sloping due to an excess of
vertices on one side. One strategy that comes to mind is
placing it at the centre of the largest area (where
"largeness" is a compound of "surface" and "squareness").
Keyboard interface
- Proposition: in linedef mode, <letter><letter> gives access to
parameter.
- Add macros and key bindings.
Documentation
- Update DEU 5.21 doc...
- Document screenshot.
- faq.html should be included in the distribution.
- Some entries in the FAQ should also be in trouble.html and vice-versa.
Unimportant :
- If bgi= or -bgi specifies a path for the .bgi driver, handle it.
- Search for .cfg in directory where .wad is. hm-hm...
- Nodes: have an option to pipe the output file through BSP.
Flat/sprite/texture viewer
- Use other palettes than #0 (also when saving).
- Use COLORMAPs (also when saving).
- Reimplement "save image to file" with PPM, PNG and perhaps XPM.
- Zoom and scrollbars.
- Add binding to toggle between SW1* and SW2*, cycle through the frames
of an animation. For Hexen, it's much more complicated (3-frame
switches...).
- Display number of patches (and posts, and patch list...).
- Show several pictures at a time.
- Add a flag somewhere to allow choosing a flat/texture that's not in
the list.
- Support pictures higher than 255 and textures higher than 128.
- If the "view" command is given a lower case argument, the positionning
in the list of sprite names is wrong.
- When viewing patches or sprites, the entire view window is refreshed
even though, in most of the cases, the picture to display is much
smaller than that.
DOS/BGI port
- Do more modules splitting (deu.c, ReadConfigFile, menus.c). In
gfx.c, move InitGfx() in a separate module.
- Be able to handle large levels.
- Switch to DJGPP
- Dig *.wad...
- Maybe compress the sidedef struct (30 B -> 12 B).
- Try to waste less space with in-core image of wad directories.
- Respect screen ;
- restore contents
- restore proper number of lines/columns
- Replace putimage() by calls to display_game_image(). Implement the
BGI version of display_game_image().
- Old bug: numeric keypad "." means Del even if Numlock is on.
- Old bug: fake pointer: make it an arrow and not flickering (Ben Davies).
X11 port
- Implement -geometry and -display.
- Add an option like in Xmame to have either a private or shared
colormap (by default shared, at least in map mode).
- Look into *WMHints*()
- When drawing the map, etc, ignore some intermediate events (for mouse
pointer position). Also, when several arrow key keystrokes are in the
input key, just count them and redraw only once.
- Set WM hints (icon name, min size, max size, etc.).
- Find a replacement for bioskey(0) in text mode.
- Look into getting the status of scroll lock.
- Handle KeymapNotify events.
- Show cursor in input boxes and let user move it with arrows and mouse.
- The numeric keypad does not seem to work.
- When there is another colour-hungry app running (like Netscape), get
error upon freeing colours. I think Xmame has the same problem.
- Make sure that input.c intercepts only events concerning Yadex's
window.
- After a resize, pointer_x/y are not updated so the wrong object is
highlighted.
- After a resize, the map is redrawn 3 TIMES ! I know why : the window
manager (FVWM) sends three sets of exposure events. Making drawmap()
and refresh in general able to do partial drawings will eliminate this
problem. And give better performance when moving a thing, or flipping
through the menus.
- Fonts: allow several font names in the config file. The first font
found is used. If none is found, use the default font.
- Fonts: be able to use variable-width fonts.
- With font "variable", in the flat viewer, underscores are not cleared
properly.
- Why do I sometimes get this when closing a window :
X Error of failed request: BadAccess (attempt to access private resource
denied)
Major opcode of failed request: 88 (X_FreeColors)
Serial number of failed request: 503121
Current serial number in output stream: 503135
I've trapped it in colour4.cc :
Warning: error freeing colour <hex number> (<cause>)
If you can reproduce this error, mail me.
- I've heard on comp.windows.x Mattias Engdegård say that bitmap_pad is
relevant. What are the constraints on it, then ?
- Use XShm.
- Perhaps optimize transparency :
pic -> img -> img(scaled) -> ximage, ximage -> pixmap, pixmap
pic -----------------------> ximage, ximage -> pixmap, pixmap
- Time spent within Yadex and time spent within the X server
- When moving sprites at large scale factor, we waste a lot of time in
Sprite::make_bitmap, scale_img and, above all, Sprite::make_ximage.
Making sprites persistent across iterations helps enormously. Do it.
Prompt
- Add access to the prompt from an editing window (":" like in vi).
- Use readline.
- "e" command (and possibly others): warn if too many arguments.
- "e" command: perhaps accept "e 4 2" as synonym to "e e4m2".
Misc.
- Implement several windows at once ?
- Replace all occurrences of BLACK, WHITE, ... by logical colours.
- The highlight proximity should always match the apparent size of the
object (done for things, to be done for vertices and linedefs).
- GetCurObject(): the radius should not be expressed in map units but in
screen units and should depend on the apparent size of the object.
Indeed, 20 is too much for linedefs at high zoom factors and too
little for vertexes at low zoom factors.
- Highlighthing things: if there is a small thing and a large thing in
the same spot, when you're "in" the small thing, it should be
highlighted, even if it's higher-numbered. At the moment, it's the
lowest-numbered thing that's highlighted.
- Externalize occurrences of ".wad".
- Externalize occurrences of ".bak".
- Let the selection include objects of different types.
- There is something that sucks in the edit loop ; when you scroll
without moving the mouse, the selection box always "lags behind"
because its map coordinates are updated only _after_ the next screen
refresh.
- Select all.
- Reverse selection (select everything that's not selected and unselect
everything that's selected).
- Edit functions : copy, cut, paste.
- Crop (delete all unselected objects).
- Persistent box for cropping ?
- BD suggests sector creation à la DCK ([r] then draw box).
- Be able to select objects of several types at once.
- Modelessness ?
- When there are several objects under the pointer, report it and give a
way to access any one of them. Or maybe implement planes ?
- When doing drag-n-drop, should the snap-to-grid be applied to A.
relative position since started dragging B. or to the highlighted
object ? If A, you can't use drag-n-drop to snap-to-grid objects that
aren't. If B, you can't drag correctly objects that are not aligned on
grid.
- Object number: the type should be "i16", not "int" (cf. SelPtr).
- Object number: the test for "none" should not be hard-coded "< 0".
- Browse mode, as in xv and psp, to browse through a large number of
wads.
- Be able to open zipped files ?
- On ProgError(), save current data to a file named yadexcrash.wad. On
startup, if that file exists, propose to use it.
- If DOOMWADDIR exists, use it ? But overridden by yadex.cfg & -iwad
- Texture browser : it's so slow that, even on a K6/200, some textures
are slow to come (AMRIBS). Should cache patches ? 1999-11-28: after
implementing Patch_dir, did not notice a huge improvement.
- Parameters :
- colour# used to represent transparent colour when saving textures,
- rgb used to represent transparent colour when saving textures,
- rgb used to represent transparent colour when displaying textures,
- While dragging or drawing a selbox, prevent Del, Ins, etc. from
working. E.G. Del would suppress the object being dragged !
- Add config file parameters for initial snap_to_grid and
lock_grid_step.
- Scale: make it local to an edit window.
- MadeChanges: make it local to an edit window.
- MadeMapChanges: make it local to an edit window.
- When saving with [F2], ".wad" should be appended automatically.
- Log file: create/update it iff the pwad file is modified.
- Things: the name is sometimes too long and cut off. It looks bad.
- A function that would be really very useful would be the possibility
to change the start/end vertex of a linedef. That could be done by
holding, say, [Alt], down and dragging the start/end until on top of
another vertex. When the button is released, the linedef start/end is
changed and the sector references of the impacted linedefs are
updated.
- Events; generalize internal events and hold refresh until all events
have been processed. Though autoscroll could bite me.
- Delete all those "huge" qualifiers ; means nothing for Unix and the
DOS version should be compiled with -mh anyway. Update: 1999-11-25:
Ha! Ha! Ha! Ha! Ho! Ho! ... I was so young and naive...
- Displaying pointer coords; should look into using PutImageFont().
- [Ctrl][Click]: Press button: do nothing. Release button: select or
unselect IF STILL ON TOP OF OBJECT. Thus we can use [Ctrl] + drag to
copy :-).
- Vertex on linedef: lower tolerance when zoom factor is high. [partly
done as of 1998-12-20 but still needs work].
- Check self-consistency of level data: for each linedef, v1 and v2 must
be either OBJ_NO_NONE or between 0 and NumVertexes and s1 and s2 must
be either OBJ_NO_NONE or between 0 and NumSideDefs.
- Showing linedef textures: several solutions:
- easiest: show raw middle texture,
- easy: show raw upper, middle and lower textures,
- hardest: show as Doom would render it, with offsets, LTU, UTU and
all. Scale it down so as to fit in the window that has a fixed size.
Optionally apply brightness. Maybe show the edge of the neighbouring
walls, it might help for alignment. ISSUE: it might not be a good
thing to respect the length of the linedef as, for long linedefs, it
will force us to scale down too much. For textures that don't
exist, show background with cross. For texture "-", show background
only. For transparent texture, background sees through. It's
probably better to use a special colour (like black) for background
as the user might want to use a bright colour for window
backgrounds, which wouldn't look too good with Doom's dark textures.
- Showing sector textures: optionally apply brightness.
- Goto function: takes as an argument either the centre of the level or
a previously set mark. Like in vi: m<mark>, '<mark>. Maybe '' to go to
centre ?
- Clicking and superimposed objects: if n1 and n2 (n1 < n2) are
superimposed, n1 is not selected but n2 is selected and you click on
them, Yadex thinks you are starting a new selection because
is_selected (highlight) is false.
- objects.cc: GetObjectCoords(): should use center_of_objects() instead.
- Permanently show a 64-wide object to scale ?
- Right-button menus: access to many different menus (no modifier,
[Shift], [Ctrl], [Alt], several of them).
- Cut, copy, paste
- Show properties
- Misc. operations
- Frequently used properties (toggle bit of linedef...)
- Change tool
- Dragging with [Ctrl] on duplicates ?
- Makefile: after changing DEFINES in the makefile, running make does
nothing ! (have to delete manually wads.o and sanity.o)
- Makefile: after hacking for two days on a machine, some objects are
not rebuilt on another machine. Even though yadex.h has changed !
- Menus: when you move the pointer over a pulled down menu is, you can
highlight the objects it hides.
- Replace "insert rectangle"/"insert polygon" by :
- insert pillar (nb. of sides, size)
- insert subsector Differences in floor/ceiling height/textures and
lighting level could be set by predefined styles :
- pedestal (floor + 48, ceiling - ...)
- hanging from ceiling
- teleporters
- In addition of make nook/make boss,
- insert protruding subsector
- insert recessed subsector
- Force the event type to 16 bit. Would make us save a few kB in the
menus (shortcut_key and cooked_shortcut).
- Change the way the menu_c class is defined so that it wastes less
space. Should probably look into other classes too. Why not using
bitvectors instead of arrays of ints used as booleans ?
- The popup menus should get the pointer position event when there is no
motion event. It's an issue when, to close a submenu, you click on the
parent menu; until you move, the parent menu still highlights the old
line.
- Object info box: if the box is already drawn, don't draw it again; it
makes the strings flicker slightly.
- [Alt] alone should highlight the menu bar.
- Minor glitch: when a popup menu is active, the spot is still shown
- Minor glitch: when a popup menu becomes active (active again) it does
not try to check if the pointer is over it. It waits for the first
motion event. I'm not sure whether this is the right thing.
- Popup menus: that code is brittle because the same menu_c object is
used for popups and pull-downs. For example, if a menu was pulled down
before the same menu (that was previously popped up) was undrawn,
weird things might happen. I don't like the idea of duplicating the
whole menus, though. It would be cleaner to split the menu_c class
into a constant part and a dynamic part but it would be a lot of work.
- Highlighting sectors: for a constant number of sectors to highlight,
gets slower as the total number of sectors increases. Might have to do
with the search for tagged linedefs.
- Highlighting linedefs: same problem when some of the linedefs to
highlight have a non-zero tag. IMO, the key of the problem is the O(2)
part in the highlighting of sectors. Should restructure
HighlightObject() and HighlightObjects(). Build a bit vector of all
linedefs that should be highlighted and do them all in a loop, without
recursion. And thus we would not highlight the same linedef more than
once anymore.
- Highlighting linedefs: the test "tag > 0" is arguable. Shouldn't it be
"tag != 0" ?
- When merging superimposed 1S linedefs, the resulting 2S linedef often
has the middle textures the 1S linedefs had.
- [Shift][Ins] doesn't work.
- Split linedefs and sector: if there is no sector between the linedefs,
they shouldn't be split.
- Split linedefs and sector: if only one linedef is
selected/highlighted, assume that the other linedef is the one
opposite.
- Split linedef: if pointer is somewhere on top of linedef, split it
there (not in the middle).
- Split linedef: buglet: the new vertex is initially put at (0,0) and
MapMaxX and friends are updated accordingly. So if the centre of the
map is way off (0,0), the next centre-map command will appear to put
the map off-centre.
- Moving/scrolling: centre view around spot under pointer (binding :
perhaps [Ctrl][But2]).
- Instead of { Beep(); Notify (); }, should have a specialized function.
- Somehow unify configuration variables and game definition variables,
at least so that "set" displays both. AYM 2000-07-11: mmm...
- Palette viewer: better cursor.
- Textures: load the texture descriptions (TEXTURE[12]) once for all
at startup.
- Textures: don't abort if the TEXTURE[12] lumps have weird things in
them.
- There is a way to trigger the "Callback %p did not set disp_" bug
message. Don't remember where. Perphaps in the texture viewer. Had to
do with missing patches ?
- James Caldwell says that, with v1.4, if you create a polygon, delete
the sector inside it and try to draw a selection box around the
linedefs, Yadex segfaults. James was not able to give me a backtrace
and, apparently, no one has been able to reproduce that bug. Does it
still occur with v1.5 ?
To do soon
- Try to restore the "save image to file" function. The data should
not be taken from the window, since clipping could occur, but directly
from the buffer.
- Talk about the above in the doc. Mention that ppm files are always
created with NL = LF.
- Finish window_to_rgbbmp()
- Transfer rgbbmp_to_rawppm() in another file (rgbppm2.cc ?)
- Rename rgbbmp_to_rawppm() -> _ppm(), and add a parameter to choose
between P3 and P6.
- Add a parameter in the config file to choose between P3 and P6 for
- screenshots
- pictures saved
- Test XK_*_ISO_* on SCO X11R5.
- Test on Final Doom.
- Add option to let Yadex tell you with which options it was compiled.
- Generate text announcement (yadex-announce, freshmeat, rgcde, cola)
- Fix any remaining problems that might remain in saving.
- "create": Fix the problem with levelname being NULL in EditLoop().
Check [F3].
- "create": every time you [F2], the wad name is reset to the default
(E.G. "map01.wad").
----------------------------------------
MISCELLANEOUS MUSINGS
----------------------------------------
COLOUR HANDLING
[AYM 1998-11-30: don't trust this, it's partially obsolete]
Yadex can run on "a variety of displays". We can have anything from 16
to 16M colours. It needs to be able to handle this variability correctly
and quickly. I have to following idea : the code uses internal colour
numbers (ICN) to specify colours. When a part of the code needs a
certain colour, it calls a particular function with the RGB spec of that
colour and the function returns an ICN. Only the function knows how many
colours are really available. The rest of the code does not have to deal
with that. If more colours than that are asked for, it tries to
allocate colours anyway, possibly by approximating the required colour
by an already existing one or even by reshuffling the palette.
The colour allocation function uses an internal table which has as many
entries as there are allocated colours. Each entry contains the RGB
description of the colour and the corresponding external colour number.
The behaviour of the colour allocation function is influenced by certain
parameters. E.G. for X11, there is a flag that says whether the user is
willing to have a private colormap for the Yadex window.
The IRGB constants in the code need to be replaced by RGB values taken
from the configuration file (like has been done for THINGS colours).
Suggestions if it's difficult to allocate all colours :
You could try to
- stop other colour-hungry applications
that may be running (such as Mozilla)
and restart Yadex,
- restart the X server with more colours
(E.G. "startx -- -bpp 16"),
- restart Yadex with -privatecmap.
WIDGETS
A widget should have the following methods :
- create:
- destroy:
- get_size: the size the widget would like to have
- set_size: the size the widget got from the geometry manager
- set_coords: the top left corner assigned by the geometry manager
- draw: can be partial !
- undraw: only some widgets can do that
- set_focus: gain or lose focus
The types of widgets :
- text label
Attribute: text
- button: a rectangle.
Attribute: text label.
Attribute: text label colour (grayed out ?)
State: depressed or normal.
State: would be activated by return.
Event: if left button is pressed on it, sinks.
Event: if left button had been pressed on _that_ button and is
released on top of it, triggers.
Event: if pointer moves away, returns to normal.
Event: if pointer comes in and left button is pressed and when it
was pressed, the pointer was on top of _that_ button, sinks.
- radio buttons
Attribute: channel #.
State: on or off
Event: similar to button.
- check buttons
Event: similar to button.
State: on or off
- window
Attribute: title
Attribute: a list of widgets with placement information.
GEOMETRY MANAGER
The geometry manager is passed a list of widgets with placement
information.
Each widget is
Braces are groups of widgets. A group of widgets is a rectangular shell.
By default, the group places its widgets from top to bottom and aligned
to the left.
A widget group can optionally be materialized by a frame and a title.
Brace modifiers:
- place widgets left-to-right
- place widgets left-to-right
- place widgets top-to-bottom
- place widgets bottom-to-top
Widget modifiers (override the per-group placement order):
- "<" left-align
- ">" right-align
- "^" place to the top
- "v" place to the bottom
DRAG-AND-DROP
When dragging a group of objects, I see two possible policies:
1. snap position of current object
2. snap relative displacement
The inconvenient of (1) is that, if no object was aligned, it is difficult
to move the group by a whole number of grid steps.
MOVING AND DRAGGING WITH THE KEYBOARD
From main mode:
[c] move cursor
[d] drag objects
[f] find object
Followed by displacement commands.
Displacement command:
[h] west
[j] south
[k] north
[l] east
[y] north west
[u] north east
[b] south west
[n] south east
Optional displacement command prefix:
[f] finer (grid step /= 4)
[c] coarser (grid step *= 4)
Any other key returns to main mode.
FASTER DISPLAY
I think that screen refreshes could be sped up a lot by avoiding to
clear the pixmap but instead redrawing every widget as black. It would
involve more CPU time per pixel but it would also divide the number of
pixels to clear by between 10 and 100, depending on the zoom factor.
It would not be very complicated to add a draw_with_background_colour()
method to edwidget_c. But, between the moment the widgets are first
drawn and the moment they're drawn again with the background colour, the
level data is likely to have changed. For example, a group of vertices
might have been dragged.
I could save the level data as I draw it. The parts of the data that
need to be saved : the vertices (x,y), the linedefs (v0,v1) and the
things (x,y,type). For a very large level (600 things, 4000 vertices,
4000 linedefs), that's 4000 * 4 + 4000 * 4 + 600 * 6 = 35 kB. Sounds
quite acceptable to me, especially as compared to the 800*600*3 = 1.4 MB
of the pixmap to clear. Idea: fold vertices data (no vertices, linedef
is defined by x0, y0, x1, y1). A bit larger, a bit faster.
I could use the undo information. But redoing might make that too
complex. Oh, and undoing it still not implemented ;-).
I could embed some sort of versioning within the level data but I
wouldn't like to slow down access to the level data, which is critical
in certain parts of the application.
If it works well, I might even get be able to do without a pixmap :-).
FILE SELECTION BOX
It would be nice to have a file selection box with a small window that
shows a preview of the level(s) and also a few indicators for textures,
flats and other lumps.
distrib
>
Mandriva
>
8.2
>
i586
>
media
>
contrib
>
by-pkgid
>
9383028e5b5e6b6c2824e168b46388d9
>
files
>
12
