In response to Zaoshi
Zaoshi wrote:
Forum_account wrote:
> I don't know how it works in DirectX, but in OpenGL you can draw the objects to a buffer that's not shown on the screen
Usually that's called Render to Texture(RTT) or Render Target

However that'll use a lot memory (similar to what it is now)

No, you're not rendering onto a texture, it's just an additional buffer (like the depth buffer, color buffer, etc.). It doesn't render a separate image, it just stores more information about the one you're rendering.
In response to Forum_account
Forum_account wrote:
Lummox JR wrote:
Just to clarify, the article you mentioned is about using quads rather than sprites. We use sprites.

Was there a reason for using sprites?

I know in some early graphical work, there were rendering issues with quads, like seams showing up in odd places and things like that.
In response to Forum_account
Forum_account wrote:
No, you're not rendering onto a texture, it's just an additional buffer (like the depth buffer, color buffer, etc.). It doesn't render a separate image, it just stores more information about the one you're rendering.

Both Depth Buffer and Color Buffers are textures. In DirectX 9 it's not very visible, but in DX 10/11 it becomes more clear (however it still differs a lot from rendering to completely different texture).
In response to Lummox JR
Lummox JR wrote:
I know in some early graphical work, there were rendering issues with quads, like seams showing up in odd places and things like that.

It wasn't DirectX issue for sure, probably programmer didn't knew how it worked or made mistake somewhere (buffer overflow for example).
In response to Lummox JR
Lummox JR wrote:
I know in some early graphical work, there were rendering issues with quads, like seams showing up in odd places and things like that.

Seams or not, the benefits would be huge:

* better framerate?
* client-side object opacity
* client-side icon RGB effects
* client-side object rotation
* camera rotation
* zoom in/out
* dynamic lighting?

I'm not sure how lighting is handled, but I wouldn't be surprised if lighting was applied differently to quads than sprites so that built-in dynamic lighting would be easier/better when using quads.

It sounds to me like it's worth a try.

