ducon said:

Note that GZDoom messed my ZDoom config file, that’s why I run ZDoom this way.


How did that happen?

Normally, it shouldn't do anything different, except add some new console variables ignored by ZDoom. If it messes the config file, there's a problem to investigate.

Share this post


Link to post

Now, ZDoom does not find zdoom.pk3 when launched without the full path. Before compiling GZDoom (and running it), everything was fine.

> zdoom
ZDoom v2.6.1 - SVN revision 3794 - SDL version
Compiled on Jul 30 2012
Using video driver x11

M_LoadDefaults: Load system defaults.
Cannot find zdoom.pk3

Share this post


Link to post

Very odd. Are gzdoom.pk3 and zdoom.pk3 in the same directory? (/usr/local/bin/ in this case.) Does the config file still contain this code?

# These are the directories to search for wads added with the -file
# command line parameter, if they cannot be found with the path
# as-is. Layout is the same as for IWADSearch.Directories
[FileSearch.Directories]
Path=$PROGDIR

Share this post


Link to post

Man that is pretty impressive, 532 cacodemon's in one cube. I was a bit disappointed by the lack of a projectile wall volleying towards me but it's certainly a sight to see, regardless. Typical gggmork stuff.

Share this post


Link to post
Springy said:

Man that is pretty impressive, 532 cacodemon's in one cube. I was a bit disappointed by the lack of a projectile wall volleying towards me but it's certainly a sight to see, regardless. Typical gggmork stuff.


"Typical" is not a word we use when it comes to gggmork.

Share this post


Link to post

Ha ha. There should be 512 by the way, not that it matters (8x8x8).
The functions I had rotated about the x y or z axis exactly only which is kinda ridgid (the cube was rotating in each at a different speed). I made a new function that allows rotation around an arbitrary axis (I think, haven't fully tested it). So basically you can draw an imaginary line anywhere and it should rotate around that line. Which probably means it can tilt up/down/left/right/tilt side/side, regardless of where it is currently pointing/facing.

It should be easy to expand/contract the cube over time by simply multiplying each x/y/z coordinate by a multiplier (because each coordinate "pretends" the center is the origin 0,0,0), and the cube itself has its own center which then is added to each coordinate. Projectiles probably won't be hard to add.

For the "photomosaic caco" idea in the OP, I thought about making the whole thing a sphere instead of a cube (because a caco is a sphere). But then rotating a sphere isn't very interesting because as you know, a soulsphere for example doesn't even need rotation frames because a sphere looks the same no matter how its rotated, whereas a cube has more interesting corners that rotate.
Also I realized an 8x8x8 cube of cacos (could be hollow too to save having to compute all the mass of "innards") wouldn't make a very high resolution image (if each caco is colored to match the pixel of the larger overall caco, then that's only 8 pixels wide.. something like 16x16 hollow might look better, or maybe a sphere.
Or maybe that'd be too much of a pain, it'd just be one frame of animation anyway.. multiple frames, like another when it shoots etc, would take forever.

I could store each individual caco in an triple nested array:
cacoArray[8][8][8]
OR just make it a single array:
cacoArray[512]
where each "object" if you will, in the array, stores an x/y/z/tid/health/shooting behavior/whatever.
I think an advantage of the former is I could immediately access a particular 8x1 plane of the cube or something, whereas the latter would need to cycle through each caco and ask "if x= bla" for each or something, which might be slower.
But the latter might have more freedom because you're not limited to an array-restricted cube form. Like a big complex thing like a giant hand or something doesn't map to a cube very well. Or the caco's horns are "extra" things that don't map with the sphere, so maybe its best to just have a 1d array. Or use either, or both, depending on what happens to map best.

I'd probably noclip the cacos too so the cube can shrink really small sometimes without them failing to warp because they're on top of eachother (I can still give the player damage or something probably by collision checking the cube with the player's hitbox).

I was gonna make it have attack patterns, and you could kill each individual caco until the whole thing was dead. Like in one attack, all the constituent cacos could come "alive" and break out of the larger caco mold to attack you as a group before returning to their grid locations again.
In another attack it could bounce off walls like a 3d pong ball, each time it hits a wall, projectiles could come randomly out of each side and ceiling or something + a quake, etc. And just kind of a visual effect thing, sometimes every other plane would rotate clockwise while the rest rotate counter clockwise. Not sure how successful or motivated I'd be to do this stuff.

Share this post


Link to post
Thorgrim103 said:

Someone post a image of this thing please.
Thanks.


Damn, image is a bit big, sorry.

gggmork said:

Ha ha. There should be 512 by the way, not that it matters (8x8x8).

Oh yeah, sorry, my bad. It starts off with 512 but increases once you fire at them.

Share this post


Link to post

I expected the thing to lag, or at least chug a little, but to my surprise it runs really smoothly.

Share this post


Link to post

Love the cacosphere, knocking holes in it with the rocket launcher is a surreal experience - bit like chipping away at a big, red easter egg.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now