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.Buffers
These functions can be used to read and write directly to the device buffer memory.
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,The only time that would really matter if you were performing substantial algorithms on each index every step with thousands of indexes
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.
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.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...
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?You really ought to be using a particle system for an effect like that
Whats that?Use the profiler to find the source of the problem. That's your best bet.
Is this for a 3D or 2D game?
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 fastI 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
Run the game in debug mode and set one of the window types to the profiler.Whats that?
3d, its with lines aswell, not sprites
Yeah they are.Arrays are faster.
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 seperatlyI'm expecting some kind of memory usage obviously, I just need it to be about twice as fast
Well thats cleared that up, thanks!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
Right ok that makes senseNope, 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)
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 atmosphereRemember, 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.
Strange how AAA games Use each of these techniques....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
That would "look" too fakeIt means developing a shader that uses the depth information and camera position of the scene to render a rainy effect
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.I understand exactly what you and Fel666 are saying, why are you even bothering to explain it? Its just making you seem patronizing
The point of the AAA games was the following:I thought you were saying I'm in for a world of hurt cus I'm not interested in AAA games
Panes are meshes.I don't want to use textured panes, I want to use meshes
Because they are busy playing the game.Why would the player not look at the rain?
eh, factor of two. In algorithmic terms, thats usually ignored.I don't want thousands of droplets I've already said I want 500 at the most
Calculating collisions is performing collision checks.There will be no collision checks, the collisions are calculated in the animation process
Thats not a reason.Panes of rain wouldn't do just as well cus I want them to be meshes
Yeah, Thats because everything is done in a shader. As i suggested above, you can simplify it with actual draw calls.Plus the code for it is HUGE
-note, When rendering geomtry, you are uing shaders.I don't like that shadertoy rain, it looks too shadery and fake
Our suggestions are two: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.
Why are you still asking questions?Why are you both still talking? neither of you have told me anything I don't already know
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 shapePanes are meshes.
As soon as they stop and look at the rain they would think, arr the rain looks abit sh itBecause they are busy playing the game.
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 performanceCalculating collisions is performing collision checks.
It is, a pane is a flat mesh, a mesh can be any kind of shapeThats not a reason.
I have already told you that I'm using vertex buffersYeah, Thats because everything is done in a shader. As i suggested above, you can simplify it with actual draw calls.
Oh are you? I didn't know that-note, When rendering geomtry, you are uing shaders.
I didn't know that eitherThats whats greate about shaders, you can modify them.
The general idea of that example is not one I want to useThe general idea can be applied to generate many other effects; rain, fog, dust, storms, snow, atmosphere, etc.
I have already done that1: Batch your raindrops to reduce draw calls.
I don't want to use panesUse panes to reduce draw calls and vertex count.
I know thatBatching allows you to keep your many individual raindrops
They would not offer more artistic control, they are flatPanes will be more efficient and offer more artistic control, but require more effort.
I already haveAt this point i would suggest you just go with batching.
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 methodI will stop all the mystery and explain it all:
I know thatDraw call are slow
No, I have already said I'm using vertex buffersI presume you are drawing each of your droplets with a seperate draw call
I know thatThats slow
I know thatBatching them together allows you to drastically reduce draw calls
So can II can think of a couple ways to draw constantly falling raindrops in a single draw call
Does it? oh I didnt know thatThough that requires the use of a vertex shader
I have already shown how that is possibleInstead, you can do in in a couple draw calls
I figured it out long before I made this threadShouldnt be too hard to figure out.
It isn't cus you can group them into batches to reduce draw calls, draw calls are slow, Very slowim affraid that doing splatters for each rain drop is unrealistic
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.Thats is why i suggest you spawn the splatters randomly
Cus you're both annoying, and lone wolf is a liar, he happily took Ā£150 off me for an hours workWhy are you still asking questions?
Wow is a quad FOUR verts? How the hell did you find that out? I would never have thought of that!Each quad is four verts
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 renderedand the framerate will plummet
Sounded like you where updating each droplet every step.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.
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
So my method developed as the thread developed, which is not misleading at all, its the opposite, I'm keeping everyone updated about any changesI 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
Agreed. So topic closed as it's just going in circles...there's not much point in carrying on with this debate