Angeba's bloodspilot X11 client todo list.

Discussions related to the BloodsPilot clients
Angeba
Posts: 88
Joined: Sun Feb 06, 2011 11:23 pm

Angeba's bloodspilot X11 client todo list.

Postby Angeba » Fri Jul 15, 2011 8:55 pm

Angeba client todo list. Last updated 2011-07-15.
Subjects in order in which they are planned to be done.
Important subjects can still be placed further down, when they seem difficult.
Topics usually apply to the bloodspilot x11 client, otherwise it is mentioned explicitly.


* Why were global.c/global.h implemented?

They do not exist in ng-4.7.2. In the bloodspilot
clients package they contain many declarations and
definitions of variables which are declared/defined
in other files. This is probably very unclean.
Is it nessesary to have these files?


* Clean up `#ifndef xyz_H #include "xyz.h" #endif *** SENT ROT-FORUM ***

There are several of such conditionals in various
files. The `#ifndef' and `#endif' should be
unnessesary, because they already are in the included
files (where any are missing they should be added).

Should we remove these conditionals to clean up the
code a bit? Or is there any reason to keep them?

2011-05-02: There is a good explanation, regarding this subject,
in the GNU C Preprocessor info documentation:
`info cpp "Header Files" "Once-Only Headers"'


* Server: Send locked player on radar with each frame

Currently the radar blinks the locked player (slowly),
so that he is not visible for several frames. This
is paradox with the fact that we are _especially_
interested in that player and his position.

I suggest that the server sends the locked player
alternating with normal size and a smaller size.
The frequency could remain about the same.


* Restrict eyes and eyesId changes

The two variables eyes and eyesId, which tell which
player ('s ship) we are watching, are set in the
client when it finds any ship in the center of the
window (+/- 1 pixel). It may happen that you are
just killed and the view is moving to your homebase,
so that you can continue with your next life/ship.
If in that situation another ship is in the window
center, then the client will switch to view with its
eyes. That's especially irritating when that ship is
from another team, because then its teammates become
painted in ally color, your teammates in enemy color
and equally all shots. This view change may even
occur while you are alive, when another ship is also
in the window center. This may happen with allied
ships, or when a phasing device is in use.

Proposed solution: Only change eyes and eyesId when:
1) the client receives an eyes packet from the server.
(PKT_EYES). I've read about the 4.5.4 server,
that it never sends that packet so far. Neither
do I know why that wasn't implemented, nor whether
the ng and fxi servers behave different. I think
it might be the best solution if the server sends
that packet.
or
2) any ship is found in the window center (like it
is), _but additionally_:
2a) we (self) are waiting (W), paused (P), or dead (D)
and (optionally, needs more checks)
2b) the previous eyes player is _not_ in W, P or D
state.

Points 2 and 2a would prevent any accidental eyes
changes while we are alive and playing.
Point 2b would additionally prevent that happening
while we are watching (through) someone else(s eyes).
But that alone would prevent us from switching eyes
(view) to any other player using the lock keys.
The solution here could be to check whether any lock
key was pressed "recently" and allow an eyes change
if it was. To simplify and for a start, perhaps
first implement points 1, 2 and 2a. That should cure
the main annoyances. Point 2b can be added later if
someone still desires it then.

New ideas: use self->lockid!!! Should clean the
problem up a lot!

Some relevant code is in
src/client/frame.c: Handle_ship()
and apparently also in
src/client/paintobjects.c: Paint_all_ships().

Watch out that currently there seem to be duplicate
definitions of the relevant eye variables, in frame.c
and also in global.c (like with many other variables).
Probably only one instance is needed for correct
behaviour.


* Show base-warnings even with baseNameColor == off

Currently basewarnings are not painted when the
`baseNameColor' client option is set to `off'.
Probably the base name should not be painted, even
while warning, but the flashing growing box and/or
ship really should.


* Shots invisible with high scalefactor and low shotsize

Affected: bpc-x11 and bpc-ng-x11 with texturedObjects
disabled.

With a high scalefactor and a low shotsize (but > 2),
bullets become invisible. For example with a
scalefactor=3 and shotsize=3 or 4, no bullets are
visible. With a lower shotsize (1 and 2) and with
a bigger shotsize (> 4), the bullets are visible.
Note that bullets are painted as rectangles for
sizes 1 and 2. For bigger sizes they are painted as
circles.

