[The Mechanic]

 Fox, on 09 October 2015 - 09:27 AM, said:

The thing is that sprites should never be outside of their visible sectors. Whenever that happens, it's because of a glitch or an improper code. For example, it's also possible to use CON to connect nonadjacent sectors, which the player would die if he tries to cross a wall. Similarly, sprites outside of their sectors is not something expected by the engine.

In my example image, the sprite is in its correct sector, its just that it is bigger than it's sector.

When moving sprites slowly between sectors, there will always be the situation at some point where the center of the sprite is in one sector (and has the correct sectnum value) but part of the sprite is in another sector. It's a case of suck it and see to find out how real a problem it is in practice. If it ends up sucking then I still have vertical movement - multi-floor TROR elevator for example.

It is possible to fudge this; when a sprite crosses two sectors, come up with a plan for adjusting x,y (setting sectnum exactly as per x,y) and then use xoffset and yoffset to nudge it back into the correct position. Compare the attached image with previous one - I've placed the sprite in the player's sector, then manipulated xoffset and yoffset to put it back exactly where it was in the first image. The sprite no longer dissapears. It's a solution - but probably more complicated than it is worth.

TTFN,
Jon

Attached thumbnail(s)

• 

[December Man]

 Hendricks266, on 06 October 2015 - 07:34 AM, said:

We're not going to give this one to you. You need to learn how to script for yourself. It's possible to understand the entire process by reading the existing code. It's essential if you want to script anything of significance.

Ok, thanks for the motivation. I figured it out, but I don't know whether this is the optimal way to do it. Currently, the shrunken enemy dies before Duke actually steps on him.

gamevar TEMP6 -1 1

state genericshrunkcode

  ifcount 32	
  {
      ifactor ENEMY
	{
	  ifpdistl SQUISHABLEDISTANCE
	{
		ifvarvarg player[THISACTOR].actorsqu TEMP6		
		{	
        addkills 1
		sound SOUND
		debris SCRAP3 40
		debris SCRAP3 40
		debris SCRAP3 40
		debris SCRAP3 40
		killit
		}
		getplayer[THISACTOR].actorsqu TEMP6
		}
		}
	else
		ifactor ENEMY2
	{
		  ifpdistl SQUISHABLEDISTANCE
	{
	    ifvarvarg player[THISACTOR].actorsqu TEMP6
		{
        addkills 1
		sound SOUND
		debris SCRAP3 40
		debris SCRAP3 40
		debris SCRAP3 40
		debris SCRAP3 40
		killit
		}
        getplayer[THISACTOR].actorsqu TEMP6
		}
		}
		
    ifpdistl SQUISHABLEDISTANCE
    pstomp
  }
  else
  {
    sizeto MINXSTRETCH MINYSTRETCH
    spawn FRAMEEFFECT1
  }
ends

[Mblackwell]

Run pstomp before killit.

[Fox]

 The Mechanic, on 09 October 2015 - 09:53 AM, said:

In my example image, the sprite is in its correct sector, its just that it is bigger than it's sector.

When moving sprites slowly between sectors, there will always be the situation at some point where the center of the sprite is in one sector (and has the correct sectnum value) but part of the sprite is in another sector.

That's fine. It's just recommended to always have sprites on their correct sectors, since otherwise it's undefined behavior and you should expect glitches. For example, you have a sprite in a door sector. If the door closes, the engine will detect that there's no line of sight between the player eyes and that sector, and the sector along with its walls and sprites won't be rendered. If you have a sprite outside of the door sector, but with its current sector ID being that of the door, it will become invisible when the door closes.

[Mark]

Mechanic, if you happen to come across a way to set a bit on a model to make it stay rendered at all times that would be great. I thought I would mention it here because it kinda ties in with what you and Fox were discussing.

[The Mechanic]

 Mark., on 10 October 2015 - 02:47 AM, said:

Mechanic, if you happen to come across a way to set a bit on a model to make it stay rendered at all times that would be great. I thought I would mention it here because it kinda ties in with what you and Fox were discussing.

Question is why is the sprite not getting rendered ?

If you have disappearing sprites due to them being in a sector but the sprites were bigger than that sector, you may be able to fix that with two identical sprites, one in the original sector then place the second in the other sector and use xoffset and yoffset to make it render where the first one is. That way if one of them isn't rendered then the other one is.

TTFN,
Jon

[Mark]

Its intended use is for large models used for buildings and terrain where the origin sector maybe be nowhere near the player's view. Also for complicated and heavy model usage indoors where pipes,cables, vents etc... would be scattered all around and again their origin sectors would get out of player's view when turning around. Or stringing power lines across a city map where buildings might block the origin sector. Many more uses but you get my meaning.

