Thread: Re: [Super-tux-devel] Leveleditor first release
Brought to you by:
wkendrick
Menu
▾
▴
super-tux-devel
|
From: Duong-Khang N. <neo...@us...> - 2003-12-28 16:18:51
|
Le Dimanche 28 Décembre 2003 12:46, vous avez écrit : > This game will be played by very little children, so a built-in editor > would be much easier to use for those. By stand-alone I mean there's the game "supertux" and another executable file "supertuxle" or something like that. It's as easy to use as the builtin editor I believe > Well, I just asked this because the world.h, badguy.h and player.h have a > line saying 'C++ Interface:'. > I've also found some comments using //. Is this already ANSI C and/or can > I use it (/* */ are annoying :P)? I think we can use "//" for fast commenting :-). I agree that it's not really C but /**/ takes 235 ms more to write :-D I use /**/ for multiple line comments and oneline comment as much as I can > Did you find the code to be too straight? If you didn't like this, you > probabily had an heart attack when looking at the old gameloop function. ;P > I could put the key events in a different function, I just didn't because > I don't like global variables that much. I don't like the way you use the global variables and the way you call the function from gameloop.c. I think that functions from gameloop.c are not for external use. And last but not least, the way you manipulate pointers don't fit me much. >I'm also not very used to write in C. I code in C++ too, but I keep it apart in my mind while programming in C > I also didn't like (neither understood) the identation you have used in > the game. You should ask Tobias for this :-) Maybe we have to vote for a common coding and identation style. > Cya, > Ricardo -- Never say if I could turn back the time, life is going on ! |
|
From: Tobias <tob...@gm...> - 2003-12-28 16:24:31
|
Ok guys, I have to clarify something. :) The indentations I use are so called GNU indentations. I have a program, wich "reformats" the sources to GNU indentations (used in the Linux kernel AFAIK) automatically and I usually do this before commiting to CVS. So there is no need for you to worry about indentations. You want to know which program? KDevelop3, I'm involved there. I believe this is also possible with emacs. Greetz... Tobias Gläßer Am So, den 28.12.2003 schrieb Duong-Khang NGUYEN um 11:20: > Le Dimanche 28 Décembre 2003 12:46, vous avez écrit : > > This game will be played by very little children, so a built-in editor > > would be much easier to use for those. > > By stand-alone I mean there's the game "supertux" and another executable file > "supertuxle" or something like that. It's as easy to use as the builtin > editor I believe > > > Well, I just asked this because the world.h, badguy.h and player.h have a > > line saying 'C++ Interface:'. > > I've also found some comments using //. Is this already ANSI C and/or can > > I use it (/* */ are annoying :P)? > > I think we can use "//" for fast commenting :-). I agree that it's not really > C but /**/ takes 235 ms more to write :-D I use /**/ for multiple line > comments and oneline comment as much as I can > > > Did you find the code to be too straight? If you didn't like this, you > > probabily had an heart attack when looking at the old gameloop function. ;P > > I could put the key events in a different function, I just didn't because > > I don't like global variables that much. > > I don't like the way you use the global variables and the way you call the > function from gameloop.c. I think that functions from gameloop.c are not for > external use. And last but not least, the way you manipulate pointers don't > fit me much. > > >I'm also not very used to write in C. > > I code in C++ too, but I keep it apart in my mind while programming in C > > > I also didn't like (neither understood) the identation you have used in > > the game. > > You should ask Tobias for this :-) Maybe we have to vote for a common coding > and identation style. > > > Cya, > > Ricardo |
|
From: Ingo R. <gr...@gm...> - 2003-12-28 19:24:42
|
Tobias Gl=E4=DFer <tob...@gm...> writes: > The indentations I use are so called GNU indentations. I have a > program, wich "reformats" the sources to GNU indentations (used in > the Linux kernel AFAIK) automatically and I usually do this before > commiting to CVS. Don't let Linus hear that, GNU and Linux indentation style is quite differnt: http://pantransit.reptiles.org/prog/CodingStyle.html --=20 WWW: http://pingus.seul.org/~grumbel/=20 JabberID: gr...@ja...=20 ICQ: 59461927 |
|
From: Tobias <tob...@gm...> - 2003-12-28 19:33:26
|
Am So, den 28.12.2003 schrieb Ingo Ruhnke um 14:24: > Tobias Gläßer <tob...@gm...> writes: > > > The indentations I use are so called GNU indentations. I have a > > program, wich "reformats" the sources to GNU indentations (used in > > the Linux kernel AFAIK) automatically and I usually do this before > > commiting to CVS. > > Don't let Linus hear that, GNU and Linux indentation style is quite > differnt: > > http://pantransit.reptiles.org/prog/CodingStyle.html You are right. I now saw, that KDevelop3 can format the source for GNU or for Linux style. I selected the style, wich is closest to Bill's coding style and this is indeed the GNU style. Greetz... Tobias Gläßer -- |
|
From: Tobias <tob...@gm...> - 2003-12-28 17:56:57
|
Am So, den 28.12.2003 schrieb Duong-Khang NGUYEN um 11:20: > Le Dimanche 28 Décembre 2003 12:46, vous avez écrit : > > This game will be played by very little children, so a built-in editor > > would be much easier to use for those. > > By stand-alone I mean there's the game "supertux" and another executable file > "supertuxle" or something like that. It's as easy to use as the builtin > editor I believe I know what you mean. I've played similar games, which used a built in editor and this had some key advantages. - Directly testing the new level by hitting a key for example. - Seeing the level like it looks in the game. Moreover maintaining the level-editor seperate would be a bad idea IMHO, because both could share some code. (remember encapsulation) Give it a chance. If you still think it is that bad, when I've commited it, then we can still create a seperate level-editor. > > Well, I just asked this because the world.h, badguy.h and player.h have a > > line saying 'C++ Interface:'. > > I've also found some comments using //. Is this already ANSI C and/or can > > I use it (/* */ are annoying :P)? > > I think we can use "//" for fast commenting :-). I agree that it's not really > C but /**/ takes 235 ms more to write :-D I use /**/ for multiple line > comments and oneline comment as much as I can The 'C++ Interface' thingy was simply a copy+paste mistake. :) Greetz... Tobias Gläßer |
|
From: Bill K. <nb...@so...> - 2003-12-29 18:17:45
|
On Sun, Dec 28, 2003 at 06:56:40PM -0500, Tobias Gl=E4=DFer wrote: > I know what you mean. I've played similar games, which used a built in > editor and this had some key advantages. > - Directly testing the new level by hitting a key for example. Not that I'm particularly for or against having the editor inside the app., there IS a possibility of using "system()" to execute a 2nd SDL app while the first is running (assuming the first isn't in full-screen, whic= h I doubt it would be, if it's a level editor :) ) > - Seeing the level like it looks in the game. If we moved some of the code to shared sources/libraries, that'd help ;^)= ;^) -bill! |
|
From: Ricardo C. <ri...@ae...> - 2003-12-28 20:23:20
|
(the dumb kmail was replying only to the person that send the mail to the=20 list, so i am resending this mail to the all list) Hey all, Em Domingo, 28 de Dezembro de 2003 16:20, o Duong-Khang NGUYEN escreveu: > Le Dimanche 28 D=E9cembre 2003 12:46, vous avez =E9crit : > > This game will be played by very little children, so a built-in editor > > would be much easier to use for those. > > By stand-alone I mean there's the game "supertux" and another executable > file "supertuxle" or something like that. It's as easy to use as the > builtin editor I believe > As Tobias mentioned, it would be cool to have a test option. Could be easi= ly=20 implemented in an internal editor. Futhermore, different executables could be easy to use for us, but not for= a=20 child. > > Did you find the code to be too straight? If you didn't like this, you > > probabily had an heart attack when looking at the old gameloop function. > > ;P I could put the key events in a different function, I just didn't > > because I don't like global variables that much. > > I don't like the way you use the global variables and the way you call the > function from gameloop.c. I think that functions from gameloop.c are not > for external use. And last but not least, the way you manipulate pointers > don't fit me much. > I would like to know more about what you find wrong in my pointers=20 manipulation... Really, I am not an experienced programmer and I am comited= =20 to improve my coding. Anyway, about the =ABfunctions from gameloop.c are not for external use=BB. Tobias said: > Moreover maintaining the level-editor seperate would be a bad idea IMHO, > because both could share some code. (remember encapsulation) > Give it a chance. If you still think it is that bad, when I've commited > it, then we can still create a seperate level-editor. What do you guys think it would be better, that the level editor called=20 gameloop functions or not? Currently, 6 gameloop funcs are called and 2 were forked. I had to fork th= em=20 because they have some stuff that had to be different, but these two could = be=20 easily changed in gameloop, in order to level editor call them from there. Anyway, I think a level editor should be internal, since it wouldn't spend= =20 much code (2 files) and integration is very cool. Now, should it use gameloop functions or not? Using them would lead to=20 simpler code in the leveleditors files, at the same time, it would lead to= =20 harder code to debug and a change in gameloop could break or, even worse,=20 create nasty and not right way visible bugs in the level editor. Regards, Ricardo =2D-=20 Tact, n.: The unsaid part of what you're thinking. |
|
From: Ricardo C. <ri...@ae...> - 2003-12-28 20:23:25
|
Em Domingo, 28 de Dezembro de 2003 19:24, o Ingo Ruhnke escreveu: > Tobias Gl=E4=DFer <tob...@gm...> writes: > > The indentations I use are so called GNU indentations. I have a > > program, wich "reformats" the sources to GNU indentations (used in > > the Linux kernel AFAIK) automatically and I usually do this before > > commiting to CVS. > > Don't let Linus hear that, GNU and Linux indentation style is quite > differnt: > > http://pantransit.reptiles.org/prog/CodingStyle.html Wow! Nice to see a celebrity around ;) Anyway, I keep thinking why are ppl so scared of the Tabs! Really, tabs ar= e=20 the best thing since sliced bread. Ricardo =2D-=20 An artist should be fit for the best society and keep out of it. |
|
From: Ingo R. <gr...@gm...> - 2003-12-28 19:56:04
|
Ricardo Cruz <ri...@ae...> writes: > Anyway, I keep thinking why are ppl so scared of the Tabs! Really, > tabs are the best thing since sliced bread. The problem with tabs is that many 'clever' text-editors are just a bit too clever handling them, ie. Emacs converts tabs and spaces from one to another pretty much randomly (have a tab and go backspace -> you get 7 spaces instead of removing the tab), resulting in a huge mess if viewed in another editor or with anotehr tab-width. One can fix Emacs to not do that, but its really far from streight forward. After all the easiest way to 'fix' this is to completly avoid tabs and use spaces always, this of course removes the freedom to use another tab width, but ensures that the sources looks everywhere the same (which is good or bad, depending on if you like the source look). -- WWW: http://pingus.seul.org/~grumbel/ JabberID: gr...@ja... ICQ: 59461927 |
|
From: Ricardo C. <ri...@ae...> - 2003-12-28 20:30:54
|
Well, I think that Tabs should be used at the begging of the line and spaces between stuff. Just like a document, where the 1st line is more inside than the rest of the paragraph. Comments and inside stuff should go for spaces. -- Tobias, in the menu.c, you should replace all NO_UPDATE by UPDATE and then remove the SDL_Flip(screen); line. This is the cause of the menu flickering, because the background is being drawn by intro.c or gameloop.c, the text entries are only drawn after and repeat the screen blitting, that was done before. Another solution would be to disable UPDATE in the intro.c and gameloop.c and keep the rest as it is. Anxious to see my level editor in the cvs :), Ricardo Em Domingo, 28 de Dezembro de 2003 19:55, o Ingo Ruhnke escreveu: > Ricardo Cruz <ri...@ae...> writes: > > Anyway, I keep thinking why are ppl so scared of the Tabs! Really, > > tabs are the best thing since sliced bread. > > The problem with tabs is that many 'clever' text-editors are just a > bit too clever handling them, ie. Emacs converts tabs and spaces from > one to another pretty much randomly (have a tab and go backspace -> > you get 7 spaces instead of removing the tab), resulting in a huge > mess if viewed in another editor or with anotehr tab-width. One can > fix Emacs to not do that, but its really far from streight forward. > After all the easiest way to 'fix' this is to completly avoid tabs and > use spaces always, this of course removes the freedom to use another > tab width, but ensures that the sources looks everywhere the same > (which is good or bad, depending on if you like the source look). -- Brain damage is all in your head. -- Karl Lehenbauer |
|
From: Tobias <tob...@gm...> - 2003-12-28 20:34:56
|
> Tobias, in the menu.c, you should replace all NO_UPDATE by UPDATE and then > remove the SDL_Flip(screen); line. This is the cause of the menu flickering, > because the background is being drawn by intro.c or gameloop.c, the text > entries are only drawn after and repeat the screen blitting, that was done > before. > Another solution would be to disable UPDATE in the intro.c and gameloop.c and > keep the rest as it is. Thanks for your hint. :) > Anxious to see my level editor in the cvs :), > Ricardo Please be patient. ;) Greetz... Tobias Gläßer |
|
From: Ricardo C. <ri...@ae...> - 2003-12-29 01:56:50
Attachments:
patch
|
Here it goes the patch, I've just replaced UPDATE by NO_UPDATE in the titl= e.c=20 and keep the rest. Bye, bye flickering! :) I've made an hugly hack to add support to shadows. I found shadows at the= =20 menu entries to be very beatiful. Give it a try, add the following two line= =20 at the drawtext() in the screen.c : if(surf !=3D letters_black) drawtext(text, x+1, y+1, letters_black, update); If you like the result, I could add another parameter to drawtext() in ord= er=20 to add or not shadow. I think the menu entries look really good with it :) See you, Ricardo Em Segunda, 29 de Dezembro de 2003 02:34, o Tobias Gl=C3=A4=C3=9Fer escreve= u: > > Tobias, in the menu.c, you should replace all NO_UPDATE by UPDATE and > > then remove the SDL_Flip(screen); line. This is the cause of the menu > > flickering, because the background is being drawn by intro.c or > > gameloop.c, the text entries are only drawn after and repeat the screen > > blitting, that was done before. > > Another solution would be to disable UPDATE in the intro.c and > > gameloop.c and keep the rest as it is. > > Thanks for your hint. :) > > > Greetz... > > Tobias Gl=C3=A4=C3=9Fer > > =2D-=20 When in doubt, tell the truth. -- Mark Twain |
|
From: Ricardo C. <ri...@ae...> - 2003-12-29 02:00:03
|
This shadow stuff I've mentioned seems to already be done, but maybe we co= uld=20 make menu entries to draw bigger shadows, since it looks prettier. It would be pretty easy to do. However, should the argument be a constant= =20 like LARGER_SHADOW or should the length be specified. Ricardo Em Segunda, 29 de Dezembro de 2003 02:00, escreveu: > Here it goes the patch, I've just replaced UPDATE by NO_UPDATE in the > title.c and keep the rest. Bye, bye flickering! :) > > I've made an hugly hack to add support to shadows. I found shadows at the > menu entries to be very beatiful. Give it a try, add the following two li= ne > at the drawtext() in the screen.c : > if(surf !=3D letters_black) > drawtext(text, x+1, y+1, letters_black, update); > > If you like the result, I could add another parameter to drawtext() in > order to add or not shadow. I think the menu entries look really good with > it :) > > See you, > Ricardo > > Em Segunda, 29 de Dezembro de 2003 02:34, o Tobias Gl=C3=A4=C3=9Fer escre= veu: > > > Tobias, in the menu.c, you should replace all NO_UPDATE by UPDATE and > > > then remove the SDL_Flip(screen); line. This is the cause of the menu > > > flickering, because the background is being drawn by intro.c or > > > gameloop.c, the text entries are only drawn after and repeat the scre= en > > > blitting, that was done before. > > > Another solution would be to disable UPDATE in the intro.c and > > > gameloop.c and keep the rest as it is. > > > > Thanks for your hint. :) > > > > > > Greetz... > > > > Tobias Gl=C3=A4=C3=9Fer =2D-=20 There's nothing like the face of a kid eating a Hershey bar. |
|
From: Bill K. <nb...@so...> - 2003-12-29 18:14:03
|
On Sun, Dec 28, 2003 at 05:20:34PM +0100, Duong-Khang NGUYEN wrote: > You should ask Tobias for this :-) Maybe we have to vote for a common coding > and identation style. I vote for the way Emacs does it for me when I hit [Tab] :^) (Though I still use vi a lot these days, cuz it loads faster ;) ) -bill! |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X