mirror of
https://github.com/ZDoom/gzdoom.git
synced 2025-04-26 12:40:58 +00:00
124 lines
3.6 KiB
Text
124 lines
3.6 KiB
Text
![]() |
|
||
|
- create Web repository for sources, patches,
|
||
|
news, and pointer to doom-editing mailing
|
||
|
list.
|
||
|
|
||
|
- get DOOM Public License from id
|
||
|
|
||
|
-----------------------------------------------
|
||
|
|
||
|
- remove m_fixed, switch to floating point
|
||
|
More stable, and prolly even faster.
|
||
|
|
||
|
- make SCREENWIDTH/HEIGHT work at startup?
|
||
|
Well, the HUD/STBar stuff is tied to the
|
||
|
scales implied by the graphics. Rather do
|
||
|
GLDOOM and use texture mapping.
|
||
|
|
||
|
- fix aspect ratio?
|
||
|
320x200 is nothing viable nowadays.
|
||
|
A 320x240 base (4:3) would be a lot better.
|
||
|
See above on width/height.
|
||
|
|
||
|
- limited look up/down by y-shearing?
|
||
|
Prolly not worth it, rather switch to GLDOOM.
|
||
|
|
||
|
- switch to C++?
|
||
|
The action function pointers have varying
|
||
|
argument lists (no parameter, one, etc.).
|
||
|
C++ doesn't like that much. A major rewrite.
|
||
|
|
||
|
- switch to doommain.c plus libdoom? Have
|
||
|
libref, libgame etc.?
|
||
|
Another major rewrite.
|
||
|
|
||
|
- use XFree86 DGA, prolly not that much faster
|
||
|
than MIT SHM, but allows for directly sampled
|
||
|
mouse (and even freelook). Recommended for
|
||
|
GLDOOM.
|
||
|
|
||
|
- put together an accompanying developer toolkit
|
||
|
source distribution: DEU, RMB, BSP for Linux/X.
|
||
|
|
||
|
- move info.h, info.c, sounds.h, sounds.c and
|
||
|
other data to a separate lump in the WAD,
|
||
|
or into a libgame.so, to separate the
|
||
|
generic stuff (refresh, I/O) from the
|
||
|
DOOM specifics.
|
||
|
|
||
|
- decide whether precaching all sounds is
|
||
|
better than retrieving and releasing
|
||
|
every so often. DOOM seems to do that
|
||
|
frequently (8bit stuff, originally for
|
||
|
DOS), and the Linux sound is 16bit
|
||
|
(conversion in the mixing, requires
|
||
|
some padding) - we prolly got the memory
|
||
|
to spare.
|
||
|
|
||
|
- 16bpp CLUT. The lightmaps and the
|
||
|
framebuffer could be changed to switch
|
||
|
to 64K colors. Prolly better to do
|
||
|
GLDOOM right away.
|
||
|
|
||
|
- remove checks for commercial etc., in
|
||
|
non-essential issues (enabling PWAD's).
|
||
|
|
||
|
- change (simplify) determination of
|
||
|
sky texture (done by game version).
|
||
|
Explicit?
|
||
|
|
||
|
- remove all game version checks
|
||
|
|
||
|
- different handling of Demo - don't
|
||
|
exit on "different game version"
|
||
|
|
||
|
- how about shareware/retail "You are here"
|
||
|
intermission animation? Wasn't in
|
||
|
commercial (DOOM 2).
|
||
|
|
||
|
- double shotgun in DOOM1, all weapons with
|
||
|
shareware
|
||
|
|
||
|
- checks for required lumps. We need fallbacks
|
||
|
for lumps that are not present, that is,
|
||
|
default sounds etc. to be used instead,
|
||
|
or removing THINGS w/o sprites etc.
|
||
|
|
||
|
- client/server? I'd suggest ripping off some stuff
|
||
|
from the abandoned IBM WebView project
|
||
|
|
||
|
- Blockmap
|
||
|
The BLOCKMAP lump might be (partly) redundant,
|
||
|
as the BSP allows for clipping (except certain
|
||
|
LineDefs that will not spawn Segs).
|
||
|
|
||
|
- LOS
|
||
|
REJECT and intersection based LOS checking could be
|
||
|
done using the BSP. In case of REJECT, certain
|
||
|
monster AI special effects would be lost, though.
|
||
|
|
||
|
- correct handling of height in collision. This is
|
||
|
not done, and the checks are scattered around in
|
||
|
many places. It does require handling of "player
|
||
|
on top of monster" situations, too - we have to
|
||
|
make sure the players falls off far enough to
|
||
|
avoid getting "stuck in monster".
|
||
|
|
||
|
- remove obsolete menus (Detail. Music Volume?)
|
||
|
|
||
|
- clip explosion range damage (and sprites) using
|
||
|
REJECT? That is, if one Sector/SSector not
|
||
|
visible from the other, do not apply damage,
|
||
|
not render sprite if player in other sector.
|
||
|
Hmmm - explosion behind small pillar might not be
|
||
|
visible at all, but do we care?
|
||
|
|
||
|
|
||
|
- Ungraceful and untimely demise of Linuxdoom (core
|
||
|
instead of I_Error) will leave idle sndserver
|
||
|
processes in your system, blocking /dev/bsp.
|
||
|
A timeout on lack of input for "sndserver"?
|
||
|
|
||
|
- threaded sndserver? SHM mixing buffer?
|
||
|
Or internal, timer-based?
|