[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.

[Danukem]

December Man, on 12 October 2015 - 09:04 AM, said:

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.

pstomp begins a sequence which results in the deletion of the sprite that is issuing the command. It is NOT used in conjunction with killit, in any order. You either use pstomp to delete the sprite, or you use killit, you do not use both. If you have any questions, look at how it is used in an unmodified GAME.CON, or look at the source code.

[Mblackwell]

And all code that you want to execute has to be run before the sprite is deleted. Telling the game to delete a sprite results in the end of its code execution.

[OpenMaw]

Is it possible to edit the Shareware of Duke3D and run it with Eduke32, but still have it considered the "shareware" version?

Alternatively, is there a way to compile a .grp that handles like a shareware copy of Duke3D?

[Hendricks266]

The short answer is yes, but why?

[Daedolon]

Bitches love shareware.

[OpenMaw]

Only for nine levels though, then they want you to pay for the rest. Hey-o!

It was just something I was curious about. I remember a long time ago trying to edit the shareware version of the game so I could release it standalone and any tampering with the grp resulted in the game thinking you were trying to run a full version.

[The Mechanic]

I was trying to detect a useractor being hit by a weapon, and unfortunately found the eduke wiki entry for ifwasweapon isn't very helpful - it mentions <weapon> but fails to give any details.

From examining the existing GAME.CON I've found:

COOLEXPLOSION1
FIREEXT
FIRELASER
FREEZEBLAST
GROWSPARK
KNEE
RADIUSEXPLOSION
RPG
SHRINKSPARK
SHOTSPARK1

Whilst the names of some of the weapons used in GAME.CON are obvious, some are not. SHOTSPARK1 appears to be both pistol and shotgun (so it seems you can't differentiate the two). As for COOLEXPLOSION1, looking through the code I thought COOLEXPLOSION1 was the octobrain's, er, whatever it's shot is called but it also appears to be fired by BOSS2 !?

Perhaps the Eduke wiki maintainer could update the relevent page.

TTFN,
Jon

PS: Also curious about FIREEXT, what is it ? I thought it might be the fire extinguisher but that actually appears (quite logically) as weapon RADIUSEXPLOSION. FIREEXT is only used in one place - in the player's code - where it simply duplicates the effect of a RADIUSEXPLOSION.

[Mblackwell]

It's all here:

http://wiki.eduke32....for_ifwasweapon

You can also theoretically check for SHOTGUN and CHAINGUN, which is just a shotspark1 actor with its extra/damage value defined by those constants.

[The Mechanic]

 Mblackwell, on 25 October 2015 - 01:39 PM, said:

It's all here:

http://wiki.eduke32....for_ifwasweapon

Cheers !

I did have a good search first but did not locate that section.

So, I'll modify my previous request to the Eduke wiki maintainer to add a link to this information from the ifwasweapon wiki page.

 Mblackwell, on 25 October 2015 - 01:39 PM, said:

You can also theoretically check for SHOTGUN and CHAINGUN, which is just a shotspark1 actor with its extra/damage value defined by those constants.

Out of curiosity how does an actor get access to this data (e.g. extra) for the weapon ?

TTFN,
Jon

[Mblackwell]

http://wiki.eduke32.com/wiki/Htextra does that help?

[Danukem]

Is there still no way to change the rotation of an in-game sprite using CON? I'm talking about the vertical rotation of the drawn sprite (not the angle). While I admit that I'm not very knowledgeable about this, it seems to me that since it is already possible to do this using the rotatesprite command on HUD sprites, then it should be possible to do it with in-game sprites (maybe by adding a functionality to tsprites).