Do we use sprite sheets at all?
by datahead
Post via forum by datahead <cjj_009@xxxxxxxxxx>:
Do we use sprite sheets at all? This basically means we would place an entire set of sprites into one image and have that loaded from the file system all at once. It would then use the coordinates on the image texture in order to properly render the sprites at runtime. This tends to help with performance.
The discussion recently came up for Super Tux - https://github.com/SuperTux/supertux/issues/183
I was just curious if we were using sprite sheets ourselves. I've not seen any reference to them, though I may not have dug deep enough to verify this yet.
--
Sent by Chessboard.
3 years, 11 months
SFML Port New Strategy...
by datahead
Post via forum by datahead <cjj_009@xxxxxxxxxx>:
I spoke the other day with Quintus in a PM discussion regarding the SFML port.
Currently, much of the code in the feature-sfml-port branch has been removed/deactivated, and people have been "filling in the holes", getting things working one item at a time. It is difficult to tell which commits introduced bugs, which we already have several of. This also could cause a risk of instability in the next release, after we fixed a good number of bugs in the last release. Given the number of tasks labeled SFML Port in the tracker (and unknown bugs), I would estimate the original effort would go on for quite some time. If we were to stick with a feature freeze on top of this, it could really slow growth of the project.
My main suggestion was that the SFML API porting and scene management architecture changes really should be two separate efforts. Furthermore, we should break each of these into as granular of tasks as possible, testing each individually before moving onto the next. Thus the game continues to function as we move from task to task.
This is one hypothetical example of a task breakdown that could be followed. This could vary quite a bit based on our findings and discussions over time:
* Phase 1 - SFML Port
* Port SDL Input to SFML
* Port SDL Graphics to SFML
* Port SDL Audio to SFML
* Port OpenGL for sprites to SFML
* Port particle system to SFML
* Release the game, and get user feedback
* Phase 2 - Scene Management Architecture Overhaul
* Create scene manager and basic scenes
* Make game objects work off of the Actor hierarchy
* Simplify main game loop
* Get rid of most global variables
* Release the game, and get user feedback
We would take the feature-sfml-port branch and use it as a reference (maybe renaming it). One or two of the child branches created for the speedfactor / collision issues in the old port effort would also be maintained for our reference.
Given that we will have reduced the amount of complexity taking place at any one time, it will be much less risky to allow features or even simple architecture changes to take place concurrently. We can thus analyze other tasks on a case-by-case basis to consider if they will put the above effort at risk or not. We still do need to finish this effort; completing phase 1 of the above plan should be a priority.
What does everyone think? This is a major decision that affects everyone.
--
Sent by Chessboard.
4 years, 1 month
Availability notice
by Quintus
Hi everyone,
just wanted to note that I have some limited availability currently. I
hope things get better towards the weekend, but don’t count on it.
I do read my email (including tsc-devel), but I haven’t found the time
to check the project’s other channels. If something important requires
my immediate attention and action, please email me.
Valete,
Quintus
--
#!/sbin/quintus
Blog: http://www.guelkerdev.de
GnuPG key: F1D8799FBCC8BC4F
4 years, 2 months
DECLARATION OF RESULTS: Changing the name of “Funky God Mode”
by Quintus
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
D E C L A R A T I O N O F R E S U L T S
2nd vote November 3rd, 2015
Hi everyone,
this is the formal declaration of results on the 2nd vote of the TSC
team. It contains the official number of voting ballots counted, their
chosen options, and it states the outcome of the vote.
History
°°°°°°°
- - 2015-10-11: Vote announcement
http://lists.secretchronicles.de/tsc-devel/2015/10/0000023.html
<87si5hsxnu.fsf(a)atlantis.cable.internal.west-ik.de>
- - 2015-10-25: Call for Votes
http://lists.secretchronicles.de/tsc-devel/2015/10/0000075.html
<8737wyzqhh.fsf(a)hades.cable.internal.west-ik.de>
- - 2015-11-03: Declaration of results
(this message)
Proponent
°°°°°°°°°
The vote was proposed by me, Quintus <quintus(a)quintilianus.eu>.
Vote Subject
°°°°°°°°°°°°
There was a discussion spawned in the issue tracker (ticket #441[1])
about whether or not to rename the special mode that makes Alex
invincible from “Funky God Mode” to something different. The main
argument was that the term might be perceived as an unnecessary and
maybe even blasphemic use of the name of God for highly religious
Christians. There has been a good number of pros and cons being
exchanged on the tracker, which I advise everyone to carefully read
before making a decision.
As it appears to be impossible to find a compromise (one can’t really
change the name only partly) and there are people arguing for both
options, I determined a vote was necessary to clear the matter up.
To ease things, this vote not only decides about whether to rename
current God Mode, but also about what to rename it to exactly to prevent
nececcisity of another voting procedure. By voting for option 1 below,
you indicate you want to keep the current naming, voting for any other
option is a vote against the current naming and in favour of another
name (the one you vote for).
Votes
°°°°°
- From 9 people allowed to vote (8 mentioned in the announcement message
plus Bugsbane who I assure you is in the team but still has not
publicised his membership, but has pointed that out on the tracker[2]) 7
did exercise their right to vote, which gives a participation of
approx. 77.78%.
These are the definitive results:
| # | Option name | Votes | Percent |
|---+-----------------------------------------------+-------+----------|
| 1 | Funky God Mode (i.e. keep the current naming) | 2 | ~28.57 % |
| 2 | Funky god mode (“God” not capitalised) | 0 | 0.00 % |
| 3 | God Mode | 0 | 0.00 % |
| 4 | Dog Mode | 0 | 0.00 % |
| 5 | Invincible Mode | 1 | ~14.29 % |
| 6 | Omega Mode | 4 | ~57.14 % |
| 7 | Underdog Mode | 0 | 0.00 % |
|---+-----------------------------------------------+-------+----------|
| - | Total | 7 | 100.00 % |
Effect of the Vote
°°°°°°°°°°°°°°°°°°
Option #6 has been ACCEPTED by the majority of the team. It is a binding
decision the team follows from now on, all circumstances being equal.
With regard to the vote subject this means that the current “Funky God
Mode” is going to be renamed to “Omega Mode”.
Right to Complain
°°°°°°°°°°°°°°°°°
Every team member has the right to file a complaint against this formal
declaration. The complaint must be filed within 14 days from now on
(timestamp of this email) with either the project lead or with the
project assistant lead. The project lead and assistant lead must file
the complaint with one another; if both are involved, a volunteer must
be seeked for.
The complaint has to contain an explanation as to why the voting rules
have been violated. The person the complaint was filed with will then
check the procedure against the requirements of the voting rules
document, and if he finds a violation, he can declare the vote failed,
which allows repetition of the vote in question.
Other
°°°°°
I am going to open an issue on the tracker for keeping track of setting
this vote’s results into effect.
Quintus
TSC project lead.
[1]: https://github.com/Secretchronicles/TSC/issues/441
[2]: https://github.com/Secretchronicles/TSC/issues/441#issuecomment-151079395
- --
#!/sbin/quintus
Blog: http://www.guelkerdev.de
GnuPG key: F1D8799FBCC8BC4F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJWOQ3nAAoJEPHYeZ+8yLxPSdwH+wfUaPfpK4apTJE0G0wPInHU
tvk8j2+VcSl6XX33yTEZrIV3Um6gDqjodwn0FLQgDDqwdHhk4gfOKesGFMWQx54b
7dtdu8SztT1IkkcLGIw6WnxL+E15ctW/IjVg+4CuKYjB+8TtKk6wbCmIDsnlOosw
AdzBl3y8TqoW0X4xFooRaQ6Gw5Rm5idaeyH9k/eLRJxKBzrf3eu5puW9r55h8lfd
rWh/wFTLxIXSlTLG3zVG9sDaRgGqnSPvjAyr8Uj4V2MQzm2VCAt5drd7LBu0HeNE
l/BEFMIqZOjMlAo+fKo/jUHirEpvPUNdA6GKFf7mBF+MWfCGsllOL1tr+Df4kVc=
=HK1l
-----END PGP SIGNATURE-----
4 years, 2 months
Binary versus XML for the levels...
by datahead
Post via forum by datahead <cjj_009@xxxxxxxxxx>:
Grimshaw|lap, a friend of mine from the SFML chat room suggested that we use XML for our level format only during development and that binary (representing the in game objects) be used for production purposes.
Thus, for campaign levels, we would use our usual XML format if developing and if we need to debug or research trouble points. We would then convert it all to binary such that we can mass load data to construct C++ objects at runtime for the final version.
For level editing for users, it would produce XML that they are able to see. The first time they run the level, it would run slower, as it caches this into binary. It would then load this binary every time they play, unless they make changes again, in which case they would take a performance hit the first time it deals with the XML again.
He pointed out this is a standard practice in many production game companies and that he would expect out level loading to be slow without this.
--
Sent by Chessboard.
4 years, 2 months