Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - lafouine88

#1
AGS Engine & Editor Releases / Re: AGS 3.6.2
Wed 28/05/2025 15:53:24
Ok that's noted.
Since I have dozens of GUI's and my whole thing is a huge mess, I understand that the things gets buggy^^
Should I try to isolate the problematic GUI or is it the combination of many that is a problem? Or should I just get back to my previous version until the next patch?

Thanks a lot for your work :)
#2
AGS Engine & Editor Releases / Re: AGS 3.6.2
Mon 26/05/2025 09:40:15
Here is the post :


So there were no big tricks. The character uses "normal sprites" and I just go "player.say("..."). For test purposes I did that using function On_KeyPress() with nothing else than "player.say("...");" The sprites are 256*256 for my character but much lower for the others, and the problem goes for each one.
sam" border="0

One interesting thing thought is that, when I use player.saybackground() the speech is centered like so:
samback" border="0

I also tried creating a new character, with different views but the issue remains:
newsam" border="0

My map is a big one so I tried walking to the far right to see if maybe the speech was displayed in a specific place, but no. Even when I walk to the right edge of the map the text displays on the right of the screen.
I was previously on 3.6.2.6 with the walkpath correction (sometimes the character would get out from walkable area and be placed back on it automatically) and it worked normally.

About GUI's I have many on screen. All lifebars buttons etc. plus one that I just use for tests which is the yellow,red,blue,green and black lines to the right. I tried deactivating this one plus some others that could have interfered. But none of them seem to be the cause.

I'll try some more things tonight and let you know if I find something. Still, this whole thing is pretty weird, especially if I'm the only one getting this problem^^


#3
AGS Engine & Editor Releases / Re: AGS 3.6.2
Sun 25/05/2025 11:41:39
Thanks for the new release!!

I just have one quick question, on my rebuilt version of the game, the characters' speech are displaced to the far right of the screen for some reason. Is there some new option that has changed and I haven't seen?

3-6-10" border="0

Thanks and good job to all of you
#4
Advanced Technical Forum / Re: RAM limitations
Mon 31/03/2025 07:26:25
QuoteAre you scaling your characters?
Yes, that is the worst of it. I'm downscaling to 50% to match the interface. So I load a big file and then reduce it to 50% so that with 'render sprites at screen resolution' it looks quite sharp... :-X

QuoteDo you really need to have 17 different pieces of armor all loaded at once? Can't you load it as needed?
No, it's just that if 17 is the strict maximum, and I need to load at least 6 at a time for the character+ennemies there is not much margin remaining and I must be very cautious not to use too many visuals, which is a bit annoying. But yeah the idea is not to load everything but just what is strictly needed.

Quote(But my advice would pretty much be to not try to make this game in AGS.)
And I also wish I could turn back time and do this again on a more adapted engine. I figured AGS would be more than enough for an isometric 2d game but really it would have saved a ton of time and work to do this on a different software:/
Let's say that after one year of creating functions and GUIs everywhere I really want this to work out^^ and I'm not so far "^^
#5
Advanced Technical Forum / Re: RAM limitations
Sun 30/03/2025 23:31:36
QuoteI'd suggest to reduce sprite sizes as much as you can to still accommodate the pieces of equipment. That will of course make setting things up less convenient: you will have to script a system of offsets which each part should have relative to the main body. But this also may have a significant positive effect on memory requirements.

Yes. I actually tried a bit more today with half sized sprites and the loss in quality show a bit too much, especially on small pieces of armor. Which is a shame.
So I think I'll actually go with the trimmed sprites. It's going to be very annoying to code with every piece of item having different sizes^^(actually if someone has suggestions to do that in an elegant way I would love it because I'm pretty sure I'll do something very complicated :P) but it will definitely be worth it.

I'll let you know if this solution is better.
Thanks
#6
Advanced Technical Forum / Re: RAM limitations
Sat 29/03/2025 20:03:43
Hi again guys

So tonight I tried to see how many pieces of armor the engine can load to the maximum, it is 17.
Which is logical because according to what @Crimson Wizard  told me, the amount of RAM spent to create a sprite is width*height*4 per sprite
So : (256*256*4)*7views*8directions*12 frames ~175Mb per item
175*17= 2 994 Mb,
175*18 =3 170Mb which is too much.

So in the end this all seems quite logical, and the obvious solution that came to me is just to divide all my spritesheets by 2. With 128*128 px I can get 4 times as many items, which will be much more cumfortable.

