Adventure Game Studio

Hi guys

I'm facing a room problem on my rpg game. I had planned to design large rooms, like in DIABLO, in which the player can feel the universe IS big. I initially thought this wouldn't be a problem for the AGS engine but after a few tries and discussions on the forum, I realized I was going to be limited by the room size.
I read in a very old post here (https://www.adventuregamestudio.co.uk/forums/advanced-technical-forum/maximum-background-dimensions/) that the max room size for a 640*400px game ( my resolution) is 2800px height and pretty much unlimited in width. I tried a few things and it is great for 2800*10000(it also works with 2800 width and 10000px height btw).
Thing is, I really had planned a 5600px high map, so I'm missing half of it with this limitation. I tried creating two different maps and setting an edge between them that teleports to the next map with eNextscreentransitioninstant, but there is a tiny pause that also breaks the character walk. The last part can be corrected with a load function I guess, but I couldn't remove the small loading pause, even with a blank room and nothing to load in it.

I guess I could go with it, it breaks a little the dynamic and maniability (which is important in this kind of game) but it's not a huge problem. But before I resort to that I would like to know if any of you already encoutered this kind of issue and if you found a trick :)

Thanks <3

I think i posted a reply to something very similar a while ago. (I cannot remember whether it was your question or someone elses).

The thing is, there's a difference between how AGS does the rooms and how "big world" games do their "rooms".

In AGS the room is a seamless bitmap for background. This is convenient in point and click games, but may be not convenient when you're making other kinds of games, such as arcades, or strategies, etc.

These games usually don't use a single background bitmap, instead they have scenes constructed of tiles dynamically (with some optimizations). These tiles may be of various sizes: small cells, or bigger chunks, - whatever is more convenient for a particular game and its art style. But in a very nutshell, they have the world in memory as some data, and generate the visuals as player walks around. When player passes a part of the world, its visuals got discarded from processing, and sometimes from memory. If the world is really big, they would not keep it whole data in memory, but load parts of it from file(s), and unload some parts when player is far away from them.

This system is doable in AGS, but you have to program it yourself in ags script, with some good forethought.

How much and what you will have to do depends on which AGS functionality are you planning to use. For example, for visuals, you may use room overlays to dynamically create visual parts of the world and displayed them in a tiled manner. If you need to use AGS pathfinding, then you will have to also dynamically update room masks as player moves to other places (the walkable mask is accessible using DrawingSurface).

---

In regards to the 2009th post about room sizes, I suggest to completely ignore that, because many things changed since.

There's no hard limit on a room size now, but there may be problems with some functions if your room exceeds 32k of size in any axis. That's because some parameters in game objects are represented as signed 2-byte numbers, meaning they will "wrap" to negative values if exceed 32k.

That said, I have no idea how well it would work if you make a giant seamless 32k x 32k room. Personally, I would recommend reconsidering this approach, and instead either split the world into multiple rooms, or think of methods that I mentioned above. But it's your choice what to do with your AGS game.

Quote from: Crimson Wizard on Fri 19/07/2024 09:34:26I think i posted a reply to something very similar a while ago. (I cannot remember whether it was your question or someone elses).

Yes, it was on an optimisation issue I had, and this topic came up^^.
I thought about your reply and I think I understand it. I would totally go for a dynamic sprite generated background map, I guess it would save considerable memory/RAM. But to do that it would be much easier to initally plant a huge room, on which you would define your walkable are mask, characters' positions etc. and then turn the background to a big black sheet, that you would continuously replace with the dynamic sprites as the character moves.
The problem is(and the second part of your reply makes me wonder why :confused: ) I tried to create a big plain room of 6k*10k but when I wanted to draw a walkable area, the program crashed. I thought I had excedeed the limits of ags but maybe that's not it.

I'll try again ^^

(https://ibb.co/N3GPGYW)

Oh yeah I forgot, this also happens (here the background is 6k*15k)

https://ibb.co/N3GPGYW

(https://i.ibb.co/W3RwRKB/crash.png)

Quote from: lafouine88 on Fri 19/07/2024 12:40:50But to do that it would be much easier to initally plant a huge room, on which you would define your walkable are mask, characters' positions etc. and then turn the background to a big black sheet, that you would continuously replace with the dynamic sprites as the character moves.

No, the idea is to not create a huge room (like 6k x 15k) at all, but create a smaller sized room, like a smaller canvas, on which you place pieces of a larger background, objects, and walkable areas, corresponding to the current "active" area.

The thing is, it does not matter whether there's a valid background, or a blank background, it takes exactly same size in memory ("blank" pixels are still pixels). And masks also take memory. And objects and characters do. If you display all of that at once, that would require extra processing and memory.

Quote from: Crimson Wizard on Fri 19/07/2024 20:54:45The thing is, it does not matter whether there's a valid background, or a blank background, it takes exactly same size in memory ("blank" pixels are still pixels).

I thought the same but was explained that pictures are like divided into areas of the same exact colors. So if you have one huge area of a single color it takes almots no memory (my room sprite was 100 ko) while a picture with different colors on every pixel will take more, even a two colors grid (the map I drew was 18Mo and it's more than 4 times as small). Multiplied by the number of maps I thought it was worth saving a bit, maybe it's not relevant compared to the extra ram it would require to generate the tiles.

To get back to the main issue.. With your explainations, I don't really see how I could work that out. It seems out of my range and maybe should have been planned earlier.

Too bad then, I guess I'll go with the loading pauses. I'll do my best to smooth them out :s

Thanks for all the tips Crimson  :)  :)

QuoteI thought the same but was explained that pictures are like divided into areas of the same exact colors.

That's true for images saved with RLE compression (for instance). But bitmaps are uncompressed when loaded in AGS memory.
Textures created from room bgs may be compressed in their own way, although I do not know if they are or which compression they use (graphics driver is responsible for that).

Actually, Using overlays seems very promising and seems doable. I ll give it a try and keep you posted if it's works, or, more likely, if I need help😅😅

@Crimson Wizard Overlays indeed look quite promising. Still I can't figure out something. This function simply draws an object/image on the existing room. But it doesn't stretch the room limits. So eventually this comes back to the problem I meant yesterday, if I want a continuous large map, I still need a huge blank map the same size on which I would add the different pieces of map right?
Or do you mean that each time I add an overlay I should 'replace' all my coordinates to get back in the center of my room. A little like a treadmill?

Quote from: lafouine88 on Sat 20/07/2024 21:25:18Or do you mean that each time I add an overlay I should 'replace' all my coordinates to get back in the center of my room. A little like a treadmill?

Indeed, more or less so, that idea is to have a smaller room and keep visuals moving sideways.

This may be implemented in various ways. It may move all the time as player moves (in which case your room may be only bit larger than the screen), or it may replace bigger chunks of the room when player reaches certain threshold.

The choice depends on various factors, including whether you are using AGS own pathfinding (walkable areas in the room).
Note that this may be easier to do in the upcoming AGS 4 update, where there's a pathfinding API which allows to use custom sprites as masks, and not rely on room itself.

Wow this seems really cool oO, thanks again
When is AGS 4 update planned for then?  :grin:  :grin:

Hi guys

So, overlays work fairly well I you're planning on doing big maps. The delay is almots imperceptible and it allows to save a lot of memory.

Basically what I've done so far is :

-I have 4 sprites, one for each part of the map and all the same size, which is also the size of the room (maybe not optimal but much easier to create the different 'parts' of the room), the edges are defined with a demi screen margin (my resolution is 640*400 so it's 200px from top and bottom and 320 on ech side).
-I created a draft room(same size) on chich I change the backgrounds to set my characters placement, walkable areas masks, objects... This is also the room in which I teleport useless characters when the part of the map changes.
-Then I created a function ( still getting better so I'll share when I'm finished) thats moves objects and characters in and out of the map(using the settings from previous room, and storing useless things in the same room), changes the map overlay, and teleports the player to the other end of the room (chen I'm on top I get to the bottom-1). This function gets triggered in Room_leaveBottom/LeaveTop etc.


Still I don't get how I import my walkable areas masks on new overlays. @Crimson Wizard  spoke of drawingsurfaces, but I didn't find how to transform tha into a real walkable area, and also (though I guess it's going to be the same method) how to change the walkbehind areas and regions.
Could you guys give me a hand here ? I feel like I'm getting close to a nice resolution :)

Thanks

Just to make sure: you're using AGS 4, right?

Quote from: lafouine88 on Wed 24/07/2024 16:46:15Still I don't get how I import my walkable areas masks on new overlays. @Crimson Wizard  spoke of drawingsurfaces, but I didn't find how to transform tha into a real walkable area, and also (though I guess it's going to be the same method) how to change the walkbehind areas and regions.

This is not done with overlays.
If you are changing areas in the room, there's GetDrawingSurface method for all of them:
https://adventuregamestudio.github.io/ags-manual/Hotspot.html#hotspotgetdrawingsurface
https://adventuregamestudio.github.io/ags-manual/Region.html#regiongetdrawingsurface
https://adventuregamestudio.github.io/ags-manual/Globalfunctions_Room.html#getdrawingsurfaceforwalkablearea
https://adventuregamestudio.github.io/ags-manual/Globalfunctions_Room.html#getdrawingsurfaceforwalkbehind

After getting a drawing surface, you may paint a new mask on them.

AGS 4 has slightly different functions.

Quote from: Khris on Wed 24/07/2024 18:33:15Just to make sure: you're using AGS 4, right?

No I was still on 3.6.1, I hadn't seen 4.0 was already out. So I'll get it to start with "^^ thanks

Quote from: Crimson Wizard on Wed 24/07/2024 18:50:07This is not done with overlays.
If you are changing areas in the room, there's GetDrawingSurface method for all of them:
https://adventuregamestudio.github.io/ags-manual/Hotspot.html#hotspotgetdrawingsurface
https://adventuregamestudio.github.io/ags-manual/Region.html#regiongetdrawingsurface
https://adventuregamestudio.github.io/ags-manual/Globalfunctions_Room.html#getdrawingsurfaceforwalkablearea
https://adventuregamestudio.github.io/ags-manual/Globalfunctions_Room.html#getdrawingsurfaceforwalkbehind

After getting a drawing surface, you may paint a new mask on them.

AGS 4 has slightly different functions.

@Crimson Wizard, what do you mean by 'painting' on it? Am I able to somehow use the import mask option to directly apply the mask shape to the drawingsurface? Because I cannot draw it using rectangles and circles, the walkable areas I'm planning to use depend on the terrain and elements of the map so it makes it drawable with the pencil tool, but not really using drawingsurface functions.
Or am I not getting what you suggest at all?^^

It looks like you need to do the following:

First, import a png that has a part of the walkable area (any color for the area, everything else transparent) to define the shape. Repeat for every part of the walkable area.

In game,
1. create a dynamic sprite (1) from the imported shape sprite
2. create a second dynamic sprite (2) and fill it with DrawingColor [AreaNumber] by drawing a rectangle to it
3. use CopyTransparencyMask to copy the transparency from (1) to (2)
4. get the drawing surface for the walkable areas, clear it, then draw sprite (2) to it

You obviously do this in a custom function, passing the area number i.e. color and sprite slot into it.

Quote from: lafouine88 on Wed 24/07/2024 19:22:09@Crimson Wizard, what do you mean by 'painting' on it?

I mean - import your world mask pieces as sprites, and then use DrawingSurface.DrawImage function to paint these sprites over room as location changes.

Quick code example, only to illustrate basic idea:
DrawingSurface* ds = GetDrawingSurfaceForWalkableArea();
ds.Clear(0);
ds.DrawImage(MASK_SPRITE);
ds.Release();

Unfortunately, there's a missing functionality in AGS 3.*, where it does not let you import 8-bit sprites into 32-bit games and keep them 8-bit (it converts everything to 32-bit). So if you are in 3.*, then you likely will have to resort to some workaround.

Khris seems to have a suggestion, although I did not test that myself.

In AGS 4.0 this may be easier, as engine lets you import and keep 8-bit masks as sprites, and use them in game as 8-bit.

There of course may be a different approach. For instance, you could try generating walkable or non-walkable areas (walls) from the background somehow, or from a custom data which describes obstacles. But this largely depends on how do you define your levels.

Quote from: Khris on Wed 24/07/2024 21:49:55It looks like you need to do the following:

First, import a png that has a part of the walkable area (any color for the area, everything else transparent) to define the shape. Repeat for every part of the walkable area.

In game,
1. create a dynamic sprite (1) from the imported shape sprite
2. create a second dynamic sprite (2) and fill it with DrawingColor [AreaNumber] by drawing a rectangle to it
3. use CopyTransparencyMask to copy the transparency from (1) to (2)
4. get the drawing surface for the walkable areas, clear it, then draw sprite (2) to it

You obviously do this in a custom function, passing the area number i.e. color and sprite slot into it.

Hi again
So I've tried this method but for some reason i'm always getting an error message. This is what I wrote :

DynamicSprite*ds2 = DynamicSprite.CreateFromExistingSprite(4177); ///sprite 4177 is a big rectangle the size of the room
 ds2.CopyTransparencyMask(4176); ////4176 is the shape i want for the walkable area

DrawingSurface* surfacewalk1 = GetDrawingSurfaceForWalkableArea();
surfacewalk1.Clear(0);
surfacewalk1.DrawingColor = 1;
surfacewalk1.DrawImage(0, 0, ds2.Graphic);
surfacewalk1.Release();
I get this error message https://freeimage.host/i/dIv9H42

Did I misplace a line or forget something here? It seems quite logic to me so I cannot find aything else^^

I wrote this from memory so I didn't realize the CopyTransparencyMask() method requires a slot.

Regarding your code, I assume you put this in a function? Which one?
Also, the error is the dreaded non-specific 0xC0000005 one, not sure what's causing this.

Quote from: Khris on Sun 28/07/2024 12:25:21Regarding your code, I assume you put this in a function? Which one?

I put it in a custom function that is called on the edges (leaveroom.bottom/top...), along with the overlays changes(and I ll also add here the walkbehinds and hot spots with the same method)

Hey guys
So I'm back from vacations and had time to think about a solution. Unfortunately, none of my not-so-brilliant ideas made it work. So I had to resort to the non elegant solution for walkable areas, which is : create many walkable areas and remove/restore theme according to the current map background. The reason I didn't want to use that is it creates many areas with various intersections (2^n -1, n being the number of parts of your map). So for my map that uses 4 different parts I have to manage 15 walkable areas, which is the maximum.
walkbehind areas will work the same, although by far not as tedious.

Thanks to everyone for suggestions and maybe in the future, a new version of the software will makes things easier :grin:  :grin:

Hello again "^^ "^^

This topic is running in all directions, I can change the title if needed.
Since it's the first time I try it (I first wanted to create a viable system for the rooms) I've just realized such a  huge walkable area slows down the game insanely. Do you guys have any piece of advice to smooth it? Like things I could do or should avoid doing when drawing the mask? When the whole map is covered in walkable area it's fluid, but it seems adding edges makes the system overload.

Thanks

The shape of the area shouldn't matter but composing it anew each frame will very much make a difference. However the whole point of doing this was to not have a massive room in the first place.

What exactly are you doing? Can you show relevant code?

You're right, it becomes hard to follow.

So, the idea was to build a big world in which the character can navigate on isometric view, like in Diablo. The map I created was 5200*16000 px for one area and I wanted to have as few "loading screens" as possible (to not break to much the rythm).
This room's size was too much for AGS limits so I first thought I would use smaller maps and use "setscreentransitioninstant" to navigate between each other. Problem was this created a lot of small pauses when you go from one room to the other, and this is not good for the pace of the game.
That s when I started this topic.

Initial idea you guys gave me was to use overlays to extend the size of the map. It's very good, there is a small loading pause, but it is very short, so acceptable. I thought a good balance between room size and the number of room changes was to divide the map in 4 2700*8200px rooms(a bit larger for the room edges to overlap the next one).
I created one room this size, 4 edges and this code (shortened version, the real one is more generic) :

function changement_zone(int j){
  // j exit direction (0 up, 1 down,  2 left 3 right)
 int s;
 int t;
if(j==0){ //up
  Zone_encours++; //some system to find the right sprite number for the next part of the map
 s=player.x;
  t=2599;
}
else if(j==1){ //down
  Zone_encours--;
  s=player.x;
  t=201;
}
else if(j==2){//left
  Zone_encours+=2;
   s=7871;
   t=player.y;
}
else{//right
  Zone_encours-=2;
s=321;
 t=player.y;
}

testmap=Overlay.CreateRoomGraphical(0,0,maptableau[Zone_encours].spritemap); ///the map sprite is found using an
testmap.ZOrder=0;
player.x=s;
player.y=t;


So far everything is ok.
Problems started with the walkable areas. Pretty much everything is in the discussion. I cannot use drawing surfaces to import my walkable areas (maybe because of the 8/32bit transformation. I had to stay on 3.6 because changing to 4.0 meant changing a lot of the code I've already written, and this seemed really too much to correct, I've worked the last 6 months just to create the RPG functions :s)

So, after trying many things I decided to go back to drawing manually the walkable areas,with intersections, and to remove or restore them according to the part of the room, something like that :

function changement_zone(int j){
  // j exit direction (0 up, 1 down,  2 left 3 right)
 int s;
 int t;

/////remove all the walkable areas
for(int x=1;x<16;x++){
RemoveWalkableArea(x);
}

if(j==0){ //up
  Zone_encours++; //some system to find the right sprite number for the next part of the map
 s=player.x;
  t=2599;
///just restores the appropriate ones
RestoreWalkableArea(1);
RestoreWalkableArea(5);  ///since walkable areas (1,2,3,4) don't overlap, it creates a lot of intersections that need to be separate walkable areas (1//2 , 1//3, 1//4, 1//2//3,1//2//4, 1//3//4 and 1//2//3//4)
RestoreWalkableArea(6); //1//2
RestoreWalkableArea(7); //1//3
RestoreWalkableArea(8); //1//4
RestoreWalkableArea(9); //1//2//3
RestoreWalkableArea(10); //1//2//4
RestoreWalkableArea(11); //1//3//4
RestoreWalkableArea(12); //1//2//3//4
}
else if(j==1){ //down
  //...
}
}


That is when I drew my first walkable area, and when I tried it, the character started to lag a lot.

That was just for the background, but while writing this I realized the problem could come from a separate function I made. And it does "^^
So this is the problematic function : The idea was to make the player able to leave the left button down to move the character(and not click every second) :

function mouse_continous_down(){
  if(mouse.IsButtonDown(eMouseLeft)&&GUI.GetAtScreenXY(mouse.x, mouse.y)==null&&Character.GetAtScreenXY(mouse.x, mouse.y)==null&&Object.GetAtScreenXY(mouse.x, mouse.y)==null){ ///the exceptions are so you can still interact with the world
  Room.ProcessClick(mouse.x,mouse.y, eModeWalkto);   
}
}

function repeatedly_execute()
{
mouse_continous_down();
}

When I comment out this function, it's ok, so the problem isn't with the walkable areas, but with this function "^^it freezes the game when I click on a non walkable area. I tried adding an exception :
function mouse_continous_down(){
  if(mouse.IsButtonDown(eMouseLeft)&&GUI.GetAtScreenXY(mouse.x, mouse.y)==null&&Character.GetAtScreenXY(mouse.x, mouse.y)==null&&Object.GetAtScreenXY(mouse.x, mouse.y)==null){
if(GetLocationType(mouse.x, mouse.y) != eLocationNothing){
  Room.ProcessClick(mouse.x,mouse.y, eModeWalkto);
}
}
}

But it blocks the continuous function. Any ideas?

And many thanks for your patience -_-

(https://i.postimg.cc/y6M9VV3P/fofo.png)

You're basically telling AGS to find a walkable path 40 times per second. You can try to lower that number like this:

int frameCounter;

function repeatedly_execute()
{
  frameCounter = (frameCounter + 1) % 5;
  if (frameCounter == 0) mouse_continous_down();
}
This should reduce the lag but have little effect on the button processing.

Solving this in an optimized way probably requires completely custom walking / walk cycle code.

Quote from: lafouine88 on Wed 21/08/2024 10:45:24I cannot use drawing surfaces to import my walkable areas (maybe because of the 8/32bit transformation.

So, I tried that and there seems to be a bug in the engine, when you try to draw non-8bit sprites on walkable surface it corrupts the game memory. This must be fixed first, and after that see again if it might work at all.

There's also a chance that this may be done differently, if DynamicSprite.CopyTransparencyMask works between sprites with different color depth. If it does then:
* create dynamic sprite from walkable area's drawing surface (the sprite should be 8-bit)
* fill the sprite with color 1
* use DynamicSprite.CopyTransparencyMask to copy only transparency from the imported sprite to 8-bit sprite
* paste 8-bit sprite back onto walkable area.


I will have to find some time and experiment with this.

If you just need to click and hold have the character move in the direction that the mouse is, you don't need to use the pathfinder at all, you just draw a line and end it in the mouse or where there is no walkable area, whatever comes first, but you can only test the amount the character can walk in a frame, which are very few pixels. Then the only one using the pathfinder are the monsters and they can be pretty easy to limit since they won't be recalculating on every frame.

The other approach is to do something like this : https://ericoporto.github.io/public_html/surviving/v6/

Essentially when you click and hold it waits the character finish walking before telling it to walk again but you can click in the middle to interrupt the walk.

Thanks for your replies :)

Quote from: Crimson Wizard on Wed 21/08/2024 13:02:51* create dynamic sprite from walkable area's drawing surface (the sprite should be 8-bit)
* fill the sprite with color 1
* use DynamicSprite.CopyTransparencyMask to copy only transparency from the imported sprite to 8-bit sprite
* paste 8-bit sprite back onto walkable area.

Maybe I misunderstand, but the problem is the first step here. When I import the 8bit-mask (either fom a pixel art software or from an AGS exported mask) it puts it into the game as a 32bit file. Even if I untick the top left box when I import the sprite. I tried using transparency mask (I put the code a few messages above), it did seem like a promising solution but there was some problem I couldn't understand :/

Here are two videos I wanted to share (disregard graphics, sorry for the mixed walking view^^):
https://streamable.com/4vs8ht (https://streamable.com/4vs8ht)
Here, I have cut walkable areas, and as you can see at the end, it starts lagging when I click on the non walkable part. But for the rest (and the second video points it even more) it walks quite well.
https://streamable.com/ow9g6y (https://streamable.com/ow9g6y)
Here I just put a full walkable area and it's OK.

The idea is to feel a good handling of the character. that's why I think the second thing you suggest @eri0o is not appropriate here. For the first part : is this a suggestion to create a custom walking code? Or an explaination of how the ags engine works ? Because if ags doesn't calculate 40 times/second the path, I might leave it as is, otherwise I'll take @Khris code to divide this number by 8^^

@Khris I'll give the custom walking code a try, because it's true I feel this way is unelegant and suboptimal. It does work well on my computer but maybe on lower performance ones it would lag.

I made a mistake, CopyTransparencyMask does not work if sprites are of different color depth. Although I think that might be technically possible to do, but AGS does not support that at this time.

Drawing a 32-bit sprite over a 8-bit mask is still possible (after I fixed it to not cause memory corruption).
But the problem is that colors have to very closely match the game palette. This is necessary to make the engine convert 32-bit color to palette indexes correctly.

So when you draw your mask sprite you must have colors exactly as game palette colors from slots 0-15.

This works, sort of.

But then I met another problem. Color 0 (no area) cannot be achieved this way for some reason. Block color always gets converted to index 16, because index 0 serves a special meaning (transparency).

I tried to do this in two steps: choose certain different color to be the "non walkable" area, then try to remove it using RemoveWalkableArea(N) in script.
But calling RemoveWalkableArea causes room to completely restore its walkable area to original, overwriting anything that you painted over it.

It is apparent that this was not very well tested, and has a lot of limitations.

I added this ability because someone suggested, but I guess they never tried to work with this either.

@Crimson Wizard if the person is me, I just never used the masks drawing with loading a file, but I drew them in script. Also I needed more than it was possible by the number of walkable or whatever areas (I remember I had an issue on this at the time). In the end I just faked everything using regular dynamic sprites - which also gave me more bits.

@lafouine88 custom walking code is not as hard as it looks, it can be done, but you can also leverage walk straight I think. I have a module (controlz) that has keyboard walking, it may not be hard to use it as base for something that would move the player. If you are using ags4 it has also both exposed pathfinder but also a character can take a path (array of points) and move accordingly.

In your video it looks like you just need to make the character walk in the direction of the vector between the character and the mouse.

Btw do you have other solid characters or things that constantly change that you need to keep in check when moving the character or are other character/objects non-solid? I have a pathfinder plugin that is just the AGS plugin exposed but it gives the option to only generate the nodes once and then you calculate the path as you want.

AGS pathfinder in the engine (not in my plugin) will instead eat the entire walkable area mask every frame that you ask for a path (but only once per frame) to account to possible other solid objects and characters, that can also move, that's why it's not fast in your big map, it's not the actual pathfinding itself.

Here: https://www.adventuregamestudio.co.uk/forums/modules-plugins-tools/plugin-ags-pathfinder-experimental-0-1-0/

Quote from: Crimson Wizard on Wed 21/08/2024 23:34:48But then I met another problem. Color 0 (no area) cannot be achieved this way for some reason. Block color always gets converted to index 16, because index 0 serves a special meaning (transparency).

Alright, I found the way.

I had to do more fixing in the engine for this to work, not exactly related to room masks, but to DrawImage command when a sprite is of higher color depth than the surface. There will have to be a new 3.6.1 patch with this fix.
I might post a fixed 3.6.1 engine here if someone wants to give it a try:
https://www.dropbox.com/scl/fi/d3zjq91yrhddt9k3u7hrt/acwin-3.6.1-fixdraw32on8.zip?rlkey=yicgf48ixz7xzs2gnpfhrjweo&st=5egu0wqk&dl=0

Anyway, the solution is following:
1. Draw a bitmap in your paint software. This may be a 8-bit bitmap, or 32-bit bitmap. That does not matter in 3.6 because 3.6 converts everything to game's color depth, as been noted. So you might as well save it as 32-bit.
2. What is important: all the colors that you use in this bitmap MUST MATCH THE GAME PALETTE colors in slots 1-15. Check out your game palette in "Colours" tab in the editor. This must be done to make those colors match the walkable areas 1-15 when you will draw this sprite in script.
3. Another important thing: you cannot achieve "area" 0 on this sprite, unfortunately, because its treated as a "special palette color" by AGS when converting a sprite. Because of that the "walls" must be done as a transparent color instead: you should import this bitmap and tell to set the wall pixels as transparent pixels. They will become "magenta" after import, and that's fine.
4. If you followed these rules correctly, you will now be able to draw this 32-bit bitmap on a 8-bit room mask in 2 steps:
- clear the mask with color 0.
- draw the sprite on it.
The "clear" step is required because the sprite has "walls" as transparent color, so they won't be drawn.
  DrawingSurface *ds = GetDrawingSurfaceForWalkableArea();
  ds.Clear(0);
  ds.DrawImage(0, 0, SPRITE_NUMBER);
  ds.Release();


Quote from: eri0o on Thu 22/08/2024 00:15:28@Crimson Wizard if the person is me, I just never used the masks drawing with loading a file, but I drew them in script. Also I needed more than it was possible by the number of walkable or whatever areas (I remember I had an issue on this at the time). In the end I just faked everything using regular dynamic sprites - which also gave me more bits.

No, it was @Snarky originally who mentioned this, but maybe this was just an idea, and he did not need it for himself.

@lafouine88 What eri0o suggests is basically to try using player.WalkStraight instead of Room.ProcessClick(... eModeWalkto).

WalkStraight command should be much faster than regular Walk, because it does not search a path, but only tests the direct line in front of a character and stops if a wall is met. This works like "raytracing".
See https://adventuregamestudio.github.io/ags-manual/Character.html#characterwalkstraight

Other than that, you may replace AGS commands with your own that:
- Animates the character
- In rep exec moves the character into the direction pointed by the mouse by directly changing character.x,y properties with certain speed.
- Tests for a wall ahead.

That's not too hard to do, perhaps try that if WalkStraight did not solve the problem.

Quote from: Crimson Wizard on Thu 22/08/2024 01:01:41No, it was @Snarky (https://www.adventuregamestudio.co.uk/forums/profile/Snarky/) originally who mentioned this, but maybe this was just an idea, and he did not need it for himself.

I've no memory of this (and I'm not 100% sure exactly which feature you are referring to), but assuming I did it was probably either in response to some challenge another user had faced, or with the idea that it could be used for something interesting (possibly a module to edit walkable areas etc. in-game; in-game editing is something I've long seen as a promising avenue to explore). But no, I've never used it.

So, 'walkstraight' is much better yes, Thanks !! All my characters were already set to 'not solid' to help fluidity so this was a good first part  :grin:  :grin:

@Crimson Wizard Do I need to install the engine plugin you linked? I tried what you said, carefully following the steps but it still won't work. I'm not sure if it's my bmp colors that are not good or my coding (I just copied what you wrote) but something is wrong. I understand you tried it yourself, could you send me the .bmp you used ? If I can get it to work then it's just my image format that's not right :s

Quote from: lafouine88 on Thu 22/08/2024 12:46:53@Crimson Wizard Do I need to install the engine plugin you linked? I tried what you said, carefully following the steps but it still won't work. I'm not sure if it's my bmp colors that are not good or my coding (I just copied what you wrote) but something is wrong. I understand you tried it yourself, could you send me the .bmp you used ? If I can get it to work then it's just my image format that's not right :s

That's not a plugin. I linked a patched engine executable, that should be used instead of the current one when compiling the game. If you like to use it, copy acwin.exe to the Editor's program files, overwriting existing acwin.exe (or rename existing one to have it as a backup).

Following my steps won't work without this patched engine, because there are bugs in the current official version that will prevent them from working correctly.

Did the walk straight use work? Great to hear.

Shoot me a build of your game sometime - I am just curious and have no time for more than writing random bits of text in the forums, but still looks like you are making a nice thing to play.  :)

Quote from: eri0o on Thu 22/08/2024 16:08:12Shoot me a build of your game sometime - I am just curious and have no time for more than writing random bits of text in the forums, but still looks like you are making a nice thing to play.  :)

I will as soon as I'm done with the test map :)

@Crimson Wizard Sorry, I would love to close this thread but I still havent' managed to make things work. The plugin you sent gets deleted by antivirus and when it doesn't it still won't work. How did you make the colors the same as 8 bit palet ? You just need to copy RGB numbers right? Could you send me a bmp that works for you so I can try it ?

Thanks, almost there...I hope :)

Quote from: lafouine88 on Fri 23/08/2024 13:12:04@Crimson Wizard Sorry, I would love to close this thread but I still havent' managed to make things work. The plugin you sent gets deleted by antivirus and when it doesn't it still won't work.

This is not a plugin!..
Can you tell what do you do, step by step, and what exactly happens as a result?

Quote from: lafouine88 on Fri 23/08/2024 13:12:04How did you make the colors the same as 8 bit palet ? You just need to copy RGB numbers right? Could you send me a bmp that works for you so I can try it ?

Yes, I copy RGB values from palette slots 1-15.

Here's an example of bitmap that worked for me:
https://www.dropbox.com/scl/fi/tc5fjtdx0gn8smuxgirq1/random.bmp?rlkey=qpnzknenm4osyekw9zhsgieq6&st=tkgqx7i5&dl=0
it has 2 colors: white and blue, should be imported telling that white color is transparent (for example - set transparent color from top-left pixel), then blue part becomes mask area 1.

Quote from: Crimson Wizard on Fri 23/08/2024 14:20:29This is not a plugin!..
Can you tell what do you do, step by step, and what exactly happens as a result?

So:
-I dl your .exe (definitely not a plugin :p) and ,after renaming the initial one, extracted it to my adventuregalmestudio 3.6.1 root folder.
-I imported the bmp file, and ticked transaprency top left pixel. Nothing else.
-I removed the walkable areas of the room
-at room load set this code :
   

DrawingSurface *ds = GetDrawingSurfaceForWalkableArea();
 ds.Clear(0);
 ds.DrawImage(2005, 1420, 5760); ///This is with your file,since it's just 320*200 I could not put it at 0,0 or it would be too far from my character so I set it manually so the blue area is below the character.
 ds.Release();


The game loads, but my character cannot move

Quote from: lafouine88 on Fri 23/08/2024 15:27:32The game loads, but my character cannot move

Do you have these debug controls in the on_key_press somewhere?

  else if (mod & eKeyModCtrl)
  {
    if (keycode == eKeyA)
    {
      // Ctrl-A will show walkable areas
      Debug(2, 3);
    }
  }

If not, try inserting this code.
And then press Ctrl + A in this room, and see how the walkable areas actually look like in game.

Do you call "remove" or "restorewalkablearea" somewhere in script?

Hi, I was on the road this last days so I couldn't try earlier, as eager as I was^^

So using the debug mode definitely helped, it semms there was a problem with the coordinates. I don't know why but when I set it to map coordinates like 2000,1400 it didn't show anywhere, but when I corrected to player.x-150; player.y-70 (which led to the same values) it worked.
So I stil have a bit of set up to work on, but the core of the problem really is solved. Thanks a million to everybody, especially to @Crimson Wizard for his patience.

As soon as I have a clean code I'll edit my post with the correct way to make this :) :)

Quote from: lafouine88 on Tue 27/08/2024 21:44:47So using the debug mode definitely helped, it semms there was a problem with the coordinates. I don't know why but when I set it to map coordinates like 2000,1400 it didn't show anywhere, but when I corrected to player.x-150; player.y-70 (which led to the same values) it worked.

This is not expected, there should not be any difference if the values are actually same. Can you post the code which you used?

Hello again

So after a few tries, I realized there was a 'RemoveWalkableArea()" lost somewhere in my messy code. I think it's @eri0o who told me in another post that the hard part was to keep your code and functions clear... "^^
When I tried earlier this week it was on another computer with an older code(and no removewalkablearea) that's why it worked there and not on my home computer. After all coordinates were not a problem, sorry for the disturbance @Crimson Wizard -_-

One last thing, since i'm now working on walkbehind, how do you change the baselines ? I went for " SetWalkBehindBase(1, X)" since I figured the drawing surface applied to walkable area1 because of the blue color but it doesn't seem to be the case.

So, I found that after painting walkbehinds engine does not update the walkbehind "cuts", so they would never cover the character.
This is another thing that was not tested properly.

All this feature is filled with mistakes, I must retest it fully, for all region types, and patch in 3.6.1

Thanks for the reply. My project is planned for christmas 2025 so maybe by then the engine wille be patched and I can include the walk behinds.

Thanks everybody for your help, I will edit the post soon to sum up the elements we gathered :)

See you

Here's an updated version, with walk-behinds problem fixed:
https://cirrus-ci.com/task/6249807860203520

(this is a full editor download from our build server)

Works great. Many, many thanks  :grin:  :grin:  :grin:

EDIT : One small thing though, the loading time (during the transition and new setting of the overlay,and drawing surfaces) is a bit longer since I added the new code for drawing surface. I downloaded the executable file in the "install" folder, but maybe I missed something ? Or is it just that walk behind are longer to settle?

Quote from: lafouine88 on Sun 01/09/2024 19:50:28EDIT : One small thing though, the loading time (during the transition and new setting of the overlay,and drawing surfaces) is a bit longer since I added the new code for drawing surface. I downloaded the executable file in the "install" folder, but maybe I missed something ? Or is it just that walk behind are longer to settle?

Every operation takes time, painting a very big image takes noteable amount of time, plus engine has to parse pixels and "cut out" walk-behind sprites.

If the operation is the same, but takes longer than in the previous version unexpectedly, then that's something to investigate. I could not tell whether this is the case from what you've said, if it is, then please clarify that?

Speaking of walk-behinds in particular, if you want to speed things up then you may just create game objects or room overlays with background portions on them instead. Then you won't need to use the walk-behind mask. They will still take time to load up, but engine will not have to do copy-pasting on a surface, and then cutting things out again.

Quote from: Crimson Wizard on Mon 02/09/2024 11:49:44If the operation is the same, but takes longer than in the previous version unexpectedly, then that's something to investigate. I could not tell whether this is the case from what you've said, if it is, then please clarify that?

Well in the previous versions, adding regions or walkable areas didn't slow down anything (compared to just changing the background overlay), it's really when I added the walkbehind area that I noticed a change...

Quote from: Crimson Wizard on Mon 02/09/2024 11:49:44Speaking of walk-behinds in particular, if you want to speed things up then you may just create game objects or room overlays with background portions on them instead. Then you won't need to use the walk-behind mask. They will still take time to load up, but engine will not have to do copy-pasting on a surface, and then cutting things out again.

...But I think using overlays is much faster, not to mention it saves the drawing time which can be quite long, so yeah I'll definitely go for that :)

Thanks...again... "^^