ID:1419199
 
Below is my attempt to see if this idea will work. If you have any thoughts, feel free to post them and I'll try it. I just want to see if it will work. :)

No bashing allowed! GO AWAY!

Obviously this can't be used in games. DreamDaemon would crash. But who says we can't do it for fun?

Progress submission #1 @ 4:37 AM:

-The late night beginning
/**

How this will work:

X and Y axis -
First, we will draw a vertical line with animate() or transform. No icons will be used. Or atleast we will try to.

Secondly, we will try to connect two vertical lines with 2 horizontal lines.

Thirdly, we will try to shade the inside of this square.

Lastly, we will try to rotate it clockwise.

Y and Z axis -
First, we will draw the shaded square again.

Secondly, we will have another square behind it. But, it's not visible because of the angle.

Thirdly, we will rotate the box evertedly.

Lastly, we will remember to move the background image similarly but a bit slower.

To make it look like an actual box, it will have to have an animated line connecting to all
four corners of the foreground box. Thus, meaning that there must be a constant relating between the corners.

X and Z axis -
First, we will draw the shadeds square once more.

Secondly, we will do what was done for the Y and Z axis everted rotation but it will be done left to right.

Done.

**/


var
x
y
z

mob/Login()
icon='player.dmi'

mob/verb/Draw3DBox()
var/icon/I= new
I.DrawBox(null,1,1)
Nobody was bashing you the first time, they were just pointing out that while it's not impossible it's not at all practical. BYOND is a 2D engine, it was made and designed for 2D games.

If you want to venture into 3D then go and play with the likes of Unity3D or UDK, there is absolutely no reason to stress BYOND to such limits trying to implement something it wasn't designed for.
In response to Mask of Illusion
Mask of Illusion wrote:
If you want to venture into 3D then go and play with the likes of Unity3D or UDK, there is absolutely no reason to stress BYOND to such limits trying to implement something it wasn't designed for.

This is for fun.

*shrugs*
Suit yourself, I was just trying to help save him time...
Xirre:
Obviously this can't be used in games. DreamDaemon would crash. But who says we can't do it for fun?

Mask of Illusion:
*shrugs*
Suit yourself, I was just trying to help save him time...

He's simply doing it for the fun of it. There are more obvious alternatives, like Unity, Blitz3D, etc..
I appreciate he's doing it for fun(as you've all said) and good luck to you Xirre, but maybe it's just me and I don't see where the fun is in doing something that isn't going to pay off.

I guess you could consider what I'm saying to be bashing, I was honestly just trying to save the guy both the time and the effort. But if that's how you have fun, then props to you!
Which part of the pseudo code represents the camera. Frame rate is where the camera comes into play.
In response to Mask of Illusion
Mask of Illusion wrote:
I appreciate he's doing it for fun(as you've all said) and good luck to you Xirre, but maybe it's just me and I don't see where the fun is in doing something that isn't going to pay off.

I guess you could consider what I'm saying to be bashing, I was honestly just trying to save the guy both the time and the effort. But if that's how you have fun, then props to you!

Sounds arrogant.

In response to Kozuma3
Kozuma3 wrote:
Sounds arrogant.


In what way does trying to suggest an alternative to save blood, sweat and tears doing something on BYOND, that is clearly wasn't made to do sound arrogant?
Once you determine how to display and rotate an 3D image you need to have a point of reference(0,0,0). The camera is a separate entity which effects view/sight. Furthermore, it determines when and where an object is rendered. It acts as a flat object that can be rotated scaled and its position given magnitude/changed/moved.
The Z coordinate creates the 3D camera camera. And the Z coordinate will be made with 2 parts: Scaling and Layer. Say you had a line symmetrical to the z-plane. If you had the box facing you directly, that like would look like a dot and the box would look like a square.

But, this box is a 32x32 box.So, on the bottom left corner of the box is that like symmetrical to the z-plan that connects the front box to the back box. They are layered from 1 to 32. When the box rotates up, the layer layered 32 will shift up and also scale to get bigger to imitate the slight image as if it's coming towards you. But it won't scale much that it looks weird. The 31st layer will do the same but will scale less and shift up. And so on, so this z-plane symmetrical line starts to shift in to the y-plane when it makes a full 90 degree turn.

Once it reaches a certain length in shifting up and scaling, it will move up still but it will scale down, starting at the top. That way it sticks to the box.

This is my design. I just have to create it. Or, if anyone wants to do it with me, sure. I attempted this somewhat 6 years ago or so. Can't remember. Back then I didn't have animate() or any of the other stuff to easily do some mimicking 3D effects. But, this way should work. It'll be laggy, but it should work. From what I have seen with creating about 600+ particles with animate, the game crashed. That apparently was the average limit. So the main issue here would have to be how to shorten the amount of objects used in this situation. If possible to shorten it down to about 10 pixels per object, then yes, this can be used for some simple games. If not possible, then this will end at just being a fun project to try out. :)
New thought: Have a main pixel. Probably the bottom left corner. Have every pixel relate to its position. And it's what rotates. Oh god.. the formula to make this happen. I think I may try the first though.
Why not to do raycasting or rasterization?
That's what I'm doing. >.> In a sense.
Lol. At least you tried. :P I have yet to put any extra work in it. Primarily because I don't feel like starting up my virtual machine and I don't want to code in a standard text editor on linux.
So I have been plugging away at this since sometime last night. It's still pretty rough around the edges, but it's running smoothly at 30fps with zero framerate hiccups. There's presently only about 28 polys being rendered, but according to the profiler, it's taking less than 1ms to render each frame, so it can take way more polygons.

3.83mb gif

Frankly I'm pretty surprised at how well this runs. I think it's practical to use this in singleplayer games. However, this is probably really bad for models that need skeletal animations, so this would work well for things like spaceships or cars or airplanes and would work poorly for things like dogs or people or robots.

I would have to do some testing to see how many polygons I can fit on the screen before the framerate takes a hit.

[EDIT]: This also runs smoothly at 60fps
How are you getting around the tesselation issues with the edge anti-aliasing around polygons, or are you?
In response to Ter13
Ter13 wrote:
How are you getting around the tesselation issues with the edge anti-aliasing around polygons, or are you?

I'm not. :(
When I put a flat white texture on the polygons, you can see the edges. This is especially apparent on the cubes, because each face on the cube is two polys.

http://puu.sh/5gOCc.png
I fixed the fov.
Another 3mb gif
In response to D4RK3 54B3R
D4RK3 54B3R wrote:
I fixed the fov.
Another 3mb gif

That's amazing :o
Page: 1 2