Legacy GM Are buffers faster than arrays?

Status
Not open for further replies.

Joe Ellis

Member
Hi all,

I know that arrays are a bit faster than ds_lists, but are buffers faster than arrays?

I know how to use buffers, I'm just wondering if its worth converting all my array stuff to buffers at the end of my development to get optimal performance.
 
C

Ctl-F

Guest
According to the manual:
Buffers
These functions can be used to read and write directly to the device buffer memory.
Correct me if I am wrong bit I interpret that to mean buffers read and write directly to and from physical memory. Arrays are also supposedly stored directly in memory which would make buffers and arrays equally fast. However without being to see how game maker actually implements arrays and buffers I can't tell you for sure.
The big difference is that buffers have a lot less safety guards around them so generally speaking Arrays are the safer rout to go.
In general though I would say it doesn't make that big of a difference. If you are storing a couple hundred items in an array, buffer, or list and iterating through them you probably aren't going to notice a difference. The only time that would really matter if you were performing substantial algorithms on each index every step with thousands of indexes.

Hope this helps.
 

Joe Ellis

Member
Thanks for replying

The only time that would really matter if you were performing substantial algorithms on each index every step with thousands of indexes
Yeah this is what I was thinking of using buffers for, I've got rain, and every rain drop has its own index, with x1,y1,z1 x2,y2 and z2 and if I have around 200 raindrops at once the fps_real goes down from 1300 to 250,

So I wanted to find a quicker way of iterating through the rain drops and applying the gravity/movement for each one at a time, and also check whether they've hit the ground or not and if they do, place them back in the sky.

At the moment I can't use the current method I've got in an actual game as the fps always goes below 60.
 
W

Wraithious

Guest
I know from one of my projects involving the storage of pixel information from an image that buffers definatly were at least twice as fast as trying to do the same thing with an array, not sure about tracking changing data like your falling raindrops coordinates tho but in my case i was taking rgb values and changing them so it sounds similar in a way
 

Yal

šŸ§ *penguin noises*
GMC Elder
Is the main reason the raindrops are slow their updating or their drawing? If you add all coordinates to a pr_linelist, you can draw all raindrops with a single draw call (which should equate a single vertex buffer). If you draw each one individually, however...
 

PNelly

Member
Thanks for replying



Yeah this is what I was thinking of using buffers for, I've got rain, and every rain drop has its own index, with x1,y1,z1 x2,y2 and z2 and if I have around 200 raindrops at once the fps_real goes down from 1300 to 250,

So I wanted to find a quicker way of iterating through the rain drops and applying the gravity/movement for each one at a time, and also check whether they've hit the ground or not and if they do, place them back in the sky.

At the moment I can't use the current method I've got in an actual game as the fps always goes below 60.

You really ought to be using a particle system for an effect like that
 

Joe Ellis

Member
Is the main reason the raindrops are slow their updating or their drawing? If you add all coordinates to a pr_linelist, you can draw all raindrops with a single draw call (which should equate a single vertex buffer). If you draw each one individually, however...
A bit of both, however creating a vertex buffer every frame doesn't really improve the performance, your replacing the draw calls with creating the buffer. I'm already putting them in a single line_list anyway.

You really ought to be using a particle system for an effect like that
But this is what I'm asking about, I don't want to use a particle system someone else has made I want to make my own, and what benefits will using a particle system have? If the way they're processed is the same as going through an array whats the difference?
 
Last edited by a moderator:

Joe Ellis

Member
Use the profiler to find the source of the problem. That's your best bet.

Is this for a 3D or 2D game?
Whats that?

3d, its with lines aswell, not sprites

I know from one of my projects involving the storage of pixel information from an image that buffers definatly were at least twice as fast as trying to do the same thing with an array, not sure about tracking changing data like your falling raindrops coordinates tho but in my case i was taking rgb values and changing them so it sounds similar in a way
I think if I switch to buffers, group the rain drops into about 20 vertex buffers initially and d3d_transform them to make them fall it'll be ok, I'm expecting some kind of memory usage obviously, I just need it to be about twice as fast
 
Last edited by a moderator:

Joe Ellis

Member
Ah right! I've never used debug mode, I didn't even know it could do that, cheers

Would you say that buffers are faster than arrays though?
 

hippyman

Member
I personally don't have enough experience with buffers to say with confidence which is faster. That's why I'm recommending the profiler. It's an extremely valuable tool, especially for situations like this. It would be really simple to setup a test project that records the speeds of reads and writes from each type (buffer/array).