[Fox]

That's a clever solution, but wouldn't work for transparent sprites, unfortunately.

[The Mechanic]

Mark., on 10 October 2015 - 07:46 AM, said:

Its intended use is for large models used for buildings and terrain where the origin sector maybe be nowhere near the player's view. Also for complicated and heavy model usage indoors where pipes,cables, vents etc... would be scattered all around and again their origin sectors would get out of player's view when turning around. Or stringing power lines across a city map where buildings might block the origin sector. Many more uses but you get my meaning.

I have an idea, though how practical it is in reality I don't know.

Attached image shows red overhead wires, one of which vanishes because it is in a sector (round the corner) not visible to the player. The following code illustrates the idea behind the fix, where the wire that goes missing is hitagged 666 :-

onevent EVENT_GAME
	getactor[THISACTOR].hitag temp3
	ifvare temp3 666
	{
		ifcansee
		    nullop
		else
		{
		    getactor[THISACTOR].sectnum temp3
			ifvare temp3 0
			{
				setactor[THISACTOR].x 29568
                                setactor[THISACTOR].xoffset 0
				setactor[THISACTOR].sectnum 1
			}
			else
			{
				setactor[THISACTOR].x 30080
                                setactor[THISACTOR].xoffset 8
				setactor[THISACTOR].sectnum 0
			}
		}
	}

endevent

OK, I hackcoded it here, but you get the idea. How feasible it'd be to automate this in a more general case I don't know.

Also in the attached map I made a second version - follow the red arrow - no CON code needed, simply duplicated the missing sprite, moved it to another sector and adjusted it's xoffset to put it exactly where the original one was. Visually overlapping which, depending on where you are and where you are looking, one may vanish but the other remains visible. Now I appreciate this may be somewhat awkward with more complex structures.

Thing is, adding a pucka eduke flag isn't so easy. OK, adding the flag is , but how do you define "always render", bearing in mind sorting is needed for who-is-in-front-of-who during rendering, that kinda thing. The situation could be improved if in addition to the rendering process using the center of a sprite for a render/no-render decision, it included say both ends of the sprite. But in particularly complex scenarious even that might fail This would require multiple player-can-see operations as well as calculating sector numbers in which those ends appear. Probably a lot of (computational) effort. Maybe someone with more detailed knowledge of the inner workings of the rendering process could better comment, but my gut feel is it would be difficult.

If I've misunderstood your issue, perhaps start a new thread with a small test map and lets see what we can do.

TTFN,
Jon

[EDit] OK, now I have me specs on, it isn't quite doing what I thought, bear with me whilst I work it out.

Attached thumbnail(s)

• 

Attached File(s)

•  missing-sprite.zip (1.35K)
  Number of downloads: 531

[Fox]

It would be better to do it with CON. Detect is the sprite is crossing wall, and spawn identical sprites within the additional sectors. Then use animatesprites to make sure only one of the sprites is displayed at once.

[The Mechanic]

(added missing xoffset stuff to code snippet).

I chose bad example sprites, hidding my error.

