super-tux-devel — Development mailing list for Super Tux

Re: [Super-tux-devel] 800x600 resolution

[Ricardo C. <ri...@ae...>]

Em Domingo, 9 de Maio de 2004 01:04, o Ingo Ruhnke escreveu:
> Tobias Gl=E4=DFer <tob...@gm...> writes:
> > no doubt 640x480 is just too less and I even think 800x600 is a bad
> > joke, since I'm using a comfortable 1280x1024 desktop.
> > If we switch to a fixed size again, 1024x768 is a wise choice IMHO.
>
> I am personally very happy with 800x600, its pretty much enough for
> everything and low enough to not waste too much space and resources.
> Especially when it comes to pixeled graphics there is little chance to
> fill the screen with a size of 1024x768. Just having a larger
> resolution is worth nothing if there is nobody to fill in all the
> details. Just a little math 800x600 has 1.56 times as many pixels as
> 640x480, 1024x768 already has 2.56 times as many pixels as we
> currently have, so software rendering is really a no-go for 1024x768.
>
 I agree with Ingo, 800x600 is good enough.

> > About the SVG thingy. There are very few 2d games using such a
> > feature currently.
>
> Pretty much all Flash games out there on the Internet use Vector
> graphics, while it isn't SVG, its still pretty much the same. If you
> want to get even more back in time, look at AnotherWorld, used fully
> vector based gfx back then in 1992. Many of the old Sierra adventure
> games also used vector graphics to save some diskspace.
>
> > Therefore we could be pioneers in this field.
>
> Not really, Flash is already pretty dominant in that place :)
>
 Obviously, SuperTux wouldn't be the first using vector graphics... Even in=
 a=20
little game of mine, I use True Type Fonts ;)
 What Tobias meant is that SuperTux could be the first (or one of the first=
s)=20
_big_ and _native_ games to use SVG.

> >  - our experiment could dramatically fail
>
> For sure they would.
>
 Don't be such a pessimist :D

> > But it would be awesome after all to have a option in our option
> >dialog where you can select nearly any screen resolution.
>
> Trivial todo with Opengl already.
>
 What OpenGL do is just to resize them and thus loosing quality. A way to=20
avoid this could be to make graphics bigger, this way it would only had to=
=20
resize them down...

> > Maybe we could even port the current PNGs without much efforts
> > to SVG, don't believe me? Then look at this project:
>
> You can't convert shaded pixel gfx into vector graphics without
> loosing *a lot* of quality, it only works well for simple black&white
> outlines and such.
>
> > A game I found using SVG is KSokoban. That's not THE killer game ;),
> > but it's awesome that you can resize it to every size without loss
> > and its tiles don't look bad (quite good) IMHO.
>
> The version I tested here used still good old pixel graphics. Yes, one
> could scale it, but the graphics would just pixelade as expected.
>
 The one shipped with KDE 3.2 already uses SVG. In fact, Atlantik and maybe=
 a=20
couple of more games also use it.

 KDE goal is to start using SVG in the all desktop on 4.0 or maybe before. =
As=20
a matter of fact, their policy is to only get graphics that also have a SVG=
=20
version. (in fact, KDE 3.2 was delayed because Everaldo wouldn't release th=
e=20
SVG, forcing other artists to mimic their graphics in SVG ;D)

> > I don't know what you think, but SVG is an exciting technology.
>
> Not really. Vector graphic is pretty old technology and has been
> around for ages. SVG is just a new name and a bloated XML format
> wrapped around it. Vector graphics are nice if you want to print to
> paper, but I havn't found them really usefull for on screen display.

 Even if that's truth and SVG hasn't technically innovated anything. I call=
=20
innovation to use existing technology, bringing it to the masses.
 Anyway, vectorial graphics are older than us :D.

=2D-=20
	A novice programmer was once assigned to code a simple financial
package.
	The novice worked furiously for many days, but when his master
reviewed his program, he discovered that it contained a screen editor, a set
of generalized graphics routines, and artificial intelligence interface,
but not the slightest mention of anything financial.
	When the master asked about this, the novice became indignant.
"Don't be so impatient," he said, "I'll put the financial stuff in=20
eventually."
		-- Geoffrey James, "The Tao of Programming"

Re: [Super-tux-devel] 800x600 resolution

[Ricardo C. <ri...@ae...>]

Hey,

 You kinda conviced me... But I still am afraid of artists lost and speed.=
=20
Well, speed shouldn't be an issue as long as we loaded everything during th=
e=20
video mode setup... It could turn into an issue, if we wanted stuff to be=20
resized in-game.
 Truth be told, I've never tested anything related with SVG (in fact, KSoko=
ban=20
is really fast - it only has about six graphics anyway :D), but I am allway=
s=20
suspicious about software rendering. And in case we don't also find a SVG=20
engine for OpenGL, SVG will have to be deal with by software-only.

 Anyway, I am willing to give it a try ;) (especially, because of that=20
png->svg converter)
 My proposal is that we, firstly, implemented a SVG engine into the Surface=
=20
class (maybe Cairo - I think our choice should be not firstly based in the=
=20
performance, but in dependencies and portability). After that, we would jus=
t=20
convert the PNGs into SVGs.
 Only for testing, code can be all hacky and graphics really ugly :)

 Agree? Anyway, I think this should get low priority, maybe we could create=
 a=20
brunch or something like that, just to test it and not break anything.=20
Though, I am looking forward to learn more about SVG.

Cheers,

 Ricardo
=20

