ID:135408
 
What I mean is proc that would allow you to shrink or grow an image in size, by percents perhaps, this would give some games the illusion of depth in some cases with out the maker having to do it himself. It would be a nice feature to have Just an idea, post what you think please.
my words exactly. I think it would be great for making fighting game such as games like Super Smash Brothers and many other games. Multplayer action so if the guys move away from each other, more of the board becomes visible also the guys shrink in % and when they move in clsoer to each other, the board zooms in and the guys return to there normal state or a certain % depending where they are.

Sincerely,
Sonder
In response to Sonder
I was thinking this would be very useful for making BYOND FPS's, since you would be able to resize objects/walls as you move toward or away from them. As much as I'd like to see a feature like this added, I'd say the chances at present are very low.
In response to Sonder
It would be nice but you can currently achieve what you need but in a more lengthy way.
In response to DeathAwaitsU
Thats a point of the procedure, to save time for the maker.
In response to ZeroCrash
ZeroCrash wrote:
Thats a point of the procedure, to save time for the maker.

Also to make it better. A built in function to scale icons would most likely be faster than a user created one.
ZeroCrash wrote:
What I mean is proc that would allow you to shrink or grow an image in size, by percents perhaps, this would give some games the illusion of depth in some cases with out the maker having to do it himself. It would be a nice feature to have Just an idea, post what you think please.

Eventually (perhaps even soonish) we'll have icon procs that can read the pixels in an icon, so you could implement this yourself. Until then, though, it ain't gonna happen.

I figure the utility of this is probably a lot lower than you think, because BYOND's drawing is all so tile-based that until it's able to draw bigger than 32x32 sprites, scaling will be useless to you.

My guess is that if/when we move to OpenGL-based drawing, we'll have a big discussion of what new features are possible and how best to implement them.

Lummox JR
In response to Lummox JR
OpenGL?
In response to DeathAwaitsU
It is a graphics API. Byond currently uses BitBlt to display its graphics, and a conversion to OpenGL would make many interesting icon manipulation functions available.
In response to Loduwijk
Loduwijk wrote:
It is a graphics API. Byond currently uses BitBlt to display its graphics, and a conversion to OpenGL would make many interesting icon manipulation functions available.

Well, it's not just icon manipulation -- it's direct manipulation of the viewable area, meaning that some of that direct manipulation could be handed over to the BYOND developers themselves. OpenGL would allow fogging, shape drawing, tinting, translucency, and a lot more, all for a minimum investment of processing resources.

(I know you already know most/all of this, but I'm just adding on. ;-))
In response to Spuzzum
By the way, is BYOND a profit making business? I mean do you guys get any money out of providing us with BYOND?
In response to DeathAwaitsU
'Tis the opposite, or at least I do believe it was for a while. They were losing money out of it.
In response to Loduwijk
So who gives you guys all the money to make this service?
In response to DeathAwaitsU
Well, nobody, as he said, they are losing money, this is a privatly run gig.
In response to Scoobert
Yah. Dan and Tom are paying from BYOND (and always have done) out of their own pockets, using money they get from their "real" jobs.

Which is why we all get really annoyed when people waste their bandwidth and storage space.
In response to Crispy
Ah ok thanks.
In response to Lummox JR
Lummox JR wrote:
Eventually (perhaps even soonish) we'll have icon procs that can read the pixels in an icon, so you could implement this yourself. Until then, though, it ain't gonna happen.

I don't know how OFD did it, but he just recently created a small icon scaling demo:

icon scaling by OneFishDown

~X

[Edit] Fixed the link. Thanks Shadow.
In response to Xooxer
Xooxer wrote:
Lummox JR wrote:
Eventually (perhaps even soonish) we'll have icon procs that can read the pixels in an icon, so you could implement this yourself. Until then, though, it ain't gonna happen.


I don't know how OFD did it, but he just recently created a small icon scaling demo:

icon scaling by OneFishDown

In the current BYOND you can mask out all but a single pixel and duplicate it as needed to make a scaled version, without having to know what the value of the pixel is. That's a lot of icon arithmetic and will cause a significant drain on the CPU for large icons. This method is not practical for scaling large numbers of icons at runtime in a multiplayer world. * I think this impracticality is what Lummox was referring to when he said "it ain't gonna happen."

Some icon procs I've heard discussed (but are still just in the idea phase with no immediate plans to implement) would allow the program to examine the icon and spit out the final result without any intermediate icons. It would be faster and much more memory friendly than the above method, taking about the same resources as it currently requires to shade an icon a few times.

This may not be the same method OFD uses. I'm at a loss to explain why his demo has such a large rsc file.

One note for OFD: you can go up to 160x160 pixels for a single atom, allowing you to scale a single icon up to 500%.

A note to Xooxer: The link won't work as you posted it. (It's fixed in my reply.) The browser assumes it is a local page if you don't supply the http:// header.

* <small>I've also found that BYOND crashes if you build too many icons pixel by pixel in a single run, so it would be best to scale the icon ahead of time and save the results as a separate utility (similar to Lummox JR's Icon Cutter). If you want to do it dynamically at runtime, you absolutely should save the results to a cache file so that you don't have to repeat the process for the same icon.</small>
In response to Shadowdarke
Shadowdarke wrote:
In the current BYOND you can mask out all but a single pixel and duplicate it as needed to make a scaled version, without having to know what the value of the pixel is. That's a lot of icon arithmetic and will cause a significant drain on the CPU for large icons. This method is not practical for scaling large numbers of icons at runtime in a multiplayer world. * I think this impracticality is what Lummox was referring to when he said "it ain't gonna happen."

You can also mask out all but a single line of pixels to get an entire vertical or horizontal column. That would be better for scaling, as it would be much faster and consume less memory.

One note for OFD: you can go up to 160x160 pixels for a single atom, allowing you to scale a single icon up to 500%.

I have never heard of this. How exactly do you accomplish such a thing?
In response to Shadowdarke
The original .zip can be found here: http://s95013793.onlinehome.us/byond/users/rob/ icon%20scaling.zip (it doesn't have a large .rsc file there)

I limited it because it starts to run slow as it gets above 300%. But, that demo does generate the icons on-the-fly, but if you know what you'd need it for an could render them all when the game starts, it'd go a bit faster.

It scales them horizontally and vertically (separately), taking a strip of the icon and blending it to a new icon. The procs then return the list of new icons and it creates the overlays.
Page: 1 2