It seems xoffset may be ignored if altered during game (or I need to call something I'm not aware of). The version where I just overlapped two sprites worked but the "CON" version doesn't seem to change the xoffset and also wont reset the position to original position when required.

Fox, on 10 October 2015 - 11:34 AM, said:

It would be better to do it with CON. Detect is the sprite is crossing wall, and spawn identical sprites within the additional sectors. Then use animatesprites to make sure only one of the sprites is displayed at once.

I think you are absolutely right, the way to do this is to spawn dupicates (triplicates, whatever), moving sprites at runtime just aint gonna work.

The "spawn" command in CON only spawns what a respawn sprite can spawn. How do I spawn/create a regular decorative sprite at runtime?

TTFN,
Jon

[Fox]

You can spawn any sprites, but you have to set the x-yrepeat and etc manually.

[The Mechanic]

Fox, on 10 October 2015 - 12:21 PM, said:

You can spawn any sprites, but you have to set the x-yrepeat and etc manually.

D'Oh ! Yes, I just discovered that. It was odd because I spawned tile 764 (building sprite) and nothing appeared, however using DNDEBUG and loading debug.map it DID appear in mapster when in 2-D mode and even drew "correctly" (as in how I expected it not realising about xrepeat) in 2D mode (when you press the [backspace] key to show textures in 2D mode).

Perhaps Mark could supply a test map giving the idea of the complexity of the areas he is dealing with. There would be lots of corner cases in spawning copies but if those corner cases 'aint going to happen in reality then things could be kept relatively simple. For exampe, xoffset is a fairly coarse adjustment so it is conceivable that you can't actually position the duplicate in the sector you want.

TTFN,
Jon

[Mark]

I know that if you are in 3rd person mode and raise the " player " camera up high, models that normally wouldn't render with the view from the ground do render when the view is up high because you are seeing so many more sectors. I don't suppose there would be a way to have 1st person player view but use data from a " second up high camera type thingy over the player " to render the models that you need to stay rendered at all times. I know it sounds goofy but I'm desperate.

EDIT: I re-read my post. Its looking even more impossible to implement. Never mind.

[The Mechanic]

Mark., on 10 October 2015 - 12:58 PM, said:

I know that if you are in 3rd person mode and raise the " player " camera up high, models that normally wouldn't render with the view from the ground do render when the view is up high because you are seeing so many more sectors. I don't suppose there would be a way to have 1st person player view but use data from a " second up high camera type thingy over the player " to render the models that you need to stay rendered at all times. I know it sounds goofy but I'm desperate.

I like the lateral thinking ! Suspect rendering a different view from the position deciding what to render may be a world of pain coding-wise, depends on how tightly coupled things are I guess.

Mark., on 10 October 2015 - 12:58 PM, said:

EDIT: I re-read my post. Its looking even more impossible to implement. Never mind.

Aww, you give up to easy Depending on complexity of sectors, it is entirely feasible to have CON code to spawn a duplicate structure somewhere else that is offset to appear in the original position. For efficiency reasons, the mapper might need to tag the sprites that need special treatment, but for the mapper it need be no more complicated that that.

TTFN,
Jon

[Mark]

I'm thinking you would need a bunch of duplicates to insure the model never disappears from any angle or spot in the map and how to determine which one to render if more than one origin sector is visible. Plus if there are going to be multiple models that need this style of rendering it would get glitchy. My brain hurts... Just carry on with what you were doing before I butted in. It sounds like you're busy enough.

[Mblackwell]

What if you simply position the sprite forcefully in front of the player, and then put it in the correct position in EVENT_ANIMATESPRITES (using tspr)?

For set dressing where collision isn't important it might work, but it's just an idea and could fail spectacularly if it (the engine) does any checks after that event triggers.

[Fox]

That would cause far more problems than solve.

If you want to force all sprites to be rendered, you can use this:

gamevar Temp1 0 0
gamevar Temp2 0 0

gamearray TempSectnum 16384

appendevent EVENT_DISPLAYSTART
  ifvarn rendmode 0
  ifvare Temp1 0
  {
    setvar Temp2 0
    whilevarvarn Temp2 16384
    {
      ifvarn sprite[Temp2].statnum MAXSTATUS
      {
        setarray TempSectnum[Temp2] sprite[Temp2].sectnum
        setactor[Temp2].sectnum camerasect
      }
      addvar Temp2 1
    }
    setvar Temp1 1
  }
endevent

appendevent EVENT_DISPLAYREST
  ifvarn rendmode 0
  ifvare Temp1 1
  {
    setvar Temp2 0
    whilevarvarn Temp2 16384
    {
      ifvarn sprite[Temp2].statnum MAXSTATUS
        setactor[Temp2].sectnum TempSectnum[Temp2]
      addvar Temp2 1
    }
    setvar Temp1 0
  }
endevent

But there are some issues with this solution:

• It works by changing the current sector to that of the camera view after the game worlds is processed, but before animatesprites. Thus sprites shade, palette or visibility depends on the current camera sector.
  
• You can see everything from the map through parallaxed skies.
  
• If there are two sectors occupying the same space, you can see the sprites from one sector on another.
  
• Always rendering all sprites (or models) it will consume too much CPU. Sprites disappearing is an intended effect afterall.

[Mark]

Thats why the solution has to include the ability to pick and choose only specific models to render always. I rarely if ever changed the palette of a floor in a map to other than zero and I use spritenoshade a lot so maybe 2 of those issues disappear?

Its been a long day at the computer. I'll try out your code tomorrow. Thanks.

[Mblackwell]

You could do the same thing but with a unique statnum, which could be set via F8. You could use htflags to force pal and shade to the intended values. You also wouldn't have to cycle through all sprites every frame. Clever girl.

[The Mechanic]

Fox, on 10 October 2015 - 05:26 PM, said:

If you want to force all sprites to be rendered, you can use this:

....
appendevent EVENT_DISPLAYSTART
  ifvarn rendmode 0
 ...

I'm curious, why woudn't this work in rendermode 0 ?

TTFN,
Jon

[The Mechanic]

What is the correct way of moving a player ? In the following test code I have a group of sprites all being moved by deltax/y/z and if I detect a player stood on one then I move the player too.

		// Eduke """"feature"""": 'movesprite' only moves half way, so double delta values
		mulvar temp1 2
		mulvar temp2 2
		mulvar temp3 2
		
        // Loop through all sprites in group and move by delta's
		setvarvar temp4 THISACTOR
		whilevarn temp4 -1
		{
			// Current pos becomes previous pos
			getactor[temp4].x temp5
			setactor[temp4].htbposx temp5
			getactor[temp4].y temp5
			setactor[temp4].htbposy temp5
			getactor[temp4].z temp5
			setactor[temp4].htbposz temp5
			
			// Move da sprite
			movesprite temp4 temp1 temp2 temp3 0 RETURN

			// If player 0 was standing on it then move player too - TODO : Multiplayer,enemies...
			setvar temp5 0
			getplayer[temp5].sbs temp5
			ifvarvare temp5 temp4
			{
				divvar temp1 2
				divvar temp2 2
				divvar temp3 2
				
				setvar RETURN 0
				getplayer[RETURN].posx temp5
				setplayer[RETURN].oposx temp5
				addvarvar temp5 temp1
				setplayer[RETURN].posx temp5
				
				getplayer[RETURN].posy temp5
				setplayer[RETURN].oposy temp5
				addvarvar temp5 temp2
				setplayer[RETURN].posy temp5
				
				getplayer[RETURN].posz temp5
				setplayer[RETURN].oposz temp5
				addvarvar temp5 temp3
				setplayer[RETURN].posz temp5
				
				updatesectorz player[RETURN].posx  player[RETURN].posy  player[RETURN].posz temp5
				setplayer[RETURN].cursectnum temp5
				
				mulvar temp1 2
				mulvar temp2 2
				mulvar temp3 2

			}

			getactorvar[temp4].nextsprite temp4
		}

When viewing the sprites in motion they are moving nice and smooth in all three dimensions. When Duke is carried on the sprites he also seems to move smoothly judging by the scenery but the group of sprites have a small bobbing up-and-down motion with a cycle of 1 second.

Is there a better way of moving the player ?

TTFN,
Jon

[Fox]

The Mechanic, on 11 October 2015 - 12:13 AM, said:

I'm curious, why woudn't this work in rendermode 0 ?

TTFN,
Jon

No reason, I was just thinking of a hack for models.

[Mark]

If you have view bobbing turned on in the menu maybe its affecting your stuff?

[Mark]

Hey Fox. Partial success. Models stay rendered and the framerate hit wasn't too terrible. But the side effects so far are any floor aligned models have an slight oscillating shimmy and shake and my zombies ( I'm testing in my Graveyard mod ) are looking like they have neon lighting on the edges. Maybe something to do with their normal and spec maps being slightly affected. Also I needed a newer version of Eduke because the older one I need to use in Graveyard did not like the appendevent command. So I temporarily slapped in the latest version and the error messages went away.

