[Danukem]

 Reaper_Man, on 07 October 2020 - 04:49 AM, said:

Out of curiosity, what would be a preferable alternative? The wiki says EVENT_EGS executes before EVENT_SPAWN, but if the palette isn't set in SPAWN then certainly that means it still won't be set at EGS, right? I would think that EGS would be preferable here as it runs for actors that are spawned at runtime, and it seems that SPAWN only runs for actors that exist on map load.

One option would be using EVENT_WORLD, since the code would run-once-per tic instead of once-per-tic-per-sprite. But the code would need to be different since it wouldn't be run by the specific sprite in question.

[December Man]

 Danukem, on 07 October 2020 - 12:31 AM, said:

That confirms the reason the EVENT_SPAWN version didn't work is the pal hadn't been set yet. The bad thing about putting that code in EVENT_GAME is that every single sprite in the game will run that line of code 30 times per second, even though it won't do anything unless the sprite is spawned by a slimer. That's very unlikely to cause you any issues but it's not optimal. If you had a big complex project with lots of code it would be worth improving.

Is EVENT_PREGAME any more efficient in this regard than EVENT_GAME?

[Fox]

 Reaper_Man, on 07 October 2020 - 04:49 AM, said:

Out of curiosity, what would be a preferable alternative? The wiki says EVENT_EGS executes before EVENT_SPAWN, but if the palette isn't set in SPAWN then certainly that means it still won't be set at EGS, right? I would think that EGS would be preferable here as it runs for actors that are spawned at runtime, and it seems that SPAWN only runs for actors that exist on map load.

EVENT_EGS is used internally to initialize newly spawned sprites. It's where the structures are reset, in case the same ID was used for another sprite before.

EVENT_SPAWN is used for both sprites that already existed in the map or newly spawned sprites. Internally it's where it changed the size of enemies, etc.

Projectiles are, however, excluded from EVENT_SPAWN, and you would use EVENT_EGS instead.

[Danukem]

 December Man, on 08 October 2020 - 05:03 AM, said:

Is EVENT_PREGAME any more efficient in this regard than EVENT_GAME?

No.

https://wiki.eduke32...i/EVENT_PREGAME

[Salvation]

A few questions:

I would like to make a bullet / projectile which has average velocity but its going to drop very soon. The idea is to make a weapon which is very good at close range but with no chance when shooting longer distances. I tried to do it myself but i can't get work on it as i planned

What's wrong with the code or is there something missing?

define SCARBULLET 15

defineprojectile SCARBULLET PROJ_WORKSLIKE 1
defineprojectile SCARBULLET PROJ_SPAWNS SMALLSMOKE
defineprojectile SCARBULLET PROJ_DECAL BULLETHOLE
defineprojectile SCARBULLET PROJ_EXTRA 20
defineprojectile SCARBULLET PROJ_XREPEAT 6
defineprojectile SCARBULLET PROJ_YREPEAT 6
defineprojectile SCARBULLET PROJ_TNUM 2
defineprojectile SCARBULLET PROJ_VEL 500
defineprojectile SCARBULLET PROJ_DROP -200

Second question: When you choose weapon like chaingun a weapon starts to appear and you are able to use it. How to change that "draw time"?
Idea is to simulate real world where lightweight weapon is easier to draw out and heavier weapon is slower.


Third question: My ironsight code does not have any penalty time when switching it on and off. I would like to have one, is there any command available or should i paste the code above?

[Danukem]

For the projectile, you need its fall to accelerate, rather than fall at a fixed rate. The projectile definition only allows for a fixed rate. This is one of those cases where you have to add some additional code outside of the projectile definition, possibly in EVENT_GAME. You might be able to get away with "appendevent EVENT_GAME ifactor SCARBULLET fall endevent" but maybe not. If that doesn't work you track its zvel in a peractor var, add to it from the previous amount and keep setting it every tic in EVENT_GAME. Also, you might want to make its vel faster.

[Salvation]

 Danukem, on 09 October 2020 - 09:27 AM, said:

For the projectile, you need its fall to accelerate, rather than fall at a fixed rate. The projectile definition only allows for a fixed rate. This is one of those cases where you have to add some additional code outside of the projectile definition, possibly in EVENT_GAME. You might be able to get away with "appendevent EVENT_GAME ifactor SCARBULLET fall endevent" but maybe not. If that doesn't work you track its zvel in a peractor var, add to it from the previous amount and keep setting it every tic in EVENT_GAME. Also, you might want to make its vel faster.

So should i make an actor for the scarbullet?

Something like this:

 TRAILFRAME2 0 1 1 1 15
useractor notenemy BEAMTRAIL 0 TRAILFRAME2
spritepal 2			
ifaction TRAILFRAME2 {
ifactioncount 3 { killit }
else
ifactioncount 2 { cstat 32768 }
else
ifactioncount 1 { cstat 2 }
}
enda

Then EVENT_GAME i add the value that after certain amount of time the projectile starts to fall? Can it be so simple?

[MC84]

I've got a noob question regarding ifrnd - basically I have a wall tile that once hit will shuffle between 3 different break tiles.

ife wall[RETURN].picnum GLASSFRONT
{ sound GLASS_BREAKING 
  lotsofglass 20 
  ifrnd 85
  { setw[RETURN].picnum GLSSFRNTBR1 }
  ifrnd 85
  { setw[RETURN].picnum GLSSFRNTBR2 }
  else
  { setw[RETURN].picnum GLSSFRNTBR3 }
  }

85 is 255/3, yet it seems to choose the final picnum (GLSSFRNTBR3) more frequently than the other two.. is this normal? It's hardly a big deal but I thought that perhaps I'd incorrectly used ifrnd? And is it preferable to use integers that are divisible by 8?

[Hendricks266]

The first thing I see is that the second ifrnd needs an else before it. Otherwise there is a 1/3 chance of using the second tile, a 2/3 chance of the third, and no chance of the first.

Second, I don't think chaining "ifrnd 85 else ifrnd 85 else" will give each result an equal 1/3 chance. The first one would have a 1/3 chance. The else would cover the 2/3 remaining chance, and the second result would have 1/3 of that = 2/9. Then the third result would have the remaining 4/9 chance. It would need to be ifrnd 85 else { ifrnd 128 else }.

Generally I prefer to avoid ifrnd messes if you want all the results to have the same likelihood. Just use randvar and a switch/case.

  randvar temp 2
  switch temp
    case 0
      setw[RETURN].picnum GLSSFRNTBR1
      break
    case 1
      setw[RETURN].picnum GLSSFRNTBR2
      break
    case 2
      setw[RETURN].picnum GLSSFRNTBR3
      break
  endswitch

[MC84]

Much better! Thanks for the explanation - it probably would have never occurred to me that each ifrnd statement alters the probability..

I assumed that this gamevar would be a 'per actor' variable, but out of curiosity I set it to 'global' and it still works? In my limited understanding of coding I would have assumed that making it global would cause issues when there are multiple states of the actor walltile being hit?

[Hendricks266]

Each ifrnd is its own dice roll, so you have to model your math based on that.

Scratch variables like temp should be marked global. There is no concurrency in CON so the variable is not contested in any way. You only need to mark a variable per-actor if each actor's value needs to be preserved from one game world tick to the next.

[Salvation]

I would like to change the font of health, armor and ammo.
I put the following code:

onevent EVENT_DISPLAYREST
	getactor[THISACTOR].extra TEMP2
	{
	digitalnumber 2992 360 160 TEMP2 0 0 0 0 0 xdim ydim
	}
endevent

The new font is now on screen on the right side but the existing one is also there, so it's a duplicate. See the attachment.

What should i do to change the font?

Attached thumbnail(s)

• 

[Danukem]

You can't pick and choose individual elements of the hud to replace; you have to disable the entire hardcoded display by setting RETURN to -1 in the event and then redraw every single thing yourself.

[December Man]

Hey, I'm using the following code to have the Jibs remain on the floor:

state rf
getactor[THISACTOR].cstat TEMP4
ifvare TEMP7 259 { cstat 2 } else
ifvare TEMP7 771 { cstat 514 } else
{ 
  ifrnd 128
    cstat 4
  else
	cstat 0
}
ends

state getfloordist
  getactor[THISACTOR].x x
  getactor[THISACTOR].y y
  updatesector x y TEMP7 // You should not trust [THISACTOR].Sectnum
  getflorzofslope TEMP7 x y z
  getactor[THISACTOR].z TEMP8
  subvarvar z TEMP8
  shiftvarr z 8
  subvar z 1