This should be changed, so that at least a one pixel
dot is always painted for a bullet.

2011-02-24: Fixed in my sources for the x11 client.
Some related troubles remain for textured shots
(see comments in src/client/x11/guiobjects.c:
Gui_paint_fastshot() and Gui_paint_teamshot()).


* lineWidth reset to 0 when displaying missiles/lasers ***SENT TO SF-TRACKER***

Verified with the x11 and ng-x11 clients. The sdl
client does not seem to be affected (not tested).
After painting any missile (smart, heat, torp),
Gui_paint_missiles_end() sets the line width in the
gameGC graphics context to 0, disregarding any other
setting via the -lineWidth client option.

The same applies to laser beams and
Gui_paint_lasers_end().

Other interfering calls to XSetLineAttributes():

In
src/client/x11/guimap.c: Gui_paint_polygon(),
and (of course) also in
src/client/ng-x11/guimap.c: Gui_paint_polygon().
Also the sdl client seems to be affected here
src/client/sdl/sdlgui.c: Gui_paint_polygon().

These should be the reasons why the lineWidth option
does not work on polygon maps so far.


* Verify/change all comparisons with constant "true"

Since C treates all values != 0 as true, one should
not compare values with a constant true (e.g. 1).
For example instead of
if (var == true)
one should better use
if (var)
or
if (var != false)
. Keep in mind that xp-replay.c (for example) uses
"True" and "False" instead of "true" and "false".


* Remove unnessesary Set_fg_color() calls.

There are redundant calls to Set_fg_color(), e.g.
before calls to ColorDrawString(). If the foreground
color only needs to be set for that string, then the
preceding Set_fg_color() call can be removed. These
calls are probably remains from before
ColorDrawString() was implemented.


* Wrong wall colors on reverse replay (very rare)

The wall colors are sometimes wrong when doing a
reverse xpr replay. For about 1 or 2 frames they
change from dark blue to dark gray, red, white or
yellow (so far noticed). This happens perhaps once
per 10 minutes of reverse replay on the same frames.
Noticed it with sparks on and only after I changed
the painting order in src/client/x11/xpaint.c:
Paint_frame().

I did fix some bugs in src/client/x11/xpaint.h:
SET_FG() and Set_gc_fg_color(), which I thought could
be related, but the problem still exists.
Idea: In SET_FG() _always_ call XSetForeground(), and
see if the problem persists. Though this might
increase client lag and/or recording size.

Perhaps this is even a problem within
bloodspilot-replay. Compare a relevant recording
with other replay programs, including the java replay
(no idea if it allows reverse playback).

The problem seems to occur on (or right after/before)
a frame without any ship painted!

2011-03-16: Just found an old recording (with old
painting order), which has a similar symptom. It's a
Polybloods recording (/dvdcdrw/xpr/Matches/2010/PBM/\
StorGapen_Incompetent_SpaceDebris-vs-Warn_Flower_O\
.xpr.gz). There the visibility border's color
changes sometimes on reverse playback. Note that the
client paints the visibility border before the walls
_on a polymap_.
So probably in general the problem affects the first
thing which is painted on some frames.

Finally I think I understand the problem: The very
first shape of each frame should always be preceeded
by its current graphics context.
Currently the GC won't be written if it does not
differ from the very last shape of the previous
frame. Like that, there is no problem with forward
replay. _But_ when replaying in reverse, the GC of
the first shape may now differ from that of the last
shape of the frame previously shown (i.e. the next
frame). Since there is no GC for this shape, it will
be painted with different GC settings, e.g. the wrong
foreground color.


* pointer_move_next defined twice (check if bug) ***SENT ROTS-FORUM***

"pointer_move_next" is declared both in global.c and
in netclient.c. I guess this is accidental and may
result in wrong behaviour/failure. Probably this
should be changed so that there is only one
declaration.
This might be connected to the sometimes jerky ship
turning (shiver) when using dirPrediction on a lagged
connection.

IIRC I saw more of such multiple declarations before.
Scan the code for these and verify whether they
should be corrected. Could the gcc warning options
-Wshadow and -Wredundant-decls be useful?
Seems like these options find a lot of redundant
stuff. This needs to be investigated (lots of work,
but probably useful).