Edit: Not that you're far off currently, but using quads would also put you within spitting distance of a 3D display mode - you'd just need to draw a cube instead of a quad and add some variables to determine if objects are drawn as cubes or quads.
In response to Forum_account
It would be much easier for you to make own game with 3D cubes instead of sprites (which isn't hard either), than remake half of BYOND just to change it into quads/cubes.

But yes, I agree with you.
In response to Zaoshi
Zaoshi wrote:
It would be much easier for you to make own game with 3D cubes instead of sprites (which isn't hard either), than remake half of BYOND just to change it into quads/cubes.

That makes no sense. The switch from sprites to quads is incredibly minor.
In response to Forum_account
Forum_account wrote:
That makes no sense. The switch from sprites to quads is incredibly minor.
Actually it's completely different (almost nothing is same).

For sprites you just set texture and array or positions to draw: http://msdn.microsoft.com/en-us/library/ bb174251(v=VS.85).aspx
RECT structure is 16 bytes in size if I'm correct, D3DXVECTOR3 is 12 bytes, D3DCOLOR is 4 bytes. So there's only 12 bytes of unique data per object (assuming all objects have same texture, they'll need only different positions)

For quads you have to create individual buffer for every single object, each containing position and texture coordinates. That's 8 bytes for position and 8 bytes for texture coordinates on every vertex, 4 vertexes for quad so that makes 64 bytes per object. (texture coordinates can differ now too, though texture itself is still same).
Function call to draw quad isn't 1 line too (gotta set texture, vertex format, vertex layout, vertex buffer; while with sprites it's in single function call).
In response to Lummox JR
I made a feature request for this, which might be a better place to discuss this or say it's not feasible.
In response to Lummox JR
Lummox JR wrote:
Zaoshi wrote:
BYOND just needs hardware support (GPU) and improved compiler/JIT so it actually runs machine code. Virtual machine is extremely slow.

JIT is quite out of the question because of the way objects and references are managed, and because it requires the ability to compile to various architectures on the fly.

I'm sure there are ways .dmb execution could be improved. Any idea what the bottlenecks are?

This isn't a comprehensive test, but I wrote a function in Java, Python, and DM to compute the sum of a list of 21 numbers. Based on the average execution times:

DM can execute the proc 59,242 times per second.
Python can execute the function 159,744 times per second.
Java can execute the method 7,112,376 times per second.

59,242 times per second sounds like a lot, but if you're making an action game that runs at 40 fps it's only 1481 times per tick. Summing up 21 numbers is a fairly trivial operation, but if you do it 300 times per tick you're at 20% CPU usage. Even then, 300 times sounds like a lot but remember that this is a trivial operation - features in your game are likely to be equivalent (in terms of CPU time) to calling this proc 10-20 times.

The possibility to make action games really highlights how slow DM can be.
In response to Forum_account
Forum_account wrote:
> I'm sure there are ways .dmb execution could be improved. Any idea what the bottlenecks are?
I know new and del operators are quite slow. But overall everything is slow as it runs in virtual machine instead of machine code.

> This isn't a comprehensive test, but I wrote a function in Java, Python, and DM to compute the sum of a list of 21 numbers. Based on the average execution times:
Could you provide Java code (with executable) which you used to do the tests? Would be nice to test C++ program on same system to see how well it runs; if you provide executable and code I can test on mine, as I don't know how to compile Java; or if you know how to compile C++ could test it on your system.
In response to Zaoshi
Zaoshi wrote:
Forum_account wrote:
> I'm sure there are ways .dmb execution could be improved. Any idea what the bottlenecks are?
I know new and del operators are quite slow. But overall everything is slow as it runs in virtual machine instead of machine code.

The test adds numbers together because that's something every language can do - there's no direct Python or Java equivalent of new /obj(). I also included Python because it runs through an interpreter, it's not compiled to machine code.

I'm sure there are tons of comparisons of C++ and Java on the web if you're interested in that. My point was more to show how much room DM has for improvement. I certainly don't expect it to rival Java but it currently takes ~2.5 times longer than Python.
In response to Forum_account
It just depends how you wrote the code.

Have you typed random numbers and put it into the loop?
Input came from keyboard?
Randomly generated numbers?
In first case compiler might optimize it a lot. I think C++ might completely remove loop.

Anyways. On my 2.13 GHz processor I was able to get 13.7 million iterations per second (100 million took 7.28 seconds).
With SSE instructions it went up to 680 million on average (100 million in about 0.145 seconds)*.

*had to use 24 floating point numbers as it has to be multiplier of 4 and I didn't knew functions for integers.
In response to Aaiko
Zynga went public yesterday.

They are not close to worth more than Activision-Blizzard, nor worth more than EA, never mind worth more than both combined.
In response to Airjoe
Airjoe wrote:
Zynga went public yesterday.

They are not close to worth more than Activision-Blizzard, nor worth more than EA, never mind worth more than both combined.

What I said really bothered you, didn't it? Haha.

I don't even care about Zynga, haven't played any of their games, don't really know anything about them. I was just stating that they make a lot of money with little work. So their stock offering flopped, fine, nobody can foresee that, but they did raise $1 billion during the process and they just make a lot of money in general. Which was the point I was trying to raise. A lot of money can be made in web/Flash games.

I was just going based off what I've read. I'm not a company worth expert. :P

I'm glad you've set the BYOND forums Zynga worth record straight, though. Haha.
In response to Aaiko
Aaiko wrote:
So their stock offering flopped, fine, nobody can foresee that,

Actually, pretty much everyone who commented on it while knowing anything about the game industry foresaw this outcome. Zynga doesn't have a shred of originality, they have the sort of developer culture which drives innovation, their games are starting to stagnate, and even if they released another hit they would just be cannibalizing their own player base.

But yeah, all that aside they still make more money than they should simply because of their distribution channels and revenue structure.
Page: 1 2 3