Messages

and lots of love from my girlfriend and her family.

First part of that phrase is cool... second one is creepy.

AGS: Our moderators are Nazis. Really.

AGS: When your thread is locked, it really means we want you to create a copy as soon as possible.

PivotMaster has hacketh your computer. Consider yourself hackethed.

Another tiny issue: could the autocomplete-box maybe pop up for function parameters even if the name of the function and the opening bracket is separated by one or maybe even more spaces?

At the moment, this shows the helper:

Code: ags

test_function( [...]

But this doesn't, and, since I call functions with a space in between name and bracket, it's kinda bothering:

Code: ags

test_function ( [...]

@Pumaman: Okay, well, it's pretty much like my example. Imagine I type this:

Code: ags

function test ( int a )
{
      if ( a == 1 )
      {
              do_something ( );

Now I want to close the if-bracket, so, I hit return after the "do_something ( );"-line, it sends me in the correct spot (2 tabs from left, right underneath the "d" from "do_..."). So, now I hit backspace to go one tab to the left and enter my closing bracket. Now it looks like this:

Code: ags

function test ( int a )
{
      if ( a == 1 )
      {
              do_something ( );
      }

And now I want to end the function, so I hit return to get to the next line and at this point, it moves the closing-bracket from the last line above all the way to the left like this:

Code: ags

function test ( int a )
{
      if ( a == 1 )
      {
              do_something ( );
}

When typing that, the editor currently moves the FIRST closing curved-bracket (}) all the way to the left, although it should have a TAB before it.

I can't replicate this. When you type the closing } and press return, it should move it back to the indent level of the previous line, then subtract the tab size. Does anyone else get this problem?

Here is a quick streaming video, which shows the problem, just so we're not somehow talking about something different.

First off, I'd like to know where you found the tracker at. I've been looking for it for ages but it's not there.

Main-Page -> Knowledge Base -> Tracker (or here)...

Another smallish observation that I hope hasn't been reported before:

The editor seems to move lines with only closing curved-brackets (}) all the way to the left by itself. In my personal style of scripting, this gets pretty annoying. Take a look at this snippet:

Code: ags

function Test ( )
// test something
{
      if ( test == 1 )
      // if test equals 1
      {
           // do something
      }
}

When typing that, the editor currently moves the FIRST closing curved-bracket (}) all the way to the left, although it should have a TAB before it.

Please either get rid of this "automatic formation" or - if it is there for some reason - allow us to switch it off!

Oh, and one "tiny, tiny" question: I was wondering how reasonable a struct-in-struct-implementation would be? I know this has been discussed before, but I can't find anything on the tracker. Now, with the editor becoming more OO every release (which is a great progression), it really would seem a logical step and very, very usable. So, I was just wondering how hard that'd be to implement for you and whether it's possible at all.

http://www.adventuregamestudio.co.uk/yabb/index.php?topic=31298.0

I had to get a new motherboard though. The capacitors had in fact popped.

Ah, very well. This now closes this thread.

Aspect #1 (my specific problem) was solved by Ashen's code.

Aspect #2 (the general confusion I saw in the rotate-function) is now solved by khrismuc's module.

Thanks a lot to everybody, again. It's been enlighting.

[Edit: By the way, it doesn't move smoothly up/down/left/right anymore like it used to when the difference in size was there because of the rotation, it jumps there once I rotate it at all! How does that make sense? I'm really confused with this, and again, I don't ever get tired of saying this, a thread with almost 20 replies now and several experts at least somewhat confused really speaks for the point I made earlier, rotating sprites in AGS is currently (imho unnecessarily) hard and confusing...]

Okay, I have it like this now:

Code: ags

      // store original image temporarily
      this.temp=DynamicSprite.CreateFromExistingSprite ( this.Image.Graphic );
      
      int cenx = FloatToInt ( this.X ) + ( this.Image.Width / 2 );
      int ceny = FloatToInt ( this.Y ) + ( this.Image.Height / 2 );
      
      // rotate
      if ( this.Angle > 0.0 && this.Angle <= 359.0 )
            this.temp.Rotate ( FloatToInt ( this.Angle ), cenx - ( this.temp.Width / 2 ), ceny - ( this.temp.Height / 2 ) );
      
      // draw the sprite
      Renderer.DrawSprite ( FloatToInt ( this.X ), FloatToInt ( this.Y ), this.temp.Graphic );

this.X/Y is the top-left corner of the sprite. this.temp is the rotated sprite and this.Image is the original. Is the above what you meant, Ashen? I don't really get the part about updating this.X/Y though. What you have put in your post there, doesn't work because that part is in Renderer::DrawSprite ( ) and a Renderer doesn't have this.X/Y - I don't think I have access to the Sprite.X/Y from the renderer. Plus, I wouldn't know why, either. Sprite.X/Y isn't ever changed by any function, right?

Edit: By the way, it doesn't move smoothly up/down/left/right anymore like it used to when the difference in size was there because of the rotation, it jumps there once I rotate it at all! How does that make sense? I'm really confused with this, and again, I don't ever get tired of saying this, a thread with almost 20 replies now and several experts at least somewhat confused really speaks for the point I made earlier, rotating sprites in AGS is currently (imho unnecessarily) hard and confusing... :p

[Aspect #1: my specific problem of rotating a sprite]

Okay, thanks for the patience and continued response, everybody. I appreciate it.

So, this thread has two basic aspects. In this post, I'll answer them one by one.

Aspect #1: my specific problem of rotating a sprite

Gilbot:

Code: ags

function CRenderer::DrawSprite ( int x, int y, int sprite_slot )
// draws a sprite
{
      // draw the sprite
      this.Surface.DrawImage ( x, y, sprite_slot );
}

Don't think anything's wrong there.

Ashen:

But the newwidth and newheight are supposed to be the same as width and height in my example, so your parameters would cancel out to x, y and that's what I have or had when testing. Am I missing something?


Aspect #2: my suggestion to possibly simplify the rotate-function for sprites

Ok, then. Maybe CJ also has an opinion regarding the function and its use. I still stick to my 4 points of improving the function, because I think it would be a lot more usable and easier usable to the general audience, but I see your points, and since - as Ashen pointed out - people don't seem to use the function very often anyways, I don't think it's all so important either. I just wanted to mention.

[See what I mean with heavy over-complication of a very basic and generally simple function? Even I with the help of three "AGS experts" can't get the function to do the one most obvious basic task without errors: rotating a simple sprite around itself. For a newbie to AGS, this function would be unusable to say the least.]

Typical beginner mistakes? In C++ and SDL (and the SDL_image library) there are Sprite.Rotate (angles) functions that allow to be used exactly as I wanted it in the first place. I just tried to convert my functions from there to here.

For a newcomer to AGS, rotating a sprite sounds simple enough, but at the moment, it's actually one of the hardest things you can do with the program.

What I'd like to see in the rotate-function then, would be:

(1) a function that can be called multiple times without having to manually reset the sprite each frame and rotating it only once. The function should, if possible, do that for the user, so that I can draw a sprite to the screen in the rep_ex () for example and when a button is pressed, I call sprite.rotate (5) and while that button is down, the sprite rotates correctly.

(2) when no optional parameters are given, the function should rotate sprites correctly around their center. To me, that is expected behavior, without making them slide away and forcing the user to add mathematical corrections in form of formulas to keep the sprite in place.

(3) as an idea: how about giving the user the chance to give the coordinates of a new center to rotate around instead of the new width, height ones? That sounds a lot more simple to me, but I haven't played around with the parameters as they are enough to judge whether this is actually a good idea or whether there's some kind of downside to be found.

(4) more freedom when specifying angles? The game crashes when an angle < 0 or > 359 is given. That means the user needs even more workarounds. When the user wants to draw a sprite to the screen and rotate it forever, he should be able to call sprite.rotate (1) in the rep_ex () and not write loops to make sure the sprite rotates correctly. It must be very easy to do this for the user in the function already, so that one can simply supply any number, including negative ones and zero (in which case the function DOESN'T crash, just doesn't do anything) and positive ones > 359.


Anyways, thanks for the help so far.

Gilbot: That rotates correctly, but it jumps across the screen (~20-30px down and right). I tried modifying the parameters (taking the /2 away or taking the whole part after x/y away), but it still jumps. See what I mean with heavy over-complication of a very basic and generally simple function? Even I with the help of three "AGS experts" can't get the function to do the one most obvious basic task without errors: rotating a simple sprite around itself. For a newbie to AGS, this function would be unusable to say the least.

[simpler version]

Ah, dumb mistake!

That fixes it, however, now it cuts the edges of the rotated sprite off. When I get rid of the additional width, height parameters, it rotates correctly without cutting edges off, but the sprite starts to move forth and back on the x- and y-axis a bit. What to do against that? Manual correction? I hope not.

To my humble opinion, this thread now already shows that a simpler version of the rotate-function or a different approach altogether should really be considered, if possible. Anybody agree?

Thanks for the answer. I tried higher numbers before, though. They mess the pixels up even when I'm doing it with this "new" way. At 15, for example, the sprite slowly gets "rounded", at 10, the core of the sprite (middle 10px or sth.) stay put, the rest flies around.

Any other suggestions?

Details, babe. Details.

Ok, not in bold then. Maybe a more elaborated example of code might be the best?

So, now I have this:

Code: ags

      // store original image temporarily
      this.temp = this.Image;
      
      // rotate
      if ( this.Angle > 0.0 && this.Angle <= 359.0 )
            this.temp.Rotate ( FloatToInt ( this.Angle ), this.temp.Width, this.temp.Height );
      
	// draw the sprite
	Renderer.DrawSprite ( FloatToInt ( this.X ), FloatToInt ( this.Y ), this.temp.Graphic );

And it still doesn't rotate correctly (only few pixels on the border move). Angle is set to 2.0.

Am I really so stupid tonight or is working with this function such a major bitch to everybody? :p

[In bold!]

That rotating an already rotated sprite screws up should be mentioned in the manual. In bold!

I didn't think that the function couldn't be used like I wanted it to use, but rather to only always rotate once. Thanks for the help there.

For a little project, I need to rotate dynamic sprites. I have one set up for now and when I press the UP cursor-key, it rotates it by calling the DynamicSprite.Rotate ( ) function with "1" passed as parameter for the angle. When trying the game out, nothing happens. When I enter "45" as angle, it works, but will mess up the pixels in the sprite the more it is rotated. When I change the sprite dimensions from even values to uneven ones, it will work with any number, BUT it will mess up the whole sprite a whole lot, reduce its size, if turned enough even make it disappear all while not rotating properly (there are rectangular areas around the sprite rotating somehow, while a little "core" zone in the middle will stay the same).

As I tried this with a few different approaches and even in the older 2.X versions already, I'm pretty sure it's not my mistake - however I was surprised to NOT find anything about it on the forums or the bug-tracker already. I can post screens, but it's really quickly and easily reproduced - plus, I'd say I'd still be pretty surprised if most people who played with AGS and its more advanced rendering options for some time don't know what I'm talking about here already.

Or are AGS' dynamic-sprite-rotating-functions not really made for rotating in "real-time" and small angle-increments?

Hope I made myself clear with this, I'm pretty tired though, so ask if you don't understand something.

Mine is hand-drawn by yours truly in an attempt to create an enemy in the style of the game Dodonpachi for an activity over at pixelation.com. I like the result and it was perfectly sized for being used as an avatar.

NEWSFLASH! Nail-clippers, coins and stones are all completely useless when trying to start a fire. They tried it on Mythbusters once. Even with wooden sticks and dry plants, it's damn near impossible to do.

Good thread idea, though. Just thought I'd pop in to bring reality back into the puzzle, plus - at the same time - remind game developers to think of new means to let the player start a fire. I've seen "you pick up a stone - use stone with wooden stick - you started a fire" way too often before in puzzles.