Objects per Room limit, not too specific problem

[X-Heiko]

So, I know that the object limit is quite high (40), compared to older Versions of AGS. I also know that AGS is intended to be a program for coding Adventure games, which is not what I'm trying to do (fully, that is, but that doesn't matter.).

I have of course searched the forums on this matter, but similar questions were always answered on either very old versions of AGS or in very special cases, giving work-arounds for given cases.

Now to my problem: I'm making an adventure which is rich in minigames. These minigames are intended to be somewhat complex. An object limit of 40 is a little too little for me because there are random riddles to be made with a lot of combinatoric possibilities of the exact outcome of the riddle itself.

I also know of the technical limitations as Object data is saved in an array, which means every extra object limit increase increases memory usage. That doesn't quite tell me why I can't increase the array capacity on my own, as the author. A simple "Warning: try to keep the object limit small" message in the preferences window would do the trick. Using a list instead of an array might be too slow, but it would be flexible for sure. Of course, giving solutions is utopian, especially with no knowledge of the source code whatsoever. Sorry if I'm sounding arrogant, I'm really not trying to do so.

Anyway, I suggest the object limit to be raised. In my case, I'd need about 60.
I would also like to suggest multi-dimensional arrays to be implemented in AGS. It requires a bit of complex mathematic structure to handle a 8192 elements large array which I wouldn't expect from a typical AGS user (which doesn't mean that I see myself as anything better.).

IF however I can only expect a specific piece of help, here's my problem:

I'm making a minigame where 12 logic gates (AND, OR, NAND, NOR, XOR, XNOR are the possible gate types) are arranged in 3 logic levels of 4 parallel gates each. There are 8 input bits and 4 final output bits. The logic levels are randomly connected and an output combination is given. The player has to figure out a combination of input which has the given output combination as a result. That's 8 objects for input bits, 4 for output, 12 for gates and 32 pieces of connective wire that each can be assigned one of 8 graphics, illustrating the connection modes. That's 56 objects, 12 of which could, if necessary, be replaced by buttons.

It's very difficult to imagine by text. If anyone is seriously interested in helping me specifically, I can send a few graphic examples.

I'd like to thank you for helping me in advance.

[Pumaman]

Well, something like this might be easier done with the Drawing Surface routines to draw directly onto the room background, rather than using objects -- especially if you have connective wire that needs to go in various different directions and would be easier drawn with DrawLine commands than having tonnes of different sprite images.

I would also like to suggest multi-dimensional arrays to be implemented in AGS. It requires a bit of complex mathematic structure to handle a 8192 elements large array which I wouldn't expect from a typical AGS user (which doesn't mean that I see myself as anything better.).

Yes, this has been requested before; thanks for your request. However it's fairly easy to create your own accessor functions to allow you to pretend that a single-dimension array is actually a multi-dimensional one ... monkey_05_06's module is an example.

[X-Heiko]

Wow. I didn't know there's a drawing command. I've not yet read into drawing surface routines but what you say sounds helpful AND a lot more like what I originally intended to do. I'll look into that, thanks big time for the help!

Yeah, of course it's possible to simulate such big arrays with tricks, but it's user-friendlier to just have multi-dimensional arrays. I am working with a mixed-base numeric system to address the array.

EDIT: Sorry for the hasty post. I've quickly overlooked it and DrawImage would be a somewhat friendly solution to it all, but my code is still based around the connection wires having an integer property at which they're addressed from inside the code. I'd need to re-program the visualization algorithm which is why more objects would be a lot more comfortable to me, but that doesn't justify "requesting" an update for AGS. I'll try to see to finding a work-around. Thanks though!

[Matti]

I was about to ask a similar question. I was going to remake a game I started some years ago using Turbo Pascal. I had some problems and stopped the project. It's a side-scrolling space-shooter and I know that it can be done with AGS. There's just this one level where the player encounteres a minefield... with about 3000 mines shown at once (some of them are just one pixel wide). Of course the object limit doesn't allow that but most of the mines don't need to be objects since they're just background fillers to create a nice 3D-effect.

Well, I know nothing about Drawing surface thingies yet, but before I get into it I just want to know if something like the following screenshot of my old game would be possible. I'm afraid that even if it would be possible, it would be too slow...

Only the largest mines are supposed to be objects:

[X-Heiko]

