Lets make a dynamic array function

[C-Dawg]

Title says it all.

The biggest thing ZScript lacks is the ability to handle arrays. This is a huge problem in making code scalable and prevents scripters from reasonably working with large amounts of data.

My interest is in enemies that produce "bullet hell," or dozens of shots on the screen at once. I don't have enough FFCs to make each bullet and FFC, but I could use draw functions, integers, and a check for Link's location to simulate FFCs moving around. Which would be great, but without arrays I have to make perhaps hundreds of ints and then tediously copy and paste them all into one long, convuluted code.

With arrays, this would be much easier because I could stick the whole shebang into a for loop. It just steps through the integer variables determining the location of each projectile and draws them accordingly. (With structures, this would be even more slick, but I digress.)

I'm at a loss as to how to code an array. Even a simple linked list requires the ability to instantiate, which I don't think ZScript can do. So I post this thread in the hopes that some data structures folks can help out. Anyone know an algorithm for making an array out of functions available in ZScript?

For now, I'm going to simulate what I need using the only dynamic array provided in ZScript - the list of enemies on the screen indexed by the order in which they were spawned. So I get a dynamic array consisting of enemies, and I can hide data in their hit points. (For instance, enemy1->HP could be XXXYYY, where X is the projectiles' X coordinate and Y is the projectile's Y coordinate). But this has some serious limitations: (1) nothing can die or the index gets shifted; and (2) large numbers of enemies slow my scripts down to a crawl due to collision checking.

EDIT: Upon reflection, the items on screen also make up a dynamic array... but items don't have internal integers like hit points and they react unfavorably with the player.

So... any thoughts?

[Gleeok]

Heh That's funny, I was just messing with this about a month or two ago. Here's the thread which was invariably a result of. http://www.armageddongames.net/forum...d.php?t=100980

I kind of gave up on it though, mainly due to the reasons you already listed. I had 25 ffcs on one screen used as "bullets" and that wasn't nearly enough however. Yes, arrays or the ability to use more than 32 ffcs would be nice, I agree.

I did start up a script though to try and implement drawtiles the way an ffc would work, tried using a crapload of int, but quickly decided that it'd be way too much friggin code to proceed in that way. Not to mention, fuck that's confusing to debug.

Where i'm at with this now is "simple" bullet pattern code, such as an ffc projectile splitting into eight drawtiles (16 integers), or a drawtile that simulates rapid fire ffcs moving at Vx or Vy only which is not too complex. Basically getting a repetoire of copy/paste reusable code rocking to start.

I really could use some insight on this myself actually.

[DarkDragon]

Arrays and a true heap are both on my todo list for the next revision of ZScript.

[C-Dawg]

So I take it there is no way to implement an array using the functions available to us in ZScript?

I've been working with the enemy list, but I can't get it to cooperate. I'm probably screwing up with the masking functions. I tried godel numbering, too, but i don't think we have a modulus function that works.

[DarkDragon]

Something's buggy with %?

There are several built-in arrays you can use in the meantime; one of the easiest is just the combos on a random player-unvisitable screen.

[C-Dawg]

Ah, I didn't even think about using combos on a non-visted screen. That wouldn't be dynamic, though. I guess one could use an entire map, that should be plenty of data...

x location of first shot = map 100, screen 00, 1st combo
y location of first shot = map 100, screen 00, 2nd combo

then the loop marches on by adding 2 to each combo each iteration, bumping ahead to the next screen when it hits the last combo.

What's the speed of accessing/writing combos on another screen compared to manipulating enemy hit points?

As for % ...

Perhaps it does work and my algorithm is wrong. What I was doing was Godel numbering an enemy's Vx, Vy, Vx sign and Vy sign using 2, 3, 5, and 7, then putting the resulting value in enemy->HP. It can't be more than five digits max (assuming Vx and Vy are capped at 4) so I thought I was good to go. I then factor the HP value by checking HP % 2, or whatever prime I'm on, and then increment enemy->Vx each time I find HP % 2 = 0.

But it doesn't seem to work. Enemy->Vx never increments.

It's pretty complicated, so I guess it's likely I did something wrong. At a glance, I didn't see anything so I assumed % wasn't fully implemented yet.