You could make a project that does the same thing with both buffers and arrays and then record the start and stop times of each test. Run some tests, do some simple math and you'll have a definitive answer vs hear-say from a forum. Not to discredit anybody from the GMC. But nothing beats cold-hard numbers.
 

GMWolf

aka fel666
Arrays are faster.
Yeah they are.
Not only are arrays faster, but they also sort out types for you. Only disadvantage (in most cases) is that they use up more memory.
Buffers do have the advantage of being able to retreive its address, allowing funcky bit manipulation and being easily saved and loaded.
 
W

Wraithious

Guest
I'm expecting some kind of memory usage obviously, I just need it to be about twice as fast
Its definatly worth trying, to test it maybe make 2 scripts that you can call one or the other, with one being the buffer script, the other an array script and monitor the fps when using them seperatly

EDIT: I found the topic I posted about buffer usage, the last post describes what I did:
https://forum.yoyogames.com/index.php?posts/51165/
I originally did all that with an array based script, then used a while loop, then ended up putting the image part of the code in a buffer, these are the speed results I observed with a 200 x 200 pixel image:
Array + for loop script - 58 seconds
Array + while loop script - 53 seconds
Use buffer script - 23 seconds (altho the image loaded in 5 seconds)

So I guess it all depends on the situation you use arrays for on weather they are faster
 
Last edited by a moderator:

Joe Ellis

Member
Yeah I'm gonna test it in as many ways as possible, maybe 1 is quicker than the other at some things and vice versa, the reason I'm thinking buffers would be quicker is arrays are built to cater for any type thrown in, at all different points in it, so I could imagine this convienience would be using more cpu than just setting a buffer up to only read one type & alignment, I'll find out soon anyway lol
 

Joe Ellis

Member
I didn't mean buffers alone making it twice as fast, all the optimizations together need to make it twice as fast, and buffers would just be contributing to this, if they're faster
 

Joe Ellis

Member
oh

doesnt it depend which data type your using tho? I'll be using integers
 
Last edited by a moderator:

GMWolf

aka fel666
Remember, When optimizing, Use better algorithms and thechniques. Data types and operators do not matter.
1: Group up your raindrops. Do they need to be individual??
2: Why 3D rain? That a waste! do them in screenspace!
3: Render them at lower res, then upscale (Looks better too since it should be blurry).
4: No need to simulate them hitting the ground or anything: Have them clip through the ground, And add random splatter effects on the ground. No one will notice.
 

Ariak

Member
This is for GMS2 - but similar numbers do apply for GMS1 (both with YYC)
Loops per step 5000, us=microseconds

Write
array 180 us - not using an accesor (@) otherwise on par with lists.
list 281 us
grid 190 us
map 1211 us
buffer(fast,u8) 337 us //peek/poke!

Read
array 171 us - as above no accessor EDIT: 101us was a typo ;)
list 295 us
grid 195 us
map 1181 us
buffer 332 us
 
Last edited:

Joe Ellis

Member
This is for GMS2 - but similar numbers do apply for GMS1 (both with YYC)
Loops per step 5000, us=microseconds

Write
array 180 us - not using an accesor (@) otherwise on par with lists.
list 281 us
grid 190 us
map 1211 us
buffer(fast,u8) 337 us //peek/poke!

Read
array 101 us - as above no accessor
list 295 us
grid 195 us
map 1181 us
buffer 332 us
Well thats cleared that up, thanks!
Nope, all stored as floats in GMS anyway.

Arrays are a contiguous block of RAM, can't get any faster than that.

(Buffers probably are too in reality, but there is extra overhead internally with buffers due to the extra functionality)
Right ok that makes sense

Remember, When optimizing, Use better algorithms and thechniques. Data types and operators do not matter.
1: Group up your raindrops. Do they need to be individual??
2: Why 3D rain? That a waste! do them in screenspace!
3: Render them at lower res, then upscale (Looks better too since it should be blurry).
4: No need to simulate them hitting the ground or anything: Have them clip through the ground, And add random splatter effects on the ground. No one will notice.
I don't think any of thats good advice, I already said about grouping them, I don't use screen space cus its fake, and when you move the camera quick you can see the edges, rendering them at lower res wouldn't look how I want it to, the rain needs to be sharp thin lines or meshes and people will notice if the impact ripples are not in sync with the drops, and 3d rain looks cool! anyone can make boring old rain overlay stuff and particley stuff, but when you look upwards and its all coming down on you, it add loads of atmosphere


