SHOW ME WHAT YOU GOT. [Show off your project!]

Page: 1 2 3 ... 199 200 201 202 203 ... 349 350 351
Jun 8 2016, 4:43 am


Decided to try implementing a line-drawing algorithm, which works okay for the most part with some exceptions.
Jun 8 2016, 4:57 am


Then this happened.
Jun 8 2016, 5:46 am


Sorry for so many gifs.
This uses a circle algorithm (definitely doesn't generate symmetrical circles).
Jun 8 2016, 5:58 am

(They look a lot smoother outside of the gif, by the way)
Jun 8 2016, 6:12 am

Generating a surface using turf shifting.
Jun 8 2016, 6:32 am
Using pixels to make pixels... can you run Minecraft within this?
Jun 8 2016, 6:40 am
This uses a circle algorithm (definitely doesn't generate symmetrical circles).

The reason that your circle algorithm doesn't make symmetrical circles is that you are using a floor() function. Cartesian Quadrants 2, 3, and 4 contain at least one negative value. floor() moves to the next-leftmost integer on the number line, which means -0.01 is -1 and 0.01 is 0. ceil() moves to the next-rightmost integer on the number line, which means 0.01 is 1 and -0.01 is 0.01 is 1.

What you want is inner() and outer() rounding:

#define inner(x) (x<0 ? ceil(x) : floor(x))
#define outer(x) (x<0 ? floor(x) : ceil(x))


Your circles will be properly symmetrical as long as you account for the truncation inconsistently above and below the zero threshold on the number line.
Jun 8 2016, 7:27 am
I think Goober is trying to trigger epileptic seizures in everyone here.
Jun 8 2016, 10:45 am
In response to Mr_Goober
Mr_Goober wrote:

(They look a lot smoother outside of the gif, by the way)




Jun 8 2016, 11:57 am
In response to Ghost of ET
Ghost of ET wrote:
Tsubasa10 wrote:
http://www.byond.com/games/Tsubasa10/ShinobiSensouOnline

What's the story/lore of your game :D?

Concept is based on Naruto, but Has few different aspects, check the Wiki page found in the game's hub.
Jun 8 2016, 2:39 pm
In response to Tsubasa10
Alright.
Jun 8 2016, 4:14 pm
In response to Ter13
Ter13 wrote:
This uses a circle algorithm (definitely doesn't generate symmetrical circles).

The reason that your circle algorithm doesn't make symmetrical circles is that you are using a floor() function. Cartesian Quadrants 2, 3, and 4 contain at least one negative value. floor() moves to the next-leftmost integer on the number line, which means -0.01 is -1 and 0.01 is 0. ceil() moves to the next-rightmost integer on the number line, which means 0.01 is 1 and -0.01 is 0.01 is 1.

What you want is inner() and outer() rounding:

> #define inner(x) (x<0 ? ceil(x) : floor(x))
> #define outer(x) (x<0 ? floor(x) : ceil(x))
>

Your circles will be properly symmetrical as long as you account for the truncation inconsistently above and below the zero threshold on the number line.

Heh I don't know. I applied it in different ways to the algorithm and I guess I know what you're talking about, but I think the way I'm doing it is different than you think. I'm really just placing a bunch of dots around a center:
    turfmap_circle(x,y,r,n=1)
        r = max(abs(r),0.1)
        var/d   = ceil(2*pi*r*n)
        var/vx  = 0
        var/vy  = 0
        var/vq  = 0
        for (var/i = 0 to d-1)
            vq = i/d
            vx = x + inner((sin(360*vq) * r) + 0.5)
            vy = y + inner((cos(360*vq) * r) + 0.5)
            turfmap_plot(vx,vy)

The 0.5 offset is more or less a means of ensuring that if the X and Y coordinates are whole numbers, the center of the tile marks the starting point and not the bottomleft.
Jun 9 2016, 4:51 pm
In response to Mr_Goober
instead of defining and setting vx & vy every loop, wouldn't it be faster to just

turfmap_plot(x + inner((sin(360*vq) * r) + 0.5),y + inner((cos(360*vq) * r) + 0.5))
Jun 9 2016, 5:56 pm
The 0.5 offset is more or less a means of ensuring that if the X and Y coordinates are whole numbers, the center of the tile marks the starting point and not the bottomleft.

No it doesn't. Dump the values.

In fact, the + 0.5 is what's causing the error I thought was being caused by the rounding. You are misapplying the radius expansion during the wrong step because cos() and sin() return positive or negative values, not just positive values. What you want to do is apply the 0.5 to the radius so that it is multiplied into the point's location according to the sign of cos/sin rather than added into it.

Adjusted code:

    turfmap_circle(x,y,r,n=1)
        var/circ = ceil(2*pi*r*n), vq
        r = max(abs(r),0.1)+0.5
        for (var/i = 0 to circ-1)
            vq = i/circ
            turfmap_plot(x + inner(sin(360*vq) * r),y + inner(cos(360*vq) * r))
Jun 9 2016, 8:47 pm (Edited on Jun 9 2016, 8:52 pm)
(Not related to the circle thing, but...)

I thought adding some particles would be neat too.

Applying Ter's altered code, I still get this odd symmetry problem (only the bottom half looks different)

This was the initial problem I was having either way.
Jun 9 2016, 8:58 pm
In response to Kozuma3
Kozuma3 wrote:
instead of defining and setting vx & vy every loop, wouldn't it be faster to just

turfmap_plot(x + inner((sin(360*vq) * r) + 0.5),y + inner((cos(360*vq) * r) + 0.5))


Often times developers opt for readability unless speed is impacted greatly.
Jun 9 2016, 9:35 pm
It appears the circle problem was caused by pi being a non-whole number. The number of dots that are to be plotted now is defined by 10*ceil(radius).
Jun 10 2016, 1:11 am

While its not much I always love sharing stuff about the collision system. It's improved a lot since it first became. What you're seeing there is a sanity check that shoves the player out of the way being inside solid bounds. It separates the check between objects and scene limit bounds so that during the shove it's not throwing mobs off the actual map scene.
Jun 10 2016, 2:41 pm
Something lurks on the horizon..
Jun 10 2016, 4:40 pm
In response to Kumorii
Kumorii wrote:
Something lurks on the horizon..

hype
Page: 1 2 3 ... 199 200 201 202 203 ... 349 350 351