Em Domingo, 9 de Maio de 2004 00:11, o Tobias Gl=C3=A4=C3=9Fer escreveu:
> Hi,
>
> I surfed a bit around and googled about SDL/SVG issues.
> There are a few tries that don't seem to be straighforward to me.
> (rsvg etc.)
>
> But then I found cairo about wich I already heared much on slashdot
> and so on. I didn't know that you can use this SVG engine with SDL,
> but indeed there is an example in its CVS repository.
> Perhaps you want to take a look.
> http://freedesktop.org/cgi-bin/viewcvs.cgi/cairo/cairo-demo/sdl/
>
> I think we could change the Surfaces to hold a svg_cairo_t structure
> additionally. This could be used as source for the actual
> surfaces/textures then. (For example if we want to change the
> resolution or draw a scaled image)
>
> After all the possible CPU and memory loads could be the biggest
> problems. I don't know benchmarks about it, do you?
>
> Maybe we could even port the current PNGs without much efforts
> to SVG, don't believe me? Then look at this project:
> http://delineate.sourceforge.net/
> Ok, this conversion won't happen lossfree. Maybe the design would
> end more like in comics. (Good or Bad?)
>
> A game I found using SVG is KSokoban. That's not THE killer game ;),
> but it's awesome that you can resize it to every size without loss
> and its tiles don't look bad (quite good) IMHO.
>
> I don't know what you think, but SVG is an exciting technology.
>
> Greetz...
>
> Tobias Gl=C3=A4=C3=9Fer
>
> Am So, den 09.05.2004 um 0:41 Uhr +0200 schrieb Tobias Gl=C3=A4=C3=9Fer:
> > Hi folks,
> >
> > no doubt 640x480 is just too less and I even think 800x600 is a bad
> > joke, since I'm using a comfortable 1280x1024 desktop.
> > If we switch to a fixed size again, 1024x768 is a wise choice IMHO.
> >
> > About the SVG thingy. There are very few 2d games using such a feature
> > currently. Therefore we could be pioneers in this field.
> > I don't want to convince you about it or persuade you I only want
> > to start a valueable discussion about the pros and cons.
> >
> > This wouldn't mean we have to use the SVG approach throughout the whole
> > game.
> >
> > Some advantages:
> >  - resizing images with no loss
> >  - change graphics/vectors in game ?
> >  - easier creation of animations ?
> >  - reusing of imageparts - merging of images
> >  - being pioneers
> >
> > Some disadvantages:
> >  - the tools/libs for using SVG inside games and
> >    esspecially with SDL are not very mature
> >    (but perhaps we can help in their development,
> >     just like planeshift for example helps crystal
> >     space with stuff they need)
> >  - graphics designers do have less experience and
> >    skills with vector graphics?
> >  - our experiment could dramatically fail
> >
> > Maybe someone of you had a look into KSVG, the KDE SVG engine.
> > SVGs are equally powerful as flashs with it, so I think it's
> > technically possible, which doesn't mean it's easy or the
> > tools/libs for this capabilities are already there.
> >
> > But it would be awesome after all to have a option in our
> > option dialog where you can select nearly any screen resolution.
> > There are big changes and a high risk. No risk no fun? :)
> > (I feel, too many realists are hanging around here;) )
> >
> > Greetz...
> >
> > Tobias Gl=C3=A4=C3=9Fer
> >
> > Am Sa, den 08.05.2004 um 23:05 Uhr +0100 schrieb Ricardo Cruz:
> > > Hey there,
> > >
> > >  It was already suggested by Ingo a resolution change to 800x600. In
> > > fact, IMO the 640x480 is too small and looks really bad when using
> > > fullscreen (especially in my monitor that uses a 1280x1024 resolution=
).
> > >
> > >  If you agree, we could either add rows to levels or/and resize image=
s.
> > > I would prefer this last solution and that would mean a change from
> > > 32x32 images into 40x40 pixels. A resize without interpolation and th=
en
> > > polishment should work just fine...
> > >
> > >  Tobias already discussed the hypotheses of using SVG graphics... IMO,
> > > these graphics have two problems:
> > > - technically, SDL_svg is yet in a very immature stage;
> > > - for artists, SVG tools are also immature, especially Linux ones.
> > >  Besides, I don't think it applies very well into games. I know there
> > > are some advantages, like the power of allowing resizing in real-time,
> > > but don't forget that OpenGL has support for this stuff. Futhermore,
> > > expect SVG real-time resizing to be slow as hell or at least not
> > > smooth.
> > >
> > >  So, what do you think?
> > >
> > >  For the record, this is only plans for mid-future, after the 0.1.x
> > > featuring the level editor.
> > >
> > > Ricardo Cruz
> > >
> > > --
> > > Better by far you should forget and smile than that you should rememb=
er
> > > and be sad.
> > > 		-- Christina Rossetti
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by Sleepycat Software
> > > Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
> > > deliver higher performing products faster, at low TCO.
> > > http://www.sleepycat.com/telcomwpreg.php?From=3Dosdnemail3
> > > _______________________________________________
> > > Super-tux-devel mailing list
> > > Sup...@li...
> > > https://lists.sourceforge.net/lists/listinfo/super-tux-devel
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by Sleepycat Software
> > Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
> > deliver higher performing products faster, at low TCO.
> > http://www.sleepycat.com/telcomwpreg.php?From=3Dosdnemail3
> > _______________________________________________
> > Super-tux-devel mailing list
> > Sup...@li...
> > https://lists.sourceforge.net/lists/listinfo/super-tux-devel
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
> deliver higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=3Dosdnemail3
> _______________________________________________
> Super-tux-devel mailing list
> Sup...@li...
> https://lists.sourceforge.net/lists/listinfo/super-tux-devel

=2D-=20
Who is W.O. Baker, and why is he saying those terrible things about me?

Re: [Super-tux-devel] 800x600 resolution

[Ingo R. <gr...@gm...>]

Tobias Gl=E4=DFer <tob...@gm...> writes:

> no doubt 640x480 is just too less and I even think 800x600 is a bad
> joke, since I'm using a comfortable 1280x1024 desktop.
> If we switch to a fixed size again, 1024x768 is a wise choice IMHO.

I am personally very happy with 800x600, its pretty much enough for
everything and low enough to not waste too much space and resources.
Especially when it comes to pixeled graphics there is little chance to
fill the screen with a size of 1024x768. Just having a larger
resolution is worth nothing if there is nobody to fill in all the
details. Just a little math 800x600 has 1.56 times as many pixels as
640x480, 1024x768 already has 2.56 times as many pixels as we
currently have, so software rendering is really a no-go for 1024x768.

800x600 has another very important advantage: my TV-Out and my TV can
handle it, which isn't the case for larger resolutions and well,
SuperTux like games are best enjoyed infront of a TV instead of a
monitor. If one goes for OpenGL only one could of course provide a way
to scale the viewport back to 800x600, even if the gfx itself have a
higherres.

