HexaTRON

[Luke-Jr]

I am working on a fork of ArmageTRON Advanced with 6 directions instead of 4 (40 degree turns) and a hexagon "flower" grid with 7 rooms and passages between them.
The 40 degree turn support is complete and I have been working on the flower grid.

However, whenever a game starts, all players are instantly destroyed. I suspect the game is detecting the players as "outside" the grid (incorrectly). My grepping thus far has not come up with where in the code this check is made, so if anyone can throw some pointers my way, I'd appreciate it.

Also, if there's any suggestions/ideas for this fork, they'd be welcome. If the ArmageTRON Advanced team is interested, I'd be glad to merge the fork into the official game (likely via #ifdefs at first).

[Sabarai]

that'd be nice, but hard with the controls: you'd have to hit left or right 4 times to just make a 180.. (make it 45 degrees..)

[Luke-Jr]

that'd be nice, but hard with the controls: you'd have to hit left or right 4 times to just make a 180.. (make it 45 degrees..)

It's all a matter of what the players are used to doing. And while it would be 4 times to do 180 with 45 degrees, it would be 6 at 40 degrees.
Also, the 40 degrees was a typo... What I meant was 60 degrees (3 turns to do 180)

[Tank Program]

Doing some searching of the forums should turn up the parts of code you're looking for.

[Your_mom]

he can use the hex tiles if he wants

[Sabarai]

luke, 6 times for 180 degrees would make you turn 30 degrees a time... 180/40=4.5
i still think 45 degrees would be more pratical since you can make a 90 degrees turn in two turns... with 60 degrees that would be impossible. However your get all 6 angles of a hexagon... dunno which one, you choose

[iceman]

how about 360 degrees, hold down key for smooth turns

[Tank Program]

how about 360 degrees, hold down key for smooth turns

ooooooooo i like this idea, the longer u hold it down the further u turn...

[Sabarai]

whooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooohhhhhhhhhhhhhhhhhhhhhhhhhh... nice idea iceman....

but you will get the problem of grinding and stuff, no mini turns anymore... double assignment has no use anymore...

[Mecca]

lol that would be awesome, but if you were at a funny angle how would yo uget back to going strait?

[Sabarai]

there the lines of the grid come in handy...

[philippeqc]

I am working on a fork of ArmageTRON Advanced with 6 directions instead of 4 (40 degree turns)

Neat! I just started to work on some code to support N axis/directions. We will probably end up merging the good ideas toghether.

and a hexagon "flower" grid with 7 rooms and passages between them.

Sadly, that wont work. Shapes have to be convex at the moment (ie: no inside angles), otherwise the "you are inside/outside" code kills you.

The 40 degree turn support is complete...

Gimme! Gimme! Gimme!

...and I have been working on the flower grid.

Any luck?

However, whenever a game starts, all players are instantly destroyed. I suspect the game is detecting the players as "outside" the grid (incorrectly). My grepping thus far has not come up with where in the code this check is made, so if anyone can throw some pointers my way, I'd appreciate it.

Well, I should have read your whole mail before starting to answer to it. My fault. Blame it on the wiskey.

As for pointers, well my research showed me that there are no easy algos for deciding if your in or out of a shape that is not designed for convex shapes.

Knowing this, a concave shape can be decomposed in a series of convex shapes. An easy way to do this is to transform your shape in a bunch of triangles.

And here is the part that gets tricky: you need to recode a lot of the game to support "multiple" grids, once for each of your convex shapes. I'm kinda stuck on this.

Also, if there's any suggestions/ideas for this fork, they'd be welcome. If the ArmageTRON Advanced team is interested, I'd be glad to merge the fork into the official game (likely via #ifdefs at first).

I'm interested in your work. Post the patch files. I'll try to come on the forum at least once a week (Sorry, I'm sadly too busy atm for more).

-ph

PS: a patch file includes the code changes and the information where to apply it in a file.

[Luke-Jr]

I am working on a fork of ArmageTRON Advanced with 6 directions instead of 4 (40 degree turns)

Neat! I just started to work on some code to support N axis/directions. We will probably end up merging the good ideas toghether.

Fairly simple... though none of my modifications are runtime adjustable, let alone server negotiable:
@@ -1905,9 +1905,15 @@
speed*=.95;
skewDot+=4*d;
if (d){
- REAL swap=dirDrive.x;
- dirDrive.x=d*dirDrive.y;
- dirDrive.y=-d*swap;
+ REAL ox=dirDrive.x, oy=dirDrive.y;
+# define cosv 0.5 //-0.5
+# define sinv -0.8660254037844386
+ //dirDrive.x=d*dirDrive.y;
+ //dirDrive.y=-d*swap;
+ // newX = cos(rDeg) * (OldX - OrigX) - sin(rDeg) * (OldY - Orig
Y) + OrigX
+ // newY = sin(rDeg) * (OldX - OrigX) + cos(rDeg) * (OldY - Orig
Y) + OrigY
+ dirDrive.x = cosv * ox - (sinv*d) * oy;
+ dirDrive.y = (sinv*d) * ox + cosv * oy;
}

if (sn_GetNetState() == nCLIENT && Owner() == ::sn_myNetID)

and a hexagon "flower" grid with 7 rooms and passages between them.

Sadly, that wont work. Shapes have to be convex at the moment (ie: no inside angles), otherwise the "you are inside/outside" code kills you.

I see no good reason for that code to exist at all, so I'd prefer to disable it until it is fixed. Interestingly, not even a convex hexagon works with it.

The 40 degree turn support is complete...

Gimme! Gimme! Gimme!

