-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathLibDocs.txt
160 lines (133 loc) · 6.24 KB
/
LibDocs.txt
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
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
Future
My medium term goal for a long time has been to return to
the days when I could crank games out really quickly. My
first few Ludum Dare were grand and I want to get back to
that level of productivity. Getting old means I probably
can't, but at least I can improve my tools.
Though Unity and Unreal are no doubt far better than any-
thing I could come up with, I am just not very speedy with
them. Knowing your own stuff, the stuff you wrote yourself
seems a very large factor.
Jank is a thing though. I made a simple map last week and
uncovered some serious flaws in my bsp compiler. To be
fair, the id tools also had trouble with it, being unable
to remove the outer nodes.
I experimented a bit with more modern developed compilers
and found an active one through github, and it built it
flawlessly without even a warning.
This + struggling against the restrictive nature of C# has
made me think about just using one of those excellent map
compilers with all my live game stuff in C. C has been a
joy to work with.
For tools though, I only really know / like winforms. C#
is fantastic at this. So I'll likely keep my C# tools
going, and just call into C libraries maybe.
Another revelation is radiant. The map editor. While
checking out newer compilers I looked at GTKRadiant and
was at first turned off. I've tried it in the past as well
and the interface just seemed unusable. This time I kept
at it and managed to get it into a standard 4 view. Entity
placement was a bit odd, but the vertex editing is
fantastic, everything is snappy, the 2D views are easy on
the eyes (I get major eye strain when mapping) thanks to
GL antialiasing. Overall much better than Quark.
Quark is easy to hack though. Radiant seems to use game
packs to support different games.
So things that need to be done:
Make a game pack for groglibs for GTKRadiant
This is mainly for my brush flags
See about texture formats. I use loose pngs, will
gtkradiant support this?
Might need to change the build tools to support my
flags. The one I'm using is q2tool. I think
rad needs texture data now as well, maybe for
stained glass windows and such? Will it do png?
BSPBuilder should load and do material stuff on bsp
files out of q2tool. Mapgrinder and such.
C side libs will probably continue to use BSPZone.
Have I written that yet? I can't remember.
Order of the above might vary but is probably as listed.
Coordinate System Notes
Up is positive Y
Forward is positive Z
Left is positive X
This is right handed.
At pitch yaw roll of 0 0 0 the camera aims +Z
For exporter info, see CharacterNotes.txt in the
ColladaConvert dir.
Audio Entity
The activated flag makes the sound immediately play when
the level is running. Unless the player is nearby, this
probably only makes sense for a looping sound.
If the audio is triggered, if also activated a triggering
will turn the sound off. If not activated a triggering
will turn it on.
Moving BSP Models
To build moving pieces of geometry such as doors or moving
platforms, create a func_door or func_plat entity in quark,
then give it a name such as Door00 in the TargetName field.
Make a trigger to activate it such as a trigger_once for a
one time opening or rising, or trigger_stand_in for a door
or plat that changes while a player is inside the triggered
area. Set the target of the trigger to the previous name
given to the door or plat.
To provide movement to a door for instance, create a
target_move_stage entity, and give it a targetname such as
DoorMover00, and set the door's target to this same value
(DoorMover00).
Move Axis determines the direction of movement. See map
coordinate system notes below.
Move amount is the amount to move along move axis for this
entire stage.
Rotate to target is a true or false value determining if
the movement rotates towards the angle specified in
rotation target over the stage interval. This can go
beyond the normal 360 value to spin around multiple
times if desired. Note that a player riding on does not
feel the angular momentum of a spin yet.
Rotation rate is an amount to continuously rotate after any
movement is completed. This stalls the stage into a locked
rotating state when it happens. Amount is degrees per
second in pitch, yaw, roll.
Stage Interval is the amount of time it takes for the stage
to complete from start to finish in milliseconds.
Ease In and out are for a smooth acceleration and slowdown.
Map Coordinate System notes
For axis angle values:
0 0 0 is facing down positive X in quark and in game.
pitch yaw roll is the x x x ordering.
To get a direction, look at the angles generated by aiming
a sunlight entity.
Character Notes
See CharacterNotes.txt in the ColladaConvert tool source.
Static Meshes -TODO: old outdated info
Statics (and characters) have an archetype and an instance.
Imagine the arch for a static as a kind of rock, and the
instances being rocks of various sizes scattered about with
odd rotations and scales. For a character the arch might
be a male or female player, and the instances each copy
with their own scales and colours and customization. The
arch stores the actual data such as vert info.
Bounds
Meshes will have an overall bound editable by ColladaConvert,
as well as submesh bounds. These can be sphere or box,
but box can involve matrix inverts so sphere is a bit better.
Characters can have bone bounds of box, sphere, or capsule
type.
Fill Lights
Characters and statics are lit via the strongest light in
line of sight. There are two fill lights that aren't
affected by this. These can be specified regionally via
the misc_trilight_info entity. The character or static
will pick up the nearest ones and blend between them via
the lighthelper class.
Particles
To create a static particle emitter as an entity in a map,
use the particle editor to get the look as desired, then
select the emitter and copy and paste it into Quark. For
gravity, the misc_particle_gravity entity creates a point
that draws linked entity particles in towards it. Give
the gravity entity a targetname such as gravity00, then for
each entity that wants to be attracted to it, set the target
of the entity to gravity00 and they will link together in
Quark.