I don't think there is any magical solution here, so unless there is a magical solution to expend the RAM limit or anything else I can touch in the settings I guess I'll go with this. I tried it and it still looks quite alright :)

Thanks anyway and many special thanks to @Crimson Wizard for all his explanations and patience ;)
#7
Advanced Technical Forum / Re: RAM limitations
Sat 29/03/2025 12:35:11
QuoteI know nothing of what your game has in it, so it's difficult to give precise advises.
Let's say on this part of the game, it's basically Diablo 2 like with huge rip off from Warcraft interface^^ it's just for personnal use :p
Here is a quick video I recorded, obviously still WIP so there's a lot of parasites everywhere but that gives you basically the style. It's very fast and I'm godmode for test purposes as well so sorry if you feel sick^^
https://streamable.com/82desi

QuoteFor example, if I remember correctly, the first episodes of Diablo series (1,2) were sprite based, but did not have a separate "body" sprite for literally every unique item, instead they had separate sprites per a "class" of an item, like: a small shield, a big shield, a sword, a mace etc.
It's pretty much the same, I don't use a single skin for every piece of item, but still, it requires a lot.

QuoteI assume that you are using "paper doll" technique, where you gather your character from multiple pieces, either by applying to their frames or by having separate character or overlay for a piece, following the main body.
That's it, Chead,cShoudler,cTorso,cLegs,Crarm and cLarm a following exactly the character and adding their separate skin when called. I can link the code I use if need be.

QuoteAssuming that's right, why do you need to load all possible armor pieces into memory, when you only need them to display on your character? Do you keep them or most of them in memory in case player changes the outfit? How do you do that? I suppose that I'd try to limit the number of stuff loaded, and only keep things that player has in inventory, or even only things that he/she was wearing very recently; and load anything else only when necessary.
Initially I wanted to have everything created at first game load so that afterwards the player can change at will with no loading time whatsoever. After speaking with you I rejected that possibility to just have a limited amount of armor sprites ready to use. I haven't yet decided how I'm going to select which should be stored and which should be erased but I don't think it's gonna be that hard. Problem is, even now with just 8 pieces of armor (all different types of weapons take a lot of space : shield,sword,left hand sword, mace, left hand mace,dagger....) I'm blocked when trying to load the NPC's sprites.

QuoteAre you saying that each piece of armor is drawn as a full-body size transparent sprite with armor piece somewhere in the middle, instead of a smaller sprite to only fit the armor piece itself?
Exactly. The size of each sprite is 256*256px, always a square because it was much easier for me to have every item with the same size (a polearm would be larger than a dagger),that way I don't have to worry about positions. But again, that was when I thought this would be no problem for the engine.
000-0001" border="0

And finally I didn't touch game config (except for compression) so I guess it's the default values :
config" border="0

I can link any piece of code you might want to see
Thanks :)


#8
Advanced Technical Forum / RAM limitations
Fri 28/03/2025 19:58:36
Hi guys

I'm currently facing a problem with my game that displays this message of error
error" border="0

I discussed it a bit with @Crimson Wizard and this seems to be due to a RAM overflow, the current limit of the engine is 3GB.

