ID:136952
 
318 (notes)

That last patch had some problems .. hopefully this will clear it up. Also, it introduces a few new long-awaited parameters to fine-tune the graphics display and movement. Look inside to see!

Also, check out the slick new logo courtesy of our very own Air-Mapster. Wooooh!
Tom wrote:
...check out the slick new logo courtesy of our very own Air-Mapster. Wooooh!

I noticed that while I was doing some maintenance at digitalBYOND - I was thinking "whoa!" where'd the new graphic come from! ...looks good AirMapster!
a-w-e-s-o-m-e

I am already thinking of ways to use the new features.

As fond as I was of the old blobular logo, this one does look snappier. Though the pinkness of the electrons is startling.

Z

In response to Zilal
True, but it goes nicely with the link on the login page. Otherwise, that color doesn't show itself that often on BYOND.
In response to Zilal
Zilal wrote:
Though the pinkness of the electrons is startling.

Pink, eh? Hmmm...looks more red on my monitor at work (Sony 21" LCD) (we are very *spoiled* here...)

...after looking at it for a few minutes, I guess it does look somewhere between pink and red - no matter; looks good anyway...
The pixel offsets are normally 0,0 and may range anywhere from -32 to 32.

Whoa! Cool! This was probably #1 on the list of "features I don't dare request." Very timely, too, for what I'm working on. Unfortunately I probably won't have a chance to try it out until the weekend... grr.

In response to Gughunter
Gughunter wrote:
The pixel offsets are normally 0,0 and may range anywhere from -32 to 32.

Whoa! Cool! This was probably #1 on the list of "features I don't dare request." Very timely, too, for what I'm working on. Unfortunately I probably won't have a chance to try it out until the weekend... grr.


I don't really understand what this does....
OK, I just switched Bombard over to using pixel_x and pixel_y, and... ew. This is obscene. It can't possibly be legal to run this smoothly.
In response to Leftley
Leftley wrote:
OK, I just switched Bombard over to using pixel_x and pixel_y, and... ew. This is obscene. It can't possibly be legal to run this smoothly.

This makes BfS work perfectly too.
In response to Sariat
The pixel offsets are normally 0,0 and may range anywhere from -32 to 32.

I don't really understand what this does....

Objects are still located on a fixed grid, but icons are no longer restricted to grid coordinates. You can shift them around however you want. You can even attach overlays or images that stick out in any direction you wish.

This feature went out to Shadowdarke, in sympathy for having busted a lot of his code by changing sleep(). I figured this would do wonders for his new project.

The SYNC_STEPS feature goes out to Deadron and all the others who have been suffering with multi-bodied objects that occasionally break up.

--Dan
In response to Dan
The SYNC_STEPS feature goes out to Deadron and all the others who have been suffering with multi-bodied objects that occasionally break up.

And let's not forget the smooth movement speed! That alone would make me give away my first-born. Well, if I had a first-born.
In response to Sariat
Sariat wrote:
I don't really understand what this does....

Me either...the pixel stuff is a bit mysterious to me, but I sure can understand that SYNC_STEPS one! That will make L&D sooo much better.

Here is a thought: Would the new pixel functionality let us do up to a 9x9 tile object with just one object? That is, if you set eight overlays with pixel offsets at the extreme corners and edges of the middle object, would you effectively take up almost 95x95 pixels for the object?

If so, would this be more efficient than moving 9 objects around in that case?

If all the above is true, perhaps it will be time to revisit my multi-tile functionality to take the more traditional approach where the mob exists at the center and collision checking is done by checking a radius around the center.

Collision checking and such would be a pain, but it could significantly reduce the number of objects on screen.
In response to Deadron
Well, for starters, it means using the Shift proc for icons is obsolete for most uses.

There is one part that I don't get, though:

"The pixel offsets are normally 0,0 and may range anywhere from -32 to 32. (You can get away with larger offsets, but they are not guaranteed to work when the object's grid location goes off the edge of the screen.)"

How do you get away with having a range of 65 before running into problems? And what exactly does happen should you set the offset more than one tile over and that puts it off the edge of the map or screen?
In response to Dan
Dantom, Awsome! this new version stopped my Dreem Maker from crashing when i put somthing like
mob/proc/DeathCheck()
if(usr.HP <= 0)
usr << "you died!"
usr.loc=locate(1,1,1)

you get the point. i couldnt tab it corrrectly, seeing how im in school, and limited on time.
but everytime i would hit Compile upon adding that code in an error would appear somthing in some .DLL file, and it will now close so i would close it and it wouldnt save, that was with versions 316-317, 318 has done wonders :) Thanks again!
keep up the good work.
- RaeKwon
P.S. i like the new features you added in ;)
When I read the pixel offset stuff I started drooling. This makes so many things feasible that weren't before, including hex-based games (and smooth movement from hex tile to hex tile!), small projectiles, particle systems....

