Several ACS functions for reusable and more flexible code

CodeImp · Post by **CodeImp** » Wed May 05, 2004 1:28 am

In this case you dont need that parameter mode, because the X and Y coordinates would come in when there are multiple sectors with the same tag. But id also like to be able to use the function WITHOUT X or Y coordinates (just 0) for flat floors/ceilings when only one sector (or multiple all with the same height) has the given tag. I dont really see myself pinpointing a sectors coordinates on the map and hardcode those coordinates for every time I use this function just for a flat sector.

MartinHowe · Post by **MartinHowe** » Wed May 05, 2004 2:38 am

Heh heh, I was thinking this myself after battling with "you-know-what" TNG for a few weeks --

cccp_leha wrote:Is it possible to program dynamic strings into ACS / how difficult would it be to do so? I think I asked before and I forgot.

OK, let's play Devil's Advocate here as regards textures or other strings.

Would it not be possible to have, say, something like CreateStringTable() and DeleteStringTable() - the former would return an INT that would be a pointer to the table. Then any function that needed to "return" a string could be given the string table pointer and return an index; e.g., mytex=GetFloorTexture(mystringtableid). Or even the "standard" C things (strcmp, strcpy, etc).

Or instead, each scope instance (global, each hub, each map, each script, each function) could have a "string table id" field that is set to 0 on start and not changed unless the programmer uses "GetStringTableId()" or similar.

When the scope instance ends, code added by ACC (not the programmer) automatically destructs any such storage (using free()). The string indexes themselves are created dynamically and stored in a master array (again, not visible to the programmer) so that ACS can check if a pointer is still valid. Could be a bit slow, but remember this check would be done by the game (i.e., in C not ACS) and would be faster than the (interpreted pcode of) ACS.

This is just food for thought written quickly, so there will be holes in it, but you get the general idea; just thought it had to be said.

Post by **Graf Zahl** » Wed May 05, 2004 3:13 am

The ACC compiler is the big problem in this. It's just not able to handle this mess. Without a complete rewrite of both ACC and the interpreter I don't see any chance to properly implement strings.

Jonathan · Post by **Jonathan** » Wed May 05, 2004 8:10 am

I'm still hoping for a GetActorAngle() or an APROP_Angle one day.

HotWax · Post by **HotWax** » Wed May 05, 2004 10:41 am

Like Graf said, let's get these other functions coded before Randy changes his mind.

Then we can worry about additional actor properties. *keeps fingers crossed*

LogicDeLuxe · Post by **LogicDeLuxe** » Mon May 24, 2004 1:12 pm

So, what can we expect to be implemented in .64?

Also, GetViewPointX(), GetViewPointY(), GetViewPointZ() and GetViewAngle() might be useful, which would return the exact coordinates of the current viewpoint. This must not be identical to the marine, but also can be an active camera. Also the bobbing would be taken into account.
Those functions might be usefull for some visual effects. Even they are not that important if we will have portals supported, they might come in handy for some other effects.

Also it might be great if one could set the scale and size of actors at runtime. For instance, growing monsters could be done with it.

Chilvence · Post by **Chilvence** » Mon May 24, 2004 3:10 pm

What effects are those then? Not saying that they wouldnt be useful, I'm just curious what you'd do with them.

LogicDeLuxe · Post by **LogicDeLuxe** » Mon May 24, 2004 3:17 pm

Chilvence wrote:What effects are those then? Not saying that they wouldnt be useful, I'm just curious what you'd do with them.

Not thought of something particular yet. You could move things and sectors accordingly. Or maybe have a monster which only wakes up when you (or a camera) turn your back to it. There's plenty you could do with those, just like with those suggested in the posts before.

HotWax · Post by **HotWax** » Mon May 24, 2004 3:39 pm

Zelda:OOT uses such a technique to begin the Queen Gohma battle in the Great Deku Tree level.

Post by **Bio Hazard** » Mon May 24, 2004 8:48 pm

i can beat ghoma in 5 seconds

on topic: i want a function to return the distance to the wall under the crosshair

blender81 · Post by **blender81** » Mon May 24, 2004 10:35 pm

I agree with LogicDeLuxe, I would also like a function that returns the player's current view angle. With this function, one could hack together a nice radar or crude on-screen automap, or perhaps a compass aiming toward the next objective.

LogicDeLuxe · Post by **LogicDeLuxe** » Tue May 25, 2004 10:38 am

blender81 wrote:I agree with LogicDeLuxe, I would also like a function that returns the player's current view angle. With this function, one could hack together a nice radar or crude on-screen automap, or perhaps a compass aiming toward the next objective.

Though, I'd say, the general GetActorAngel (as suggested before) would be more important. That shouldn't be hard to implement and is really useful in many situations.

LogicDeLuxe · Post by **LogicDeLuxe** » Sun May 30, 2004 8:38 am

I have another suggestion for better subtitle support:
int ActorOnScreenX(TID)
int ActorOnScreenY(TID)
which would return the coordinates of the position an actor is curently visible on screen. The format should be identical to the centered format which you use in HudMessage, so it can be used for subtitle positioning of (spoken) text from actors.
Of course, for cases you can't be sure if the actor actually is on screen, we also need
int IsActorOnScreen(TID)

Post by **Graf Zahl** » Sun May 30, 2004 8:51 am

LogicDeLuxe wrote:I have another suggestion for better subtitle support:
int ActorOnScreenX(TID)
int ActorOnScreenY(TID)
which would return the coordinates of the position an actor is curently visible on screen. The format should be identical to the centered format which you use in HudMessage, so it can be used for subtitle positioning of (spoken) text from actors.
Of course, for cases you can't be sure if the actor actually is on screen, we also need
int IsActorOnScreen(TID)

This sounds simpler than it really is. There is no way to determine with 100% certainty whether an actor is visible or not. In software mode you can check whether parts of it are being rendered but for ZDoomGL such a calculation is useless.

LogicDeLuxe · Post by **LogicDeLuxe** » Sun May 30, 2004 9:10 am

Graf Zahl wrote:This sounds simpler than it really is. There is no way to determine with 100% certainty whether an actor is visible or not. In software mode you can check whether parts of it are being rendered but for ZDoomGL such a calculation is useless.

As I thought of this functions as a subtitle helper, it doesn't really matter if the actor is actually visible or not. This merely should make it possible to have the subtitle line on screen at the same position the sound comes from (or were it would come from it it were dubbed in case it isn't). I know, there would be cases where actors are rendered, but coverd from objects in front of it, though, the engine has calculated the coordinates at least, which is sufficient in this matter.