My game is not really adapted to the AGS engine,it's not really a point and click but more of a RPG. This entails a very greedy use of graphics :
-My maps are 2800*5000px ,oO
-the enemies get created cutting a big spritesheet into dynamic sprites that create 5 views of 8 directions and 8-16 sprites per loop(on average that's 480 sprites per enemy)
-The player's pieces of armor get created similarly creating views for each one, this time:7 views of 8 directions and 816 sprites per loop (670 sprites per piece of armor).

At first I planned to create all the views at startup and then just use them but this definitely asks too much memory. So I tried to divide the needed memory by just loading what's necessary and then deleting the sprites.

For example :
-At game start, the game loads the first map and the 5 first pieces of armor. It also loads the NPC on that map(by creating the necessary views through dynamic sprites).
-When the player changes room, the pieces of armor are kept because the player still wears them, but all the dynamic sprites for NPC get erased to create the new ones : the ennemies from this zone.
-If I get back to the first one, those same dynamic sprites are erased again and replaces by the NPC's.
-and so on...it's a bit longer to load maps because the game creates and recreates over again each time but this saves RAM.

The problem is, even with this method the game still crashes, it actually seems that the 3GB limit is reached very quickly.
According to my calculations, each enemy should use around 125mB, and armor is 175mB. Which means that if I carry 6 pieces of armor (helmet,shoulder,weapon1 and 2, torso and trousers), I already reach 1/3 of my allowed space. Each map loads around 8 different enemies so that's 1/3 more. My map takes around 120mB so that doesn't leave much room, but still it should work.

Do you know how much RAM loaded arrays take(because I use a lot of those for spells, capacities,ennemy stats etc.), and do you think this should also be reduced to a strict minimum? Same for sprites, I use 256*256 because it's more convenient but I guess I could crop the sprites to the minimum necessary, should I ? Or do you have other suggestions to keep my RAM alive ?

Thanks a lot  :-D
#9
Yes that's a good one. But it doesn t work for Dynamic Sprites view.

I need to create a lot of "blank" views with the right number of frames. It s not especially long, it s just very annoying^^ if you could like copy-paste a view,it would be cool. Though it stays a very casual need so I m not sure it would be that useful for most games^^
I was asking,just in case

Thanks anyway😃
#10
By the way, Is there a way to add frames and loops in view, other than manually? When you create many it's long and annoying. I've noticed I can use the notepad and the game.agf file but I find it even longer, and more hazardous.
#11
QuoteThere's a section starting with <Views> that has information for all the views stored in the project. Maybe something wasn't getting deleted properly.
Yes that was it. I don't know why but some views hadn't been deleted. I just copied/paste the code and changed the view numbers and they reappeared for creation !



Thanks guys!!
#12
Hi guys

I've recently changed a lot in my view system, so I had to delete them to start back on a clean basis. I used like 250+ views and I deleted them all to just have around 30 left. And start again.
Something weird happens though when I create my new views.Instead of adding normally : view 31,32,33... sometimes one or more Id numbers are skipped. It goes 31,32,35,36,37,39 for instance. Which is annoying because I really need the view order for legacy coding. And it doesn't make sense because I ve checked many times, views 33,34 or 38 in this example don't exist anymore.

Any ideas why this would happen?

Thanks
#13
Great! Thanks! I'll check this ASAP  :grin:
#14
Hi guys

I found this old post since I'm facing the exact same issue as jumpjack. And I also followed the discussions here
https://github.com/adventuregamestudio/ags/issues/1879
and here
https://github.com/adventuregamestudio/ags/pull/2658

I see that the posts are very recent. I just don't understand it all since I find the github interface a bit confusing. From what I get, ivan-mogilko is working on a new fix for pathfinding ? Or did he post somewhere a little code to fix (there s a lot of mentionning of 'teleporting the player back to a walkable area if he gets out). I was thinking maybe @eri0o who seems to follow the topic, or @Crimson Wizard  could give me a heads up.

Thanks
#15
So, I confirm using characters seems much better than Dynamic Sprites in this case. Equipment changes are instant, and the CPU load is transparent.
Plus, you don t even need to bother with Sprites priority(meaning for instance that left arm is above the right one on left views, but below on right ones).
I just set :
Clegs.baseline=player.y;
Ctorso.baseline=player.y+1;
CLarm.baseline=player.y+2
CRarm.baseline=player.y+2;
Cshoulder.baseline=player.y+3;
Chead.baseline=player.y+4;
And it s all good👍👍

Thanks guys😁
#16
Quote from: Crimson Wizard on Mon 07/10/2024 16:52:20Using "repeatedly execute" on its own has nothing to do with RAM. RAM is memory, it's used by creating new sprites and objects. Maybe you mean CPU load?
Yeah sorry I always confuse those^^ I mean CPU load. basically my intention is to lighten this one as much as possible to have as fluid a game as possible. If this coasts extra memory (or ram :p) I feel this is fine.


Quote from: Crimson Wizard on Mon 07/10/2024 16:52:20Setting new graphics to the view frames needs to be done only once the player wears the item.

Setting the current loop, current frame to sync with the main body has to be done in rep-exec.
Yes, no problem with the new views. I was just thinking maybe adding 12 repeatedly execute could affect the speed. And planned to limit this as much as possible. But in this case it really seems smoother to do it your way.
I planned to use baseline for limbs, should work fine. But once again, what I liked with dynamic sprites is that you calculate the whole thing once (including limbs priority according to positions) and then you're all good until the next change. Requiring no CPU load at all. As @Snarky said, it's hard to know how it would go on the average computer. On my gamer pc, multiple repeteadly execute is supported without problem but I don't know for a weaker one.