ends
				
onevent EVENT_GAME
			
ifactor JIBS1
{
state getfloordist
ifvarl z 0 
	{
	sound GIB_LAND2
	changespritestat THISACTOR 1
	state rf
	setactor[THISACTOR].picnum 2249
	      ifrnd 84
        spawn BLOODPOOL
        else
		guts JIBS6 3
}
}
endevent

Each time a Jib drops inside an invalid sector, eDuke32.log spills out the error:

Line 801, getflorzofslope: invalid sector -1

This error is being spammed in dozens of kilobytes over an hour of gameplay. Is there a way to avoid this?

[Jimmy]

Try having the game check to see if the gib is in an invalid sector, and if so, break and killit.

[December Man]

Jimmy, on 28 October 2020 - 12:08 PM, said:

Try having the game check to see if the gib is in an invalid sector, and if so, break and killit.

The issue is that I'm not sure how to do that.

[jimbob]

hey, havent been to this site in ages, but i had the urge to make some duke mods and was wondering about a few things.

1, i want to add new reload animations to a custom weapon wich replaces the chaingun. it behaves like the chaingun/ripper except it needs a 30 round magazine, and some reload animations
i have all the artwork in place, might need some tweaking, but i cant for the life of me figure out how to tell the game when to reload, where the artfiles are and how long the animation needs to last, tried looking at the wiki and use the 'manual reload' tutorial, but it just jiggles the gun infinetly.
i have the new reload animation, 7 frames long at tile 2582, and basically it is an oscillation of pulling out a mag, and sticking it back in.
for the weapon i use these gamevars.
// thompson
gamevar WEAPON3_WORKSLIKE 3 0
gamevar WEAPON3_CLIP 30 0
gamevar WEAPON3_RELOAD 60 0
// gamevar WEAPON3_FIREDELAY 1 0
gamevar WEAPON3_TOTALTIME 10 0 // was 10
// gamevar WEAPON3_HOLDDELAY 0 0
gamevar WEAPON3_FLAGS 73813 // 85
gamevar WEAPON3_SHOOTS CHAINGUN
// gamevar WEAPON3_SPAWNTIME 0 0
gamevar WEAPON3_SHOTSPERBURST 0 0
gamevar WEAPON3_INITIALSOUND 0
gamevar WEAPON3_FIRESOUND CHAINGUN_FIRE
gamevar WEAPON3_SOUND2TIME 0
gamevar WEAPON3_SOUND2SOUND 0
gamevar WEAPON3_SPAWN SHELL

2, i have an actor wich spawns at a certain point, goes through an AI routine, but i want this actor to litteraly keel over and die after X seconds, after wich i want the corpse to be removed after a while.
i have the routines down, and even the corpse cleanup code but the game refuses to use 'count' if it is going through other routines, or if it moves. i have a a cleanup state as follows
state cleanup
cstat 2
ifcount 330
{
cstat 514
}
ifcount 360
{
killit
}
ends

this kicks in after the actor has been shot and is dead on the floor ( aparently if movement is 0 it starts counting )

i trier adding something like
ifcount 1000 action GIDROPDEAD ( the actors falling dead animation )
strength 0
state GIDYING ( check the DYING state of the actor for ifhitweapon etc )

but because it keeps going through its routines and keeps moving it never reaches the count number, or, when it dies it keeps looping its dying animation.

[jimbob]

i thought about it for a bit, and perhaps substracting health every other state will eventually drain the actors health, causing it to quite litterally die, this would give some random amount of time before this happens, and wil definatly cause the actor to die eventually.

another thing, how do i change the offset for the ejecting brass, right now it spawns in an incorrect location.

and since where on the topic of editing existing things, the muscle flashes used with the chaingun have three different offsets so they animate in front of each 'barrel' of the gun, i'd like to change this to one location for my new gun.

[Reaper_Man]

I have a bunch of questions about performance. How "expensive" are the following commands?

sqrt
updatesector
cansee
setarray
setvarvar (specifically pulling data from an array)

