ID:1202462
 
Libraries like Zaltron's Effects and Shadowdarke's PixelProjectiles have all been doing the same thing: moving actual objects around. Despite what may at first seem logical, I don't believe that is the ideal method to achieving fast projectiles or other particle effects in BYOND. I think the fastest way would be to not move the objects at all and just rapidly change their icon states depending on the path of the projectile.

I'm not sure yet, but I think you could use bitwise operations on the actual image data to switch the colors much faster than the built-in icon procs. However, I don't really know if the bitwise operations would end up all that fast due to client-server communications. Supposedly, they work with the CPU on a very low level, but I don't know if that's actually the case in BYOND.

The idea here is that you would have an icon state for every "pixel" at every possible location, and simply switch them around based on coordinated names. However, "pixel" here would probably be defined as larger than an actual pixel, since otherwise you would need to switch between 1024 states an several layers for an icon size of 32X32. Since each one contains only a solid color with a single pixel, it should use a relatively small amount of RAM though.

Obviously the implementation would be completely different in the case of pixels. You would need a powerful datum that renders "shapes" out of these virtual pixels, and then another system that can make them appear to "move" around on the screen.

This is all just theory and speculation for now, so I have no idea of this would actually be feasible. It all depends on how well BYOND can handle a huge number of icon states, lots of layers, and the bitwise operators.

This would require quite a large, complex datum to implement, and the AND, OR, and ZOR thing is still very new to me, so I won't try making this "rendering" engine any time soon. Most programmers today probably take no notice of the bitwise operators, but perhaps they can be very effective in BYOND.

Sorry to make a long post here. I didn't want to make a whole topic about this. This concerns the subject of projectiles and particle effects anyway.
Kaiochao wrote:
That would be incredibly inefficient and would definitely freeze the game.
I thought someone might say that. I should run some kind of test to compare the efficiency of changing all the different vars and running all the different procs. It would be nice to have a reference that rates them some how.

Anyway, I'm curious why you say it would be so terrible. Is switching icon states really all that slow? I had figured it was the single most quick graphical change that can occur on a map, other than the frames moving. Are the movement procs somehow faster than just changing a var? That doesn't make much sense to me.

The best way to understand this is to think of a good example. Let's say you wanted to try moving 500 objects across the screen at once. Would it be faster to call Move() on each and every one of those, or just change the icon states enough times to make them appear to move to the destination? I think that the problem with using Move() in this case would just be caused by the great number of objects the proc is being called on. Changing the icon_state vars in loop a certain amount of times should ultimately end up with less overhead. This is only the case when you are dealing with really huge numbers of objects. If you just want to move 10 or so objects around then yes, Move() should always be faster.

Think about this. When using Move() to move the objects, that requires there to actually be "[insert rediculous amount]" objects on the screen at once. However, if you just change icon_state in loop, then all you need is enough objects to cover the screen! This means you are either calling Move() on some 500 objects or changing the icon_State of some 10 or so objects in loop. It makes more sense to me that the latter would be the more efficient method if it were done just right.

If you disagree with this, then please explain what's wrong with my logic, or where the inefficiency lies.
Kaiochao wrote:
Setting up a ton of subtiles at every possible location is simply not something BYOND can handle.

Besides, it's not just changing one variable. The concept behind pixel projectiles is 2D vectors. For every object, you have a coordinate (x, y). For every projectile, you also have a velocity (vx, vy). For every movement of the projectile, you have to adjust the projectile's position by its velocity AND check for collisions each step of the way.

This library is for colliding bullets. It's not just a visual thing. What you're proposing doesn't actually make sense, as you're suggesting that there's nothing guiding the pattern of changing icon states.
Kaiochao wrote:
Setting up a ton of subtiles at every possible location is simply not something BYOND can handle.

Perhaps you are misunderstanding. I don't want to make an object for every possible location. I want to make an object for each tile on the screen, then switch the icon states, which in total, would fill the whole tile, but you wouldn't have a large number at once within a single tile.