@Snarky Thanks, I also thought of this trick at first but it didn't go too well. It slowed down just a bit, but 10 times. Which was really bad for game experience. It's hard to find the right balance between immersion and engine cumfort. I also thought of a place restriction (like you can just gear up in town) and the new views for all attack moves would be done when you exit town (thus going throught a loading screen that would be used to create the next views), but it seemed really too heavy for gameplay :/
#17
you confirm this kind of calculation would be transparent for the AGS engine? I remember one advice from Khris I think who said that most of the time there is a better way than to use 'repeatedly execute' to save RAM. The advantage of the previous method was that once it was calculated it's done (and you don't need to take into account limbs ordre of appearance according to current frame for instance).
Maybe I could go for a mix of both, like, until the next loading screen it follows using this method, and then it moves to dynamic sprites on the next loading screen? Or do you think it is irrelevant ?
#18
Quote from: Crimson Wizard on Mon 07/10/2024 15:27:17It's "late_repeatedly_execute_always":
https://adventuregamestudio.github.io/ags-manual/RepExec.html

Sorry I read too fast...Seems pretty good now.
Thanks a lot :)
#19
You're right, it seems way easier "^^
One thing though, "late_repeatedly execute" doesn't work for me. I had to put in in "repeatedly execute" to see the dummy characters actually follow the animation. ???
#20
Hi guys
I'm working on a RPG game, and to allow multiple item skins to be show, I used a function with dynamic sprites. Each item has 10 views (walk, idle atk,death...) and the maximum number of pieces of equipment is 6(torso,legs,head,Right hand,left hand and shoulders).
So if you equip an item, it's associated with a number that corresponds to the first view(walk), the rest are logically found with+1,+2...
As so :
Code: ags
///loading function at start up, defines all the items
butin[5].name=sword;
//...items characteristics
 butin[5].viewskin=100;---->the run sword view. 101 is idle, 102 is atk...always in the same order for each item


There is also an array to store the item number for each piece of equipment.
Code: ags
int Skin_stuffed[6];

So when you equip a new item, it changes the Skin_stuffed
  • number and then redraws the wholes views(10 views of 8-15 sprites :/) with all different parts of equipment like this :

Code: ags
 DynamicSprite *MySprite[80];///idle 10*8
 DynamicSprite *MySprite2[64];///run 9*8
 DynamicSprite *MySprite3[128];///atk 16*8
 DynamicSprite *MySprite4[104];///kick 13*8
 DynamicSprite *MySprite5[104];///LH 13*8
 DynamicSprite *MySprite6[112];///sweep 14*8
 DynamicSprite *MySprite7[80];///aoe 10*8
 DynamicSprite *MySprite8[120];///cry 15*8
 DynamicSprite *MySprite9[240];///die 30*8
 ViewFrame *Runviewframe[6]; 
 ViewFrame *Idleviewframe[6]; 
 ViewFrame *Atkviewframe[6];
 ViewFrame *Kickviewframe[6];
 ViewFrame *LHviewframe[6];
 ViewFrame *Sweepviewframe[6];
 ViewFrame *Jumpviewframe[6];
 ViewFrame *Cryviewframe[6];
 ViewFrame *Dieviewframe[6];


