BYOND Client: Flash games vs DS games in BYOND Discussion

Page: 1 2 3
#20 Nov 10 2011, 6:32 am
In response to Forum_account (#19)
Forum_account wrote:
> some it makes more sense for users to implement themselves (like this one). I hope this isn't true, but it sounds like you think that every feature would be better handled by BYOND.

But won't it be slow to hide/show hundreds-thousands of images? It's would be much easier to work with as well as faster, if invisibility/visibility variable was BitFlag or even a list.
#21 Nov 10 2011, 7:01 am
In response to Zaoshi (#20)
The problem with that feature (which is the same problem with many feature requests) is that there are many ways you might want it to work. If it's handled on the client the feature isn't extensible so you're stuck using the feature only how it's implemented. If you want it to work differently, you have to re-implement it yourself.

It's better for BYOND to provide a better means to implement it yourself than to provide one way the feature could work.
#22 Nov 10 2011, 8:52 am
In response to Forum_account (#19)
Forum_account wrote:
BYOND games have to be able to compete with Flash games in terms of quality because game players won't care what tool was used to make the game.

Flash games are able to achieve much more fancy graphic effects, it's as simple as that. Why use BYOND for making single player games when you could just use Flash and do the same things and more?

Adobe isn't going to be working on mobile versions of Flash anymore so I think just focusing on a Flash client is the right choice. HTML5 will win the arms race soon enough so it's probably in BYOND's best interest not to get too tied up in Flash support.
#23 Nov 10 2011, 9:57 am
In response to SuperAntx (#22)
SuperAntx wrote:
Forum_account wrote:
BYOND games have to be able to compete with Flash games in terms of quality because game players won't care what tool was used to make the game.

Flash games are able to achieve much more fancy graphic effects, it's as simple as that.

BYOND doesn't have to compete with Flash but it does have to keep up with modern expectations. When I posted A Miner Adventure many people found it to be unplayable because Dream Seeker was struggling to draw the screen 35 times per second.

I'm sure that many of BYOND's graphical limitations come from the desire to keep game development simple. There's no way to expose all of the graphical capabilities you'd have with Flash or other tools and still keep it as simple as BYOND is. These limitations are acceptable. The problem is that there are also limitations because BYOND's features are implemented poorly. If you could run Quake 2 at 35 fps on a Pentium 1 with 32 MB of RAM, it should take quite a lot of objects to make a BYOND game on a modern computer run slowly.
#24 Nov 10 2011, 11:25 am
In response to Forum_account (#23)
Forum_account wrote:
> If you could run Quake 2 at 35 fps on a Pentium 1 with 32 MB of RAM, it should take quite a lot of objects to make a BYOND game on a modern computer run slowly.

BYOND just needs hardware support (GPU) and improved compiler/JIT so it actually runs machine code. Virtual machine is extremely slow.
#25 Nov 10 2011, 11:52 am
In response to Zaoshi (#24)
Zaoshi wrote:
BYOND just needs hardware support (GPU) and improved compiler/JIT so it actually runs machine code. Virtual machine is extremely slow.

We already use hardware support via DirectX.

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.
#26 Nov 10 2011, 7:52 pm
In response to SuperAntx (#22)
SuperAntx wrote:

Adobe isn't going to be working on mobile versions of Flash anymore so I think just focusing on a Flash client is the right choice.

Adobe, unlike Byond, is smart to admit their defeat and start aggressively making HTML5 building applications where the market is (mobile apps). This fact has opened the door for many entertainment industry partners...HTML5 game engines have been snagged up for hefty prices. Aves was bought by Zynga... Even Disney (uh...yea, Disney) even put their money in the honey pot. I also recently stumbled upon something I will not talk about until I release my project. But let's just say, you might want to jump on the HTML5 bandwagon now while it's hot.

Btw, I cannot stress enough that Byond can easily be replaced by a node.js server. So your "multiplayer" novelty will eventually be "phased out", being replaced with newer and better web technology. Byond could always participate in making node.js simpler in conjunction with its software, but I foresee the missed opportunity.

HTML5 will win the arms race soon enough so it's probably in BYOND's best interest not to get too tied up in Flash support.

^
#27 Nov 11 2011, 6:59 am
In response to Lummox JR (#25)
I've seen many people complaining about how slow BYOND is when it comes to transparent icons, I've experienced that myself too. Only 50-100 transparent objects on screen and Dream Seeker is dying already.
On other hand, I worked a little with DirectX 9 and I was able to get transparency lag only when I created too many particles, that was over 10,000 particles in total over 100 million pixels per frame. Even then it ran at 15 FPS, still higher than Dream Seeker.
By these two factors I can surely say BYOND does NOT use hardware.
#28 Nov 11 2011, 7:08 am
In response to Neblim (#26)
Neblim wrote:
SuperAntx wrote:

Adobe isn't going to be working on mobile versions of Flash anymore so I think just focusing on a Flash client is the right choice.

Adobe, unlike Byond, is smart to admit their defeat and start aggressively making HTML5 building applications where the market is (mobile apps). This fact has opened the door for many entertainment industry partners...HTML5 game engines have been snagged up for hefty prices. Aves was bought by Zynga... Even Disney (uh...yea, Disney) even put their money in the honey pot. I also recently stumbled upon something I will not talk about until I release my project. But let's just say, you might want to jump on the HTML5 bandwagon now while it's hot.

Btw, I cannot stress enough that Byond can easily be replaced by a node.js server. So your "multiplayer" novelty will eventually be "phased out", being replaced with newer and better web technology. Byond could always participate in making node.js simpler in conjunction with its software, but I foresee the missed opportunity.

HTML5 will win the arms race soon enough so it's probably in BYOND's best interest not to get too tied up in Flash support.

^

It certainly sounds like focusing on HTML5 makes more sense than worrying about Flash, but it makes me wonder if it'd just be better to avoid the whole thing. Some day we might be talking about HTML5 games like we currently talk about Flash games, but I'd be surprised if those kinds of games completely phased out standalone games. It seems just as likely that this could be BYOND's chance to find ways to stand out by being its own platform, rather than settling for being "the easy way to make ____ games" (where you put Flash or HTML5 in the blank).
#29 Nov 11 2011, 8:19 am
In response to Zaoshi (#27)
Zaoshi wrote:
I've seen many people complaining about how slow BYOND is when it comes to transparent icons, I've experienced that myself too. Only 50-100 transparent objects on screen and Dream Seeker is dying already.
On other hand, I worked a little with DirectX 9 and I was able to get transparency lag only when I created too many particles, that was over 10,000 particles in total over 100 million pixels per frame. Even then it ran at 15 FPS, still higher than Dream Seeker.
By these two factors I can surely say BYOND does NOT use hardware.

Well, it's a good thing you know everything about the way the software is written and can in no way attribute that to driver issues or measurement error on your own part, then.

Here's the factors by which I can surely say BYOND does in fact use hardware: 1) It's calling DirectX to draw when it's in hardware mode, which is whenever the user has not disabled that and when there are no interface features like transparent windows that force us to switch to software mode. 2) Switching between hardware and software rendering mode actually shows a clear visual difference.

Several factors are going on here that you have not taken into account. Dream Seeker does additional processing to build the map. Very large maps require more processing because individual icons have to be sorted, regardless of transparency. The ease with which transparency is rendered depends on many factors including your own driver setup. Certain interface decisions (as mentioned above) force DS to use software mode instead of hardware. And DS does still more processing you are not aware of, not to mention if you are also running it as a server then you also have to deal with server overhead.

I can think of many conclusions you could have legitimately drawn from your test, like the fact that a game in DS is obviously going to be slower than a C++ equivalent because the latter can be streamlined (and multithreaded) and is not running in an interpreter. But saying that it's definitely not using hardware is incorrect. It may not be using hardware on your particular system or in the particular game you tested, but the bottom line is it's calling DirectX so it's going to use whatever hardware capabilities DirectX can offer it.
#30 Nov 11 2011, 11:43 am
In response to Lummox JR (#29)
Lummox JR wrote:
I can think of many conclusions you could have legitimately drawn from your test, like the fact that a game in DS is obviously going to be slower than a C++ equivalent because the latter can be streamlined (and multithreaded) and is not running in an interpreter.

I'm not sure how it's handled when you're running a game locally through Dream Seeker, but when you're connected to a remote server the program generating the graphical output has nothing to do with the program that's interpreting DM code. In the example, the lag seems to come from having to draw transparent objects, not from having to execute complex DM code that makes the transparent objects move around.

I haven't used DirectX much but I know it gives you enough rope to hang yourself. Using it doesn't mean you're using it effectively. Based on some of the display quirks I've seen I'm inclined to think there's something screwy about the usage of DirectX.
#31 Nov 11 2011, 11:48 am
In response to Forum_account (#30)
Forum_account wrote:
I'm not sure how it's handled when you're running a game locally through Dream Seeker, but when you're connected to a remote server the program generating the graphical output has nothing to do with the program that's interpreting DM code. In the example, the lag seems to come from having to draw transparent objects, not from having to execute complex DM code that makes the transparent objects move around.

I haven't used DirectX much but I know it gives you enough rope to hang yourself. Using it doesn't mean you're using it effectively. Based on some of the display quirks I've seen I'm inclined to think there's something screwy about the usage of DirectX.

It's just basic sprite blitting. It really couldn't be more straightforward than that. That isn't to say there might not be some advanced tricks we could pull out to improve the process, but it is what it is.
#32 Nov 11 2011, 12:15 pm
In response to Lummox JR (#31)
Lummox JR wrote:
It's just basic sprite blitting. It really couldn't be more straightforward than that. That isn't to say there might not be some advanced tricks we could pull out to improve the process, but it is what it is.

If it was that straightforward tutorials like this one would be a lot shorter.

Again, I'm not too familiar with DirectX but I know that if you don't manage things effectively you can end up increasing the overhead drastically. For instance, if textures aren't managed well you may need to repeatedly send texture data to the graphics hardware instead of loading it to the GPU's memory once. These aren't advanced tricks that you have to pull out, it's just how you use the GPU. You have to make an effort to use it effectively for it to perform well. With how much a GPU can do in parallel a seemingly small difference can have a huge impact on performance.
#33 Nov 11 2011, 12:36 pm
In response to Forum_account (#32)
If you are seeing a problem, then construct a demo and post a bug report and we'll take a look. The code is pretty straightforward. Way back in testing I profiled the GPU memory to ensure that it did what I expected and didn't have a leak. Results vary on different cards and it may be a more isolated program, but AFAIK this is not the bottleneck people think it is. But if it is holding you back, by all means, get that report to us.
#34 Nov 11 2011, 12:40 pm
In response to Zaoshi (#27)
Zaoshi wrote:
I've seen many people complaining about how slow BYOND is when it comes to transparent icons, I've experienced that myself too. Only 50-100 transparent objects on screen and Dream Seeker is dying already.

A good test would be to compare with non-transparent icons, because internally we don't make the distinction so that would definitely be something on the hardware. Just contruct the simplest case possible and see how the trans vs non-trans versions compare. Go ahead and post it to bug reports if there is a difference, and at the very least we can test it to see if it is consistent on our cards (and if so, that should help isolate).
#35 Nov 11 2011, 3:09 pm
In response to Forum_account (#32)
Just to clarify, the article you mentioned is about using quads rather than sprites. We use sprites.
#36 Nov 12 2011, 4:33 am
In response to Lummox JR (#35)
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?

That could be the problem. Most games use lots of quads and some sprites. I wouldn't be surprised if GPUs were highly optimized for quad drawing and not-so-optimized for sprite drawing.

It looks like using quads would give you some trivial benefits like client-side rotation and icon coloration. Instead of being icon procs these could be handled entirely by DirectX.
#37 Nov 12 2011, 7:28 am
In response to Forum_account (#36)
Forum_account wrote:
> It looks like using quads would give you some trivial benefits like client-side rotation and icon coloration. Instead of being icon procs these could be handled entirely by DirectX.
I've been trying to tell that for very long time but no one cared. Sprites work a bit differently than normal rendering, either way, quads are always better. However BYOND still needs to save icon in RAM in order to resolve mouse clicks correctly; that'll have to be done on CPU either render rotated icon into texture and then load it into RAM. But there is an alternative, could "rotate" mouse position, instead of icon, that would give same effect and much faster.
#38 Nov 12 2011, 8:15 am
In response to Zaoshi (#37)
Zaoshi wrote:
Forum_account wrote:
> It looks like using quads would give you some trivial benefits like client-side rotation and icon coloration. Instead of being icon procs these could be handled entirely by DirectX.
I've been trying to tell that for very long time but no one cared. Sprites work a bit differently than normal rendering, either way, quads are always better. However BYOND still needs to save icon in RAM in order to resolve mouse clicks correctly; that'll have to be done on CPU either render rotated icon into texture and then load it into RAM. But there is an alternative, could "rotate" mouse position, instead of icon, that would give same effect and much faster.

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 and use that to lookup objects. Instead of drawing the objects as they'd be shown on the screen, you draw a color that corresponds to an object. You just look in the buffer at the coordinates where the mouse is and you'll know what object it's over.
#39 Nov 12 2011, 1:08 pm
In response to Forum_account (#38)
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)
Page: 1 2 3