* Use pedantic gcc warning options to find weaknesses ***SENT ROTS-FORUM***

Some relevant options: -Wall, -Wconversion, -Wshadow,
-W, ...
For more see:
info gcc "Invoking GCC" "Warning Options"


* Double quote $@ in build*.sh scripts

In build-{x11,454,ng-x11,sdl,replay}.sh replace '$@'
with '"$@"'. The bash info file states:
... When the expansion occurs within double quotes,
each parameter expands to a separate word. That
is, `"$@"' is equivalent to `"$1" "$2" ...'.
This makes it possible to supply options with spaces
to the build scripts, which will be passed on
correctly to configure. For example:
./build-x11.sh "CPPFLAGS=-DANGEBA_MODS -Wall" ...

2011-02-12: Done in my local sources.


* Specify mandatory tests after (bigger) changes

Write down which tests should be done after changes
to the program code have been made. The aim is to
increase the likelihood that the program continues
to work normally.
Which programs need to be tested depends on which
files were modified. E.g. if some fundamental file
like configure (config.ac) was changed, then all
programs have to be tested (x11, ng-x11, sdl and 454
clients and replay). If a file in src/client was
changed, then the x11, ng-x11 and sdl clients need to
be tested. We should add a note (perhaps in
src/client/454/_SRC-INFO.txt) that the 454 client
does not depend on files in the src/client directory
(I assume that is true). If some files only in a
specific sub-directory of a program were changed,
then only that program needs testing; e.g. for
changes in src/client/x11, only the x11 client needs
testing.
Write a shell script "propose-tests.sh". This will
use diff to find changes that have been made between
the previous directory and the working directory.
Based on the diff results, the script can then
suggest which programs need to be tested.
- The propose-tests.sh script should get an
option (-d do tests), which lets it execute the
tests which it would otherwise only suggest.
Before each sub-test, it should tell what the
tester should verify. After each sub-test, it
should ask whether the test was successful and log
the result (e.g. to "test-results"). It could
offer to make additional notes to each test result,
so that the tester can specify in detail which
problems occured.
- The propose-tests.sh script should also get options
to explicitly choose which tests to do and to
disable the diff comparison.

Tests to do:
- clients in default configuration (environment
variable XPILOTRC=/dev/null)
- clients with various configurations. Since there
is an untestable high number of option combinations
, use at least a subset which seems most important.
These configurations could be kept in an own
directory "tests/client".
- all the client tests above with various server
configurations. Different maps (ball, race, item).
Create some special test maps, which use important
option combinations.
Offer to test with various servers
(4.5.x, ng, fxi). Omit tests with unavailable or
explicitly excluded servers.
- Test build/compile success. Test with various
warning options; scan output for any warnings
and pay special attention to warnings considered
potentially more important.

Look whether available testing tools can be useful
(e.g. GNU autotest (testsuite), now integrated into
autoconf ???). Seems to be most appropriate for
automated tests, relying on output and exit values.
Probably also relatively complex to learn and not
much better suited to the interactive testing
required here, than the proposed customized shell
script.


* Warn when SpeedZoom and textures are used together

Issue warning messages from the relevant
set-functions when both SpeedZoom and textures are
enabled. The required bitmap (-scale) updates need
a _lot_ of processing time and will probably add a
lot of client lag. Wall textures don't seem to be
scaled, but will look strange, because they will
"slide" about the walls.
Relevant options are speedZoomMaxFact,
texturedObjects, wallDrawMode and decorDrawMode.


* Rename "selfVel" references to "speed"

Should be more self-explaining. The selfVel variable
in the code should remain unchanged, but the display
to the player should be changed (e.g. on the extHUD,
in -extHUDContents and when mentioned in option help
text).


* Show total record time and (record)fps on exit

In src/client/x11/record.c: Record_cleanup() show the
total record time (seconds = frames / (record)fps).
Could use src/client/x11/painthud.c:
Seconds_to_time_string(), which should be moved to a
more suitable place then (perhaps portability.c?)
Also show recordFPS.
E.g.:
Recorded 2145 frames (2:45 min at 13 FPS) to
/tmp/xpilot.xpr