I think I'm gonna change the system to pre-animated vertex buffers anyway, kind of in groups and layers, and have them synced in a way that keeps them looking random, which will have hardly any impact on performance at all

Eg:

shader_set(rain)
uniform_set(animpos1)
vertex_submit(rainlayer1)
uniform_set(animpos2)
vertex_submit(rainlayer2)
uniform_set(animpos3)
vertex_submit(rainlayer3)
uniform_set(animpos4)
vertex_submit(rainlayer4)
uniform_set(animpos5)
vertex_submit(rainlayer5)
uniform_set(animpos6)
vertex_submit(rainlayer6)
uniform_set(animpos7)
vertex_submit(rainlayer7)
uniform_set(animpos8)
vertex_submit(rainlayer8)
shader_reset()
 
Last edited:

GMWolf

aka fel666
I don't use screen space cus its fake, and when you move the camera quick you can see the edges, rendering them at lower res wouldn't look good and the rain needs to be sharp thin lines and people will notice if the impact ripples are not in sync with the drops
Strange how AAA games Use each of these techniques....
More importantly? because its FAKE?! Its a game, the whole thing is fake! You are representing objects as triangle. Things in real life are not made of triangles! Faking it is how you get glever game rendering techniques: SSAO, Differed rendering, etc. They are all less accurate, but better looking, faster techniques used in AAA games.

Just to be clear: I screenspace effect does Not mean overlaying a a rain image. It means developing a shader that uses the depth information and camera position of the scene to render a rainy effect.

Beutiful example of a screenspace rain effect: https://www.shadertoy.com/view/XdSGDc
And they didnt have propper depth info to work with, or the camera position and all the other neat maps you can generate! That + a bit of geometry splatter and you have yourself some great rain!
[edit] This could be done far more efficiently with actual geometry to model the 'drapes' of rain too...
 
Last edited:

Joe Ellis

Member
You're both missing the point of what I mean by fake, real would be actually having the rain drops in the level, fake is not

I want the rain drops to actually be in the level and mesh based

I know what screen space is, and you can always tell its screen-space

I'm also not interested in the graphics of AAA games
 

Joe Ellis

Member
I don't understand what you mean? theres millions of games that aren't AAA quality, yours isn't, its like a flash cartoon

Pretty much every person that uses game maker isn't making an AAA game

And what about people who make pixel art games? are they in for a world of hurt too?

It means developing a shader that uses the depth information and camera position of the scene to render a rainy effect
That would "look" too fake
 
Last edited by a moderator:

Joe Ellis

Member
I understand exactly what you and Fel666 are saying, why are you even bothering to explain it? Its just making you seem patronizing

In what way have I been nasty, your game does look like a flash cartoon, I wasn't saying its a bad thing

I thought you were saying I'm in for a world of hurt cus I'm not interested in AAA games

And with saying that would "look" too fake I was trying to explain in which way I was using the word fake,

I'm not being nasty to anyone

I feel like your both attacking me just cus I want to use mesh based rain, and anyway, I'm not facing any kind of problem, I will have roughly 500 rain drops with about 8 vertices each, thats only 4000 vertices, what problem am I facing?
 

GMWolf

aka fel666
I understand exactly what you and Fel666 are saying, why are you even bothering to explain it? Its just making you seem patronizing
Because we have tried simmilar things before, and have learnt that it is a terrible Idea. We wish to help you, and teach you that this is a bad idea.
We can be patronizing to you, as you have asked for our help on these forums. Plus, given you ideas and attitude, i would say we have more experience than you.

I thought you were saying I'm in for a world of hurt cus I'm not interested in AAA games
The point of the AAA games was the following:
AAA games a built on custom, ultra-optimized engines. They can often dish out many more vertecies than you ever will in GM:S. However, even with all this extra power, 'propper' 3D rain simply isnt an option. Its is increadibly ineficient.
This is why we suggest you dont use it.
A screen space effect is not only cheaper, but beleive it or not, actually offeres you more options in terms of making it look good.
I would recomend you use a hybrid system, where drapes of rain are rendered on screen using flat panes in the 3d world, using a shader to texture it. Then use a screenspace shader to blend it correctly with the background. -> A depth buffer can be used to clip correctly.

As for the droplets, the player will not notcie that the splash effect doesnt happen where the drop falls. There are many reasons for that: Player doenst look at rain, There is a lot of it. Its hard to tell rain depth, rain falls fast, etc.
More importantly, with thousands of droplets, do not expect to be able to do that many collision checks! Sure it may run on early test builds, but cpu usage quickly ramps up with as more features and systems are implemented.

