---------------------------------------- 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.