What you're proposing doesn't actually make sense, as you're suggesting that there's nothing guiding the pattern of changing icon states.

I left out this part because it is very complicated and hard to describe in words. This is what the datum would cover. You would need to name the each icon state based on the pixel coordinate of the "pixel" it contains, such as "1,1", "1,2", etc. Then, you would need to either use IconStates() to get a list of those states, or just code one in manually, since it only needs to be done once. Then, you would need to create a datum that can use the list of coordinate states to mathematically and dynamically draw paths onto tiles at different velocities (using something like a changing sleep() delay). For collisions, you would need to update a list of "virtual locations" of these projectiles, and compare the values to determine what goes where. There is a very high degree of math involved, but computers generally handle calculations like lightning, so that shouldn't be a problem.

I can't specify any more detail than that, as I'm not an expert on the subject, and haven't thoroughly examined how the processes would work.
I suspect it may be possible to pull off something similar without even needing to change the icon states at all, and just using some combination of ANDing, ORing, and ZORing on a complex image mask system. The image mask would be a next-to-invisible alpha image, where the actual colors of the alpha correspond to pixel coordinates. The bitwise operations on the image would change color values in a certain way to make certain pixels visible and others not.

Unfortunately this implementation would be even more complicated than the other one.
Ease wrote:
If you're just changing icon_states, and not using a layer of tiles across the whole screen, your pixel will only be able to travel across that single icon.

Also, the previous version of the library had a proc called Intercept() which checked the path of the pixel without actually moving it, and called Hit() on the first atom encountered under than path. However, it operated my getting a list of the turfs that the path passed through, and if the turf had any dense contents then it automatically hit them.

With pixel movement this function behaves improperly, as objects in the turf, but not under the thin path of the pixel projectile, will be hit too. Checking on a pixel by pixel basis would be needlessly complicated and most certainly more CPU-intensive.

Using the in-built BYOND Move() which automatically calls Cross() and Bump() when necessary (and on a pixel-by-pixel basis) is more pragmatic, at least in my eyes.

That said, if you could create a library and demo using your own proposed method I would be keen to see it, though I suspect your time would be better spent either developing a game for BYOND, learning programming, eating ants, or indeed anything else.
Magnum2k wrote:
I think you're over-complicating the scenario way too much. First of all, we have no low-level access to images, so your first suggestion is trivial. Actually, the method you're suggesting right now isn't even how most game engines would handle it. As Kaiochao said, pixel projectiles are just simply 2D vectors; they can't get any more difficult than that.

EDIT: It seems to me that you just discovered the concept of bitwise operators and it's now your one-stop solution to all of your problems.
Ease wrote:
If you're just changing icon_states, and not using a layer of tiles across the whole screen, your pixel will only be able to travel across that single icon.

I don't think you understand. I would be using a layer of tiles across the whole screen. Each tile would be an instance of the rapid state-switching object.

Using the in-built BYOND Move() which automatically calls Cross() and Bump() when necessary (and on a pixel-by-pixel basis) is more pragmatic, at least in my eyes.

Automatically calling a bunch of different procs and updating vars whenever it thinks it's necessary is exactly the problem with using Move() for this purpose. When designing a particle engine, it is important to keep the movement optimized, and only make calls when they are required. Move() automates too many things for you, and as a result, it will create quite a lot of overhead when calling it for hundreds of objects.

Magnum2k wrote:
I think you're over-complicating the scenario way too much.

I can understand why you would think that. This concept isn't exactly something that has been done in DM before. The idea behind this is to create the illusion of movement on a much lower level, in order to avoid 90% of the overhead associated with tons of objects and the built-in Move() proc calling a lot more things than necessary.

First of all, we have no low-level access to images, so your first suggestion is trivial.

That's too bad then. I was betting that the built-in bitwise operators would let me alter the binary data of a /icon object, since it does get loaded into memory. Is this not the case? If not, then that shouldn't be a problem anyway. I would just have to find another method of switching colors very fast.