> About the SVG thingy. There are very few 2d games using such a
> feature currently.

Pretty much all Flash games out there on the Internet use Vector
graphics, while it isn't SVG, its still pretty much the same. If you
want to get even more back in time, look at AnotherWorld, used fully
vector based gfx back then in 1992. Many of the old Sierra adventure
games also used vector graphics to save some diskspace.

> Therefore we could be pioneers in this field.

Not really, Flash is already pretty dominant in that place :)

> Some advantages:
>  - resizing images with no loss

Well, the loss already is in the graphic itself. Doesn't really matter
if you can scale losslessly when the source itself already is sucky,
which is the case for most vector gfx after all, they just have this
'vectorish' look which you can't really escape.

>  - easier creation of animations ?

If you do it in vectors or in pixels doesn't really matter.

>  - reusing of imageparts - merging of images

Called copy&paste, works pretty well in pixel images.

>  - being pioneers

See Flash.

>  - the tools/libs for using SVG inside games and esspecially with
>  SDL are not very mature (but perhaps we can help in their
>  development, just like planeshift for example helps crystal space
>  with stuff they need)

Just for the record, the SVG tools we currently have are easily 5-10
years behind the stuff that you have on the windows side. And I
personally consider sodipodi completly unusable, while inkscape has a
much better interface, it still lacks a whole lot of features.

>  - graphics designers do have less experience and skills with vector
>  graphics?

No, vector graphics helps you with getting a smooth curve, it doesn't
help you to get the curve into the right spot.

>  - our experiment could dramatically fail

For sure they would.

> But it would be awesome after all to have a option in our option
>dialog where you can select nearly any screen resolution.

Trivial todo with Opengl already.

> Maybe we could even port the current PNGs without much efforts
> to SVG, don't believe me? Then look at this project:

You can't convert shaded pixel gfx into vector graphics without
loosing *a lot* of quality, it only works well for simple black&white
outlines and such.

> A game I found using SVG is KSokoban. That's not THE killer game ;),
> but it's awesome that you can resize it to every size without loss
> and its tiles don't look bad (quite good) IMHO.

The version I tested here used still good old pixel graphics. Yes, one
could scale it, but the graphics would just pixelade as expected.

> I don't know what you think, but SVG is an exciting technology.

Not really. Vector graphic is pretty old technology and has been
around for ages. SVG is just a new name and a bloated XML format
wrapped around it. Vector graphics are nice if you want to print to
paper, but I havn't found them really usefull for on screen display.

--=20
WWW:      http://pingus.seul.org/~grumbel/=20
JabberID: gr...@ja...=20
ICQ:      59461927

Re: [Super-tux-devel] 800x600 resolution

[Tobias <tob...@gm...>]

Hi,

I surfed a bit around and googled about SDL/SVG issues.
There are a few tries that don't seem to be straighforward to me.
(rsvg etc.)

But then I found cairo about wich I already heared much on slashdot
and so on. I didn't know that you can use this SVG engine with SDL,
but indeed there is an example in its CVS repository.
Perhaps you want to take a look.
http://freedesktop.org/cgi-bin/viewcvs.cgi/cairo/cairo-demo/sdl/

I think we could change the Surfaces to hold a svg_cairo_t structure
additionally. This could be used as source for the actual
surfaces/textures then. (For example if we want to change the
resolution or draw a scaled image)

After all the possible CPU and memory loads could be the biggest
problems. I don't know benchmarks about it, do you?

Maybe we could even port the current PNGs without much efforts
to SVG, don't believe me? Then look at this project:
http://delineate.sourceforge.net/
Ok, this conversion won't happen lossfree. Maybe the design would
end more like in comics. (Good or Bad?)

A game I found using SVG is KSokoban. That's not THE killer game ;),
but it's awesome that you can resize it to every size without loss
and its tiles don't look bad (quite good) IMHO.

I don't know what you think, but SVG is an exciting technology.

Greetz...

Tobias Gläßer

Am So, den 09.05.2004 um 0:41 Uhr +0200 schrieb Tobias Gläßer:
> Hi folks,
> 
> no doubt 640x480 is just too less and I even think 800x600 is a bad
> joke, since I'm using a comfortable 1280x1024 desktop.
> If we switch to a fixed size again, 1024x768 is a wise choice IMHO.
> 
> About the SVG thingy. There are very few 2d games using such a feature
> currently. Therefore we could be pioneers in this field.
> I don't want to convince you about it or persuade you I only want
> to start a valueable discussion about the pros and cons.
> 
> This wouldn't mean we have to use the SVG approach throughout the whole
> game.
> 
> Some advantages:
>  - resizing images with no loss
>  - change graphics/vectors in game ?
>  - easier creation of animations ?
>  - reusing of imageparts - merging of images
>  - being pioneers
> 
> Some disadvantages:
>  - the tools/libs for using SVG inside games and
>    esspecially with SDL are not very mature
>    (but perhaps we can help in their development,
>     just like planeshift for example helps crystal
>     space with stuff they need)
>  - graphics designers do have less experience and
>    skills with vector graphics?
>  - our experiment could dramatically fail
> 
> Maybe someone of you had a look into KSVG, the KDE SVG engine.
> SVGs are equally powerful as flashs with it, so I think it's
> technically possible, which doesn't mean it's easy or the
> tools/libs for this capabilities are already there.
> 
> But it would be awesome after all to have a option in our
> option dialog where you can select nearly any screen resolution.
> There are big changes and a high risk. No risk no fun? :)
> (I feel, too many realists are hanging around here;) )
> 
> Greetz...
> 
> Tobias Gläßer
> 
> Am Sa, den 08.05.2004 um 23:05 Uhr +0100 schrieb Ricardo Cruz:
> > Hey there,
> > 
> >  It was already suggested by Ingo a resolution change to 800x600. In fact, IMO 
> > the 640x480 is too small and looks really bad when using fullscreen 
> > (especially in my monitor that uses a 1280x1024 resolution).
> > 
> >  If you agree, we could either add rows to levels or/and resize images. I 
> > would prefer this last solution and that would mean a change from 32x32 
> > images into 40x40 pixels. A resize without interpolation and then polishment 
> > should work just fine...
> > 
> >  Tobias already discussed the hypotheses of using SVG graphics... IMO, these 
> > graphics have two problems:
> > - technically, SDL_svg is yet in a very immature stage;
> > - for artists, SVG tools are also immature, especially Linux ones.
> >  Besides, I don't think it applies very well into games. I know there are some 
> > advantages, like the power of allowing resizing in real-time, but don't 
> > forget that OpenGL has support for this stuff. Futhermore, expect SVG 
> > real-time resizing to be slow as hell or at least not smooth.
> > 
> >  So, what do you think?
> > 
> >  For the record, this is only plans for mid-future, after the 0.1.x featuring 
> > the level editor.
> > 
> > Ricardo Cruz
> > 
> > -- 
> > Better by far you should forget and smile than that you should remember
> > and be sad.
> > 		-- Christina Rossetti
> > 
> > 
> > -------------------------------------------------------
> > This SF.Net email is sponsored by Sleepycat Software
> > Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
> > deliver higher performing products faster, at low TCO.
> > http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> > _______________________________________________
> > Super-tux-devel mailing list
> > Sup...@li...
> > https://lists.sourceforge.net/lists/listinfo/super-tux-devel
> > 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
> deliver higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> _______________________________________________
> Super-tux-devel mailing list
> Sup...@li...
> https://lists.sourceforge.net/lists/listinfo/super-tux-devel
> 