function skin_limbs(int currentloop,  int currentframe, int move, int limb){
  if(Skin_stuffed[limb]!=0){
    if(move==0){//run
        Runviewframe[limb]= Game.GetViewFrame(Skin_stuffed[limb], currentloop, currentframe);
        }
    else if(move==1){ ///idle
        Idleviewframe[limb]= Game.GetViewFrame(Skin_stuffed[limb]+1, currentloop, currentframe); 
      }
    else if(move==2){ ///atk
        Atkviewframe[limb]= Game.GetViewFrame(Skin_stuffed[limb]+2, currentloop, currentframe); 
        }
    else if(move==3){ ///kick
        Kickviewframe[limb]= Game.GetViewFrame(Skin_stuffed[limb]+3, currentloop, currentframe); 
        }
    else if(move==4){ ///Latk
        LHviewframe[limb]= Game.GetViewFrame(Skin_stuffed[limb]+4, currentloop, currentframe); 
        }
    else if(move==5){ ///sweep
        Sweepviewframe[limb]= Game.GetViewFrame(Skin_stuffed[limb]+5, currentloop, currentframe); 
        }
    else if(move==6){ ///jump
        Jumpviewframe[limb]= Game.GetViewFrame(Skin_stuffed[limb]+6, currentloop, currentframe); 
        }
    else if(move==7){ ///cry
        Cryviewframe[limb]= Game.GetViewFrame(Skin_stuffed[limb]+7, currentloop, currentframe); 
        }
    else if(move==8){ ///die
        Dieviewframe[limb]= Game.GetViewFrame(Skin_stuffed[limb]+8, currentloop, currentframe); 
        }
  }
else{///empty slots,view 55 is blank frames

  Idleviewframe[limb]=Game.GetViewFrame(55, currentloop, currentframe); 
  Runviewframe[limb]=Game.GetViewFrame(55, currentloop, currentframe); 
  Atkviewframe[limb]=Game.GetViewFrame(55, currentloop, currentframe); 
  Kickviewframe[limb]=Game.GetViewFrame(55, currentloop, currentframe);
  LHviewframe[limb]=Game.GetViewFrame(55, currentloop, currentframe);
  Sweepviewframe[limb]=Game.GetViewFrame(55, currentloop, currentframe);
  Jumpviewframe[limb]=Game.GetViewFrame(55, currentloop, currentframe);
  Cryviewframe[limb]=Game.GetViewFrame(55, currentloop, currentframe);
  Dieviewframe[limb]=Game.GetViewFrame(55, currentloop, currentframe);
}
}

function AlterEgoNormalView() 
{
  int MySpriteNo=0;
  int currentloop=0; 
  int currentframe;


  while (currentloop <= 7)//7 views
  {
    currentframe = 0;
    while (currentframe < 8) ///run view number of sprites
    {
      MySprite2[MySpriteNo] = DynamicSprite.Create(256, 256, true);
      DrawingSurface *MySurface = MySprite2[MySpriteNo].GetDrawingSurface();
      
      
      skin_limbs(currentloop, currentframe, 0,0);
      MySurface.DrawImage(0, 0, Runviewframe[0].Graphic); 
      skin_limbs(currentloop, currentframe, 0,1);
      MySurface.DrawImage(0, 0, Runviewframe[1].Graphic); 
      skin_limbs(currentloop, currentframe, 0,5);
      MySurface.DrawImage(0, 0, Runviewframe[5].Graphic); 
      skin_limbs(currentloop, currentframe, 0, 2); ///r arm
      MySurface.DrawImage(0, 0, Runviewframe[2].Graphic); 
      skin_limbs(currentloop, currentframe, 0, 3); ///L arm
      MySurface.DrawImage(0, 0, Runviewframe[3].Graphic);
      skin_limbs(currentloop, currentframe, 0, 4); shoulder
      MySurface.DrawImage(0, 0, Runviewframe[4].Graphic);
      }

       MySurface.Release();

      ViewFrame *MyViewFrame = Game.GetViewFrame(8, currentloop, currentframe);
      MyViewFrame.Graphic = MySprite2[MySpriteNo].Graphic;
      MySpriteNo ++;
      currentframe ++;
    }
    currentloop ++;
  }
player.ChangeView(8);///view 8 is the run combined view, 9 is idle,10 atk...
}

///then pretty much the same for
//function AlterEgoIdleView();
//AlterEgoaoeView();
//AlterEgoatkView();
//AlterEgocryView();
//AlterEgodeathView();
//AlterEgokickView();
//AlterEgosweepView();
//AlterEgoLHView();


//and this function is called when the item is equipped :

function reloadskin(int base, int slot){ 

Skin_stuffed[slot]=base;
  
AlterEgoNormalView();
AlterEgoIdleView();
AlterEgoaoeView();
AlterEgoatkView();
AlterEgocryView();
AlterEgodeathView();
AlterEgokickView();
AlterEgosweepView();
AlterEgoLHView();
}

I know that s a lot of information. basically each time you equip a new item it redraws 80+64+128+104+104+112+80+120+240 dynamic sprites...it's too much for the engine and it entails a small freeze (around 1-2 seconds depending on the computer's performance).
So there's two questions :
1/I suppose the code is far from optimal, maybe there s things I could change to make it less greedy.
2/If not, do you have ideas of a clever way to smooth the calculating time, something like : When you change equipment it just changes idle and run(which you need straight away) but the atk death views will be calculated at loading screen. Which does'nt create this unpleasant slow in game.

Any ideas to lower the calculation time would be great :)

Thanks and enjoy your week


SMF spam blocked by CleanTalk