I'm trying to improve performance on my A* pathfinding, and I'm trying to identify which operations are very "expensive" that I should avoid or limit my usage of. I am calling these potentially thousands of times for every enemy on a given frame. There's not frequently frame drops and I am doing what I can to limit the frequency for these calls, but I'm curious which of these are the most heavy on CPU.

I am using "sqrt" for a simple Euclidian distance calculation, as dist / ldist takes actors and not X/Y positions:

defstate astardist
{
	setvarvar ASTARDELTAX ASTARPOSX
	subvarvar ASTARDELTAX NODEPOSX
	abs ASTARDELTAX

	setvarvar ASTARDELTAY ASTARPOSY
	subvarvar ASTARDELTAY NODEPOSY
	abs ASTARDELTAY

	mulvarvar ASTARDELTAX ASTARDELTAX
	mulvarvar ASTARDELTAY ASTARDELTAY

	addvarvar ASTARDELTAX ASTARDELTAY

	sqrt ASTARDELTAX ASTARDIST
}
ends

Is there a cheaper method of getting the distance between 2 arbitrary points in space?

I'm using "updatesector" in conjunction with "cansee" to validate if 2 points in space are valid (IE not in the void):

// Ignore any point we don't have line of sight to
getactor[THISACTOR].sectnum ASTARSECT
updatesector ASTARPOSX ASTARPOSY ASTARSECT
getsector[ASTARSECT].floorz ASTARPOSZ
subvar ASTARPOSZ 6144

getactor[THISACTOR].sectnum NODESECT
updatesector NODEPOSX NODEPOSY NODESECT
getsector[NODESECT].floorz NODEPOSZ
subvar NODEPOSZ 6144

cansee ASTARPOSX ASTARPOSY ASTARPOSZ ASTARSECT NODEPOSX NODEPOSY NODEPOSZ NODESECT ASTARCANSEE

I need to validate line-of-sight between 2 points, is there a less expensive method than this?

I don't have concise examples of using "setarray" and "setvarvar" for pulling values from an array, but suffice it to say that 2 separate arrays have their values checked and/or set potentially thousands of times during each loop. I know that this sucks, and I try to use a reference to the array value (rather than comparing it directly, IE ifvarvarl VAR ARRAY[INDEX]), but I am not sure I can improve things further. How much of a CPU hit could this be causing?

[Danukem]

Reaper_Man, on 10 December 2020 - 09:33 AM, said:

I'm trying to improve performance on my A* pathfinding, and I'm trying to identify which operations are very "expensive" that I should avoid or limit my usage of. I am calling these potentially thousands of times for every enemy on a given frame.

Those calculations aren't super expensive but you are sure doing them a lot. It sounds like you are making your actors re-evauluate the path every single tic, which is excessive in my opinion. You can give each actor an interval and then have them do it every 10 tics or so. Stagger it so that only certain actors are doing it on certain tics (for example you could use the actors sprite ID to offset player_par and then mod 10 on the result to determine when to calcaulte). A lag of up to 10 tics on their reaction speed to changes in the maze won't be very noticeable but will reduce the calculations per second by nearly 90%

[Salvation]

A noobish question - i just can't figure this one out:

I would like to increase chaingun rate of fire by decreasing it's TOTALTIME. Like this:

gamevar WEAPON3_TOTALTIME 6 0

Original TOTALTIME was 12

After inserting this it wont display anymore chaingun firing tiles (the firing tiles contained cool muzzle blast) and it only "shakes" when shooting. Only main tile, which is nr 2537 appears but firing tiles 2538, 2539 and 2540 does not.

Any simple ideas how to fix this?

[Danukem]

The chaingun fires multiple times during the 12 tics and animates, so simply cutting that in half is not the right approach. Leave TOTALTIME alone, and instead try changing the weapon's flags:

gamevar WEAPON3_FLAGS 73820 0

That will add the "fire every other" flag which I think should make it fire on almost every tic now (because it also has the fire on every third flag). You could also try removing the fire on every third flag and just have fire on every other which would give you flags 73804

But it's been a while since I messed with it so I could be mistaken about how these flags will affect things -- it's not always straightforward. These days I code the animation so I can change things more drastically.

[Reaper_Man]

Danukem, on 10 December 2020 - 11:27 AM, said:

Those calculations aren't super expensive but you are sure doing them a lot. It sounds like you are making your actors re-evauluate the path every single tic, which is excessive in my opinion. You can give each actor an interval and then have them do it every 10 tics or so. Stagger it so that only certain actors are doing it on certain tics (for example you could use the actors sprite ID to offset player_par and then mod 10 on the result to determine when to calcaulte). A lag of up to 10 tics on their reaction speed to changes in the maze won't be very noticeable but will reduce the calculations per second by nearly 90%

No, the routine only runs basically once every animation cycle. It essentially looks like this:

ifactioncount 5
	resetactioncount
else
ifactioncount 4
{
	state astar
	state facetarget

	action A_ASTAR
	move M_ASTAR geth getv
	break
}

The reason there's so many calls is because of how the navigation nodes are built, which is basically just valid points on the grid. So if a hypothetical map takes up a 32768 x 32768 square, and if the nodes are built at 512 intervals, that's still 4096 potentially valid points. It's also possible that some points are evaluated multiple times by looking at a node's neighbors, so 4096 is actually the best case scenario because it assumes essentially a straight unobstructed line from corner to corner. Theoretically this count could go up to 28,672 in very bad scenarios, where nearly every node is re-evaluted for each of it's neighbors. (Of course the real-world execution will be much lower, outside of particularly bad maze-y designs, but I digress.)

Decreasing the navigation node density obviously improves things (512 to 768 for example), but then it becomes less useful in areas with tight navigation. It is possible to have areas of varying node density, but that is outside the scope of solving the core algorithm performance.

I've found a way to reduce the sqrt calls for checking distance, but they are still called up to 8 times per each neighbor, and the nature of the algorithm requires the rest of the culprits are all called if the distance check succeeds.

[Danukem]

Ok, so it's not done the way I suspected, but it still seems to me that you could break up the workload and spread it over time more. EDIT: Also you have your nodes very close together if I understand correctly. This could also create a potential for too many sprites in the map, once you get a big map with a log ot effects going on.

EDIT2: I'm guessing you are spawning in the nodes via code, which would explain why you have them so dense. If you hand place them in maps you can reduce the density a lot. That does mean that maps have to be hand edited to use the system but otherwise you need some very smart code for analyzing the map structure and placing nodes with the minimal density required in a particular area of a map.

[Reaper_Man]

Danukem, on 10 December 2020 - 01:51 PM, said:

Ok, so it's not done the way I suspected, but it still seems to me that you could break up the workload and spread it over time more. EDIT: Also you have your nodes very close together if I understand correctly. This could also create a potential for too many sprites in the map, once you get a big map with a log ot effects going on.

EDIT2: I'm guessing you are spawning in the nodes via code, which would explain why you have them so dense. If you hand place them in maps you can reduce the density a lot. That does mean that maps have to be hand edited to use the system but otherwise you need some very smart code for analyzing the map structure and placing nodes with the minimal density required in a particular area of a map.

To clarify, the nodes aren't actors, they are X and Y positions recorded in an array. The system actually doesn't spawn anything, which is why dist / ldist aren't useful and I have to use sqrt to do the distance calculation manually. This is also why manually placing waypoints isn't a viable solution. As I mentioned I do have some actors that can generate nodes in the X/Y arrays with a variable density in their vicinity, but that's more for things like doorways and other tight areas where mappers need granular control, rather than manually creating a navigation mesh for the entire map.

[Danukem]

That sounds good. Well, I don't have anything to contribute as far as optimizing the calculations. In my experiences with dealing with similar problems in CON, my guess is that fiddling with the code that does the calculations will only give you micro-optimizations and most of your gains will come from reducing the number of (virtual) nodes and/or spacing out the workload more.

[Reaper_Man]

Danukem, on 10 December 2020 - 03:03 PM, said:

That sounds good. Well, I don't have anything to contribute as far as optimizing the calculations. In my experiences with dealing with similar problems in CON, my guess is that fiddling with the code that does the calculations will only give you micro-optimizations and most of your gains will come from reducing the number of (virtual) nodes and/or spacing out the workload more.

Right, I feel like I'm probably up against the wall with what I can do from CON. I can do away with the sqrt calls and use a more simplistic distance guesstimate, but it's the cansee calls I worry are the culprit. I don't know how updatesector works under the hood, and if I'm going overkill to validate the X/Y positions.