[Fox]

It would be possible to improve this code, but it's still a shitty hack. You should ask Eduke32 developers to include an event to control the displaying of sprites.

[Mark]

Hendricks and TX are busy with other stuff, Plagman isn't around much and Helix said he wasn't interested in new features at this time. Thanks for your effort. I'll just hang in there. Something might happen some day. Today's experiment gives hope.

[Hendricks266]

Fox, on 11 October 2015 - 07:31 AM, said:

It would be possible to improve this code, but it's still a shitty hack. You should ask Eduke32 developers to include an event to control the displaying of sprites.

Indeed I'm busy at the moment--from what I understand skimming the conversation, you're talking about always rendering sprites regardless of what sector they're in, for stuff like model-based terrain? It's been talked about before, and I'm going to be working in that area of the renderers for some Duke 64 stuff.

If you clarify to me what the request is, I can add it to the mental pipeline to implementation.

[Fox]

The discussion was about fixing the glitch which sprites and models disappear on the corner of sectors. Some smart code could be written if it was possible to control which sprites are rendered or not.

[December Man]

Mblackwell, on 09 October 2015 - 02:22 PM, said:

Run pstomp before killit.

I must've done something horribly wrong, since the placement of pstomp doesn't change a thing. Yes, I think I tried all the possible placement and the whole code I have written is just bad.