Re: [Super-tux-devel] 800x600 resolution

[Tobias <tob...@gm...>]

Hi folks,

no doubt 640x480 is just too less and I even think 800x600 is a bad
joke, since I'm using a comfortable 1280x1024 desktop.
If we switch to a fixed size again, 1024x768 is a wise choice IMHO.

About the SVG thingy. There are very few 2d games using such a feature
currently. Therefore we could be pioneers in this field.
I don't want to convince you about it or persuade you I only want
to start a valueable discussion about the pros and cons.

This wouldn't mean we have to use the SVG approach throughout the whole
game.

Some advantages:
 - resizing images with no loss
 - change graphics/vectors in game ?
 - easier creation of animations ?
 - reusing of imageparts - merging of images
 - being pioneers

Some disadvantages:
 - the tools/libs for using SVG inside games and
   esspecially with SDL are not very mature
   (but perhaps we can help in their development,
    just like planeshift for example helps crystal
    space with stuff they need)
 - graphics designers do have less experience and
   skills with vector graphics?
 - our experiment could dramatically fail

Maybe someone of you had a look into KSVG, the KDE SVG engine.
SVGs are equally powerful as flashs with it, so I think it's
technically possible, which doesn't mean it's easy or the
tools/libs for this capabilities are already there.

But it would be awesome after all to have a option in our
option dialog where you can select nearly any screen resolution.
There are big changes and a high risk. No risk no fun? :)
(I feel, too many realists are hanging around here;) )

Greetz...

Tobias Gläßer

Am Sa, den 08.05.2004 um 23:05 Uhr +0100 schrieb Ricardo Cruz:
> Hey there,
> 
>  It was already suggested by Ingo a resolution change to 800x600. In fact, IMO 
> the 640x480 is too small and looks really bad when using fullscreen 
> (especially in my monitor that uses a 1280x1024 resolution).
> 
>  If you agree, we could either add rows to levels or/and resize images. I 
> would prefer this last solution and that would mean a change from 32x32 
> images into 40x40 pixels. A resize without interpolation and then polishment 
> should work just fine...
> 
>  Tobias already discussed the hypotheses of using SVG graphics... IMO, these 
> graphics have two problems:
> - technically, SDL_svg is yet in a very immature stage;
> - for artists, SVG tools are also immature, especially Linux ones.
>  Besides, I don't think it applies very well into games. I know there are some 
> advantages, like the power of allowing resizing in real-time, but don't 
> forget that OpenGL has support for this stuff. Futhermore, expect SVG 
> real-time resizing to be slow as hell or at least not smooth.
> 
>  So, what do you think?
> 
>  For the record, this is only plans for mid-future, after the 0.1.x featuring 
> the level editor.
> 
> Ricardo Cruz
> 
> -- 
> Better by far you should forget and smile than that you should remember
> and be sad.
> 		-- Christina Rossetti
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
> deliver higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> _______________________________________________
> Super-tux-devel mailing list
> Sup...@li...
> https://lists.sourceforge.net/lists/listinfo/super-tux-devel
> 

[Super-tux-devel] 800x600 resolution

[Ricardo C. <ri...@ae...>]

Hey there,

 It was already suggested by Ingo a resolution change to 800x600. In fact, IMO 
the 640x480 is too small and looks really bad when using fullscreen 
(especially in my monitor that uses a 1280x1024 resolution).

 If you agree, we could either add rows to levels or/and resize images. I 
would prefer this last solution and that would mean a change from 32x32 
images into 40x40 pixels. A resize without interpolation and then polishment 
should work just fine...

 Tobias already discussed the hypotheses of using SVG graphics... IMO, these 
graphics have two problems:
- technically, SDL_svg is yet in a very immature stage;
- for artists, SVG tools are also immature, especially Linux ones.
 Besides, I don't think it applies very well into games. I know there are some 
advantages, like the power of allowing resizing in real-time, but don't 
forget that OpenGL has support for this stuff. Futhermore, expect SVG 
real-time resizing to be slow as hell or at least not smooth.

 So, what do you think?

 For the record, this is only plans for mid-future, after the 0.1.x featuring 
the level editor.

Ricardo Cruz

-- 
Better by far you should forget and smile than that you should remember
and be sad.
		-- Christina Rossetti

Re: [Super-tux-devel] Re: [Super-tux-commit] supertux TODO,1.36,1.37

[Tobias <tob...@gm...>]

It's worth fixing IMHO.
Maybe I'll have a glance at it.

Greetz...

Tobias Gläßer