Actually, the method you're suggesting right now isn't even how most game engines would handle it. As Kaiochao said, pixel projectiles are just simply 2D vectors; they can't get any more difficult than that.

BYOND isn't like "most game engines". It just can't do vectors that well with the built-in procs. It has a tile-based design and was never even built for vectors in the beginning. Basically, it uses sprites moving around a certain number of pixels relative to the tile-based map. There are no vectors involved there. Trying to make sprites do "vector" type movement is not going to work out very well. Sprites are already fully rasterized. Real vector engines work by "rasterizing" the vectors (or lines) that get calculated on the fly. The concept of them is completely, and fundamentally different from how BYOND works at all. This is why I am thinking of a way that you could effectively make a vector-interpreted rasterizing engine in BYOND, so instead of pixels moving around, you have lines and shapes appearing. This could even be extended to some very basic 3D software rendering, however slow it might be.

It seems to me that you just discovered the concept of bitwise operators and it's now your one-stop solution to all of your problems.

I don't know where you're getting that idea from. If I wanted to use bitwise operations for all my problems I would just go the rest of the way and program things in pure assembly, but we don't have to because we have great engines like BYOND to translate the high level source code for us. However, if an engine's higher level implementation of a procedure is inefficient or doesn't properly do something as needed, then that's when it's okay to use lower level functions. Besides, you can design your own procs around these functions that can be just as easy to call as the built-in functions.
Kaiochao wrote:
It's never been a particle engine. It's bullets being fired and hitting things.

There's nothing complicated about vectors, either. The simplest "particle" you can have is one that moves along a straight line (which is what these pixel projectiles are doing), minus the collision detection.
> //  This is a vector pointing southeast.
> var vel_x = 1
> var vel_y = -1
>
> spawn for()
> step_x += vel_x
> step_y += vel_y
> sleep world.tick_lag
>

What you're talking about is a lot more complicated than addition and is very unnecessary.
Kaoichao wrote:
It's never been a particle engine.

That depends on what your definition of a particle is. A particle engine can just as easily handle any kind of projectile. It doesn't have to be all tornados and fireworks. Projectiles themselves often have particles anyway. Think about rockets. They would have a trail of flame and smoke behind them. These concepts both rely on vectors, so it should be easier and more flexible to make a datum that can be used for both projectiles and random particles. Optimizing it for particles ensures that any projectiles you make will be really fast compared to the more CPU intense particles.
Magnum2k wrote:
Ok, so my question to you is, would you rather spend your time writing a potential, impracticable(and possibly even a lot more inefficient) solution to the current problem(which isn't really a problem, mind you) or use good 'ol trigonometry and accomplish the same task a lot faster and less obscure? ;)

Either way, I love the way you tackle problems though, you remind me of someone in my Comp Sci. class. :)

P.S. It wouldn't hurt to see your method. :)
I would rather use whatever solution can bring the absolute highest efficiency possible, regardless of the complications involved. It should be something that can really squeeze the most power out of BYOND.
Kaiochao wrote:
Again, this isn't a particle engine. It's a library for bullets that are fired and hit things.
It uses DM, so it's actually not better to have a million objects sitting around to catch every possible particle, instead of one object per particle.
You are mistaken on the number of objects involved there. My method would involve relatively less objects than this one. If you have 20 mobs on the screen all firing weapons, you will end up with hundreds of objects, instead of just the number of tiles required to cover the client's screen.
Kaiochao wrote:
So your projectiles aren't objects?
WHAT!? Did you just now figure that out?
No, my projectiles are only an illusion produced by changing icon states.
Kaiochao wrote:
What holds the information about the projectiles?
Appearance, velocity, bounds?
Maybe you should read through what I wrote again...

I'm not sure what you are asking there. The information would not be held by any built in vars. It would be held in associative lists specific to whatever data is needed, which would be updated by the datum when necessary.
Kaiochao wrote:
What's the difference between a list and an object?
Page: 1 2 3