Byond and rotational attacks in Developer Help

ID:240606
 
Feb 2 2012, 10:45 pm
(See the best response by Forum_account.)
Problem description:
I have an aimer that is 224x224 that in-game has to have the ability to be fully-rotated all 360 degrees. The problem is DM even lags when I attempt to open the .dmi and in game there's a huge lag spike when I load up the obj with the aimer icon. It is however pretty fine after that.

Can anyone think of any workarounds?
#1 Feb 2 2012, 11:01 pm
Take a look at the icon/Turn() proc, it should allow what you want, but it's a little processor intensive.
#2 Feb 2 2012, 11:41 pm
I already have the icon with 360 icon_states each one turned by 1 degreee. The problem is that its very to open up. And if your suggesting to create each state dynamically the it is exactly as you said it is processor intensive.
#3 Feb 2 2012, 11:44 pm
The only other thing you can really do about it, as far as I'm aware, is make the icon smaller, does it really need to be that huge?

Edit: I just thought, have you tried separating each state/frame into separate icon files and loading them individually? That would cut down on the long load time without needing to be rendered at runtime.
#4 Feb 2 2012, 11:51 pm
The original aimer is 96x32 but since it needs to be perfectly rotated it needs to be that 224x224. [Trust me did the math]. The second one intreges me however, but I'd need to know how many sections I'd have to break it up for it to be effiecient enough Quadrants or maybe even eighths.


*edit*
Or maybe give each one a seprate icon... That seems like it would work really well. Just I'd have to make sure each one gets into the resource file which would be a pain.
#5 Feb 3 2012, 12:52 am
No. You don't need 360 different states. Try 72 states (one per 5 degrees) or 32 states (one per 11.25 degrees)
#6 Feb 3 2012, 1:07 am
This is an aimer for an attack [long ranged at that] I've tried 5 degree intervals and it feels too clunky for aiming. It feels like the game is lagging and isn't aiming where you want it to aim.
#7 Feb 3 2012, 3:04 am
I really wanna point out that your choice of 360 states is incredibly arbitrary. Obviously you're going for 1 per degree, but a degree is just an arbitrary scale. You really can break it down into 180 (per 2 degrees) and 120 (per 3 degrees) or more, as a change of 1 degree is barely-perceptible.
#8 Feb 3 2012, 4:14 am
In response to Popisfizzy (#7)
Depends on situation.
I worked a little with 3D graphics and when I used pi value with 3 digits after comma, instead of 6, there was a huge gap between separate 3D objects. In degrees such difference is only about 0.04 degrees.
#9 Feb 3 2012, 6:39 am
In response to Zaoshi (#8)
Zaoshi wrote:
Depends on situation.
I worked a little with 3D graphics and when I used pi value with 3 digits after comma, instead of 6, there was a huge gap between separate 3D objects. In degrees such difference is only about 0.04 degrees.

What.
#10 Feb 3 2012, 6:49 am (Edited on Feb 3 2012, 7:46 am)
Popisfizzy wrote:
I really wanna point out that your choice of 360 states is incredibly arbitrary. Obviously you're going for 1 per degree, but a degree is just an arbitrary scale. You really can break it down into 180 (per 2 degrees) and 120 (per 3 degrees) or more, as a change of 1 degree is barely-perceptible.

My clients view by default it 30x20 [which can be full screened capping around 40x40] If the person is aiming at another player a 30 tiles away a one degree difference is a huge deal.

Also:

Popisfizzy wrote:
Zaoshi wrote:
Depends on situation.
I worked a little with 3D graphics and when I used pi value with 3 digits after comma, instead of 6, there was a huge gap between separate 3D objects. In degrees such difference is only about 0.04 degrees.

What.

Pretty straight-forward. basically 0.04 degree differences in rotation makes huge differences. :\
#11 Feb 3 2012, 8:09 am
In response to Tubutas (#10)
Tubutas wrote:
Pretty straight-forward. basically 0.04 degree differences in rotation makes huge differences. :\

Like Popisfizzy said, the increments you use should be tailored to your situation. Relying on arbitrary figures from some random software probably isn't the way to go.

That said, maybe we are underestimating the level of precision you require; perhaps if you shared an example or mock-up of what you are trying to achieve, people could offer greater assistance.
#12 Feb 3 2012, 8:10 am
I guess I'll release a demo of it.
#13 Feb 3 2012, 8:19 am
Create the icon as a single state (of it pointing north or whatever). Use the code based icon procs to generate a list of 360 new icons in-game (in world/New(), for example), one for each angle. Then just change the icon of the object to the relevant icon from this list each time it updates, instead of keeping all 360 states in a single file, or generating redundant new icons every time it turns.
#14 Feb 3 2012, 9:03 am
I turns out the lag only exists when initially calling on the icon, but the lag is pretty noticeable. I want there to be at least two [minumum realisticly I want 5-10 types] of this aimed type attack though. It freezes for about a second everytime I try to open it up
#15 Feb 3 2012, 6:56 pm
In response to Robertbanks2 (#1)
Best response
Robertbanks2 wrote:
Take a look at the icon/Turn() proc, it should allow what you want, but it's a little processor intensive.

BYOND supports some client-side icon operations. It may still be processor intensive, but being done on the client is better than doing it all on the server and transmitting new icons to the client.
#16 Feb 3 2012, 7:16 pm
As long as I preload the icons [world/new give the make a new obj with a loc, there is no visible in-game lag.

http://dl.dropbox.com/u/7032543/SkillShotDemo.zip

Link to demo if anyone is intrested in what I am attempting to do.