* Ships vanish while exactly on visibilityBorder

If some ship (or probably other object) is exactly on
the visibilityBorder, it is possible that it is
neither painted as a ship, nor as a mapRadar circle.
This should be changed so that (at least) one of the
two representations is painted. Probably the
mapRadar circle painting needs broader limits,
because I assume that the ship is not even sent by
the server in the case in question, otherwise it
would be painted (check code). The HUD-radar circle
is present in the moment in question.


* Replay: -output option enhancements

In the usage text add "file" after the "-output"
option, so that one knows about the required file
name.
If "file" is "-", act as a filter and sent output to
stdout. We should ensure that diagnostical messages
are all sent to stderr then. Make a comment close to
the top of the source that all diagnostics should go
to stderr, so that programmers know this when doing
further modifications.
An output file opened with popen() needs to be closed
with pclose(). This needs to be changed for the case
that -output and either -gzip or -compress are used
together.
Exit the replay program always with an appropriate
error code, e.g. if record file is corrupt etc.
Currently 0 (success) is returned in that case.
Do not display (i.e. map) the X11 windows when
-output is used. Probably only the call to
XMapWindow() needs to be omitted therefore.
Diagnostical and error messages which are shown in
X11 windows should be sent to stderr in this case.


* Add client lag deviation and stats on client exit

Add (standard) deviation to the client lag statistics
. No idea so far how that is calculated.
The client could also record client lag statistics
over its whole runtime and print them to stdout on
exit. This could be useful to compare performance of
different setups and/or clients; also/especially in
testing.


* Display mouse coordinates and ship dir on ExtHUD

Display current horizontal mouse coordinates on the
extended HUD. Could be similarly interesting like
the key display.
Could also display the ship direction, both what
dirPrediction thinks it is and also what the server
sends. Might help in debugging "jumping" ship
direction with dirPrediction turned on. Happens
mostly on fxi server with maxfps=25 and also on
the 4.5.4 server xpilots.lkrauss.de on 56k modem
(~150 ms < lag < ~250 ms).


* Write GC with each frame to a (buffered) recording

Test by how much the recording size increases when
writing the graphics context (GC) at the start of
each frame. More specifically the lineWidth should
be saved with each frame.
Currently the lineWidth is mostly written when
recording is toggled on (initiated from
RWriteHeader()). Thus when using buffered recording
and lines wider than 0, the replay will only switch
to the real lineWidth after the buffered part.
Also the lineStyle (dashed or not) could be saved at
the start of each frame. This would cure the dashed
lines when going backwards in a replay from a point
where dashed lines are used (connecting to a ball).
Alternatively the style could be cured within
xp-replay, by dynamically inserting the previous
style at the start of a frame if the style changes in
that frame.

2011-03-26: Generally the complete GC should be
recorded with the first shape of _each_ frame. This
will cure many (potential) graphical glitches when
replaying backwards or cutting scenes from a
recording.


* Use recent average selfVel in SpeedZoom

Calculate average selfVel over the last frames
(could use a client option -speedZoomAverageTime).
Use this average then instead of selfVel in further
calculations. This might help in leveling out
scaleFactor bounces (e.g. when grabbing balls).

2011-01-18: Mostly done. Works basically, but
some more cleanups can be done. Perhaps rename
speedZoomDampingTime to speedZoomTransitionTime
now, because the damping is now mainly done by
speedZoomAverageTime. speedZoomTransitionTime
remains useful when using speedZoomSteps > 0,
otherwise it could be mostly superseded by
speedZoomAverageTime.
If no one finds a use for speedZoomSteps, then
we can probably remove both speedZoomSteps and
speedZoom(Damping|Transition)Time. Ask people
(on the sf tracker) which speedZoom settings they
find useful (if any ...).


* missing ", __func__" in my newest patch