Gads, one dirt-simple thing is to go back to an image snippet I posted (I think in Newbie Central) a few months ago for a meter that follows your mob around one tile over. Setting one of the image's pixel offsets to -32 or 32 would do the job beautifully, and no extra objects would be needed.

A much more recent suggestion, ExAdv1's idea for a car demo, becomes much more realistic. Racing games that would have been ridiculous to attempt before can be done.

It's actually a shame Incursion won't use much of this stuff--though I think it could have benefited more early in development if I'd taken some things in a different direction. Most of the sub-tile stuff is done now with directional icons (which are more convenient) or with icons that get overlapped and built dynamically.

At some point I may amuse myself playing with some of these features, maybe to build an interesting demo or a small game. The capabilities of BYOND have just stepped up dramatically with a simple change. A thousand thanks!

Lummox JR
Tom wrote:
Also, it introduces a few new long-awaited parameters to fine-tune the graphics display and movement. Look inside to see!

I may be missing something about SYNC_STEPS...the doc says:

"You should have at least one object in the conglomerate without SYNC_STEPS set; that object will serve as the leader of the others when determining movement speed."

Here is my situation: The typical multi-tiled mob is 2x2, with the lower left-hand corner being the "lead" mob. So I set all the non-lead mobs to SYNC_STEPS. What is happening is that the SYNC_STEP mobs are moving in unison, but without sliding animation (they just pop from turf to turf), while the head mob uses sliding animation.

So 3/4 of my mob jump to the next location, while my head mob slowly slides in place. (It's sort of like a pirate effect.)

If I set the head mob to also have SYNC_STEPS, then everything moves in unison, but with no sliding animation.

Am I doing something wrong?
"...wreathed in flame" - Saruman

I'm feelin like we're getting really close to that big icons thing. It should just be for atom/movables as turfs would overlap all weird, but with this new pixel_offset thing, it looks like we're really close to getting big mobs. The wreathed in flame thing is because I really want REALLY big demons in Maeva, and dragons. PLEASE! I'm sorry, I'll shut up now.

DerDragon, the ever hopeful creator of Maeva.
In response to DerDragon
I'm feelin like we're getting really close to that big icons thing.

Well, considering that the maximum size of an icon is now effectively 96x96, I'd say we're very close indeed!
In response to Leftley
"The pixel offsets are normally 0,0 and may range anywhere from -32 to 32. (You can get away with larger offsets, but they are not guaranteed to work when the object's grid location goes off the edge of the screen.)"

How do you get away with having a range of 65 before running into problems? And what exactly does happen should you set the offset more than one tile over and that puts it off the edge of the map or screen?

When rendering the map, objects directly outside of the visible map are taken into account, so effects attached to them that are shifted over into the visible region will work. However, objects outside of that border region are not taken into consideration, so effects from them (even when shifted over more than 32 pixels) are not visible.

Asside from that, the can do pixel offsets from -95 to +95. Beyond that, you will run into problems with the size of the offset variable currently used to handle pixel offsets in combination with smooth movement.
In response to Deadron

Here is a thought: Would the new pixel functionality let us do up to a 9x9 tile object with just one object?

Yes. Of course, this may or may not be convenient, depending on whether you want the extra space to be filled in the grid for the purpose of Bump() and what-not. In general, if you do not want the extra space to be filled, this method (just using offset overlays) is more efficient, but I would recommend doing whichever is easier in a particular case.

--Dan
Page: 1 2 3