See above for 60 degree. A slightly newer patch that is more friendly with changing the degree is:
@@ -1905,9 +1905,16 @@
speed*=.95;
skewDot+=4*d;
if (d){
- REAL swap=dirDrive.x;
- dirDrive.x=d*dirDrive.y;
- dirDrive.y=-d*swap;
+ REAL ox=dirDrive.x, oy=dirDrive.y;
+ #define deg (REAL) 2 * M_PI / 4
+# define cosv cos(deg)//0.5 //-0.5
+# define sinv sin(deg)//0.8660254037844386
+ //dirDrive.x=d*dirDrive.y;
+ //dirDrive.y=-d*swap;
+ // newX = cos(rDeg) * (OldX - OrigX) - sin(rDeg) * (OldY - Orig
Y) + OrigX
+ // newY = sin(rDeg) * (OldX - OrigX) + cos(rDeg) * (OldY - Orig
Y) + OrigY
+ dirDrive.x = cosv * ox - (-sinv*d) * oy;
+ dirDrive.y = (-sinv*d) * ox + cosv * oy;
}

if (sn_GetNetState() == nCLIENT && Owner() == ::sn_myNetID)

...and I have been working on the flower grid.

Any luck?

Not really. Can't find the code that kills people outside the grid

However, whenever a game starts, all players are instantly destroyed. I suspect the game is detecting the players as "outside" the grid (incorrectly). My grepping thus far has not come up with where in the code this check is made, so if anyone can throw some pointers my way, I'd appreciate it.

Well, I should have read your whole mail before starting to answer to it. My fault. Blame it on the wiskey.

Nah, this works better for simulating an actual conversation.

As for pointers, well my research showed me that there are no easy algos for deciding if your in or out of a shape that is not designed for convex shapes.

Assuming there is a good reason to do so... which there isn't, as far as I can tell.

Knowing this, a concave shape can be decomposed in a series of convex shapes. An easy way to do this is to transform your shape in a bunch of triangles.

And here is the part that gets tricky: you need to recode a lot of the game to support "multiple" grids, once for each of your convex shapes. I'm kinda stuck on this.

Why not generate this when parsing the shape and only use it for inside/outside detection?

Also, if there's any suggestions/ideas for this fork, they'd be welcome. If the ArmageTRON Advanced team is interested, I'd be glad to merge the fork into the official game (likely via #ifdefs at first).

I'm interested in your work. Post the patch files. I'll try to come on the forum at least once a week (Sorry, I'm sadly too busy atm for more).

The directional turning patch parts are above. They both apply to tron/gCycle.cpp
For arena shapes, I'm currently just hacking them into the tron/gArena.cpp manually. Here's a nice auto-circle arena code-clip, though IIRC it doesn't work with the inside/outside stuff at all (even for squares):
+ // circle/auto
+ int npt = 3; // Number of points
+ REAL x, y, ox, oy;
+ REAL deg = 2 * M_PI / npt;
+ x=y=73;
+ R=grid->Insert(eCoord(x, y));
+ printf("grid start at %f %f\n", x, y);
+ //x = y = 73;
+ for (int pt = 0; pt < npt; ++pt) {
+ ox = x; oy = y;
+ x = cos(deg) * (ox - 250) - sin(deg) * (oy - 250) + 250;
+ y = sin(deg) * (ox - 250) + cos(deg) * (oy - 250) + 250;
+ R=grid->DrawLine(R, eCoord((int)(x+.49), (int)(y+.49)) * sizeMul
tiplier, tNEW(gWallRim) (grid), 0);
+ printf("...grid to %f %f\n", x, y);
+ }
+ x=y=73;
+ R=grid->DrawLine(R, eCoord(x, y) * sizeMultiplier, tNEW(gWallRim) (grid)
, 0);
+ printf("grid closed at %f %f\n", x, y);
+

-ph

PS: a patch file includes the code changes and the information where to apply it in a file.

None of the modification sets I have made really diff cleanly (without including a ton of commented old-code and various other unrelated changes, so I have the relevant stuff above. Should fit into existing codebases cleanly...

[philippeqc]

quick answer to your post:

1. Neat idea to work with cos and sin. I'm doing it with "axis array" and array index + 1 for left, - 1 for right turn (mod numberOfWinding ).

2. Inside detection. Take 0,0 1,0 1,1 0.5,0.5 0,1 0,0 (square with a dent on the top). points like 1,1 get to be "behind" the line described by the segment (0.5,0.5) to 0,1

more later

-ph

[Z-Man]

Just my two cents:

Indeed, it may be a good idea to drop the convex shape condition in the code; instead of forcing everything to stay inside the rim walls, everything should simply be forced to stay inside the bounding rectangle of the rim walls. This will be fairly easy, the code is in eRimWall::Bound()/Clip()/IsBound(), you can just disable it there for testing ( let IsBound() return true always and turn the other functions into NOPs ). Undesired side effect: with a non-rectangular rim, the camera will then stray outside the rim wall bounds. This can be fixed by either a 2d-bsp structure like in good old doom that manages the rim walls ( That would be the algorithm for keeping something inside a non-convex shape you were looking for ), or by rendering the rim walls so that you can see through them when the camera gets on the other side ( this is already done a bit, but it looks horrible ), or by trying to utilize the normal collision detection. The last option sounds like it would be the simplest.

There are some undesired side effects of non-rectangular turns, too:
- The AI will get confused ( hard to fix completely )
- Some bits of the cycle netcode depend on 90 degree turns: The clientside code that determines where the wall corners should be after an enemy has turned ( it is buggy anyway, so I'll try to make it cope with all kinds of turns when I fix the bug ), and the server side code that works around packet loss of client control commands.

Fixing the side effects would be my job, I guess