forked from BackupTheBerlios/supertux-devel-maillist
-
Notifications
You must be signed in to change notification settings - Fork 0
/
2006-April.txt
7987 lines (7160 loc) · 279 KB
/
2006-April.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
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
From matze at braunis.de Sat Apr 1 15:15:33 2006
From: matze at braunis.de (Matze Braun)
Date: Sat, 01 Apr 2006 15:15:33 +0200
Subject: [Supertux-devel] Development Focus
Message-ID: <[email protected]>
Develpoment for milestone2 has been very varying so far. We collected
lots of ideas and are still flooded every day with new ideas from
ourself and others. The engine has gone a major overhaul and we
implemented lots of new features. We have new music new graphics new
tilesets, better tools, a scripting language.
And still looking at Milestone2 we're still far away from it. I think
part of the problem is that development isn't focused enough. We add
random new features everywhere but lack a clear goal of what we need for
milestone2.
I think we reached a point where we have enough new features and stuff
collected for milestone2, it's time to work specifically towards this
release. To achieve this we'll start several development cycles. A cycle
is a set of feature that somehow relate to each other and should be
attacked as a bunch. Once we have a cycle completed we can move to the
next one, but should have everything in the cycle ready for milestone2.
So we'll start with Cycle1:
http://supertux.berlios.de/wiki/index.php/Cycle1
Goal:
The goal is to get world1 polished up and integrated to fit Milestone2.
Tasks:
* Make intro cutscene play when the user enters world1 (no savegame yet)
* Change worldmap to have alternative ways and shortcuts. It should be
possible to beat worldmap 1 with 7 levels (So users don't have to
play all 26 levels again to get to world2). All the other levels
should stay but be on alternative/optional paths
* At the end of the fortress we need a cutscene to the yeti
* the yeti has to work perfectly
* When the yeti is defeated play a cutscene
* Open way to slide on the worldmap and make it work
* Make sure all old maps still work
So I'd like everyone to concentrate on these things so that we can
hopefully see some real progress soon! Seeing all the new pieces come
together should give the needed boost to move towards the next release.
Greetings,
Matze
From wansti at gmx.de Thu Apr 6 09:49:03 2006
From: wansti at gmx.de (Marek M.)
Date: Thu, 06 Apr 2006 09:49:03 +0200
Subject: [Supertux-devel] Re: [Supertux-commit] r3248 - in trunk/supertux: data/images/engine
src
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
A console?! Cooooooooooool! :-D
Gotta try it as soon as I get home from work.
Finally a good place to move the cheats to. :-)
Marek
sommer at BerliOS wrote:
>Author: sommer
>Date: 2006-04-06 03:46:31 +0200 (Thu, 06 Apr 2006)
>New Revision: 3248
>
>Added:
> trunk/supertux/data/images/engine/console.jpg
> trunk/supertux/src/console.cpp
> trunk/supertux/src/console.hpp
>Modified:
> trunk/supertux/src/game_session.cpp
> trunk/supertux/src/game_session.hpp
> trunk/supertux/src/msg.hpp
> trunk/supertux/src/title.cpp
> trunk/supertux/src/worldmap.cpp
> trunk/supertux/src/worldmap.hpp
>Log:
>Simple Console
>
>
>
>
From rflegel at gmail.com Thu Apr 6 22:14:55 2006
From: rflegel at gmail.com (Ryan Flegel)
Date: Thu, 6 Apr 2006 14:14:55 -0600
Subject: [Supertux-devel] Moving graphic and audio source files
Message-ID: <[email protected]>
Hi there,
I'm wondering if anyone has a problem with moving all graphic and
audio source files (eg, .xcf and .rg files) to trunk/media in the svn
repo. I'm particularily looking for input from those that work with
graphics and sound.
The advantages of moving these files to trunk/media is that it would
make the trunk/supertux checkout 30+ MB smaller and trunk/media would
only have to be checked out by people interested in working with the
sound and graphics.
Thoughts? Opinions?
--
Ryan
From wansti at gmx.de Fri Apr 7 10:12:19 2006
From: wansti at gmx.de (Marek M.)
Date: Fri, 07 Apr 2006 10:12:19 +0200
Subject: [Supertux-devel] Moving graphic and audio source files
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
Hi!
The source files should all be in the contrib/ directory (with the
exception of some xcf files that serve as placeholders for badguys and
other objects that still need to be animated), together with currently
unused data.
Moving the whole contrib directory out of the way (into trunk/contrib or
whatever) sounds okay to me.
Marek
Ryan Flegel wrote:
>Hi there,
>
>I'm wondering if anyone has a problem with moving all graphic and
>audio source files (eg, .xcf and .rg files) to trunk/media in the svn
>repo. I'm particularily looking for input from those that work with
>graphics and sound.
>
>The advantages of moving these files to trunk/media is that it would
>make the trunk/supertux checkout 30+ MB smaller and trunk/media would
>only have to be checked out by people interested in working with the
>sound and graphics.
>
>Thoughts? Opinions?
>
>--
>Ryan
>_______________________________________________
>Supertux-devel mailing list
>Supertux-devel at lists.berlios.de
>http://lists.berlios.de/mailman/listinfo/supertux-devel
>
>
From rflegel at gmail.com Fri Apr 7 20:38:22 2006
From: rflegel at gmail.com (Ryan Flegel)
Date: Fri, 7 Apr 2006 12:38:22 -0600
Subject: [Supertux-devel] Moving graphic and audio source files
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
Okay, the media files from contrib/ have been moved to trunk/media/.
If you want to work with the rosegarden or gimp source files then you
should checkout trunk/media:
svn checkout svn+ssh://developername at svn.berlios.de/svnroot/repos/supertux/trunk/media
supertux-media
This should cut down on the size of the main trunk/supertux branch by
about 30+ MB.
--
Ryan
On 4/7/06, Marek M. <wansti at gmx.de> wrote:
>
> Hi!
> The source files should all be in the contrib/ directory (with the
> exception of some xcf files that serve as placeholders for badguys and
> other objects that still need to be animated), together with currently
> unused data.
> Moving the whole contrib directory out of the way (into trunk/contrib or
> whatever) sounds okay to me.
>
> Marek
>
> Ryan Flegel wrote:
>
> >Hi there,
> >
> >I'm wondering if anyone has a problem with moving all graphic and
> >audio source files (eg, .xcf and .rg files) to trunk/media in the svn
> >repo. I'm particularily looking for input from those that work with
> >graphics and sound.
> >
> >The advantages of moving these files to trunk/media is that it would
> >make the trunk/supertux checkout 30+ MB smaller and trunk/media would
> >only have to be checked out by people interested in working with the
> >sound and graphics.
> >
> >Thoughts? Opinions?
> >
> >--
> >Ryan
> >_______________________________________________
> >Supertux-devel mailing list
> >Supertux-devel at lists.berlios.de
> >http://lists.berlios.de/mailman/listinfo/supertux-devel
> >
> >
>
> _______________________________________________
> Supertux-devel mailing list
> Supertux-devel at lists.berlios.de
> http://lists.berlios.de/mailman/listinfo/supertux-devel
>
From allen at a-king.us Sat Apr 8 17:17:35 2006
From: allen at a-king.us (Allen King)
Date: Sat, 08 Apr 2006 11:17:35 -0400
Subject: [Supertux-devel] "Remote Control" for Supertux
Message-ID: <[email protected]>
Folks of Supertux,
As part of a machine learning testbed, I want to add a "remote
control" API to Supertux. This will allow another program sitting as a
client on a port to Supertux to supply button information for tux and
receive back which icons are visible on the screen and where. Because
the client program may be slow, it will have to have control the advance
of Supertux time, and thus in this mode, Supertux will not be "real
time". (Perhaps it might even be faster!^) Repeatability of runs is
also desirable, so control of random number seeds must be gained.
The following questions to your group are on my mind:
1. What work is ongoing that would help me with this effort? I
noticed a post about a console.
2. What is the right forum to pick people's brains, with further
design questions? I notice a lot of game-play programming activity
in http://developer.berlios.de/mail/?group_id=3467 , but little
with the "engine" part. Are there specific people who specialize
in the "engine" parts of Supertux? Who are they?
3. What would it take to have the "remote control" operation, given
it works and is well structured, be incorporated into the Supertux
codebase? I would supply documentation of the API, and a minimum
diagnostic demo as an example of the API's use. Do I just submit
a patch and pray, are there "powers to be" that nod and give me
svn access, or what?
4. From the standpoint of the Supertux community, what is the
desirability of having a "remote control" ability incorporated
into the mainline Supertux code base? I see the following
advantages: a) automated testing of Supertux, b) increasing the
Supertux user community with people, like myself, interested in
machine learning, and c) "it's easy, why not!"
So I've actually been fiddling with a copy of the supertux source (an
svn checkout on 4/6/06). So far I have built a PortServerController
subclass of Controller, instantiated it in supertux in a very simple way
(alongside of JoystickKeyboardController), which talks via ports to a
lightweight client. So here is my plan, which I'd like to pick your
collective brains about:
1. The plan is to have my PortServerController register using
tux.set_controller, and buttons should "just work".
2. I was planning on adding two class variable to game_session, one
to fix the increments of time simulated to a fixed value, and the
other to stop simulation to wait for more API commands. The plan
is to add where needed (bracketed by if statements) the code for
non-real time (port) operation. These notions are currently
"fuzzy", I suspect there are better ones.
3. How to gather object info to send back is a few days out for me.
Thought was to add a statusString serialization method to some of
the game object classes, and just package up the results. I am
interested in a block name/UID which will be stable over
revisions, perhaps some basic properties (like solid, background,
sprite (for tux, bad guys, and coinage), etc). Also the game
status line.
4. The following is last: modifications for random number generator
repeatability would be as follows: In normal operation, the
random seed (probably selected by time()) would printed out on a
console. If that run was interesting, it would be possible to
force that seed with config code. Are any efforts to this effect
already in the code?
5. Does this plan look sane? Are there other ways to accomplish my
goals which come to mind? Are there ongoing changes to the
"engine" which I sould know about?
Hope that you can guide my effort, and that my work can contribute to
Supertux. All opinions, thoughts, and help are welcome.
Allen King
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.berlios.de/pipermail/supertux-devel/attachments/20060408/8c7c4273/attachment.html>
From matze at braunis.de Sun Apr 9 15:27:39 2006
From: matze at braunis.de (Matze Braun)
Date: Sun, 09 Apr 2006 15:27:39 +0200
Subject: [Supertux-devel] "Remote Control" for Supertux
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
Am Samstag, den 08.04.2006, 11:17 -0400 schrieb Allen King:
> Folks of Supertux,
>
> As part of a machine learning testbed, I want to add a "remote
> control" API to Supertux. This will allow another program sitting as
> a client on a port to Supertux to supply button information for tux
> and receive back which icons are visible on the screen and where.
> Because the client program may be slow, it will have to have control
> the advance of Supertux time, and thus in this mode, Supertux will not
> be "real time". (Perhaps it might even be faster!^) Repeatability of
> runs is also desirable, so control of random number seeds must be
> gained.
In general the current development version should be suitable for your
tasks. As you probably don't depend on a finished and polished game, you
should just grab a svn version and use that.
>
> The following questions to your group are on my mind:
> 1. What work is ongoing that would help me with this effort? I
> noticed a post about a console.
The console is mainly a debugging tool to execute some commands from
inside the game and display warnings and errors to users.
> 1. What is the right forum to pick people's brains, with further
> design questions? I notice a lot of game-play programming
> activity in http://developer.berlios.de/mail/?group_id=3467 ,
> but little with the "engine" part. Are there specific people
> who specialize in the "engine" parts of Supertux? Who are
> they?
By far most activity around supertux happens in our irc channel
#supertux at irc.freenode.net and in our wiki at
http://supertux.berlios.de/wiki
> 1. What would it take to have the "remote control" operation,
> given it works and is well structured, be incorporated into
> the Supertux codebase? I would supply documentation of the
> API, and a minimum diagnostic demo as an example of the API's
> use. Do I just submit a patch and pray, are there "powers to
> be" that nod and give me svn access, or what?
As already said, svn version already has such an API. We typically grant
svn access when someone has submitted some good patches and plans to do
further work on supertux. About develpoment/patching you should take a
look here:
http://supertux.berlios.de/wiki/index.php/SetupDev
http://supertux.berlios.de/wiki/index.php/Download/Subversion
> 1. From the standpoint of the Supertux community, what is the
> desirability of having a "remote control" ability incorporated
> into the mainline Supertux code base? I see the following
> advantages: a) automated testing of Supertux, b) increasing
> the Supertux user community with people, like myself,
> interested in machine learning, and c) "it's easy, why not!"
> So I've actually been fiddling with a copy of the supertux source
> (an svn checkout on 4/6/06). So far I have built a
> PortServerController subclass of Controller, instantiated it in
> supertux in a very simple way (alongside of
> JoystickKeyboardController), which talks via ports to a lightweight
> client. So here is my plan, which I'd like to pick your collective
> brains about:
Of course we like to see other people using our code and having fun with
it. And I don't want to discourage you here. But in the main development
line this remote control seems total overkill and won't help the normal
players of the game.
So I'd say you better maintain this stuff as a fork/set of patches to
the game. I think the Controller API will stay like it is now in the
future, so you should have few risk that your stuff breaks.
> 1. The plan is to have my PortServerController register using
> tux.set_controller, and buttons should "just work".
> 2. I was planning on adding two class variable to game_session,
> one to fix the increments of time simulated to a fixed value,
> and the other to stop simulation to wait for more API
> commands. The plan is to add where needed (bracketed by if
> statements) the code for non-real time (port) operation.
> These notions are currently "fuzzy", I suspect there are
> better ones.
The simulation is already advances in a fixed time. All the behaviour
and game logic runs in a logical framerate of 60fps (depending on your
machine fewer frames might actually get drawn). In the latest svn
version you can find that code in mainloop.cpp you should be able to
extend/hack mainloop.cpp to stop the simulation if that is needed.
> 1. How to gather object info to send back is a few days out for
> me. Thought was to add a statusString serialization method to
> some of the game object classes, and just package up the
> results. I am interested in a block name/UID which will be
> stable over revisions, perhaps some basic properties (like
> solid, background, sprite (for tux, bad guys, and coinage),
> etc). Also the game status line.
well that's something we surely wouldn't like to see in the main
codebase (more bloat and more work for people who invent new object
types). At least additional fields/methods pushed into these classes
would be bad from our point of view. If you keep the code for this stuff
externally (you could dynamic_cast around and use hashmaps with the
objects to store additional metadata) then this is of course less
intrusive.
> 1. The following is last: modifications for random number
> generator repeatability would be as follows: In normal
> operation, the random seed (probably selected by time()) would
> printed out on a console. If that run was interesting, it
> would be possible to force that seed with config code. Are
> any efforts to this effect already in the code?
In general we try to keep the behaviour predictable and free of random
events that we can't really control. The only cases where randomness
really matters is that Dispenser badguy which has a random mode (which I
personally would rather see be removed). Making the randomness
controllable by having a global random number generator that is used
throughout supertux would also be important for record/playback of
demos. Patches would be apreciated ;-)
> 1. Does this plan look sane? Are there other ways to accomplish
> my goals which come to mind? Are there ongoing changes to the
> "engine" which I sould know about?
>
> Hope that you can guide my effort, and that my work can contribute to
> Supertux. All opinions, thoughts, and help are welcome.
Maybe it would be best if you try to catch me or someone of the others
on irc...
Greetings,
Matze
From matze at braunis.de Sun Apr 9 15:27:39 2006
From: matze at braunis.de (Matze Braun)
Date: Sun, 09 Apr 2006 15:27:39 +0200
Subject: [Supertux-devel] "Remote Control" for Supertux
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
Am Samstag, den 08.04.2006, 11:17 -0400 schrieb Allen King:
> Folks of Supertux,
>
> As part of a machine learning testbed, I want to add a "remote
> control" API to Supertux. This will allow another program sitting as
> a client on a port to Supertux to supply button information for tux
> and receive back which icons are visible on the screen and where.
> Because the client program may be slow, it will have to have control
> the advance of Supertux time, and thus in this mode, Supertux will not
> be "real time". (Perhaps it might even be faster!^) Repeatability of
> runs is also desirable, so control of random number seeds must be
> gained.
In general the current development version should be suitable for your
tasks. As you probably don't depend on a finished and polished game, you
should just grab a svn version and use that.
>
> The following questions to your group are on my mind:
> 1. What work is ongoing that would help me with this effort? I
> noticed a post about a console.
The console is mainly a debugging tool to execute some commands from
inside the game and display warnings and errors to users.
> 1. What is the right forum to pick people's brains, with further
> design questions? I notice a lot of game-play programming
> activity in http://developer.berlios.de/mail/?group_id=3467 ,
> but little with the "engine" part. Are there specific people
> who specialize in the "engine" parts of Supertux? Who are
> they?
By far most activity around supertux happens in our irc channel
#supertux at irc.freenode.net and in our wiki at
http://supertux.berlios.de/wiki
> 1. What would it take to have the "remote control" operation,
> given it works and is well structured, be incorporated into
> the Supertux codebase? I would supply documentation of the
> API, and a minimum diagnostic demo as an example of the API's
> use. Do I just submit a patch and pray, are there "powers to
> be" that nod and give me svn access, or what?
As already said, svn version already has such an API. We typically grant
svn access when someone has submitted some good patches and plans to do
further work on supertux. About develpoment/patching you should take a
look here:
http://supertux.berlios.de/wiki/index.php/SetupDev
http://supertux.berlios.de/wiki/index.php/Download/Subversion
> 1. From the standpoint of the Supertux community, what is the
> desirability of having a "remote control" ability incorporated
> into the mainline Supertux code base? I see the following
> advantages: a) automated testing of Supertux, b) increasing
> the Supertux user community with people, like myself,
> interested in machine learning, and c) "it's easy, why not!"
> So I've actually been fiddling with a copy of the supertux source
> (an svn checkout on 4/6/06). So far I have built a
> PortServerController subclass of Controller, instantiated it in
> supertux in a very simple way (alongside of
> JoystickKeyboardController), which talks via ports to a lightweight
> client. So here is my plan, which I'd like to pick your collective
> brains about:
Of course we like to see other people using our code and having fun with
it. And I don't want to discourage you here. But in the main development
line this remote control seems total overkill and won't help the normal
players of the game.
So I'd say you better maintain this stuff as a fork/set of patches to
the game. I think the Controller API will stay like it is now in the
future, so you should have few risk that your stuff breaks.
> 1. The plan is to have my PortServerController register using
> tux.set_controller, and buttons should "just work".
> 2. I was planning on adding two class variable to game_session,
> one to fix the increments of time simulated to a fixed value,
> and the other to stop simulation to wait for more API
> commands. The plan is to add where needed (bracketed by if
> statements) the code for non-real time (port) operation.
> These notions are currently "fuzzy", I suspect there are
> better ones.
The simulation is already advances in a fixed time. All the behaviour
and game logic runs in a logical framerate of 60fps (depending on your
machine fewer frames might actually get drawn). In the latest svn
version you can find that code in mainloop.cpp you should be able to
extend/hack mainloop.cpp to stop the simulation if that is needed.
> 1. How to gather object info to send back is a few days out for
> me. Thought was to add a statusString serialization method to
> some of the game object classes, and just package up the
> results. I am interested in a block name/UID which will be
> stable over revisions, perhaps some basic properties (like
> solid, background, sprite (for tux, bad guys, and coinage),
> etc). Also the game status line.
well that's something we surely wouldn't like to see in the main
codebase (more bloat and more work for people who invent new object
types). At least additional fields/methods pushed into these classes
would be bad from our point of view. If you keep the code for this stuff
externally (you could dynamic_cast around and use hashmaps with the
objects to store additional metadata) then this is of course less
intrusive.
> 1. The following is last: modifications for random number
> generator repeatability would be as follows: In normal
> operation, the random seed (probably selected by time()) would
> printed out on a console. If that run was interesting, it
> would be possible to force that seed with config code. Are
> any efforts to this effect already in the code?
In general we try to keep the behaviour predictable and free of random
events that we can't really control. The only cases where randomness
really matters is that Dispenser badguy which has a random mode (which I
personally would rather see be removed). Making the randomness
controllable by having a global random number generator that is used
throughout supertux would also be important for record/playback of
demos. Patches would be apreciated ;-)
> 1. Does this plan look sane? Are there other ways to accomplish
> my goals which come to mind? Are there ongoing changes to the
> "engine" which I sould know about?
>
> Hope that you can guide my effort, and that my work can contribute to
> Supertux. All opinions, thoughts, and help are welcome.
Maybe it would be best if you try to catch me or someone of the others
on irc...
Greetings,
Matze
From urrakis at gmail.com Sat Apr 8 22:11:59 2006
From: urrakis at gmail.com (Urrakis)
Date: Sat, 8 Apr 2006 22:11:59 +0200
Subject: [Supertux-devel] use your program
Message-ID: <[email protected]>
can i use your free supertux in my web for download?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.berlios.de/pipermail/supertux-devel/attachments/20060408/133e8536/attachment.html>
From bernhard at intevation.de Mon Apr 10 14:44:32 2006
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 10 Apr 2006 14:44:32 +0200
Subject: [Supertux-devel] Joystick support for 0.1.3 (Debian #288432)
Message-ID: <[email protected]>
Hi Supertux Developers,
thanks for the nice an entertaining game!
And thanks for making it Free Software!
A great wish for me would be support for joysticks.
Pierre Pronchery made a patch for 0.1.3,
which can be found here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=288432
With it, a joystick works!
My only to wish to this is: I want supertux to jump, when moving the joystick
upwards.
Anyway, I am just bringing this to your attention!
Bernhard Reiter
--
www.kolab-konsortium.com Professional Maintenance, Consultancy and Support.
From andersersej at gmail.com Wed Apr 12 14:31:42 2006
From: andersersej at gmail.com (Anders er sej)
Date: Wed, 12 Apr 2006 14:31:42 +0200
Subject: [Supertux-devel] Danish translation of SuperTux
Message-ID: <[email protected]>
Hello
I've translated the devel-version of SuperTux to danish. I have
attached the po files in this mail in a .tar.bz2
- Anders
-------------- next part --------------
A non-text attachment was scrubbed...
Name: da-supertux.tar.bz2
Type: application/x-bzip2
Size: 9649 bytes
Desc: not available
URL: <https://lists.berlios.de/pipermail/supertux-devel/attachments/20060412/6ea22a5a/attachment.bin>
From afief.h at gmail.com Wed Apr 12 18:18:36 2006
From: afief.h at gmail.com (Afief Halumi)
Date: Wed, 12 Apr 2006 18:18:36 +0200
Subject: [Supertux-devel] use your program
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
Don't know what you mean with "in my web for download" if you mean "upload
it into my website so people can download it" AFAIK that is okay according
to the GPL as long as you give credits to the developers.
Don't take my word as a law though, i've not read all of the GPL license
Afief
On 4/8/06, Urrakis <urrakis at gmail.com> wrote:
>
> can i use your free supertux in my web for download?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.berlios.de/pipermail/supertux-devel/attachments/20060412/3798c8a8/attachment.html>
From p637777 at aol.com Wed Apr 12 20:24:04 2006
From: p637777 at aol.com (Markus Engel)
Date: Wed, 12 Apr 2006 20:24:04 +0200
Subject: [Supertux-devel] Patch for Infoboxes
Message-ID: <000001c65e5e$4ba418a0$2001a8c0@homepc01>
Hi!
I have just written a little patch for the scrolling functions of the
Infoboxes. After you patched the file, the arrows for scrolling are only
shown, if the text is too long and you can't scroll down now if the text
fits in the window.
Markus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scrl.patch
Type: application/octet-stream
Size: 2967 bytes
Desc: not available
URL: <https://lists.berlios.de/pipermail/supertux-devel/attachments/20060412/f54dd2cc/attachment.obj>
From rflegel at gmail.com Wed Apr 12 22:37:16 2006
From: rflegel at gmail.com (Ryan Flegel)
Date: Wed, 12 Apr 2006 14:37:16 -0600
Subject: [Supertux-devel] Danish translation of SuperTux
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
Thanks! The translation has been added. I've added you to the credits
as "Anders". If you'd like your last name in there, just let me know.
On 4/12/06, Anders er sej <andersersej at gmail.com> wrote:
> Hello
>
> I've translated the devel-version of SuperTux to danish. I have
> attached the po files in this mail in a .tar.bz2
>
> - Anders
>
>
>
From cwebber at dustycloud.org Thu Apr 13 20:20:31 2006
From: cwebber at dustycloud.org (Christopher Allan Webber)
Date: Thu, 13 Apr 2006 13:20:31 -0500
Subject: [Supertux-devel] use your program
In-Reply-To: <[email protected]>
([email protected]'s message of "Sat, 8 Apr 2006 22:11:59 +0200")
References: <[email protected]>
Message-ID: <[email protected]>
Urrakis <urrakis at gmail.com> writes:
> can i use your free supertux in my web for download?
Urrakis:
The GPL explicitly preserves your rights to copy, modify and
distribute this program as much as you like, as long as the copyrights
and the license itself remain intact, and if you make any
modifications, you follow the clauses of the GPL itself.
In other words, yes :)
From contact at yotamelal.com Thu Apr 13 20:01:26 2006
From: contact at yotamelal.com (Yotam Elal)
Date: Thu, 13 Apr 2006 20:01:26 +0200
Subject: [Supertux-devel] Link?
Message-ID: <[email protected]>
An HTML attachment was scrubbed...
URL: <https://lists.berlios.de/pipermail/supertux-devel/attachments/20060413/e2a46908/attachment.html>
From MADDOGMIKE05 at aol.com Wed Apr 19 05:53:56 2006
From: MADDOGMIKE05 at aol.com (MADDOGMIKE05 at aol.com)
Date: Tue, 18 Apr 2006 23:53:56 EDT
Subject: [Supertux-devel] (no subject)
Message-ID: <[email protected]>
When is Milestone 2 coming out iv' e been waiting like 2 months!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.berlios.de/pipermail/supertux-devel/attachments/20060418/d97a48de/attachment.html>
From allen at a-king.us Fri Apr 21 11:00:46 2006
From: allen at a-king.us (Allen King)
Date: Fri, 21 Apr 2006 05:00:46 -0400
Subject: [Supertux-devel] "Remote Control" for Supertux -- status
Message-ID: <[email protected]>
I've been working on the "Remote Control" changes to Supertux that we
talked about last week, and have a first version that works -- I have a
program that supplies button presses from a canned list to supertux over
a port, and supertux returns a list of all the surfaces drawn, with
texture file names. The changes are still fluid, so I'm inclined not
going to release any patches right yet.
I told Matze I would next make a patch for platform independent
repeatable random numbers, and I am well on my way to completing that.
To finish, I have some (seven) questions on the mods, which I would
like responses to (the first 3 are generic fishing and educational, on
the last 4 I need detailed answers):
BASIC DESIGN:
1) allows for two random generator modes, under control of the
configuration file:
a. If a (random_seed <decimal number>) line is present in the
configuration file, it is used used as the random seed to start
the run.
b. If the above line isn't there, the seed obtained from time()
in the usual way, and is additionally printed, so it can later
be pasted into the configuration file if the run wants to be
reproduced.
QUESTION #1: seem reasonable?
2) Files [.cpp/.hpp] for a platform-independent class RandomNumbers
were added. They were transliterated from C sources found at
http://www.jbox.dk/sanos/source/lib/random.c.html. A wizard friend
of mine claimed this to be "the fastest and best quality" around.
QUESTION #2: any reason not to proceed this way? Is copyleft okay
for supertux?
3) I've included RandomNumbers in a wrapper file "rand.hpp" which
redefines rand() and srand() for general consumption by supertux.
WARNING: Supertux files which call rand() or srand() and which do
NOT include rand.hpp will use the old rand facility, which will be
neither initialized correctly, controllable by config, nor platform
independent. So this would not happen, I buried an include for
rand.hpp deep in game_object.hpp, which is included by all the "bad
guys". I also (redundantly) added similar includes in all .cpp
files which contained calls to [s]rand(), with a shameless
promotional comment, so developers would get the idea.
QUESTION #3: any objections to this? suggestions of better ways
(e.g. changing calls to rand to BlaBlaRand, and redefining rand()
and srand() to print helpful errors?
SUPERTUX FUNCTIONALITY:
4) There is a call to srand() in player.cpp, which occurs after a
player is killed. I do not understand why it would be necessary to
do this -- it seems totally superfluous, but with my very limited
knowledge am way too afraid to comment it out. It would be great if
it could go! As it stands now, random number repeatability ceases
after the first time Tux dies.
QUESTION #4 (THIS IS THE REASON I WROTE THIS EMAIL): Could someone
verify that this call was just put in by someone who didn't
understand random numbers (or not)? If so, the solution is simple.
If not, not.
5) There is another call to srand() in sqstdmath.cpp, but nobody in
supertux-ville seems to call the routine that contains it. I added
an throw of runtime_error to discourage its future use.
QUESTION #5: Is this okay, or too harsh.
6) I was thinking of adding a commented-out setting of random_seed
in the default ~/.supertux/config . (I noted that that was made for
me when I first ran supertux, but a cursory scan didn't show me how.)
QUESTION #6: Can someone help me determine how I would modify the
default ~/.supertux/config? I will do this if someone does.
7) One could turn on/off the use of platform-independent
random_numbers with a ./configure --<option> .
QUESTION #7: Is it worth doing? Enough so that someone could
outline the requisite changes to configure.ac (and friends).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.berlios.de/pipermail/supertux-devel/attachments/20060421/c0e51a61/attachment.html>
From supertux at 2006.expires.deltadevelopment.de Fri Apr 21 20:18:56 2006
From: supertux at 2006.expires.deltadevelopment.de (Christoph Sommer)
Date: Fri, 21 Apr 2006 20:18:56 +0200
Subject: [Supertux-devel] "Remote Control" for Supertux -- status
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
Hey Allen,
Allen King wrote:
> I've been working on the "Remote Control" [...]
> program that supplies button presses from a canned list to supertux over
> a port
[...]
> a. If a (random_seed <decimal number>) line is present in the
> configuration file, it is used used as the random seed to start
> the run.
> b. If the above line isn't there, the seed obtained from time()
> in the usual way, and is additionally printed, so it can later
> be pasted into the configuration file if the run wants to be
> reproduced.
>
> QUESTION #1: seem reasonable?
Depends, I'd say.
If a button press reaches the game one frame later than in the last run,
e.g. killing a badguy that consumes one random number per frame, you
might end up with a different stream of random-numbers from that point
in time on.
> QUESTION #3: any objections to this? suggestions of better ways
> (e.g. changing calls to rand to BlaBlaRand, and redefining rand()
> and srand() to print helpful errors?
I like that approach better. "Altering" standard functions seems a
little odd to me.
> 4) There is a call to srand() in player.cpp, which occurs after a
> player is killed. I do not understand why it would be necessary to
> do this -- it seems totally superfluous
Seems like it got introduced in rev 3320 (Hacked together a "coin
losing" effect when Tux is killed), so it seems superfluous to me, too.
> 5) There is another call to srand() in sqstdmath.cpp, but nobody in
> supertux-ville seems to call the routine that contains it. I added
> an throw of runtime_error to discourage its future use.
> QUESTION #5: Is this okay, or too harsh.
I'm just guessing, but might this be called from a squirrel script?
> QUESTION #6: Can someone help me determine how I would modify the
> default ~/.supertux/config? I will do this if someone does.
I think it's just written by Config::save in gameconfig.cpp
Regards,
Christoph
--
Plan to be spontaneous tomorrow.
From matze at braunis.de Fri Apr 21 22:20:21 2006
From: matze at braunis.de (Matze Braun)
Date: Fri, 21 Apr 2006 22:20:21 +0200
Subject: [Supertux-devel] "Remote Control" for Supertux -- status
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
Am Freitag, den 21.04.2006, 05:00 -0400 schrieb Allen King:
> I've been working on the "Remote Control" changes to Supertux that we
> talked about last week, and have a first version that works -- I have
> a program that supplies button presses from a canned list to supertux
> over a port, and supertux returns a list of all the surfaces drawn,
> with texture file names. The changes are still fluid, so I'm inclined
> not going to release any patches right yet.
>
> I told Matze I would next make a patch for platform independent
> repeatable random numbers, and I am well on my way to completing that.
> To finish, I have some (seven) questions on the mods, which I would
> like responses to (the first 3 are generic fishing and educational, on
> the last 4 I need detailed answers):
>
> BASIC DESIGN:
> 1) allows for two random generator modes, under control of the
> configuration file:
> a. If a (random_seed <decimal number>) line is present
> in the configuration file, it is used used as the
> random seed to start the run.
>
> b. If the above line isn't there, the seed obtained
> from time() in the usual way, and is additionally
> printed, so it can later be pasted into the
> configuration file if the run wants to be reproduced.
> QUESTION #1: seem reasonable?
The deterministic random number generator is needed for 2 use cases:
Saving Demos and Doing reproducible runs with your AI code. For the
first case we have to save the seed in the demo file, in your case you
probably want to send the seed over network. That would make alot more
sense than putting it into a config file IMO.
> 2) Files [.cpp/.hpp] for a platform-independent class
> RandomNumbers were added. They were transliterated from C
> sources found at
> http://www.jbox.dk/sanos/source/lib/random.c.html. A wizard
> friend of mine claimed this to be "the fastest and best
> quality" around.
>
> QUESTION #2: any reason not to proceed this way? Is copyleft
> okay for supertux?
>
Yep this is the most important part of all this. I personally would call
the calss Random or RandomGenerator though...
> 3) I've included RandomNumbers in a wrapper file "rand.hpp"
> which redefines rand() and srand() for general consumption by
> supertux. WARNING: Supertux files which call rand() or srand()
> and which do NOT include rand.hpp will use the old rand
> facility, which will be neither initialized correctly,
> controllable by config, nor platform independent. So this
> would not happen, I buried an include for rand.hpp deep in
> game_object.hpp, which is included by all the "bad guys". I
> also (redundantly) added similar includes in all .cpp files
> which contained calls to [s]rand(), with a shameless
> promotional comment, so developers would get the idea.
>
> QUESTION #3: any objections to this? suggestions of better
> ways (e.g. changing calls to rand to BlaBlaRand, and
> redefining rand() and srand() to print helpful errors?