Am Sa, den 08.05.2004 um 20:43 Uhr +0100 schrieb Ricardo Cruz:
>  Well, the old code also have that problem, but it looks like it is worse 
> now...
> 
> Ricardo Cruz
> 
> Em Sábado, 8 de Maio de 2004 10:56, o Ingo Ruhnke escreveu:
> > Ricardo Cruz <ri...@ae...> writes:.
> > >  Just to add that it couldn't be because of any of those, since the
> > > text displaying is done by display_text_file(), that is totally
> > > independent.
> >
> > I don't mean that 'intro', my wording was a bit missleading there. I
> > mean the gameplay happening in the title screen background, ie. if tux
> > reaches the end of that level it skips a bit weird around, instead of
> > completly seamlessly going to the start of that level, which it should
> > do since start and end of the level look exactly the same.
> 
> -- 
> You recoil from the crude; you tend naturally toward the exquisite.
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
> deliver higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> _______________________________________________
> Super-tux-devel mailing list
> Sup...@li...
> https://lists.sourceforge.net/lists/listinfo/super-tux-devel
> 

Re: [Super-tux-devel] Re: [Super-tux-commit] supertux TODO,1.36,1.37

[Ricardo C. <ri...@ae...>]

 Well, the old code also have that problem, but it looks like it is worse=20
now...

Ricardo Cruz

Em S=E1bado, 8 de Maio de 2004 10:56, o Ingo Ruhnke escreveu:
> Ricardo Cruz <ri...@ae...> writes:.
> >  Just to add that it couldn't be because of any of those, since the
> > text displaying is done by display_text_file(), that is totally
> > independent.
>
> I don't mean that 'intro', my wording was a bit missleading there. I
> mean the gameplay happening in the title screen background, ie. if tux
> reaches the end of that level it skips a bit weird around, instead of
> completly seamlessly going to the start of that level, which it should
> do since start and end of the level look exactly the same.

=2D-=20
You recoil from the crude; you tend naturally toward the exquisite.

[Super-tux-devel] Little jumps bug

[Ricardo C. <ri...@ae...>]

  In TODO:
=AB[L] tux sometimes makes short jumps in the endsequence, mostly when
    going through the goal with a small jump, might be old_up related=BB

 Is this really a bug? I allways thought Tux did little jumps cause he was=
=20
happy to finish the level :D Honest, I did.
 So, should we fix it?

Ricardo Cruz

=2D-=20
If Karl, instead of writing a lot about Capital, had made a lot of Capital,
it would have been much better.
		-- Karl Marx's Mother

Re: [Super-tux-devel] LevelEditor Progress...

[Ricardo C. <ri...@ae...>]

 Oh, all my stuff make use of colorkey, instead of images with alpha, so I'=
ve=20
never noticed that...

 One solution would be to transform alpha from all our images into a specif=
ic=20
color. It would be pretty trivial, we just needed to make program for that=
=20
propose. Anyway, I don't think this was ideal...

 Maybe this would work; make a temp surface (without an alpha mask), fill i=
t=20
with a specific color, make that color as colorkey, blit the surface into t=
he=20
temp one, apply alpha to the temp and blit it into the screen.
 Do you think this would work?

 Anyway, maybe we could get that code from somewhere... Wouldn't be pretty =
