-
Notifications
You must be signed in to change notification settings - Fork 9
/
TODO
123 lines (93 loc) · 3.61 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
- 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?