Yesterday, I took a look at the link Pumaman posted. Assuming that you have only your starship and the mines (Can you shoot? Then let's just assume we have 5 projectile objects or "others"), then you can use about 30 mines without problems. The rest would be background.

And, as far as my understanding of it goes, it would definitely NOT slow down the game, it could increase loading time at best. In short you convert the background into a Drawing Surface, then stick a lot of little mines in the image (could even make them random) and THEN give the order to release your changes into the actual background. There is not 3000 little objects, there's just (up to) 3000 iterations where mines are being pasted into the background. You could do it even more elegant and just use layers - larger pictures with a few hundred mines each. That would mean 6 or so additional lines of code, each not much more CPU intensive than loading the BG into the video memory. Hell, you could even make ONE single background image, but then - why not just include them in the background image? Or did you mean parallax scrolling?

You can't excessively slow down the game with too many objects because their number is limited.

For parallax scrolling, you could yet use another trick. Get each mine of the same size into one sprite, a big layer so to speak. Let them move with differring speeds, faster for large mines, slower for small mines. That would still only be 4-5  additional objects (I can't quite make out how many different mine sizes you've got there). If the large objects slow down too much, you could still use a refreshing algorithm in the "repeatedly execute" function, which would go something like "On every game cycle: Change the background of the room to [picture with no mines]. Make it a drawing surface. Depending on the position of the player, draw [picture with smallest mines] on (player's X coordinate / large number). Then draw [picture with second smallest mines] on (player's X coordinate / less large number). Then, Then, Then draw [picture with largest non-object mines] on (player's X coordinate / smallest number), then release the changes." The Y coordinate would have to be constant and same for all.

A possible result would be: Let's say the player flew a bit and is at X = 200. Given the number 10, 7, 5, 3, 2, the mine layers would have their left border at 20, 28, 40, 66 and 100. That's only a possible example and I'm not sure whether it's even a good idea, but you may want to try it. Drawing Surface is actually really helpful.

[Matti]

Yesterday, I took a look at the link Pumaman posted. Assuming that you have only your starship and the mines (Can you shoot? Then let's just assume we have 5 projectile objects or "others"), then you can use about 30 mines without problems. The rest would be background.

Yeah, something like that. But the ship's shield, some missiles and explosions would have to be objects too I guess. But, well, I could do it with about 20 mine objects if neccessary...

In short you convert the background into a Drawing Surface, then stick a lot of little mines in the image (could even make them random) and THEN give the order to release your changes into the actual background. There is not 3000 little objects, there's just (up to) 3000 iterations where mines are being pasted into the background. You could do it even more elegant and just use layers - larger pictures with a few hundred mines each. That would mean 6 or so additional lines of code, each not much more CPU intensive than loading the BG into the video memory. Hell, you could even make ONE single background image, but then - why not just include them in the background image? Or did you mean parallax scrolling?

Ah, well, the mines in the background are supposed to move leftwards, each "layer" (there were 8 in my old game - 5 in the background, 2 in the foreground) with a different speed. Is that possible?

You can't excessively slow down the game with too many objects because their number is limited.

Yes, of course. But - if possible - I would have to draw the (non-object-) mines into the background every gamecycle in order to have them moving. I thought that could cause a slowdown..

For parallax scrolling, you could yet use another trick. Get each mine of the same size into one sprite, a big layer so to speak. Let them move with differring speeds, faster for large mines, slower for small mines. That would still only be 4-5  additional objects (I can't quite make out how many different mine sizes you've got there). If the large objects slow down too much, you could still use a refreshing algorithm in the "repeatedly execute" function, which would go something like "On every game cycle: Change the background of the room to [picture with no mines]. Make it a drawing surface. Depending on the position of the player, draw [picture with smallest mines] on (player's X coordinate / large number). Then draw [picture with second smallest mines] on (player's X coordinate / less large number). Then, Then, Then draw [picture with largest non-object mines] on (player's X coordinate / smallest number), then release the changes." The Y coordinate would have to be constant and same for all.

Yeah, I thought of something like that. I didn't quite understand everything but it sounds like it would be possible.

Ah, well, I should just check the manual and try around a bit. Thanks for the answer.. So here are some screenies of my old game, scaled down from a 1024 to a 640 resolution:





And all the mines in their original size:

[X-Heiko]

The rocket ammunition gauge indicates you're from Germany! That's actually funny, because I'm from Germany, too.

The Surface Drawing wouldn't allow you to put mines in FRONT of your ship, so the parallax scrolling method only works under the assumption that the largest mines are the game-relevant ones.

About the slow-down: You'd just have to try it. I don't know the source code well enough to give you an exact estimation of processor usage, but I think, more than the number of mine layers, the absolute size of your background in pixels is the important factor. I'm no professional, but loading a larger picture into the video memory is, depending on color depth and compression (i.e. file size). Seemingly, your background is quite a large bitmap, and "only" 20 mines for a big minefield is a bit too little I guess. One solution would be to let the mine field consist of multiple shorter levels. Another idea would be not to "destroy" mines after they leave the playfield or collide with the player, but to just change their position back to the front. That way you could have 20 mines on screen at once, not necessarily 20 mines at all. But if you, for example, intend the background (with 5 background mine layers) to have, say, a few thousand pixels in width, that would be 6 huge bitmaps to load every cycle.

I guess you can only experiment. If you want to talk to me in German so I can explain a few things easier, mail at x-heiko@skullbyte.de

[Matti]

The rocket ammunition gauge indicates you're from Germany!

Well, it's not too funny because quite a few Germans are wandering around this forum..

That's actually funny, because I'm from Germany, too.

Yeah, I thought so. "Heiko" sounds quite german  .

The Surface Drawing wouldn't allow you to put mines in FRONT of your ship, so the parallax scrolling method only works under the assumption that the largest mines are the game-relevant ones.

Yes, I'm aware of that.

Another idea would be not to "destroy" mines after they leave the playfield or collide with the player, but to just change their position back to the front. That way you could have 20 mines on screen at once, not necessarily 20 mines at all.

That's exactly what I did when making the game with Pascal... But I'm afraid 20 mines were still insufficient. Back then I used 50 mines at once and that was a good amount. I hope CJ will raise the object limit once more in the next version...

I guess you can only experiment. If you want to talk to me in German so I can explain a few things easier, mail at x-heiko@skullbyte.de

Yeah, I will see if a can get this thing to work. Thanks for the offer, it's appreciated. I'll mail you in case I get problems. On the other hand I think I won't test it soon since I'm working on another, more serious project right now. I just wanted to know if something like that minefield would be possible using the RawDraw-functions before getting into it.

[X-Heiko]

Well, come to think of it, you could draw the background mines using 8 objects, each object being a big layer. Would also solve the foreground mines problem. However, if you really need this many mines at once, you'd still have to figure something out.

Fun thing is: My name is not actually Heiko.