Anyhow, do as you please. Good luck.


[edit after reading wolff's post] Yep, raw vertex count probably isnt the bottle neck here. But wasting that much geometry here when panes of rain would do just as well... :/
 

Joe Ellis

Member
Why are you both still talking? neither of you have told me anything I don't already know

I don't want to use textured panes, I want to use meshes

Why would the player not look at the rain?

I don't want thousands of droplets I've already said I want 500 at the most

There will be no collision checks, the collisions are calculated in the animation process

I didn't know that cpu builds up the more features and systems are implemented, thanks

Panes of rain wouldn't do just as well cus I want them to be meshes



None of the things I've said have got anything to do with what style of rain I think looks best, I think every style is equally as good depending what type of game they're used in.

I wasn't asking for advice on how to make rain, the thread is titled: are buffers faster than arrays

I was using the rain as an example of something that might need to be optimized by using buffers

I don't like that shadertoy rain, it looks too shadery and fake

Plus the code for it is HUGE
 

GMWolf

aka fel666
I don't want to use textured panes, I want to use meshes
Panes are meshes.

Why would the player not look at the rain?
Because they are busy playing the game.

I don't want thousands of droplets I've already said I want 500 at the most
eh, factor of two. In algorithmic terms, thats usually ignored.

There will be no collision checks, the collisions are calculated in the animation process
Calculating collisions is performing collision checks.

Panes of rain wouldn't do just as well cus I want them to be meshes
Thats not a reason.
"Quicksort wont do because i want it to be insertion sort" <- Yeah.....

Plus the code for it is HUGE
Yeah, Thats because everything is done in a shader. As i suggested above, you can simplify it with actual draw calls.

I don't like that shadertoy rain, it looks too shadery and fake
-note, When rendering geomtry, you are uing shaders.
Thats whats greate about shaders, you can modify them.
Whats more, I was showing this example to show an example technique. The general idea can be applied to generate many other effects; rain, fog, dust, storms, snow, atmosphere, etc.

None of the things I've said have got anything to do with what style of rain I think looks best, I think every style is equally as good depending what type of game they're used in.
Our suggestions are two:
1: Batch your raindrops to reduce draw calls.
2: Use panes to reduce draw calls and vertex count.

Both of those do not impose a style. Infact, Batching allows you to keep your many individual raindrops.
Panes will be more efficient and offer more artistic control, but require more effort.

At this point i would suggest you just go with batching. I will stop all the mystery and explain it all:

Draw call are slow. Very slow. I presume you are drawing each of your droplets with a seperate draw call. Thats slow.
Batching them together allows you to drastically reduce draw calls. Infact, I can think of a couple ways to draw constantly falling raindrops in a single draw call! Though that requires the use of a vertex shader.
Instead, you can do in in a couple draw calls. Shouldnt be too hard to figure out.
If you are looking for something that will run on actual hardware, im affraid that doing splatters for each rain drop is unrealistic. Perhaps if you had access to the full power of the CPU, but you dont. (Actually, There may be a fairly convoluted way with shaders and surfaces).
Thats is why i suggest you spawn the splatters randomly. This will look just as good in most cases.

Why are you both still talking? neither of you have told me anything I don't already know
Why are you still asking questions?
 
Last edited:

Joe Ellis

Member
Panes are meshes.
I know they are meshes, why would I not know that? But they are flat meshes, a mesh thats called a mesh and not a pane can be any shape

Because they are busy playing the game.
As soon as they stop and look at the rain they would think, arr the rain looks abit sh it

Calculating collisions is performing collision checks.
They are calculated once during the animation process, not every frame, ei. the collisions are not calculated while the game is running therefore during the game, there is none, so it has no impact on performance

Thats not a reason.
It is, a pane is a flat mesh, a mesh can be any kind of shape

Yeah, Thats because everything is done in a shader. As i suggested above, you can simplify it with actual draw calls.
I have already told you that I'm using vertex buffers

-note, When rendering geomtry, you are uing shaders.
Oh are you? I didn't know that

Thats whats greate about shaders, you can modify them.
I didn't know that either

The general idea can be applied to generate many other effects; rain, fog, dust, storms, snow, atmosphere, etc.
The general idea of that example is not one I want to use

1: Batch your raindrops to reduce draw calls.
I have already done that

Use panes to reduce draw calls and vertex count.
I don't want to use panes

Batching allows you to keep your many individual raindrops
I know that

Panes will be more efficient and offer more artistic control, but require more effort.
They would not offer more artistic control, they are flat

At this point i would suggest you just go with batching.
I already have

I will stop all the mystery and explain it all:
I already understand everything you've said, I just don't want to do it the way that you would. It doesn't mean that your way is wrong, I just don't want to do it that way, there isn't one way of doing everything, you should be less narrow minded, and if your going to say that I am being narrow minded, I'm not, I just want to use a particular way in this particular case, a few months down the line I will be making another type of rain, using another method

Draw call are slow
I know that

I presume you are drawing each of your droplets with a seperate draw call
No, I have already said I'm using vertex buffers

Thats slow
I know that

Batching them together allows you to drastically reduce draw calls
I know that

I can think of a couple ways to draw constantly falling raindrops in a single draw call
So can I

Though that requires the use of a vertex shader
Does it? oh I didnt know that

Instead, you can do in in a couple draw calls
I have already shown how that is possible

Shouldnt be too hard to figure out.
I figured it out long before I made this thread

im affraid that doing splatters for each rain drop is unrealistic
It isn't cus you can group them into batches to reduce draw calls, draw calls are slow, Very slow

Thats is why i suggest you spawn the splatters randomly
I have understood why you are suggesting it since you first suggested it, but I immediatley told you that I dont want to do that, so you should've left it there.

Why are you still asking questions?
Cus you're both annoying, and lone wolf is a liar, he happily took Ā£150 off me for an hours work

Each quad is four verts
Wow is a quad FOUR verts? How the hell did you find that out? I would never have thought of that!

Is a triangle THREE verts? wouldn't surprise me if it was, and that explains why you said some quads are 6 verts depending on how you do it

and the framerate will plummet
How is it possible to render 300000 quads without the framerate even dropping by 1 fps_real then? thats 1.8 million verts and the performance is the same as if there are no verts being rendered

And you can render 1 million quads / 6 million verts and the framerate is still on 65 fps_real, in case you don't know that means it doesn't go jerky at all, it starts going jerky when the fps_real drops below the screen refresh rate, which is 60, or 70 if you set your monitor to use this mode

I don't understand how you can be so arrogant and patronizing, when your just telling people commonly known stuff and half of it is wrong

And why do you keep talking about multiplying each vert against a world * view * perspective transform, thats the most commonly known thing to do with rendering and your acting like its something dead clever and its dead good how you know that
 
Last edited:

GMWolf

aka fel666
So I wanted to find a quicker way of iterating through the rain drops and applying the gravity/movement for each one at a time, and also check whether they've hit the ground or not and if they do, place them back in the sky.
Sounded like you where updating each droplet every step.


Also sounds like you are building a new vertex buffer every step....

The idea is that you use a single vertex buffer you do not need to rebuild.

If this is already what you are doing, then there is no need to iterate through each raindrop...

If however, what you said above, is somehow very misleading and you are not doing any calculations per step and are drawing everything in a single step, what is it you where asking about again? Because its probably irrelevant.
 
Last edited:

Joe Ellis

Member
I explained after that:

I think if I switch to buffers, group the rain drops into about 20 vertex buffers initially and d3d_transform them to make them fall it'll be ok, I'm expecting some kind of memory usage obviously, I just need it to be about twice as fast
I think I'm gonna change the system to pre-animated vertex buffers anyway, kind of in groups and layers, and have them synced in a way that keeps them looking random, which will have hardly any impact on performance at all
So my method developed as the thread developed, which is not misleading at all, its the opposite, I'm keeping everyone updated about any changes

And I was asking about if buffers are faster than arrays and I got my answer, and thats all I wanted to know, how you came in telling me how I should do the rain, after not reading everything that I said beforehand is moronic

there's not much point in carrying on with this debate, I'm gonna leave it here, sorry if I offended you, I was just telling you my opinion, I didn't mean any of it to be hurtful, It was just quite infuriating that you kept going on and on about the same stuff when I'd already said that I'm using a similar technique, and also telling me loads of things that I have known for ages, as if I didn't know them, you shouldn't assume that people know less than you when you've got no evidence of it, I am aware that rendering 3d rain is a challenge, but thats mainly why I want to do it, I'm trying to develop something thats not widely used and available, I'm not interested in recreating a technique thats tried and tested and known to be a good technique, what's the point, someone else has already come up with it

Again, please don't take offence by what I'm saying, I'm just telling you straight forwardly what I'm trying to achieve
 
Status
Not open for further replies.
Top