Forum_account's Shoutbox

Page: 1 2 3 4 5 6 7 ... 19 20 21
Jun 10 2011, 3:43 pm
Is it okay that your CSS design gave me a boner?
Jun 21 2011, 8:58 am
The song

If you dont like it, i could make something else :o
Well, its not that "Calm" XD But it clings :)
Jun 24 2011, 11:45 am
Tafe wrote:
The song

If you dont like it, i could make something else :o
Well, its not that "Calm" XD But it clings :)

Hey, I finally got a chance to listen to it. I like it, it just doesn't fit any of the environments I've made so far. I'm not musically inclined at all so I don't know what I'd change to make it fit.

If you have any other songs, or even just bits of songs, I'll gladly take a listen. Hopefully I'll know what I want when I hear it =)
Jul 5 2011, 7:19 am
Hey FA, an outside user (perhaps affiliated with a gaming company) is trying to contact you regarding Tiny Heroes. I wanted to forward his info to you but it looks like your registered BYOND email is a throwaway. Can you contact me at [email protected] and I will send his info, and you can contact him back if you are interested.
Jul 6 2011, 2:52 pm
Ok, Forum_account...
I am not sure if i can make tracks to you atm, if so... youl have to wait. im going to move over to pro-tools, so i will probably spend the comming months exploring it. :)

FL_Studio really is some basic stuff XD
Jul 9 2011, 4:46 am
Hey, are you going to get around to making bounding circles any time soon? I feel like, a lot of shapes are circular. It would be nice. Thanks!
Jul 9 2011, 5:50 am
OrangeWeapons wrote:
Hey, are you going to get around to making bounding circles any time soon? I feel like, a lot of shapes are circular. It would be nice. Thanks!

A lot of shapes are circular, but most of the time you can represent them as rectangles. Most games represent your highly detailed 3D model as a simple shape (or a set of simple shapes), so most BYOND games will do fine with the approximation. You might not be able to use the library to make a billiards game, but I'm okay with that.

Having spheres really complicates 3D movement. If you find a case where you absolutely need it, I can offer some help in getting it to work. But I don't think I'll have the time to voluntarily implement this.
Jul 9 2011, 6:17 am
Well, I would use it for an RPG method of sorts. You know, certain attacks can be circular, and if you represent them by a bounding box, it will be unfair. Either the attack will cover too much of a radius, or not enough. Having to avoid something such as circle objects would be difficult to play out fairly.

Also, being able to do something such as have all mobs within an object's circle be affected by something. I know this is a weak, nerdy example, but check out Naruto's character Neji:

http://fc04.deviantart.net/fs39/f/2008/313/e/0/ Neji__8_trigrams_64_Palms_by_SaveSasuke_Kun.jpg

He uses an attack within a circle proximity. Think about your basic RPG. Using an attack that will hurt all of those within a circumference. It just seems, so basic, and necessary. Think about it. The top BYOND games aren't BYOND games, as SilkWizard has stated (and I happen to agree with).
Jul 9 2011, 6:41 am
You can do something like this:

mob/proc/circle(radius = 100)
    . = list()
    var/rad_sq = radius * radius
    for(var/mob/m in oview(src, round(radius / 32) + 1)
        var/dist_sq = (m.px - px) * (m.px - px) + (m.py - py) * (m.py - py)
        if(dist_sq < rad_sq)
            . += m

mob/proc/attack()
    // hit every mob within 200 pixels
    for(var/mob/m in circle(200))
        m.damage(10)


You don't need circular bounding boxes for things like this.
Jul 9 2011, 8:15 am
Wow, neat. Thanks! I shall definitely try to put this to use. I didn't know that you could so easily incorporate many ways for pixel movement to work efficiently.
Jul 9 2011, 10:32 am
By the way, I don't get why you're using mobs as projectiles instead of objects.
Jul 9 2011, 10:59 am
OrangeWeapons wrote:
By the way, I don't get why you're using mobs as projectiles instead of objects.

Because only mobs have movement loops. The pixel_move, movement, and set_pos procs aren't defined for objs (or for atom/movable). Objs are generally used for things that don't move, at least not in the same way that mobs do - objects placed on the map, items, etc., so I decided to not give them pixel movement. For an atom to use pixel movement it must be a mob.
Jul 21 2011, 9:45 am
pixel_move()
...
var/tx = (dpx == 0) ? 1000 : ix / dpx
var/ty = (dpy == 0) ? 1000 : iy / dpy


This spot in pixel_move() seems to cause errors if either dpx or dpy is 0, but not both. If only one or the other is 0 it reaches this step and brings up a division by zero error. It happens rarely but it's become pretty frequent with the multiple projectiles I'm using.

I honestly don't know why it's continuing on to do the division, even though there's basically a sanity check right in there, but it's happening and it's the only time that any division happens in the proc.

Error:
runtime error: Division by zero
proc name: pixel move (/mob/proc/pixel_move)
usr: null
src: the bullet (/mob/bullets/bullet)
call stack:
the bullet (/mob/bullets/bullet): pixel move(24, 0)
the bullet (/mob/bullets/bullet): movement()
: movement()
: movement loop()
: movement loop()
Jul 21 2011, 9:47 am
This happens with an old version of the library; I encountered it quite a bit. I made a post on the forum somewhere, so please let me know if you can't find it. It contains a solution.
Jul 21 2011, 9:49 am (Edited on Jul 21 2011, 9:55 am)
Thanks, much obliged.

to F_A: the new performance boosts are incredible, I'm able to manage about 50 mobs at once now. Very smooth. =)

Edit: Found it in the forums but it seems to be a fairly new issue that he's looking into Here
Jul 21 2011, 10:57 am (Edited on Jul 21 2011, 11:10 am)
Thanks, I'm glad to hear that. Enabling the two dimensional mode really speeds it up.

I don't think I mentioned it anywhere and without looking at the library I'm only 75% sure this'll work, but if you don't need a mob to trigger the stepped_on and stepped_off proc you can set its on_ground var to always be zero. The set_pod proc maintains the list of atoms you're standing on and this will disable that. It should make a noticeable difference.

Edit: I'll look into the divide by zero error but I don't know when ill have the time.
Jul 22 2011, 9:22 am
Hey,

I've been meaning to actually start a game with your sidescroller library, but I have a question that really only you'd be able to answer because you designed it and know the code so well -

If I wanted to create a game that utilized a foreground and background for movement (and the player can alternate between the two)... how useful would your library be, and what way would you go about appending it if you were to make this very game?

It's been an idea I've had for a while and while I made a (relatively decent) sidescroller library for myself a while back, it's not damn near complete and is still slower than yours.

Would appreciate a response back if you have any ideas for me. Thanks.
Jul 22 2011, 10:21 am
I'm not sure how you'd want it to look, so I don't know how you'd handle the visual aspects of it. Here's what I'd do:

Have a proc that merges two z levels. It takes a z level and adds it as the foreground of another by creating objs to represent each turf from the second map. These objects would be visible when the player is on the foreground and partially transparent when they're on the background.

To handle the movement you'd override the can_bump proc so that you only bump into an atom if you're both in the foreground or both in the background.
Jul 22 2011, 11:08 am
Byond 489: Handling of pixel offsets for movable atoms has been improved, causing network performance gains for games that make heavy use of pixel offsets for smooth movement.

It just keeps getting better ;3
Jul 22 2011, 6:14 pm
How would I go about easily implementing diagonal pixel movement? Take your time with answering, this isn't my top priority at the moment. Thanks!
Page: 1 2 3 4 5 6 7 ... 19 20 21