Perhaps another step in error was my attempt to ensure that Vx is an integer before I load it up. Rationals will gum up the coding. I did this:

Vx = Vx & 1.00000;

In an attempt to zero out the significant figures right of the decimal. But maybe this is bitwise and doesn't work with integers...?

P.S. Gleeok, I got swarms of bullets (50 or more) working nicely, but I have to keep track of the general movement pattern and I can't yet embed Vx and Vy into each bullet enemy individually.

[Gleeok]

Hehe...using screen combos as data for enemy attacks. Why that's not apparently obvious for some reason....And it seems C-, that you've progressed a bit farther than I have on this too. I'm curious as to what the code looks like for accessing this screen combo array and how much easier it is to keep track of all the variables in the end. I did manage to whip up something, however, another oversight revealed another annoyance; How are you keeping track of bullets that hit Link? I'm thinking right now something like "who wants the bullets to disappear after Link gets hit anyway."

[C-Dawg]

How are you keeping track of bullets that hit Link? I'm thinking right now something like "who wants the bullets to disappear after Link gets hit anyway."

Ah, I'm not. I didn't go with the "integers-draw functions" solution. I went with the "enemies" solution.

Essentially what I do is put enemies on the screen and tag what number they are (the boss's hit point enemy is No. 1, the rest are Nos. 2 - 52). The enemies get stashed off screen normally. Then each frame the game checks whether each enemy is on the screen. If so, the game adjusts the enemy's X and Y coordinates according to the boss's current state. The boss state code, in turn, only has to move the enemies somewhere on the screen and they take off.

So, for instance, in state 1, the code bumps each enemy's x by:

enemy->x = enemy->x + 2*Sin((360*i)/50);*

where i is the enemy's index number.

The reason I'm doing this is that because enemy objects exist in an array on the screen, so long as no enemies die, I can access them all in turn with a simple for loop rather than copying and pasting code that would move a bunch of draw functions.

I'm not clear at all on whether updating ints, using draw functions, and checking link's location is faster than writing to an enemy's x and y, though. Plus, I can't vary enemy hit boxes, so I can't make really small bullets this way.

My current hurdle is this. I don't want to control enemy movement only based on the enemy's index number, i. I want to be able to store Vx and Vy somewhere so they each move independently and I can treat them like FFCs. For that, I need to effectively encode Vx and Vy in their hit points or somewhere else, like screen combos.

Suprisingly, 50 enemies don't lag my game too much on my system. I bet more would, though, so I'm thinking of modifying my custom weapon code so it only checks the first 25 or so enemies for damage. Any more than 25 enemies on the screen, and you can safely assume some of them are bullets so it doesn't matter you're not checking them for collisions.

* = Where does this function come from? Well, Sin(t) smoothly sweeps all the values from -1 to 1 and back again while (t) varies from 1 to 360. So I change the index number i to a number from 1 to 360 according to the proportion: i/50 = x/360. Then I multiply to speed it up, and presto.

[DarkDragon]

Access speed should be comparable, ie, both are just a memory dereference. To make it dynamic, pick a value you treat specially as a "NULL" (no more data) symbol, and you can manipulate the array like you would a statically-allocated string in C.

For what you're doing, ideally you want an array of NPC pointers, instead of plain integers, but I don't think that's possible at all currently.

[C-Dawg]

Yes, an array of NPCs would be best. But we already have that, as long as we control how many enemies are on the screen. Enemies above the ones being manipulated can die, but none below can, or the index goes to shit.

I think my task tonight will be to code a series of generic array functions. I'll choose a map to dedicate to data storage, then code functions to:

retrieve data at an index in the map;
write data to an index in the map;
write data to the end of the map;
return the size of the array;and
zero out the data in the map.

Shouldn't be to hard to do, actually. Tricky bit will be decoding the index into Screen and Combo IDs. Then you'll have at least one array of ints for general use.

What value do you suggest I use for NULL? The highest possible combo, perhaps? And maybe return an error of some kind of the player tries to write that int to the array?

Oh crap, I just realized something else. I can only store positive ints this way. So I still need a sign bit next to each integer. God dammit... I'm going to turn a map into a damn Turing tape.