Dungeon Master Forum

Jan wrote:A combination of a ruster, a crab, a blackbird, a gingerbread sweet that my mother always makes for Christmas, and Santa Claus!

That was exactly what I was going for

Havn't been any progress post for a while because I'm recreating particlesystem for nicer spells and effects, I'm also rewriting the HLSL shader with the purpose to increase the fps update.

It's not as big job as it sounds, and I should be able to post some videos on the result til sunday.

Good going. You're taking the advice, WOW!... sorry if I sound surprised here, but all the REAL people in my life (the people I actually see, not the people I have to type to) NEVER take any of my advice, then afterwards they go "Oh crap! Maybe I should have taken that advice."

Anyways, back on topic, I'm glad to hear that your deciding to optimise what you have already done. It's much more efficient to improve what's there, than to work with something that needs the optimising. I'd prefer to test my program at 100fps (that's my app's limit, BTW. It's more like 500-600 ), rather than test at 30fps with an UNoptimised process or ten, or that might just be me. However, you're further on in your development than I am. I may very well run into performance issues later on too.

Keep up the good work, dude. You're plowing through development, keep it up. <BoNes gives two thumbs up>

He's faster than light

Tell me about it. He's just pounding through this development! I honestly can't believe just how quick he is...

Thank you guys

Lord Bones, you shouldn't be supriced that I took your advice, I even sent you mail to get some advice on how to manage a good particle system And I do agree with you, this is some major flaws in the game right now that I have to fix.

I think I will be able to opimize the system so that the game will run at atleast 120 fps at lowest settings, and 60 fps at highest settings. And the game will go even faster if I learn a faster way to sort particles in back to front order, if the shown particles exceds 300-500, the game starts to lag more and more, and if they goes up to 999 particles, the games fps are down at 3-4 fps. I think I will have to do some shortcut here and only sort the particles that are closest to the camera.

One more thing is that if I do no rendering at all, the fps are at up at only 200 fps. If the FTL team manage to create a atleast 20 fps update without graphic rendering on the Amigas 6 Mhz processor, I should be able to create make the non graphic update non noticeable on my dual core 2,1 GHz machine

I know that this may sound like a stupid question to ask, but are you only sorting the ones that are actually going to be displayed.
From the look of the videos, you still have a "grid based" wall system... IE: like RTC is "grid based" with it's walls and movement. You've just made it free-cam...
One way I can think of to optimise your sorting of ANYTHING:
Use linked-list arrays to store the objects on each given grid-square (3 tiered arrays - for x,y & z. Then you just have the first entry in each array link the second, and the second to the third, etc.)
So any particles that are occupying (1,1,1) get put in a linked-list just for (1,1,1) and any particles for (2,1,1) go to the list for (2,1,1). The reason this works... you just sort the distance to each grid-square, much quicker than per particle, and draw all the linked-objects (particles in this case) based on the grid-square's distance from the camera.

I'm not sure if you'll be able to understand all this, typing is such a difficult way to advise anyone on pretty much anything.

Yes, I do only sort the once that are going to be displayed
I think I understand, and you are right about "grid based" wall system, everything that is positioned on non viewable squares are not rendered.
As it is now (not in the video), I render the "squares" in front to back order because the hlsl shader simply skips drawing pixels where a closer pixel already has been rendered. This speeded up the fps alot.
What you mean is that I identify every particle with the squares they are positioned on, and then render the particles in the squareorder back to front. But also that I have extra grinds in every square so that all the particles in the same square get rendered in the right order, or that I sort the particles manually in every square and then render them in the right order square by square.
This would save alot of extra calculations, I think you already understand what it means to check every particles if I have lets say 1000 particles, to check particle with every particle in this case would require 1000*1000 distance checks. The system I have now are not THAT primitive What I do is that when I add new particles I put it in the right listposition depending on its distance. And then the sorting gets alot easier because the program "jumps" the checking of all the particles that are in right order. But still :S Not good enough

If I practice your idea with the "sorting system" I already have it might work out nicly Thanks

When the particle is created is when you'd chuck it into its linked-list. You'd also have to check it whenever the particle moves. You could try to span it out... make it so that it does the calculations for 1/2 the particles one frame, and the other half on the next frame.

Also, is your program multi-threaded? If it is, then setup some threads specifically to update your particles (with my above example, you could have 2 threads, one for the 1st 1/2 of the particles, and one for the 2nd 1/2).

Linked-lists are EXTREMELY useful for sorting, you can alter/add/remove at will (with a "well setup one", of course), and you can break your sorting down into multiple smaller fragments, then you can pick and choose which ones you want to update, and when to update them, saving CPU/GPU cycles... only recently have I discovered the real power of linked-lists.

One rule that you should teach yourself (I learnt this one VERY quickly, even if only recently fully discovered):
Every CPU & GPU cycle is prime real-estate. If your program uses a "full single core" (in other words, a dual core using 1 core, or 50% of the CPU, constantly... this means that the program DOESN'T use true multithreading) or if it uses ALL of the CPU constantly... then you need to rework your timer/main-loop function.
By this I mean that the CPU should only ever max out any of your cores when it NEEDS to... not all the time. Most games don't apply this rule, as a result, they actually cost themselves CPU cycles (wasted on unoptimised timers and such) you should try it out... go run a game, then press control-alt-delete (open task manager) and track the CPU usage, you'll find out what I mean

EDIT: You should put your particles into the linked-list in a "pre-determined" drawing order... the ones you want draw first are in the list first.

Rasmus wrote:I render the "squares" in front to back order because the hlsl shader simply skips drawing pixels where a closer pixel already has been rendered. This speeded up the fps alot.

Interesting. I'd always heard that you needed to draw from back to front to take advantage of alpha blending and other niceness, because it needs to know what pixels are already there before you can blend them, obviously. Does your program not use such things, or do the shaders handle this for you, too?

Have you looked into testing your game with different shaders? That may be a cause of your performance bottle-neck.

Sophia wrote:

Rasmus wrote:I render the "squares" in front to back order because the hlsl shader simply skips drawing pixels where a closer pixel already has been rendered. This speeded up the fps alot.

Interesting. I'd always heard that you needed to draw from back to front to take advantage of alpha blending and other niceness, because it needs to know what pixels are already there before you can blend them, obviously. Does your program not use such things, or do the shaders handle this for you, too?

No this advantage is only posible when rendering solid objects. After that you render the blended objects in back to front order so that the alpha comes out correct.

Shouldn't you do them both in the one pass, determined by distance from camera? So that the particles are drawn at the same time as the dungeon square that they're on... in other words, draw the floor/ceiling then the particles for the square... all in one go. Then you move on to the next closest square...

I have read a bit about multithreading, but I really havn't had any use of it because the real bottleneck is the rendering. But you are right Bones, sorting alpha particles is the perfect use for it
One positive I recently discovered is that as long as I am running the game under debug mode the fps is around 60 - 65, but when a run the release, the fps increases to 100. This was a positive supprice, I didn't know that the diffrence was THAT big.

I might add that when I am now running on 60-65 fps I have the viewing distance at 10 squares. Before I altered the shader I had a viewingdistance on 4 squares and only running between 40 - 50 fps.
I have also modified the shader so that the bumpmapping only comes from the player light. This is because every square now can take up to 10 lights at once. Before I had a limit at three lights/square and that all light used the bumpmapping technic. Now lights even out the bumpmap from the playerlight.
This was a real speed boost and looks better to because I can use more lights without affecting the fps as I did before.

When you say Linked-lists you mean that every particlestructure (pos, vel, color etc.) have an address to it. In this case I only have a need to move the address and not the hole particlestructure? If this is what you meant, then I have already done that

I haven't tried diffrent shaders because the general opinion on the net is that some shader are good at something and bad on other things and so on, so that the preformance in the end would be the same. One idea here might be to combine diffrent shaders to diffrent rendering tasks..

I really appricate the ideas you give me Lord Bones, they really helps

Lord_BoNes wrote:Shouldn't you do them both in the one pass, determined by distance from camera? So that the particles are drawn at the same time as the dungeon square that they're on... in other words, draw the floor/ceiling then the particles for the square... all in one go. Then you move on to the next closest square...

If I draw the particles at the same time as I draw the square I have to render the squares in back to frontorder, and that lower the fps.
It really doesn't matter if I draw the particles after that I have drawn all the squares, because the squares with walls etc. isn't alpha blended.
I understand what you mean, but I do draw the particles in the square distance order, but only after I have drawn all the squares.

You'd have to draw certain particles BEFORE same walls (particle half-way behind a wall). I don't understand how sorting your squares would slow it down that badly... just do what I suggested for the particles to order your walls aswell... as I said, linked-lists are EXTREMELY potent.

It doesn't get slowed down that badly, but we are talking about 10 % extra speed by rendering the squares in front to back order.
The reson why I don't have to draw the particles before the walls is because Z-buffering isn't disabled. If I draw a particle behind a already drawn wall, the particle will not be drawn, the shader fix this.
After I have drawn all the non blended squares, I will have a solid depthfield, and then it's only to draw the particles in back to front order with Z-Write disable so that they dosn't intefer with eachother.

Before I do any rendering I have also already calculated which squares that are viewable and nonviewable depending on the camangle or if other walls are in the way.

I might add that I am using the sorting particles by square technic, I'm just drawing the particles after that I have drawn the walls..

Rasmus wrote:the real bottleneck is the rendering

Rasmus wrote:sorting alpha particles is the perfect use for it

Maybe. If your real bottleneck is rendering, then making the renderer sit there and wait while the sorting/processing/whatever thread finishes manipulating the linked list won't help you at all. There are ways around all this, of course (mostly involving buffering and not rendering from the actual physics data) but it may be more than you feel like doing, depending on how badly you really need multiple threads.

Rasmus wrote:The reson why I don't have to draw the particles before the walls is because Z-buffering isn't disabled. If I draw a particle behind a already drawn wall, the particle will not be drawn, the shader fix this

Oh, that's great.

Except if your walls aren't solid, anyway. But that's kind of an odd case for DM...

I hope that your project advances well

Here comes a video with the new shader..
http://s955.photobucket.com/albums/ae36 ... Shader.flv

I will add a video with the spells later tonight...

RAF68: Two more weeks, then I release the beta.

Sopfia: I found a way to make the particlesystem work nicely without the need of multithreding. When I add a particle I do it in the right back to front order. The only problem is that some particles have a lifetime on 1 second, and are moving in diffrent directions, this creates the problem that some particles will get in front of others. I fixed this by only sorting all the particles once with the one that is closest to it in the list, if the order is backwards, I switch places on them. In this way I only have to do 1000 calculations for 1000 particles every frame.
The output result was that it is nearly imposible to see if one particle now or then happends be to rendered in the wrong order.

Well, the fakewall is alphablended, but I think I will solve this problem by adding the wall to the particlesystem so that when it comes to that it will take a little shortcut to RenderFakeWall(x, y).

Well, that looks incredibly well, Rasmus!

I didn't follow the previous discussion, but I wanted to ask - why are the corners (edges) of the walls rounded? In reality, sharp (square) corners would be more likely, especially in case of bricks in the Hall of Champions, or maybe irregular in the caves bellow. But it's just a detail.

Remarkable work...Congratualtions on getting
this far.

Appears to be a mirror image of a place
I have visited!

Thank you Paul and Jan

About the rounded corners, this is something I added a while ago because I didn't want the game to look squarish (if that is a word ). I can easely change it back, or maybe only on some level with particular walls. But for now, they will stay until a realsed the Beta. After that I will go into those details..

I saw the video and I am very to impress! , I await the playable demo

Hi Rasmus, looks great and can't wait to give it a go... however, why is it mirrored - as paul noted...?

Thank you RAF..

I am now in progress fixing the spells with new particles..
If somebody knows how much poisondamage the poisonbolt does on enemys over time it would be appriciated
The same goes for the poisondart.

money wrote:Hi Rasmus, looks great and can't wait to give it a go... however, why is it mirrored - as paul noted...?

Hehe, he has a sharp eye
When I first imported the map from the RTC editor I got the X or Y axis in the wrong order.. And when I noticed it, then it was to much work of correcting it.
It can be a bit confusing at first for the veteran DM player, but I hope it doesn't destroy the gameplay to much

Rasmus wrote:If somebody knows how much poisondamage the poisonbolt does on enemys over time it would be appriciated
The same goes for the poisondart.

They don't do any. The damage is done solely on impact.