Thanks for your input as always, Dan!

[Reaper_Man]

For anyone who comes across this later, I wound up using a square root approximation, which works because my node points are on a grid.

// Search distance 1.5 times node graph size, cheap method of accounting for diagonal distance
setvarvar ASTARMAXDIST NODEGRAPHSIZE
mulvar ASTARMAXDIST 15
divvar ASTARMAXDIST 10

// Estimated square root distance for diagonal movement
setvarvar ASTARSQRT NODEGRAPHSIZE
mulvar ASTARSQRT 1414
divvar ASTARSQRT 1000

[ . . .]

// ASTARPOSX/Y and NODEPOSX/Y are the X/Y position of the start and end points, respectively
setvarvar ASTARDELTAX ASTARPOSX
setvarvar ASTARDELTAY ASTARPOSY

subvarvar ASTARDELTAX NODEPOSX
abs ASTARDELTAX

subvarvar ASTARDELTAY NODEPOSY
abs ASTARDELTAY

// If node within range
ifvarvarl ASTARDELTAX ASTARMAXDIST
	ifvarvarl ASTARDELTAY ASTARMAXDIST
{
	// Cheap square root approximation
	ifvare ASTARDELTAX 0
		setvarvar ASTARDISTANCE NODEGRAPHSIZE
	else
	ifvare ASTARDELTAY 0
		setvarvar ASTARDISTANCE NODEGRAPHSIZE
	else
		setvarvar ASTARDISTANCE ASTARSQRT

In this specific case, NODEGRAPHSIZE is 700 units, so ASTARMAXDIST becomes 1050 and ASTARSQRT becomes 989. Subtracting the start X or Y position from the ending X or Y position gives you the distance on one axis, and if both are less than the ASTARMAXDIST, then that means the distance is either going to be 700 or 989.

Anyway, my next question:

I am using several for loops, but often run into cases where I can/should exit out of them early. Is it possible to end a for loop early? The wiki makes it seem like you can't, and "break" doesn't seem to do anything either. Should I use while loops instead of for loops for cases where I know I will need to break them early? Is it faster to use a while loop in situations where I might break out of early, and for loops where I know I will need to iterate through every item?

[jimbob]

If i understand your idea, it scans for valid player spaces every X and decides that is a valid point for the actor to move in, in order to speed up efficiëncy is there something like a pre-calculated mesh of nodes? In certain older games you could 'render' pathfinding and it would create a waypoint system, and would calculate movement off of that instead of doing it realtime, wich sounds much more CPU efficiënt than checking the entire build grid every X.

[Reaper_Man]

jimbob, on 13 December 2020 - 11:33 AM, said:

If i understand your idea, it scans for valid player spaces every X and decides that is a valid point for the actor to move in, in order to speed up efficiëncy is there something like a pre-calculated mesh of nodes? In certain older games you could 'render' pathfinding and it would create a waypoint system, and would calculate movement off of that instead of doing it realtime, wich sounds much more CPU efficiënt than checking the entire build grid every X.

Yes, the node graph is precalculated only once at map load, and I have a system to store and load the node graph on the disk and use that instead of generating it every map load, to speed things up further. But the node generation isn't a bottleneck, it's the various checks and iterations through the node graph. Consider a map that is 65536 units square, and the node graph density is 700 units, or 94 grid points per axis. That creates an array of only 8800 items. Searching through 8800 items is pretty fast. Searching for 8800 items 8799 separate times - or 77 million searches - is what is slow. Reducing that number, and reducing any other expensive calls within each of those iterations, is the goal.

The square root approximation method here works because every point is on a grid. Neighboring nodes are either straight or diagonal, and the distance is precalculated using the square root approximation for the diagonal points. Using the sqrt function isn't necessary because the distance is only ever going to be one length or the other.

I've been playing around with multiple search densities and I think I've come up with a system that balances speed/performance and search accuracy. It does 2 searches - a coarse grid search to find the nearest point, and then a fine local search to the nearest point. Think of this as searching for the path based on rooms and hallways, and then a second search to navigate the room you're in to get to the doorway. This cuts down the hypothetical 77 million searches down to only a few thousand.