Fill Spectre v3.1

[Pixel Eater]

This is looking good so far. The magick + signs are a little wonky but seem to show perspective skewing (maybe just reversed?)

I tried changing this line to:

Code: Select all • Expand view

if(e.thing.bismonster == true && e.thing.checkclass("Spectre") == true)

And surprisingly it actually worked for me


Edit: I just added 'x 2' after each 'coordinate_numbers[i].height' in the magick code section and it stretched the bounding box to the full height of the Spectre

Code: Select all • Expand view

Screen.drawText(smallfont, Font.CR_White, position_on_screen.x + (coordinate_numbers[i].radius * defect),position_on_screen.y + (coordinate_numbers[i].height * 2 * defect * level.pixelstretch), "+");
Screen.drawText(smallfont, Font.CR_White, position_on_screen.x - (coordinate_numbers[i].radius * defect),position_on_screen.y + (coordinate_numbers[i].height * 2 * defect * level.pixelstretch), "+");

Will that work or am I just adding bandaids?

[Apeirogon]

I dont know. Magic is a magic because I dont know whats going on there.
For me, with "default" numbers, it works fine. Only with boss monsters, large I mean, frame from + too stretched.

I do so because I thought that it can work using laws/theorems/axioms of similar triangles (or how it named in english?) like at picture

HRODA6A4 — копия.png

and it works for my sreen resolution, my fov, my aspect ratio, my etc.

Looks like gzdoom project scene to/on spherical surface, which represent screen, not to/on flat. Try set fov to 180 and see what I says.
I try add some amendment for transforming it to spherical coordinates.

But if I fail, I just found all 8 vertices of actor bounding box, which means "execute all code in "for(int i = 0; i < coordinate_numbers.size(); i++)" brackets 8 times", and then find points on a screen which can be ignored since it inside of "actor on screen area" rectangle of bigger size. But for this CPU dont say "thanks for optimizations".

[Pixel Eater]

But for this CPU dont say "thanks for optimizations".

I'm not sure what will happen when there are multiple Spectre 'hotspots' happening (even overlapping) and the shader must distinguish them apart. That could get messy, performance-wise

[doomfiend]

Would it be possible if a spectre was behind a fillspectre it would be invisible? It could help with CPU work load and not make a mess of things? If I knew how to help / understand code I would totally experiment around with some theories lol

[Pixel Eater]

Drawing the Spectre behind isn't too much of an issue and could eventually be increased up to around Five in a row (RetroSpectre already has this) thanks to Rachael's scary-good "alpha extractiony" technique. But what I'm worried will hurt is sending unpredictable numbers of hitbox datapoints to the shader which may need lots of logic (shader Kryptonite) to decide whether it's made a "hit". And to make it more confusing the boxes will be skewed by perspective. I am hoping it's something that can be overcome, because I like where Apeirogon is taking this

Feel free to share any theories you have, I promise I won't steal them

[Apeirogon]

what will happen when there are multiple Spectre 'hotspots' happening (even overlapping)

All points will be calculated in one pass of "for(every monster in array)" block, and only the send it to shader.
If rectangle overlap each other it only means that shader apply two/three/sixteen times to that screen area.

What happens next I dont know, its from the field of shader knowledge.



I think thatll be the last version. Only need to test on PC from a grim darkness of a past, how it handle with this.

shader test Ъ.zip

[Pixel Eater]

Thanks Apeirogon! I've combined the shader into the main project and made a little progress, though it's rough

[Apeirogon]

Spectre, when chase player, crawls out of the "shader frame"!? This is because of gzdoom interpolations. Summon spectre, type in consol i_timescale 0.1 and look. But firstly add to player enter event something like

Code: Select all • Expand view

players[ consoleplayer ].mo.speed *= 5;

so you can move more freely.
Actor, as game object, move more like "instantly warping from current position to another", and its new position "shader frame" almost instantly(~0.1 miliseconds) calculated in render overlay. But to make illusion that actor move normal, as IRL, gzdoom interpolate sprite position betweeen this two, previous and current, positions.
Here, or change gzdoom from within, or increase frame size.

If you mean "if I very fast move mouse "shader frame" dont fit to spectre position" I need in some way take into account camera slope/pitch change in between calculation of frame vertex.


Also, shader apply only to one spectre, even if there are more than one spectre on a screen.

[Pixel Eater]

Summon spectre, type in consol i_timescale 0.1 and look. But firstly add to player enter event something like

Code: Select all • Expand view

players[ consoleplayer ].mo.speed *= 5;

so you can move more freely.

Well that's trippy!

Could it be due to the 'doeffect()' in 'check_owner_fov'? I think that works in ticks...

[Apeirogon]

No, actor act, and move, every tick. Interpolations happens outside of game ticks.
I dont know how check sprite movement, in gzdoom, without chroma key. Because for game sprite just a picture bound to actor. Well, technically not exactly, but in zscript it is so.

[Pixel Eater]

nochroma.jpg

NO CHROMA!

[Apeirogon]

My respect

Also, lens effect inside frame was planned?

[Pixel Eater]

Not planned but I wasn't aiming for perfection yet. This was the third try- 1st was upside down, 2nd was the last state's first frame. It's going to take a lot more work to accomplish but it's only possible thanks to your efforts
I suspect it will still need chroma keying in the background for when the sprite gets eclipsed, but it shouldn't interfere much I don't think.
Another pic:

nochroma2.jpg

Here's the lookup table/sprite sheet:

sprite_lut.png

By telling the shader the Spectre's state and it's angle relative to the player's then it should be easy to animate it

[Apeirogon]

About angle...
UI restrictions dont allow to run deltaangle function, to find angle relative to the player, inside of it.
Use this this

Code: Select all • Expand view

firstly find angle of player and angle of monster;

double result_angle = angle of player - angle of monster;

if(result_angle > 360)
{do{result_angle -= 360;}
while(result_angle > 360)
}

if(result_angle > 180)
{result_angle-=360;}


This return angle of monster relative to player in range from -180 to 180.



And about "eclipse". How do you imagine to self how it should work? Algorithm I mean. If some wall or othe actor sprite overlaps specter sprite it should...?

[Pixel Eater]

Cheers, I'll give that angle code a go when I next can

To handle the foreground overlapping I'll use the simpler chroma keying method from RetroSpectre. I'm hoping to use it only as an overlap test so that it doesn't have an impact on rendering. That is just a theory though and I won't know for sure until I can test it