Messages

I had some trouble using the z-layer as well.
But you can simply edit out the space below the character sprites in the original files and re-import the sprites by right clicking all the character sprites in the sprite folder and selecting import from source.
If you don't have a proper tool to cut out the empty space below the character sprites, you can use gimp, which is freeware. It has a plug in that you can look for and download separately which allows you to export layers. So you can add all images in one project file as different layers. Remove the lower space with the "Crop to Selection" tool.
Then export them.
And then import them into the game as described above.
If you know what you're doing this is done in an hour and your game is fixed.
If you do it this way and you have troubles on the way feel free to ask.

_{written with Android 4.0}

[The game plan (illustrations):]

Hey.

In my adventure game I want to include some kind of 2 person fighter.
With a slight difference.
The main character, who flies, has to fly away from the constant attacks of the enemy character.
And after avoiding the attack quickly counter attack by clicking on the enemy.

So before creating this part I wanted to see if I can create the script more efficiently.
I have illustrations on how the game works, and a sample script how I would have scripted it.
I am open for any critic of the script or suggestions to do it completely differently or get a shorter and more efficient script.
You could even only suggest your idea on how to do it and completely ignore my script.

One can learn a lot from how other people do things.
Thanks for any ideas in advance.

(It says beginner's technical forum is for help with starting off scripts so I reckoned this is the right place to post this)

The game plan (illustrations):

Spoiler

In the first? level the screen is split into two fields.
The enemy is going to attack randomly one of the fields (announced with a title or a gui):


If you-re on the attacked field then you need to quickly move to the field that is not attacked to save yourself.


When the enemy reaches the middle of the attacked field, he changes the view to an "attack" frame, and now you have to click on him to counterattack.


If the enemy looses three lifes before you do, you move on to the next level.
If you loose all three lifes you die and have to restart the fight.

The further levels will evolve but I leave it with level 1 for simplicity's sake.

[close]

How I would have scripted it

Spoiler

Note: Apparently some space bar entries have been replaced with question marks when posting.


In Global variables I declare the following variables:

int life=3; int enemylife=3; int position; int field; int playerfield; int currentlevel=1; int n; bool attackable=false;

life defines how much life the character has (starts with 3)
enemylife defines enemy's life.
position defines if the dog attacks from the left or right in level 1.
field defines which field the dog attacks (field 0 or 1 in level 1).
playerfield defines in which field the player cureently find himself in (field 0 or 1).
currentlevel defines what Level you are currently on.
n is used to run a loop later on.
attackable defines wether the monster has already reached the point where you can counterattack or not.

The game begins in a different room than the rest of the game.

before the room is loaded I put the enemy character and the attack sign gui outside the room borders so you see only the character flying.

Then in after the room fades in:

Code: ags

function room_AfterFadeIn()
{

field=Random(1); //decide which field will be attacked.
position=Random(1); //decide from which position/direction the enemy attacks
if(position==0)
? {gattack.x=...; //place the attackgui in the corresponding field.
? cEnemy.LockView(...);//Lock enemy into the right frame to attack from that position
? cEnemy.x=...;
? cEnemy.y=...;}//place the Enemy to attack from the right direction
else
? {gattack.x=...;
? cEnemy.LockView(...);
? cEnemy.x=...;
? cEnemy.y=...;}

Level[1]=Timer.Start(120);//Set Timer "Level" array 1 (stands for Level 1) to three seconds before the enemy attacks.

}

And In the Global Script:

Code: ags

// main global script file
Timer*Level[10];//Timer called "Level" to define time before enemy attacks for each level, created with Crimson Wizard's module. Level timer is exported to Global Header script
Timer*Hit;// Timer used define how long enemy stays in hitting/attack view
Timer*Waittimer[10];//Timer used when I want non-blocking Waiting time
bool avoidwrongtrigger[100];//this bool will help me differentiate different functions that are set off when the enemy finds himself on specific coordinates (see below)

function? repeatedly_execute_always() 
{

if(Timer.IsExpired(Level[1]))
? {gattack.x=-1000;//put gui out of screen
? if(field==0) 
? ? {cEnemy.move(x0,y0,eNoBlock...);//move enemy to attackpoint of field 0. The main character still has to be able to move around, so I need to do it non-blocking.
? ? avoidwrongtrigger[0]=true;}
? else 
? ? {cEnemy.move(x1,y1,eNoBlock...);//move enemy to attackpoint of field 1.
? ? avoidwrongtrigger[1]=true;}
? }

if((cEnemy.x==x0&&cEnemy.y==y0&&avoidwrongtrigger[0]==true)||(cEnemy.x==x1&&cEnemy.y==y1&&avoidwrongtrigger[1]==true))//if the enemy crosses x[sub]0[/sub],y[sub]0[/sub] or x[sub]1[/sub],y[sub]1[/sub] at any other point in the game accidentally I don't want this function to be triggered, that's why I use the avoidoverlap bool
? {
? for(n=0;n!=2;n? )
? {avoidwrongtrigger[n]=false;} //set all avoid bool arrays to false (important for later levels with more fields)
? if(field==playerfield)life=life-1;//if the character finds himself in the same field as the the attacked field he looses a life
? attackable=true;
? cEnemy.LockView(...);//Lock enemy into hitting/attacking view
? Bite=Timer.Start(40);//Start timer to unlock hit/attack view after 1 second
? cEnemy.Move(x2,y2,eNoBlock);//move enemy out of screen again
? }
//defining in which field the player finds himself in:
//level on is very easy. The screen resolution is 1600x900,so:

if(currentlevel==1)//the fields change for the upcoming levels
?? {if(cm.x<801) playerfield=0;
?? else playerfield=1;}

//how to proceed after the attack

//If both still have lifes:
if(life!=0&&enemylife!=0) Waittimer[1]=Timer.Start(40);

if(Timer.IsExpired(Waittimer[1]))
{//same script as above
field=Random(1); //decide which field will be attacked.
position=Random(1); //decide from which position/direction the enemy attacks
if(position==0)
? {gattack.x=...; //place the attackgui in the corresponding field.
? cEnemy.LockView(...);//Lock enemy into the right frame to attack from that position
? cEnemy.x=...;
? cEnemy.y=...;}
else
? {gattack.x=...;
? cEnemy.LockView(...);
? cEnemy.x=...;
? cEnemy.y=...;}
attackable=false;//make it so that you cannot attack the enemy again, until he reaches the attack point.
Level[1]=Timer.Start(120);//Set Timer "Level" array 1 (stands for Level 1) to three seconds before the enemy attacks.
}

//if player looses

if(life==0)gLoose.Visible=true;//Shows a full screen gui that pauses the game when visible. You have a funny YOU LOST image and two buttons: Quit or Retry. When you quit you change to the menu room. And when you click retry:

function Retrybutton_OnClick(GUIControl *control, MouseButton button)
{
life=3;
enemylife=3;
Waittimer=Timer.Start(1);
}

//if enemy looses

gWin.Visible=true; //Full screen gui that is as well a button. Any click on the gui will start Level two. (resetting lifes and everyting, and now starting Level[currentlevel 1]-timer)

THE COUNTERATTACK

For the counterattack I have a function that is triggered when clicking on the enemey.
In Global script I made it so that whenever you left click, the Usermode1 (mousemode8) Mouseclick is triggered at the mouse-coordinates.

So when clicking on the enemy this is what happens:

Code: ags

function cEnemy_Mode8()
{
if(attackable==true)
{
cplayer.Lockview(attackviewID);
cplayer.SetWalkspeed(50,50);
cplayer.Walk(cEnemy.x,cEnemy.y,eBlock);
aEnemyscream.Play(...);
enemylife=enemylife-1;
cplayer.Lockview(normalflyviewID);
cplayer.Walk(cEnemy.x,cEnemy.y,eBlock);
cplayer.Animte(cplayer.Loop...,eRepeat);//keep flapping the wings while in the air
}
else{}

[close]

The life bar

Spoiler

The life bar I want to create with a gui.
Every heart will be one button with a heart graphic.

Another function I will run in repeatedly execute in global script then will be:

Code: ags

function repeatedly_execute_always() 
{
if(life==0)
? {Button1.Visible=false;}
else
? {Button1.Visible=true;
? if(life==1)
? ? {Button2.Visible=false;}
? else
? ? {Button2.Visible=true;
? ? if(life==2)
? ? ? ? {Button3.Visible=false;}
? ? else
? ? ? ? {Button3.Visible=true;}
? ? }
? }
}

And then I repeat that with int monsterlife.

[close]

[END OF SPOILER]

Okay, I understand now what you're talking about Snarky. And you're right.
But it would be quite easy to adjust that in the method I proposed.

I'll explain it in geometrical terms, because I think it's easier to understand:

You simple move the entire shadow shape down to the intersection point:



And then you stretch only the lower part below the "shadow area" ("SA") baseline and shear it:



So that is easily solved and gives a perfect shadow shape for horizontal SA baselines.


Now for the angled walls, I tried it out:

With the method I initially proposed, you would get this result in your example:



If now you only stretch and shear the part below the SA baseline, and leave the upper part unstretched you get a similar result:



It is better and more realistic though, definitely.

However, I noticed another flaw in the method I proposed.
Since the wall is so angled, the shadow shape on the vertical wall should actually decrease it's width, since you look at it on it's angle.
Since that is not included, you can see that the legs are not fitting together on the vertical and horizontal SA:


So, there should be a stretching width wise (or on the y-coordinate, skipping x-lines) of the vertical shadow shape, depending on the angle of the wall. In the example, it would already look better:


But the legs are still not completely aligned. And that is because the gaps between the two legs, or the two arms and the body would slowly dissapear, the more the light comes in from the side. Because essentially the two legs, and the arms and the body, are more and more on one level now, from the light's perspective.
So you could create a similar effect of decreasing the gap by removing more gap pixels, the bigger the angle is. (the program could recognize a gap pixel when it runs through every x-value of the y-line. It reaches the first black pixel for one x-value. Then it reaches the transparent pixels. If after that for a higher x-value it reaches a black pixel again, then the transparent pixels before that and after the last black pixel count as "gap pixels".

Removing the gap pixels would make the vertical shadow look perfect in the example:



Side note on removing gap pixels:

Spoiler

It could also be possible to draw the turned character mask shape or import the mask shape unto the shadow shape, and add the turning axis.
It would not be all that complicated for the program to calculate the steps inbetween to make it look like the character is turning.

END OF SPOILER
___________________________________________________________________________________________________

[close]

Now you could also add an addition that when the wall's angle surpasses 45 degrees for example, that the module does not use the character's current view frame, but the view frame ID of the adjacent loop. This way you would have a perfect side shadow.

To illustrate:

You are using the side view as the shadow, and move it to the intersection point:



Now all you have to do is shear the part above the SA baseline (and not stretch it's height ), and stretch it's width negatively, as I explained above.
And then all that is left to do is shear the lower part into place:



Looks good enough to me.

However what I noticed is that with such a strong wall angle you can't only shear the y-lines of the part below the SA baseline. The best result I got when shearing the y-lines only (and stretching) was:



Not exactly perfect, I know.
So you actually have to shear BOTH y-lines AND x-lines at the same time, and not stretch the lower part. Which makes it more complex to calculate the amount of shearing necessary. (Because shearing the y-lines completely changes the outcome of the shearing of the x-lines and vice versa). However it creates the perfect shadow shape.

That knowledge for double shearing might be useful for you, even if you'll use a different system.
Anyways, since you said you want to use a different system to create shadows, I'll leave it with that and leave you to it.

Most obviously, the vertical scaling of the wall shadow is not correct. Assuming a distant lightsource and a vertical character, the shadow cast on a vertical surface will be exactly as tall as the character.

Yes, and they ARE in my illustrations.
So all of the vertical scaling is correct.
I think you didn't understand my illustrations.
Whenever you set the angle to 90 degrees (meaning the distant light source shines on the the vertical character in a linear way parallel to the ground) the shadow is as tall as the character.

(Also, consider how it works if the shadow is cast sideways.)

My model is close enough to reality.
It's a 2D assimilation.
In certain cases you might use the side view frame maybe.
But okay, if you want to have a perfectly realistic shadow then you should create a 3D model of the character sprite and calculate the shadow from a sideways angle and create a 3D model of the room to project the shadow on.
Sounds easy enough to do with AGS lol.

Well anyways, if you don't have time for it then there's no point for me to suggest ideas. It sounded like you were interested to do it that's why I shared it.

Thanks for the tips!

Interesting, not a long time ago I came up with an original idea for a game that takes place in deadly freezing coldness. Even before I read this thread.

But creating it before the end of the month?? Ugh..

I definitely would not have the time draw the graphics myself this fast.
Does anyone know good links with existing art work and sprites I could use for the game (characters, items, background)?

Hopefully, not considered offtopic, I'll leave this here for inspiration :

I find it inspiring. Would it be possible to use the music for the game without copystrike?

[y-axis]

Great you moved the thread Snarky!

Thanks for the illustrations, ManInBoots! Yes, that's more or less what I had in mind.

Sure thing. When I read that you wanted to create a shadow module, I just immediately could imagine it how it would work!
Yesterday I kept thinking about this throughout the day and came up with ideas on how to manipulate the dynamic sprites to create the shadow shape.

I use a lot of illustrations, so open the panels to look at it. I hoped using the panels "show/hide" gives for a better overview?...

Spoiler

First I want to mention that I believe that it would be better to use a shadow character and draw on it's view sprite instead of the background. This would allow to draw shadows on other objects as well. You would assign the character you choose as the shadow character or it's ID to the module with a certain function for example. And the characters baseline would repeatedly be Playercharacter.baseline-1, so it would cover everything behind the player character, but nothing in front, and not the player character himself. Otherwise how can it throw shadows on any object that the character walks past?

I want to describe a method to transform the sprites in a way so you can determine exactly from which direction, or which angle the light falls unto the character.

And I mean, as well from the x-direction:



As from the y-direction:



EXPLANATION OF TERM "LINE"

Spoiler

A quick explanation for when I talk about shearing.
Here we have a simple box 11x11 pixels (strongly magnified):



And now I am moving the "Y-LINES" to the right (since every line has an y value)



Now I move the "X-LINES" of the original box down (every line has an x-value)



This just to show what I mean with the terms "x-line" and "y-line".

[close]

MANIPULATION ON THE X-AXIS

Spoiler

Now, back to the transformation:

How would you manipulate the shadow sprite into the right shape when changing only the x-direction of the light source? (As those three different shadow examples in this picture below)



First you would have to choose the x-angle from which the light comes. In the illustration you see the red x-axis.
I marked the angles 45 degrees and 135 degrees. But obviously you could choose any angle between 1 and 179 degrees.
I also marked the baseline of the "vertical wall shadow area" with a dotted line.



Now let's take the example of 135 degrees.



First you would calculate the intersection point of the baseline with line that leaves from the characters base point (characters x,y coordinate) with 135 degrees.
I marked the intersection point with a blue X:



Now the x-value of that intersection point is the x-value where you place the shadow sprite.



Now you cut off (yellow line) the lower part of the shadow sprite and shear it into place.



There you have it! The shadow is finished!



Now when you actually draw the Dynamic Sprite the best way, from how I understand it, would be to draw it from bottom to top.
So you start with the sheared part. The first y-line is drawn just like the character sprite on the characters x-postion.
The second y-line then is moved/sheared to the right in this example. How much to the right?
Well you would calculate the difference between the x-coordinate of the original character and the x-value of the intersection point. Then you divide that by the number of "y-lines" that are being sheared. That number equals the distance between the character's y-coordinate and the shadow area baseline.
Let's say hypothetically in this case the y-line will be sheared by 10 pixels. The the second then will be moved and re-drawn with 20 pixel offset. The third 30 pixels, and so on.
So the y-lines are being sheared until we reach the baseline.
So from now on the y-lines won't be sheared anymore.
Let's say the last shear has been moved by 200 pixels. That means from now on every y-line of the sprite above the baseline will be drawn 200 pixels to the right. And thus the upper part will look normally drawn, just further to the right, as it should.

[close]

MANIPULATION ON THE Y-AXIS

Spoiler

Now how would you manipulate the sprite for the y-axis angle?

Let's say you have the angle of 135 degrees on the x-axis, and now also you want to transform the shadow with 135 degrees on the y-axis.



(Note that if x-angle<90degrees, the the y-angle would automatically switch to the left side of the y-axis, in case you understand what I mean by that. So again we don't need 360 degrees for the y-axis, but only the values 1-179)

So, y-angle set to 135 degrees, now we need to calculate the intersection point of the y-angle line with the x-value of the formerly mentioned intersection point with the baseline. I marked this second intersection point with an orange X.



As before, now we place the shadow sprite on the X-intersection value with the baseline.


But this time, before shearing the lower part as we did for the x-axis, we will SCALE the shadow sprite first! But only for the y-value! We basically "squish" or negatively stretch it.
And we stretch it until it has exactly the height of the y-angle intersection point:



(I assume one could use the same code as the engine uses for character scaling, but do it only for the "y-lines" and not the "x-lines")

Once this is done, we shear the part below the baseline like we did for the x-axis.



And voila! The shadow is finished. Now the light is coming in from the high left:




So for the sprite drawing:
You would have to stretch (in this case negatively stretch) the character to the right size first. Then you would start with the shearing and continue like you did when transforming on the x-axis.
Let's say the negative stretching is achieved by skipping certain y-lines. Then it would be advisable to make the process of stretching (skipping y-lines) and shearing at the SAME time, in order to safe drawing time and possibly avoid using an additional canvas.

There you have it. Those are my ideas on how to angle the shadow on the x- and y-axis!




I also have an idea for the angled walls! How to manipulate the sprites to create such a shadow:



But it's getting late here. I'll explain it more thoroughly another time.

[close]

SHEARING

Spoiler

Concerning shearing I want to mention a detail. Moving the y-lines when shearing to the left for example (as happened in the examples above) works fine.
HOWEVER, when you shear too much, it can create gaps between the pixels. Take for example a simple one pixel thick line (magnified in the illustration):



Now when you shear it strongly, this would happen (right side of the image cut out):



So the module would have to recognize gaps between the y-lines and automatically fill them up. Fortunately it would have to fill them up only with "black" pixels since the shadow is one-colored.
And how many pixels should it add to the right of the previous y-line?
Basically when drawing the new sheared y-line on top of the previous y-line, the module should:
add the 1/2 the length of the first y-line and 1/2 the length of the second y-line.
If that addition is shorter than the shearing distance, than it needs to draw additional pixels.
(the amount of pixels would be the difference: shear distance MINUS 1/2 * (y-line 1 PLUS y-line 2). Not sure if this was clearly enough explained.
(side note: for this to work, the module would have to recognize which pixels are "drawn" and which ones are transparent, in order to properly define the length of the y-line)

In the example:
The first y-line is one sprite one long.
The second as well.
The shearing distance is 2 sprites.
So the module needs to fill out:
2-(0,5 PLUS 0,5)=1
Since every y-line has the same length, the module needs to draw ONE pixel to the right of each y-line:

[close]

[close]

You are guys more advanced than I am with the programming, but maybe this can give you some ideas and some inspiration.

Anyways, I think it's an exciting project!

2ND EDIT: For your idea about the horizon Snarky, the vanity point etc. actually I think it's possible. But you wouldn't use a vanity point or horizon, but simply scale the shadow depending on it's y-value. That's the efficient way to do it I suppose.

The character's shadow could be automated with a module

It's not the topic of this discussion, but I've also thought about it and the main difficulty is that shadows are not additive. Only the brightly lit parts of the background would become darker. The parts that are already under a cast shadow from the scene would not get darker. It means you can't just draw the character's shadow over the scene, as is. You'd need to keep the overall shadows in a separate channel. It quickly becomes overly complicated.

When the character stands between the object and the wall/floor the shadows ARE additive.
And for the non-additive shadows, I do not believe that it would become overly complicated.
From how I understood Snarky the areas upon which the shadows fall (I'll call them "Shadow Areas") would be drawn, just like you draw the walkable areas or walk behinds.
In that case it's very easy to simply cut a hole into the shadow area where the object shadow is placed. (Illustrations and Explanations below)

Spoiler

I understood it that you'd draw the shadow areas because he said, there would be horizontal and vertical areas. You would have to define those areas.
And the best way is to draw them.



Because, what if there is a hole or a window in the wall?



You wouldn't want to the hole to be covered by the shadow either!

Also you would need to define a Baseline for the Shadow Area (just like for the walk-behinds). Because the distance between the wall and the character defines the distance between the character and the shadow. (And maybe also the intensity/transparency of the shadow)


Those are supposedly flying men with wings!

Let's say you have a shovel object in the room with it's object shadow.



Then you just need to leave a hole where the shadow object is when drawing the shadow area. (Similar as when you draw walk-behinds)
And you can fill up the "hole" with another Shadow Area ID, in order to restore or remove it, so that character's shadow is cast or not cast on the place, depending on weather the shovel is picked up or not.



It's exactly like walkable areas/walk-behinds. And those are not complicated. And it would create a perfect shadow, because the overlaying shadow is cut out:



The real complications maybe only start when you have angled walls and different distances for the light source, but the module wouldn't need to include that.

Unless implementing the option to draw the shadow area is too complex, I say a simple shadow module/plugin is worth it and totally possible. Even if you couldn't draw the exact outlines of the shadow area, I wonder if depending on how the shadow sprites are drawn- as dynamic sprites I assume- if you could simply create a walk behind that cuts the "shadow hole" (at least in simple cases where you can play around with baselines)...

[close]

I read through this post and saw that De-communizers idea actually isn't a bad idea at all, if you just add variables and loops. I know I'm too late- umm 11 years?
But I thought it through and it actually gives for a really simple script, so I thought I'd share:

Code: ags

int Rainbow[8],i,n=1; //you need at least 8 arrays
Rainbow[0]=Random(9);
Rainbow[1]=Random(9);
while(n<7)
{
for(i=0;Rainbow[i]!=Rainbow[n]&&i!=n;i  ){}
if(i==n)n  ;
Rainbow[n]=Random(9);
i=0;
}

[EDIT:]

Hm... It's actually when I build and run the normal game from the editor. And I tried it out, it's the same when I start it via the winsetup.
This sprite cache seems to be a real trouble maker!
You told me about the counter that is inaccurate. The sprite limit is not very accurate now as well it seems. Maybe I'm just interpreting it wrong.
However I wonder if multiple inaccuracies like that could also lead to game crashes in more extreme situations, like high resolution animations.

EDIT: Just to clarify what I meant by it, because I talked about inaccuracies before in this thread:
If the game does not keep track correctly of the statistics (the sprites, the maximum sprite cache etc.) maybe some calculation will create an error or the engine believes sprite cache is full even though it isn't.

what are other numbers in the message? It should say "Sprite cache size: X (limit Y, locked Z)".

It says:

Code: ags

Sprite cache size: 78319KB (limit: 131172 KB, 100 locked)

But actually don't worry, it's fine.
As soon as the sprite cache size surpasses the limit, the limit grows with it, so it's not actually a problem for me.
I thought the limit defines the maximum cache size.

You can set it in the editor, by opening a character for edit and pressing "Make this the player character" button (it's right above the view preview).

Oh yes of course, you're right. Been so long I used the button, I didn't even see it! Thanks.


And anyways, I'm happy you also found a few things that can be improved in the engine and that can make the program better.

[Why could it be that I have only 131MB free cache??]

I'm glad, those are valuable insights Crimson Wizard.

It's cool to know all this. I experimented with it, and I was able to reduce the locked sprites to 100 KB in my original game with the video intro.

What striked me however is that it tells me that I have only 131172KB total sprite cache available. Only 131 MB?

I set the Sprite cache to 2 GB in Default Setup.
I saved the game in the editor.
I built the .EXE file.
I ran the game from the editor.
I ran the game over the winsetup file. Same result.

I have 3,84 GB usable RAM.
I have 1,759 GB total Graphic card memory.

Why could it be that I have only  131MB free cache??

Thing is... it does not seem to unlock locked sprites after calling Mouse.ChangeGraphic again.

Ok, good thing we also talked about the other means to preload sprites! It's always good to find out a little bit more beyond what seems relevant at the moment!

I also found another bug, related to locked size counter

Does the locked size counter actually have a limit?

I also removed obligatory player's view precaching. That made game startup almost instant for me.

Same for me, with your plugin there is no frozen black screen.


Side note: The character who's view sprites are locked into cache is always the character ID 0. I tried setting different characters as player anywhere in the scripts before the room was loaded, but that did not work (maybe it could be possible if you communicate directly to the machine...). I think it's not the first player's view, but simply Character ID 0's view that is being locked.
In order to reduce locked sprites I set character ID 0 to an empty view and created a different character whom I set up as my player.

Also interesting to know: the Speech, Idle and Blinking view are not being locked into cache. Only the normal view.

[Edit:]

Heya

Saw your post only recently.

it takes too much time to startup the game. There's no "preload" screen in this game, and it looks like game window froze

I can see the Loading symbol when I run the game on my computer, so that probably means that your computer pre-loads the sprites fast enough so that you don't even get to see the Loading symbol.

For me, too, it takes too much time starting the game with a blank, black screen (in the "room before fade in" phase).
Also, as a side note: When I start a project and create a high resolution animation with less sprites, only a bunch of them, it works without any problem. However from a certain number of sprites this terrible lag and the error message is happening. Relating to what you said

There's a peculiar issue of sprite cache reporting "locked size" = 1.5 GB.

my theory is that the software does actually -before the room is loaded- lock a certain number of normal sprites only used in animation into cache, which would be badly programmed. So when I have a few sprites in the animation and thus only a few sprites in locked cache it does not interfere because it's nowhere near 2 GB.
So it seems the "Locking" into cache is not very clean and accurate when choosing which sprites to lock.

NOTE: I have 16 GB RAM on my PC.
Okay, 64-bit Windows may be limiting 32-bit programs to 2 GB actually:

So I assumed right after all, that it's not directly related to RAM but also related to engine. I'm glad it's not just my PC. Is your Graphic Card Memory anywhere near 2 GB?
Does it make any difference when you change the Sprite cache in Settings to 2 GB? (Because the demo is set to 1GB as is)

I mean after all that is a great insight you have! So if at any point this problem is addressed in development, you already know that the core problem is in how the sprites are selected and filtered to get locked into the sprite cache.

You can see it if you stop intro mid-way somewhere before it crashes and press Ctrl+V.

You can press Ctrl+Alt+V in game to see how much is locked.

Sorry, what do you mean by "stop" the intro? Press escape? Close the game? I was not able to view the Locked Sprite info, no matter at what point.
Neither by pressing "Ctrl+V", nor by pressing "Ctrl+Alt+V".

UPDATE but after I commented out all ChangeModeGraphic calls, that reduced "locked size" only to 1.35 GB.....

That again shows how "unclean" and inaccurate the selection process for sprites is. I pre-loaded the biggest part of the animation. The sprite file is almost 700 MB big.
So under no condition should the locked Sprite size be reduced by only 150 MB. It should be either ALL the pre-loaded sprites that get locked, because Mouse Cursor Graphics are locked, or NONE that get locked. But it's neither of those two options, it seems that only SOME of the pre-loaded sprites get locked.

Normally, one would create 2 tiny objects as flashes and animate these, but instead in this game you have five 1600x900 full-screen sprites which has nothing but these tiny flashes in the middle. These could be easily reduced to like 16x16 sprites put onto 2 objects in the room, making this part of animation take about 100 times less memory already.

Well, images usually only take up a lot of space when they include a LOT of different colors and textures, such as exactly the photographs I use that are vividly colored. But plain, one-colored sprites (or plainly transparent sprites) do not actually take up a lot of space. One transparent sprite, sized 1600x900, takes up more or less 55-60Kb. So by reducing the sprite size I would save only 50-55 KB in this example (55x6sprites=330KB). That is next to nothing when I have to reduce 1 GB or 1000000 KB sprite cache. And working through the entire animation to try to save space like that is just a waste of time. I really pushed myself to the limits doing this animation, I haven't really done a lot of animation before, so I already got exhausted creating this. On top of that I want the sparkle in the eyes to be placed exactly where it feels right to me. So I have to go to my graphics program, make the size smaller, than measure exactly the difference to the full sized image for the smaller sprites for both x and y, and transfer those Coordinates to AGS. Now imagine I do that for every object in the entire animation. It's a lot of work and it has very insufficient results. Whereas when I animate in full size I can simply set x,y to 0,900 and it's perfectly placed, and I added only 55KB to Sprite cache.

the marble with a face and wings - these sprites are bigger than necessary and could be cropped to reduce to around twice as smaller size. In fact, if you push to max effect, you could place the face, that does not change at all, onto the 1 separate sprite and object, and animate wings on 2 separate objects. This would reduce memory for these flying faces more roughly by 1/3.

Yeah I could have done the separating between wings and face to save space. However I am reluctant to reduce the quality and size them down somehow...

the "monster attack" animation I found in the sprite folders - again, the sprites are 1600x900 big but contain too little, these could be cropped significantly and played while also moving object around.

I cannot just move the sprite to make it look like he jumps. The monster is rotating while he jumps, which makes things more complicated again since rotating is not developped and integrated in AGS yet. Also it would be really messy to make it look like he catches the flying marble perfectly and align two different sprites perfectly. I would set approximate coordinates, run a terribly lagging animation, estimate new coordinates again, run a terribly lagging animation again, estimate new coordinates again... That's just too much. And again same thing:  I would save only very little space with a lot of work.

the "Press escape to skip intro" looks like basically one image rescaled several times to make an animation. This could be optimized by having 1 image and scaling the room object. Or have a TTF font or sprite font and drawing a text.

Yes I could have done that with Scaling and saved some sprites, true. I'm not gonna use that symbol eventually anyway. Can you scale Sprite font texts? For now I'm having difficulties with your type writer, seems a bit complex to me on the first attempts. I will still experiment a little bit more with it...

At least now you know that there are issues concerning the locking of sprites that can be adressed to improve the engine. The lagging music seems to be only my PC when it has to perform too much, so nothing engine related at all. I had the same problem to a lesser degree with a different game that wasn't AGS related. But that genius insight you had with the sprite locking, and the error message you get on your PC as well, that's AGS.
I for one will continue making the animations as videos. It's easier, it has way better performance, and I don't get all of those problems, which freaked me out a little bit at one point to be honest.

It's maybe not the worst suggestion to make the sprites all as small as possible where you can. But as I said it's just sooo messy and so much trouble doing that with AGS that it's barely worth it.
However that gave me an idea for a very useful option in the room editor that would make it all extremely easy, and I feel like anyone who has worked on a more elaborate animation so far could agree on it's utility:

Spoiler

An option to actually preview an object or character on a specific sprite in the room editor, and an option to preview it with scaling!
This way you can view a character in the view that you use in the animation, with the scaling that you use in the animation, move it exactly to the spot you want. And then you simply copy their x,y-Coordinates and use them in script of the animation, super easy!

I made some illustrations just for how that would look like, to make this clearer.
Those are only illustrations, obviously:




View in High Resolution: https://i.imgur.com/Xy29pto.png

So you can click the button in order to preview the character (or object- I will say only character from now on, only because I am too lazy to mention object as well every time) with a specific sprite that you choose, and if you click again you deactivate the preview.



View in High Resolution https://i.imgur.com/sNw8dZQ.png

So when you click on the little loading box on the side you can choose what Sprite you want the character to be previewed as. You can either type the sprite number or browse:


And then you can activate or deactivate the preview, while seeing on the button what Sprite you can preview as:




And for the scaling one could add a tick box, simply like this:



View in High Resolution: https://i.imgur.com/azU3JDu.png



View in High Resolution: https://i.imgur.com/qOaNtXw.png

And then you could choose the Scaling value for preview, by clicking on the small loading box on the side next to it. There you have the option to have a specific Scaling value, or preview the character with the scaling of the walkable area at it's x,y Coordinate:



Just to be clear, this wouldn't have ANY effect on the game play itself, it would only change the preview in the EDITOR while the button is clicked or the box is ticked.
This would really help organize and structure animations in an intuitive, effective way. You will know exactly where your characters and objects have to go during animation, you can accurately estimate the whole process of the animation. I know you guys are all geniuses when it comes to programming and logical problems, way better than me. But I think that part of creating games is also the story-telling, the creation of a world, being very IMAGINATIVE. And for that I think an intuitive tool like that can help tremendously make game creation and animation a bit more intuitive and imaginative, and will result in slightly better games.
What do you think Crimson, or anybody for that matter?

[close]

I got this idea here while working with this animation, but maybe I should post this in Editor development

Edit: And sorry, just saw how long this reply became. I just wrote off the top of my head, you can answer when you get to it, no pressure

Alright, okay.

Let's say, I want to create several Timers, and I know from the beginning that I prefer using all of them as objects.
So that I can script

Code: ags

MyTimer.Start(120,eOnce);
...
MyTimer.Stop();
...
MyTimer2.Start(120,eOnce);
...
etc.

So instead of writing an additional line of

Code: ags

MyTimer.Create();

for every single Timer I basically create the timer object from the very beginning in one line. Just because it's faster.

Instead of

Code: ags

Timer*MyTimer;
MyTimer=Timer.Create();

I just write

Code: ags

Timer.CreateAsObject(MyTimer);

That's all lol, that's what the idea was about.

Because it takes only one line, not two. So it's easier to write.

Btw. The links didn't work for me I had to change the ending to download it, e.g.  "... ags-script-modules.git" to "... ags-script-modules/downloads/" maybe that's just my PC

There are two links: first, with big "DOWNLOAD" point to zip archive, and another - "git cloning address" is to be used with "Git" source version control tool.

Makes sense, thanks for the explanation

On a side note, I seem to finally able to get most of planned tasks off my hands, so hopefully will be checking your demo game soon too.

So the question for you is then how worthwhile it is to look into making the way animation is handled more efficient. eri0o already tested it and it works fine on his PC, so the lagging comes also from lower PC performance. You have the overview of what you're working on, so you know what's important for the game development.

Btw, I just thought for a second, would it be possible to add a function like this to the timer script:

Code: ags

function AddAsObject(String name)

{Timer*name;
name=Timer.Create();}

And then you can create the timer object with just one line:

Code: ags

Timer.AddAsObject(MyTimer);

Does that make sense?

Seems safe enough to me! As long as you code correctly, it works- that's as safe as the rest of AGS. Do as you see fit, and thanks for the help 

Personally I like it.
And how would "less safe" show itself concretely?
Would it not work only sometimes?