Patch uploaded to sf on 2011-01-05 needs an
additional __func__ as the second argument in
painthud.c: Paint_HUD_values(): in the call
beginning with:
warn("%s(): Ignoring unknown ExtHUD item

2011-01-18: Fixed in my local working sources.


* ng-x11 client aborts on opening the color config ***SENT TO SF-TRACKER***

Before quitting the client outputs:
assertion "Option_get_type(opt) == xp_int_option"
failed: file "configure.c", line 479, function
"Config_creator"

Comparing ng-x11/configure.c with x11/configure.c
shows that the ng version completely lacks support
for color_index options. The question is whether
that was not yet implemented in the ng client, or
removed by mistake.
From the bloodspilot GIT repository try to find the
last version of the ng-x11 client with a working
color menu. Then the next change should be
responsible for this problem.

2011-02-22: (Partially) fixed by Rotunda. The color
value "off" is not supported in the ng client. Not
sure whether it was somewhen, but I guess it was.
Color codes are also not supported currently. I
assume that they were supported previously, because
the client option "-ignoreColorCodes" is still
available, allthough it doesn't do anything now,
without color codes.
For these two points, a valid bpc-x11 .xpilotrc will
not be useful for the bpc-ng-x11 (wrong colors).


* Basewarning in bpc-ng-x11 is broken ***SENT TO SF-TRACKER***

Doesn't work at all.


* -hudRadarDotScale in bpc-ng-x11 is broken ***SENT TO SF-TRACKER***

It doesn't have any effect.


* Phased/cloaked display of (own) ship is broken (bpc-ng-x11) ***SENT TO SF-TRACKER***

Sometimes the ship is correctly displayed for some
frames, but most of the time the ship is painted with
full lines while it is phased/cloaked (the correct
painting style is with dashed lines).


*FORUM* * Put each bloodspilot client in its own directory?

Seeing how broken the bloodspilot ng-x11 client is
atm, how about seperating all clients from each other?
The bp-454 client already has a seperate code base,
but the x11, ng-x11 and sdl clients all share lots of
code (all files in src/client/*.[ch]).
When a developer wants to change only a single client,
touching any of the shared files makes it nessesary to
verify that the other clients continue to work
correctly. Practically it is impossible to verify
everything, with all the option combinations on the
client and server side.

Having shared sources (like now) may have some
advantage when one wants to change something in all
clients at once. He doesn't need to modify 3 files,
but only one.

Personally I can't build/test the sdl client, because
my systems are not compatible. Also I don't see any
reason to use the ng-x11 client. The only feature it
has, which the x11 client has not, is the seperate
radar map, which I generally don't find useful.

So in my opinion the ng-x11 client can rest in peace
in its own directory. Whoever wants to maintain/
modify it, can perfectly do it there. It is then
still available for comparison/testing/use, like the
454 client.

I guess that the sdl client may be usable (never used
it) and should certainly be the easiest bloodspilot
client to build on windows, if someone wants to help
with that. After all, the windows client from
xpilot-ng is the sdl client, right?

Personally I am only using and developing the
bloodspilot-x11 client. I am willing to assist if
someone wants to implement any of my changes into
another client, but I could develop quicker if I
didn't have to care about the ng-x11 and sdl clients.


*FORUM* * What is the seperate radar map good for?

I find it useful to get an overview about a map, which is mostly useful for
unknown maps.
What can this radar map be useful for within a game??? To me it is usually
too dangerous to look onto it within a game, because in that moment I would
not see shots heading for me. I am happy with only the hud radar and the
radar objects mapped into the extended visible area (those circles beyond
the visibility border).

I don't even use the wall-overlay of the bloodspilot x11 client, because it
distracts me. An idea to try out with it, would be to paint the wall
overlay filled, but blending the "real" game world under it through, so
that it is still visible. That should be possible to try with the sdl client.


* portability.c: showtime() date format

The new showtime() function could display the date in
ISO 8601 format, i.e. "%Y-%m-%d" (e.g. 2011-01-13).

2011-02-23: Done (in my local sources).


* Add (HTML-) documentation to the repository

For the client and probably also for the server,
place the documentation in the SF repository.
For a start take the docs from bloodspilot.sf.net.
Try to organise the files into a clear structure.
This documentation can then be copied to the website,
for online browsing, but can also be shipped with
the client and server packages.


* Add developer guidelines/documentation

Add documents for developers with recommendations
about how to write code and about what should be
avoided.
Explain how certain things in XPilot/bloodspilot
work. The source code to both server and client is
quite large and it has grown over 2 decades, with
contributions from many people. The names of all the
source files can give a rough idea about what they
contain, but often one does not know where something
is done. Also functions, macros, variables, type
definitions, constants etc are sometimes not in the
best suitable file. It would be nice if each file
had a comment close to the top, with a brief
description of the purpose of the file and what it
contains.

Add comments!!! It is a bad help to the community
and probably to yourself, to write (complicated) code
without (meaningful) descriptions. Another developer
can understand much quicker what is done and how
something works when there are descriptive comments.
And not least, while you comment your code, you will
understand it better yourself. I find it helpful to
write the function description first along with the
function name, its arguments, argument and result
description. Only when these things are clear, it is
time to start writing the actual function code.
Also note in the function description which side
effects occur, like use or even modification of global
or "file-global" variables.
State any deficiencies, hacks and what you think
should be improved.

When several functions work together to do some task,
do also explain that.

Have a look at the related GNU coding standards
section. From a shell run:
`info standards "Writing C" Comments'.

Try to find meaningful names for files, functions,
macros, variables etc. The code will be easier to
understand. Add a comment at each name declaration
(function, macro, variable, type, constant etc.),
describing its meaning and intended use.

Provide templates for file, function and macro
descriptions.
Add templates/style guides for client/server options.
Give naming recommendations, state what the help text
should contain (and what not), how much to put into
the help text and recommend a single text layout,
i.e. line length, indentation etc.


* Put replays and webreplay on the website

To raise first look interest, place some nice
(multiplayer) recordings on the website. Use
screenshots as thumbnail pictures, possibly a couple
of (gif) animated frames. Use the java webreplay for
easy online viewing. Remove player messages before
publication of a recording. Tell players that you
want to make a recording for publication, so that they
can watch their language in messages, or even leave if
they don't want to be published. Perhaps they even
want to use a nicer shipshape or another nick name for
the recording.
Try to set up fair, balanced teams, since these result
in more interesting games.
Perhaps even arrange a real match over the classic 12
rounds, with locked server. Would be interesting to
have the same match recorded from different players,
at least one from each team.


* HitArea should be painted before the ship

So that it does not obscure the ship. This is
especially visible with a lineWidth >= 2.


* portability.h: timeval_sub() overflows quickly

timeval_sub() currently returns values of type int.
With a 32 bit int, the result will overflow for times
which differ by more than about 35 minutes (2147
seconds). Keep this in mind, if it's possible that
the given times may differ by more than this.
Document this in timeval_sub().


* Base name misaligned for bases facing to the right

Base names start left of the base, but the number of
lives extends to the right side of the base.
Alignment is probably also wrong for up and down
bases.
src/client/x11/guimap.c: Gui_paint_base()

Is it useful at all to have the number of remaining lives shown
at the base? I don't think so, I see on the score list and from
the ship colors how many lives remain. Should only have player
name and team shown at the base. Both team and lives just
makes it confusing (what is team and what is lives).


* Missing base warning on treasure box collision

Basewarnings are missing for players who died through
a collision with a treasure box. Probably the
message scanner needs an additional check for the
respective death message.
! This happens rarely, needs more testing.
Perhaps it happens when dying by a "shove"?
Also msg-parser.c should reset cover and ball
warnings on round reset/total reset.


* Don't do a (flashy) base warning for friendly ships

It's not important to have a base warning for
friendly ships. With many players it is especially
irritating to have base warnings for friends.
Or flash in (white|red)/blue for friends
(teamShipColor), instead of white/red.
Does the client know about the server's teamimmunity
setting? Adapt to it if possible.


* Replay: Playback goes ultra-fast after long pause

Pausing the playback of a xpilot recording for a long
time (try 1 or 2 hours perhaps, hasn't been measured
exactly) and then continuing to play, makes the
replay go ultra fast. Can be reset to normal speed
by stepping backwards once (e.g. 'b' key).


* Replay inserts duplicates of previous scenes.

Sometimes when playing back a recording, replay skips
back to a previous scene, showing that again, then
continues with the normal playback order. Haven't
yet found a way to reproduce that. I guess it sets
some pointers wrong in its frame lists. Might be
triggered by stepping back and forwards and some
other condition.
The frame counter and position display increase while
replaying the previous scene, thus at the end they
show higher values than the real length of the
recording.


* Add an -adaptscale option to replay

If this option is set, then the replay program will
adapt all shapes it draws to the current window size.
This can be useful to view (old) recordings, which
have a low resolution, in full screen on a higher
resolution.
Another use could be to create thumbnails, i.e. to
convert to a lower resolution/display size. This may
be very useful for creation of promotion videos and
animated gifs.

We could even add an option so that one can specify
a fixed scale factor or a fixed window size.


* Sparks (debris) should not be painted over shots

Sparks should be painted before shots, so that they
can't hide shots. Especially annoying when using
big sparks (like sparkSize 4 or bigger).

Strangely in src/client/paintobjects.c: Paint_shots()
there _is_ first the call to Paint_debris() and
Paint_fastshots() is called later, like I thought it
should be changed to ...

The problem seems like follows:
src/client/x11/paintdata.c: Paintdata_end() does:
Segment_end();
Arc_end();
Rectangle_end();
Where the objects stored since the last call to
Paintdata_start() are finally painted. Since shots
and debris are stored in the same "cycle", the shots
will be painted before the debris if they are circles
(arcs), because debris are painted as rectangles.
Shots are painted as circles if shotSize is greater
than 2.

Two possible solutions:
A)
Add "Paintdata_end(); Paintdata_start();" in
Paint_shots() just after "Paint_wormholes();", i.e.
before the calls to Paint_fastshots().
It's just a bit ugly, because the only place where
Paintdata_start() and Paintdata_end() were previously
called was in x11/xpaint.c, but it seems to work.

2010-12-08: !Solution A is not compatible with the
ng-x11 and sdl clients, which don't have these
functions. Removed from my own code. Implement
solution B!

B)
Split src/client/paintobjects.c: Paint_shots() into
two functions, right after the "Paint_wormholes();"
call. Name them Paint_misc_objects() and
Paint_shots(). Then insert
Paintdata_start();
Paint_misc_objects();
Paintdata_end();
in x11/xpaint.c: Paint_frame(), right before
Paintdata_start();
Paint_shots();
This is the clean solution. It also moves the
painting of several non-shot objects to a function
with a more appropriate name.

2011-03-26: Done. A variation of solution B is now implemented. The
file `paintobjects.c' was completely overhauled. The X11 client uses
the new painting order now (for now only with `ANGEBA_MODS' defined).
If testing proves that this was a good change, then it should be easy
to adapt the ng-x11 and sdl clients likewise.


* Rethink painting order in Paint_frame()

Think and test whether a changed painting order in
src/client/x11/xpaint.c: Paint_frame() can improve
visibility of important objects.
For example calling Paint_shots() after Paint_ships()
should prevent enemy shots to be hidden behind enemy
ships. It may be useful to call especially these
two functions very late (e.g. last) in Paint_frame().
Like that they won't be obscured by any other element
, like HUD radar circles or the main HUD.
That the other elements may then be obscured by shots
and ships may be tolerable. This needs to be
assessed by testing (e.g. using big shots, textured
balls ...).

2011-02-09: Partially done. Experimental changes
are used when ANGEBA_MODS is #defined. Needs some
more analysis, but generally seems like a useful
modification.

2011-03-26: Done.


* Include some xpilot map editor in the package ***SENT TO SF-TRACKER***

Probably xp-mapedit, which comes with xpilot-4.5.4
in src/mapedit, should be added to the clients
package.

2011-03-10: Perhaps better don't include the map ***SENT TO SF-TRACKER***
editor, because it consists of quite a bit of source
code and we don't have enough developers to look
after even more things. Building xp-mapedit from
the xpilot-ng package showed several warnings while
compiling, allthough it build and ran successfully.

Allthough a map editor is nessesary to support the
game, currently I think it's okay to use it from
the ng or xpilot-4.x packages. Seems there was some
activity around xpilot-4.x recently (last year).

If the xpilot-4.x developers continue with their
work, it would be better to develop the map-
editor in one place anyway, to save resources.
Either there or in bloodspilot.
The same applies to xp-replay. The version in
bloodspilot has several useful feature additions and
bug fixes over the ng and 4.x version.


* Output of 4.5.4 client on "Local" button (on NetBSD 3.0)

xpilot: sendto 127.0.0.1/15345 failed: (Address family not supported by protocol family)

Connect still succeeds, while ng and bp clients
exit with value 1.

Bloodspilot Client 1.4.0alpha1 outputs

bloodspilot-client-x11: ERROR: Couldn't send contact requests


* Gui_paint_incomplete_ball_connectors_begin()

There is such a prototype declaration in
src/client/proto.h, but it was apparently never
implemented. Would be nice to write such a function,
which should draw ball-connectors where either the
ball or the connected ship are outside of the visible
area.

P.S.: Perhaps `incomplete meant a "connecting"
connector (i.e. one in dashed lines, which is not yet
"snapped in").


* Client stops when maxfps=6 with 4.5.4 server@13 FPS

It pauses painting any frames in that constellation,
but continues when changing maxfps to any other
value. This happens with bloodspilot-x11,
bloodspilot-ng-x11 and also 4.5.4 clients.


* Some ships not visible when viewed robot is kicked

To reproduce do: Pause and lock onto some robot.
Kick the locked robot out. -> Now several other
robots are not visible neither on radar, nor on the
playfield anymore. Their exhaust sparks and
connector _are_ visible.


* Abbreviate player names uniquely to maxCharsInNames

Create a function which generates unique nick names
with upto maxCharsInNames characters. This should
help to tell players apart who have identical leading
characters. E.g. "Space Clown" and "Space Ace" could
be abbreviated to "SpC" and "SpA" if maxCharsInNames
is 3.


* Mark self and locked player in scorelist

Oneself could be underlined. Locked player perhaps
with a "*" in front of the nick name.
Alternatively doubly underline oneself, and singly
underline the locked player. Another option would be
to paint a rectangle around either scorelist entry.
The aim is to find oneself and the own team, plus the
locked player quickly in games with many players/
robots (e.g. these fishtank maps).
Display the full nick name of the locked player for
e.g. 2 seconds, after it has changed. This should
help to lock onto the correct player when several
players use a nick with the same prefix. Abbreviate
the nick as usual after the lock has not changed for
the set time (2 seconds). The same method could also
be applied to the HUD lock display.

2009-06-13: Partially done: Locked player is marked
now.


* Overhaul client option help

The descriptive help text of all the client options
should be checked for correctness. Some descriptions
may be outdated, others incomplete. Put this on
Rotunda's forum or on the SF bug tracker, so that
people can join the fun and contribute ideas and
corrections. The result should be much better if
several people share ideas here, because what is
plausible to one player, may be unintelligible to
another.


* MOTD support

MOTD (Message of the day) could be used, to explain
the special features of a server/map.
Could be a big source of help especially for newbies.

On the other hand, the server could display an URL
as server greeting, where this information could
probably be presented better.
Downside is that the admin would need a website.


* Include description/notes in mapfile

The map format could be extended, so that the author
can include description and notes into it.
Add a multiline capable option mapDescription.
This description could be requested by the client on
connect to a server if Newbie help is true and
displayed in a window like the MOTD.
Additionally make a menu entry "Map Description" or
"Map Info", that requests that info manually.

Even in the server selection window the map names
could be changed to buttons. A press would request
and display the description.


* Compare use of QUICK_LENGTH() vs LENGTH()

In src/client/x11/painthudradar.c the macro
QUICK_LENGTH() is used to calculate the HUD radar
walls. Check whether the walls look (much) better
when using LENGTH() instead. LENGTH() calculates
much more precise, but executes probably (much)
slower.

Samaseon
Posts: 13
Joined: Wed Mar 24, 2010 2:47 pm

Re: Angeba's bloodspilot X11 client todo list.

Postby Samaseon » Thu Aug 25, 2011 11:20 pm

global.c/global.h:
Can't obviously reply to everything in this message at once, but regarding global.c and global.h I think the idea was that these were previously in files like client.c or such files that contain a lot of functions and I just the globals away them away from there to reduce the size of those files. I prefer a lot of small files to a few massive files that nobody has full over view of. It was a work in progress. You can look at the xpilot 4.5.4 or the xpilot NG source codes to see where those globals have been residing earlier.


Return to “BloodsPilot Clients”

Who is online

Users browsing this forum: No registered users and 1 guest