if=20
it would be slow :(

Ricardo Cruz

Em S=C3=A1bado, 8 de Maio de 2004 00:34, o Tobias Gl=C3=A4=C3=9Fer escreveu:
> Sorry, it's not all that easy. Such a blitting method takes up
> to 300 lines of code, believe me.
> (Because you have to do it by hand, since SDL DOESN'T support it)
>
> Read it in the SDL documentation, if you don't believe me. ;)
> Alpha on Alpha surface blitting just doesn't work out of the box.
> http://sdldoc.csn.ul.ie/sdlsetalpha.php
>
> [quote]
> Note:  Note that RGBA->RGBA blits (with SDL_SRCALPHA set) keep the alpha
> of the destination surface. This means that you cannot compose two
> arbitrary RGBA surfaces this way and get the result you would expect
> from "overlaying" them; the destination alpha will work as a mask.
>
> Also note that per-pixel and per-surface alpha cannot be combined; the
> per-pixel alpha is always used if available
> [/quote]
>
> Greetz...
>
> Tobias Gl=C3=A4=C3=9Fer
>
> Am Sa, den 08.05.2004 schrieb Ricardo Cruz um 1:07:
> >  Anyway, it was working, couldn't we just port it again?
>
> It was working? No, it wasn't. And I'm quite sure here.
>
> >  AFAIK, you just need to create another surface, blit the surface you
> > want to blit into the screen into this one, apply alpha to the temp surf
> > and then just blit the temp surf into the screen. It is nothing from
> > another world :) I have made the current code, and I dunno why it isn't
> > working...
> >
> >  In case it is too slow, we can allways get rid of it...
> >
> >  And this code that can be found at draw_bg, draw_part or draw_stretche=
d:
> >   if(alpha !=3D 255)
> >     SDL_SetAlpha(sdl_surface ,SDL_SRCALPHA,alpha);
> > will make the surface to have that alpha forever. This code should be
> > removed.
> >
> > Ricardo Cruz
> >
> > Em S=C3=A1bado, 8 de Maio de 2004 00:03, o Tobias Gl=C3=A4=C3=9Fer escr=
eveu:
> > > Am Sa, den 08.05.2004 schrieb Tobias Gl=C3=A4=C3=9Fer um 0:57:
> > > > Am Sa, den 08.05.2004 schrieb Ricardo Cruz um 0:03:
> > > > >  Those are great news.
> > > > >  There is only this issue that I think that should get priority:
> > > > > - the SDL frontend doesn't seem to support Alpha when blitting
> > > > > surfaces. i think this worked before... anyway, when looking at
> > > > > Background, for instance, the Foreground and Active stuff just
> > > > > dissapears...
> > > > >
> > > > > Ricardo Cruz
> > > >
> > > > Actually, as I stated in another mail, SDL software rendering isn't
> > > > able to do alpha on alpha surface blitting. :(
> > > > For the same reason the minimap is a OpenGL only feature, too.
> > > >
> > > > Greetz...
> > > >
> > > > Tobias Gl=C3=A4=C3=9Fer
> > >
> > > Before another one comes up with it now. Yes, you could write your
> > > own blitting method for this purpose. But on the on hand it's pretty
> > > tough to write it. (Or wouldn't the SDL folks provide it in their
> > > renderer, if it was easy to implement?) And on the other hand the
> > > resulting blitting method would be a very slow one.
> > >
> > > Can someone think of an alternative solution for the editor?
> > >
> > > Greetz...
> > >
> > > Tobias Gl=C3=A4=C3=9Fer

=2D-=20
"Data is a lot like humans:  It is born.  Matures.  Gets married to other=20
data,
divorced. Gets old.  One thing that it doesn't do is die.  It has to be=20
killed."
=2D- Arthur Miller

[Super-tux-devel] Re: [Super-tux-commit] supertux TODO,1.36,1.37

[Ingo R. <gr...@gm...>]

Ricardo Cruz <ri...@ae...> writes:

>  Just to add that it couldn't be because of any of those, since the
> text displaying is done by display_text_file(), that is totally
> independent.

I don't mean that 'intro', my wording was a bit missleading there. I
mean the gameplay happening in the title screen background, ie. if tux
reaches the end of that level it skips a bit weird around, instead of
completly seamlessly going to the start of that level, which it should
do since start and end of the level look exactly the same.

-- 
WWW:      http://pingus.seul.org/~grumbel/ 
JabberID: gr...@ja... 
ICQ:      59461927

Re: [Super-tux-devel] LevelEditor Progress...

[Tobias <tob...@gm...>]

Sorry, it's not all that easy. Such a blitting method takes up
to 300 lines of code, believe me.
(Because you have to do it by hand, since SDL DOESN'T support it)

Read it in the SDL documentation, if you don't believe me. ;)
Alpha on Alpha surface blitting just doesn't work out of the box.
http://sdldoc.csn.ul.ie/sdlsetalpha.php

[quote]
Note:  Note that RGBA->RGBA blits (with SDL_SRCALPHA set) keep the alpha
of the destination surface. This means that you cannot compose two
arbitrary RGBA surfaces this way and get the result you would expect
from "overlaying" them; the destination alpha will work as a mask.
        
Also note that per-pixel and per-surface alpha cannot be combined; the
per-pixel alpha is always used if available
[/quote]

Greetz...

Tobias Gläßer

Am Sa, den 08.05.2004 schrieb Ricardo Cruz um 1:07:
>  Anyway, it was working, couldn't we just port it again?
It was working? No, it wasn't. And I'm quite sure here.

>  AFAIK, you just need to create another surface, blit the surface you want to 
> blit into the screen into this one, apply alpha to the temp surf and then 
> just blit the temp surf into the screen. It is nothing from another world :)
>  I have made the current code, and I dunno why it isn't working...
> 
>  In case it is too slow, we can allways get rid of it...
> 
>  And this code that can be found at draw_bg, draw_part or draw_stretched:
>   if(alpha != 255)
>     SDL_SetAlpha(sdl_surface ,SDL_SRCALPHA,alpha);
> will make the surface to have that alpha forever. This code should be removed.
> 
> Ricardo Cruz
> 
> Em Sábado, 8 de Maio de 2004 00:03, o Tobias Gläßer escreveu:
> > Am Sa, den 08.05.2004 schrieb Tobias Gläßer um 0:57:
> > > Am Sa, den 08.05.2004 schrieb Ricardo Cruz um 0:03:
> > > >  Those are great news.
> > > >  There is only this issue that I think that should get priority:
> > > > - the SDL frontend doesn't seem to support Alpha when blitting
> > > > surfaces. i think this worked before... anyway, when looking at
> > > > Background, for instance, the Foreground and Active stuff just
> > > > dissapears...
> > > >
> > > > Ricardo Cruz
> > >
> > > Actually, as I stated in another mail, SDL software rendering isn't able
> > > to do alpha on alpha surface blitting. :(
> > > For the same reason the minimap is a OpenGL only feature, too.
> > >
> > > Greetz...
> > >
> > > Tobias Gläßer
> >
> > Before another one comes up with it now. Yes, you could write your
> > own blitting method for this purpose. But on the on hand it's pretty
> > tough to write it. (Or wouldn't the SDL folks provide it in their renderer,
> > if it was easy to implement?) And on the other hand the resulting
> > blitting method would be a very slow one.
> >
> > Can someone think of an alternative solution for the editor?
> >
> > Greetz...
> >
> > Tobias Gläßer
> >
> >
-- 

Re: [Super-tux-devel] LevelEditor Progress...

[Ricardo C. <ri...@ae...>]

 Anyway, it was working, couldn't we just port it again?

 AFAIK, you just need to create another surface, blit the surface you want =
to=20
blit into the screen into this one, apply alpha to the temp surf and then=20
just blit the temp surf into the screen. It is nothing from another world :)
 I have made the current code, and I dunno why it isn't working...

 In case it is too slow, we can allways get rid of it...

 And this code that can be found at draw_bg, draw_part or draw_stretched:
  if(alpha !=3D 255)
    SDL_SetAlpha(sdl_surface ,SDL_SRCALPHA,alpha);
will make the surface to have that alpha forever. This code should be remov=
ed.

Ricardo Cruz

Em S=C3=A1bado, 8 de Maio de 2004 00:03, o Tobias Gl=C3=A4=C3=9Fer escreveu:
> Am Sa, den 08.05.2004 schrieb Tobias Gl=C3=A4=C3=9Fer um 0:57:
> > Am Sa, den 08.05.2004 schrieb Ricardo Cruz um 0:03:
> > >  Those are great news.
> > >  There is only this issue that I think that should get priority:
> > > - the SDL frontend doesn't seem to support Alpha when blitting
> > > surfaces. i think this worked before... anyway, when looking at
> > > Background, for instance, the Foreground and Active stuff just
> > > dissapears...
> > >
> > > Ricardo Cruz
> >
> > Actually, as I stated in another mail, SDL software rendering isn't able
> > to do alpha on alpha surface blitting. :(
> > For the same reason the minimap is a OpenGL only feature, too.
> >
> > Greetz...
> >
> > Tobias Gl=C3=A4=C3=9Fer
>
> Before another one comes up with it now. Yes, you could write your
> own blitting method for this purpose. But on the on hand it's pretty
> tough to write it. (Or wouldn't the SDL folks provide it in their rendere=
r,
> if it was easy to implement?) And on the other hand the resulting
> blitting method would be a very slow one.
>
> Can someone think of an alternative solution for the editor?
>
> Greetz...
>
> Tobias Gl=C3=A4=C3=9Fer
>
>

=2D-=20
The intelligence of any discussion diminishes with the square of the
number of participants.
		-- Adam Walinsky

Re: [Super-tux-devel] LevelEditor Progress...

[Tobias <tob...@gm...>]

Am Sa, den 08.05.2004 schrieb Tobias Gläßer um 0:57:
> Am Sa, den 08.05.2004 schrieb Ricardo Cruz um 0:03:
> >  Those are great news.
> >  There is only this issue that I think that should get priority:
> > - the SDL frontend doesn't seem to support Alpha when blitting surfaces. i 
> > think this worked before... anyway, when looking at Background, for instance, 
> > the Foreground and Active stuff just dissapears...
> > 
> > Ricardo Cruz
> 
> Actually, as I stated in another mail, SDL software rendering isn't able
> to do alpha on alpha surface blitting. :(
> For the same reason the minimap is a OpenGL only feature, too.
> 
> Greetz...
> 
> Tobias Gläßer

Before another one comes up with it now. Yes, you could write your
own blitting method for this purpose. But on the on hand it's pretty
tough to write it. (Or wouldn't the SDL folks provide it in their renderer,
if it was easy to implement?) And on the other hand the resulting
blitting method would be a very slow one. 

Can someone think of an alternative solution for the editor?

Greetz...

Tobias Gläßer

Re: [Super-tux-devel] LevelEditor Progress...

[Tobias <tob...@gm...>]

Am Sa, den 08.05.2004 schrieb Ricardo Cruz um 0:03:
>  Those are great news.
>  There is only this issue that I think that should get priority:
> - the SDL frontend doesn't seem to support Alpha when blitting surfaces. i 
> think this worked before... anyway, when looking at Background, for instance, 
> the Foreground and Active stuff just dissapears...
> 
> Ricardo Cruz

Actually, as I stated in another mail, SDL software rendering isn't able
to do alpha on alpha surface blitting. :(
For the same reason the minimap is a OpenGL only feature, too.

Greetz...

Tobias Gläßer

Re: [Super-tux-devel] OpenGL fix

[Ricardo C. <ri...@ae...>]

 Bad news is that we are unable to fix that bug...
 Good news is that it isn't our fault anyway ;)

 I will update my drivers (to the 5xxx version), as soon as I install a new 
version of Mandrake, and then I will check if it is driver's fault or not.

 Anyway, thanks for your help.

Ricardo Cruz

Em Sexta, 7 de Maio de 2004 18:40, o Keir Lawson escreveu:
> On Thu, 2004-05-06 at 22:38 +0100, Ricardo Cruz wrote:
> >  Oh, right. You just needed to replace endl by std::endl, I am used to
> > put 'using std::endl;' in the beginning of my code...
> >
> >  Anyway, if you have used:
> > std::cerr << "screen->w: " << SCREEN_W;
> > std::cerr << "screen->h: " << SCREEN_H;
> >
> > they will surely print 640 and 480, since you are just outputting the
> > definitions... Instead of SCREEN_W and SCREEN_H use screen->w and
> > screen->h, respectively. These in the end of the st_video_setup_gl(),
> > that it.
>
> the following lines i put right at then end of that function:
>
> std::cerr << "SCREEN_W: " << screen->w << std::endl;
> std::cerr << "SCREEN_H: " << screen->h << std::endl;
>
> the extra output is the same:
>
>
> SCREEN_W: 640
> SCREEN_H: 480
>
> Keir Lawson
>
>

-- 
Everything is worth precisely as much as a belch, the difference being
that a belch is more satisfying.
		-- Ingmar Bergman

Re: [Super-tux-devel] LevelEditor news

[Ricardo C. <ri...@ae...>]

 I just tried it, it is very cool! Good work ;)

Ricardo

Em Sexta, 7 de Maio de 2004 18:35, o Tobias Gl=C3=A4=C3=9Fer escreveu:
> Hi all,
>
> as stated it only works in OpenGL mode. You have to go over
> the right/left arrows with your mouse or press right/left
> on your keyboard to see it.
> Adding another shortcut for it is a good idea! :)
>
> Greetz...
>
> Tobias Gl=C3=A4=C3=9Fer
>
> Am Fr, den 07.05.2004 schrieb Ricardo Cruz um 15:42:
> >  How can one start the map? Is there a key?
> >
> > Ricardo
> >
> > Em Quarta, 5 de Maio de 2004 23:11, o Tobias Gl=C3=A4=C3=9Fer escreveu:
> > > Hi folks,
> > >
> > > the LevelEditor just got a simple MiniMap. But here
> > > yet another problem with SDL software rendering appeared
> > > and therefore it is a OpenGl mode only "feature".
> > > I dunno if calling it a feature in its current state is
> > > overestimating, since it's actually not more than
> > > a displaying help.
> > >
> > > There is ONE major bug left in the LevelEditor, after
> > > this one is fixed it should be near to production ready.
> > >
> > > Greetz...
> > >
> > > Tobias Gl=C3=A4=C3=9Fer

=2D-=20
	A manager asked a programmer how long it would take him to finish the
program on which he was working.  "I will be finished tomorrow," the=20
programmer
promptly replied.
	"I think you are being unrealistic," said the manager. "Truthfully,
how long will it take?"
	The programmer thought for a moment.  "I have some features that I wish
to add.  This will take at least two weeks," he finally said.
	"Even that is too much to expect," insisted the manager, "I will be
satisfied if you simply tell me when the program is complete."
	The programmer agreed to this.
	Several years later, the manager retired.  On the way to his
retirement lunch, he discovered the programmer asleep at his terminal.
He had been programming all night.
		-- Geoffrey James, "The Tao of Programming"

Re: [Super-tux-devel] LevelEditor Progress...

[Ricardo C. <ri...@ae...>]

 Those are great news.
 There is only this issue that I think that should get priority:
=2D the SDL frontend doesn't seem to support Alpha when blitting surfaces. =
i=20
think this worked before... anyway, when looking at Background, for instanc=
e,=20
the Foreground and Active stuff just dissapears...

Ricardo Cruz


Em Sexta, 7 de Maio de 2004 21:56, o Tobias Gl=C3=A4=C3=9Fer escreveu:
> Heeeya,
>
> I just commited major internal changes to the editor. It
> makes use of the World-class now, which solves several problems
> at once. The object automatic badguy repositioning (if it lands
> in a wall) for example is working now and the leveleditor
> can be started from command-line.
>
> Some things are for sure broken currently. I'm going to
> fix em and then this should be release ready. What do you think?
>
> Greetz...
>
> Tobias Gl=C3=A4=C3=9Fer

=2D-=20
Leave no stone unturned.
		-- Euripides

[Super-tux-devel] LevelEditor Progress...

[Tobias <tob...@gm...>]

Heeeya,

I just commited major internal changes to the editor. It
makes use of the World-class now, which solves several problems
at once. The object automatic badguy repositioning (if it lands
in a wall) for example is working now and the leveleditor
can be started from command-line.

Some things are for sure broken currently. I'm going to
fix em and then this should be release ready. What do you think?

Greetz...

Tobias Gläßer
-- 

Re: [Super-tux-devel] OpenGL fix

[Keir L. <ke...@th...>]

On Thu, 2004-05-06 at 22:38 +0100, Ricardo Cruz wrote:
>  Oh, right. You just needed to replace endl by std::endl, I am used to put 
> 'using std::endl;' in the beginning of my code...
> 
>  Anyway, if you have used:
> std::cerr << "screen->w: " << SCREEN_W;
> std::cerr << "screen->h: " << SCREEN_H;
> 
> they will surely print 640 and 480, since you are just outputting the 
> definitions... Instead of SCREEN_W and SCREEN_H use screen->w and screen->h, 
> respectively. These in the end of the st_video_setup_gl(), that it.

the following lines i put right at then end of that function:

std::cerr << "SCREEN_W: " << screen->w << std::endl;
std::cerr << "SCREEN_H: " << screen->h << std::endl;

the extra output is the same:


SCREEN_W: 640
SCREEN_H: 480

Keir Lawson

Re: [Super-tux-devel] LevelEditor news

[Tobias <tob...@gm...>]

Hi all,

as stated it only works in OpenGL mode. You have to go over
the right/left arrows with your mouse or press right/left
on your keyboard to see it.
Adding another shortcut for it is a good idea! :)

Greetz...

Tobias Gläßer

Am Fr, den 07.05.2004 schrieb Ricardo Cruz um 15:42:
>  How can one start the map? Is there a key?
> 
> Ricardo
> 
> Em Quarta, 5 de Maio de 2004 23:11, o Tobias Gläßer escreveu:
> > Hi folks,
> >
> > the LevelEditor just got a simple MiniMap. But here
> > yet another problem with SDL software rendering appeared
> > and therefore it is a OpenGl mode only "feature".
> > I dunno if calling it a feature in its current state is
> > overestimating, since it's actually not more than
> > a displaying help.
> >
> > There is ONE major bug left in the LevelEditor, after
> > this one is fixed it should be near to production ready.
> >
> > Greetz...
> >
> > Tobias Gläßer
-- 

Re: [Super-tux-devel] SuperTux - fonts

[Ingo R. <gr...@gm...>]

Ricardo Cruz <ri...@ae...> writes:

>  If you agree, we could use Benjamin's hand-written ones. Here, have
> a screenshot:

The hand-written fonts are pretty much a 'must', the old font were
just rather ugly. I personally would replace the plain blue with a
soft gradient and make the font lines a little bit thicker so that
the white is more clear and doesn't get greyish due to the
antialiasing and the black border..

-- 
WWW:      http://pingus.seul.org/~grumbel/ 
JabberID: gr...@ja... 
ICQ:      59461927

Re: [Super-tux-devel] LevelEditor news

[Ricardo C. <ri...@ae...>]

 How can one start the map? Is there a key?

Ricardo

Em Quarta, 5 de Maio de 2004 23:11, o Tobias Gl=C3=A4=C3=9Fer escreveu:
> Hi folks,
>
> the LevelEditor just got a simple MiniMap. But here
> yet another problem with SDL software rendering appeared
> and therefore it is a OpenGl mode only "feature".
> I dunno if calling it a feature in its current state is
> overestimating, since it's actually not more than
> a displaying help.
>
> There is ONE major bug left in the LevelEditor, after
> this one is fixed it should be near to production ready.
>
> Greetz...
>
> Tobias Gl=C3=A4=C3=9Fer

=2D-=20
The SAME WAVE keeps coming in and COLLAPSING like a rayon MUU-MUU ...

Re: [Super-tux-devel] SuperTux - fonts

[Ricardo C. <ri...@ae...>]

 Done.
 I also replaced the current back button with Benjamin's ones.

 Benjamin, your checkboxes are pretty small, could you resize them? Thx.

Ricardo

Em Sexta, 7 de Maio de 2004 02:54, o Benjamin P. Jung escreveu:
> > If you agree, we could use Benjamin's hand-written ones. Here, have a
> >screenshot:
> >http://rpmcruz.planetaclix.pt/trash/newfont.png
> >(ignore the big and small font glitches, that can be fixed)
> >
> > So, what do you prefer the current's or the hand-written ones?
>
> I think my hand-written font looks pretty cool given it has a certain
> size... for the small (tiny!) letters I think it's better to use the
> ATARI font as it is readable while my hand-writing isn't.
>
> Benjamin
>
>

-- 
There is nothing new except what has been forgotten.
		-- Marie Antoinette

Re: [Super-tux-devel] SuperTux - fonts

[Christopher A. W. <cr...@li...>]

I vote for the hand-written font

On Thu, 2004-05-06 at 20:54, Benjamin P. Jung wrote:

> > If you agree, we could use Benjamin's hand-written ones. Here, have a 
> >screenshot:
> >http://rpmcruz.planetaclix.pt/trash/newfont.png
> >(ignore the big and small font glitches, that can be fixed)
> >
> > So, what do you prefer the current's or the hand-written ones?
> >  
> >
> I think my hand-written font looks pretty cool given it has a certain
> size... for the small (tiny!) letters I think it's better to use the 
> ATARI font as it is readable while my hand-writing isn't.
> 
> Benjamin
>