Gamestudio Links
Zorro Links
Newest Posts
New FXCM FIX Plugin
by flink. 06/04/24 07:30
AlpacaZorroPlugin v1.3.0 Released
by kzhao. 05/22/24 13:41
Free Live Data for Zorro with Paper Trading?
by AbrahamR. 05/18/24 13:28
Change chart colours
by 7th_zorro. 05/11/24 09:25
AUM Magazine
Latest Screens
The Bible Game
A psychological thriller game
SHADOW (2014)
DEAD TASTE
Who's Online Now
0 registered members (), 1,454 guests, and 8 spiders.
Key: Admin, Global Mod, Mod
Newest Members
AemStones, LucasJoshua, Baklazhan, Hanky27, firatv
19058 Registered Users
Previous Thread
Next Thread
Print Thread
Rate Thread
Page 7 of 11 1 2 5 6 7 8 9 10 11
Re: Dumb terrain question.. Cannot get it to move... [Re: EvilSOB] #386538
11/04/11 14:55
11/04/11 14:55
Joined: Oct 2008
Posts: 513
Carlos3DGS Offline
User
Carlos3DGS  Offline
User

Joined: Oct 2008
Posts: 513
Ok, started doing tests to see if you guys can help me out.

firstly... I will detail the method I am using to get the times (just in case this is not a good option and it screws up all my timings).

I declare this globar variable:
Code:
double STOPWATCH;


And then I do this before and after my paint function calls:
Quote:
beep();
dtimer();


t_format2=bmap_lock(Sand_BM,0);
t_format2=bmap_lock(Grass_BM,0);
t_format2=bmap_lock(Rock_BM,0);
t_format2=bmap_lock(Snow_BM,0);

for(x=0;x<TERRAIN_COUNT;x++)
{
for(y=0;y<TERRAIN_COUNT;y++)
{
Terrain_Paint(x,y);
wait(1);
}
}

wait_for(Terrain_Paint);
bmap_unlock(Sand_BM);
bmap_unlock(Grass_BM);
bmap_unlock(Rock_BM);
bmap_unlock(Snow_BM);

STOPWATCH=dtimer();
STOPWATCH/=1000000;
beep();

NOTE: I am now using 9x9 (81) Terrains, because I want an odd number for the future when I want everything centerd around a central terrain the player is on, but that will come later...


-Times with my current code: all around 25.5 secs

0> No wait calls during my my single paint functions or height calculation function, only between terrains.

1>Only have one pixel_for_bmap and one pixel_to_bmap instructions, disabled both of them:
around 25.1 secs
Code:
//pixel_source = pixel_for_bmap(Source_BM,Pixel_pos.x,Pixel_pos.y);
//pixel_to_bmap(NewSkin,Pixel_pos.x,Pixel_pos.y,pixel_dest);



2>I think I only have two pixel colour calculation instructions, disabled both of them:
around 24.7 secs
Code:
//t_color = pixel_to_vec(NULL, t_alpha ,t_format2,pixel_source);
//pixel_dest=pixel_for_vec(t_color,t_alpha,t_format1);



3>enabled all my previously disabled pixel & colour instructions. Disabled my height funcion call and substituted it with a random number:
around 5 secs
Code:
//height = get_height(Pixel_pos.x,Pixel_pos.y,i,Terr);
height=random(200);



4>pulled bmap_create out of the function to set it as a global and only create it once on startup after level_load. I also disabled "if(height>16)", since the bmap will be fully substituted each time because we don't start off from sand texture for consecutive paint calls. Enabled height calculations again:
around 26 secs
NOTE: does not work correctly, all skins are modified since the same bmap is reused for all terrains, they all end up having the same texture as the last terrain created.

5> Cannot disable bmap_lock, they have to be locked to read from (or write to), causes an E1513. No viable way to solve this unless I disable absolutely everything else.



The culprit seems to be the height calculations... only 5 secs withought that... 5 secs for painting 100 512x512 textures?!?!? That is awesome!!!! (but sadly this paint speed is only with random heights instead of my height calculations), but still the paint speed is pretty impressive for retrieving 100 textures, creating 100 textures, reading 26214400 pixels, calculating their respective 78643200 colour vector values, setting those 26214400pixels again, removing 100 ent skins, and setting 100 skins! all in 5 secs!
http://www.youtube.com/watch?v=CbNp-rD4Jog

EDIT: my get_height() function mostly does simple add, subtract, multiply and divide operations. Besides that it uses some vector operations that also are fairly simple vec_set and vec_sub. besides that I only have one vec_cross and one vec_to_angle instruction (that also do nothing extraordinary besides a few basic multiplications and additions). So I think the only instructions left in that function that could be causing the problem are the ent_getvertex calls?

I havn't used shaders yet, so I am not sure if I can. But I own A8 Commercial.

Last edited by Carlos3DGS; 11/04/11 16:30.

"The more you know, the more you realize how little you know..."

I <3 HORUS
http://www.opserver.de/ubb7/ubbthreads.php?ubb=showflat&Number=401929&page=1
Re: Dumb terrain question.. Cannot get it to move... [Re: Carlos3DGS] #386543
11/04/11 17:00
11/04/11 17:00
Joined: Feb 2008
Posts: 3,232
Australia
EvilSOB Offline OP
Expert
EvilSOB  Offline OP
Expert

Joined: Feb 2008
Posts: 3,232
Australia
Excellent testing technique.

But Im sorry.... my bad. I only skimmed over your get-heights,
so I didnt see the ent_getvertex's in there.
They are a well-known SERIOUS issue with speed when calling on a pix-by-pixel basis.

As you are certainly aware, when you just call ent_getvertex(?,?,xx) you get
just ONE vertex worth of data. Obviously..
But were you aware, if you call ent_getvertex(?,?,1) then ent_setvertex(?,?,1),
it gives you access to ALL the vertices, without any more ent_getvertex calls?
(At least until the next wait(), and then the buffer gets flushed away.)

I know your code, to my un-familiar eye, doesnt look friendly to the idea,
but is it PLAUSABLE to fit the following concept into a SINGLE frame...?
[because if you hit any wait(), you need to re-call ent_getvertex(?,?,1) & ent_setvertex(?,?,1)]

1> Call ent_getvertex(?,?,1) then ent_setvertex(?,?,1) to access the vertex buffer.

2> Set all your heights DIRECTLY into this buffer. Do a ent_setvertex to lock it in.
[note: even though you did a ent_setvertex(?,?,1) to save, the buffer is STILL THERE until the next wait()]

3> Paint your skin using the data from the buffer rather than individual ent_getvertex calls.

Does that sound within the realms of possibility?
And YES, I am aware thats a LOT of changes...

I am CERTAIN this will give you a serious improvement, but I GUESSTIMATE
it will actually give a HUGE improvement, based on my rough understanding
of the sheer number of times your get_height gets called, which looks large.
BUT, will it be enough? And will the improvement be worth that much re-coding?

I certainly HOPE so.... But only time and MUCH effort will tell...

Best of luck...


"There is no fate but what WE make." - CEO Cyberdyne Systems Corp.
A8.30.5 Commercial
Re: Dumb terrain question.. Cannot get it to move... [Re: EvilSOB] #386544
11/04/11 17:04
11/04/11 17:04
Joined: Feb 2008
Posts: 3,232
Australia
EvilSOB Offline OP
Expert
EvilSOB  Offline OP
Expert

Joined: Feb 2008
Posts: 3,232
Australia
Oh... BTW....

A8 commercial gives full access to all possible shader techniques.

So it may be worth your while to post a 'help' in the shader section.
I suspect it is possible to write a shader that will do this calculation
on the GPU as a form of single-frame object shader...

Im no shader guru, so its out of my league. but if you do post there, I will
keep an eye on the thread in case a guru asks any questions too tricky for you...


"There is no fate but what WE make." - CEO Cyberdyne Systems Corp.
A8.30.5 Commercial
Re: Dumb terrain question.. Cannot get it to move... [Re: EvilSOB] #386551
11/04/11 17:59
11/04/11 17:59
Joined: Oct 2008
Posts: 513
Carlos3DGS Offline
User
Carlos3DGS  Offline
User

Joined: Oct 2008
Posts: 513
I will try to adapt my code to do 3 at a time for each call.
But I don't know how to achieve that... Could I get a call example?

Lets say I want verts 1,2,34... how would I build the new get_vertex() call?

Currently I would do it like this:
c1= ent_getvertex(Terrain,NULL,1);
c1= ent_getvertex(Terrain,NULL,2);
c1= ent_getvertex(Terrain,NULL,34);


"The more you know, the more you realize how little you know..."

I <3 HORUS
http://www.opserver.de/ubb7/ubbthreads.php?ubb=showflat&Number=401929&page=1
Re: Dumb terrain question.. Cannot get it to move... [Re: Carlos3DGS] #386552
11/04/11 18:13
11/04/11 18:13
Joined: Mar 2006
Posts: 3,538
WA, Australia
J
JibbSmart Offline
Expert
JibbSmart  Offline
Expert
J

Joined: Mar 2006
Posts: 3,538
WA, Australia
EvilSOB's idea of a single-frame object shader to handle the painting with height calculations is totally doable and would be very quick.

Alternatively, you could re-think your use of get_height -- you may want to have a height_init function or something that prepares a terrain for height calculations, and then a new get_height function that uses data from height_init:
Originally Posted By: manual
The c.v pointer points into the mesh vertex buffer, which is an array of D3DVERTEX structs with a total size given by ent_status(ent,1)*ent_status(ent,22) . Calling ent_getvertex(ent,NULL,1) followed by ent_setvertex(ent,c,1) retrieves a pointer to the start of the vertex buffer, and allows to modify the whole vertex buffer without further ent_getvertex or ent_setvertex calls. However this fast method only affects one mesh chunk of multi-mesh entities, and the row/column order of the vertices in the buffer correspond to the chunk size in that case, and not to the whole terrain size.
Direct manipulation of the data should be quite a bit faster, although it's still a lot to do for the CPU and I definitely recommend exploring the pure shader-based option.

I hope this is helpful -- I haven't read the whole thread.
EDIT -- I didn't realise EvilSOB had already covered the ent_getvertex optimisation as well.

Last edited by JibbSmart; 11/04/11 18:15.

Formerly known as JulzMighty.
I made KarBOOM!
Re: Dumb terrain question.. Cannot get it to move... [Re: JibbSmart] #386554
11/04/11 19:17
11/04/11 19:17
Joined: Feb 2008
Posts: 3,232
Australia
EvilSOB Offline OP
Expert
EvilSOB  Offline OP
Expert

Joined: Feb 2008
Posts: 3,232
Australia
I would suggest trying to do more than three at a time, but if this is for a trial, then OK...

In a ROUGH conversion of your actual code, I would take your OLD code...
Code:
//retrieve first point of containing triangle (base corner)
	c1= ent_getvertex(Terrain,NULL,SW);
	Triangle[0].x=c1.v.x;
	Triangle[0].y=c1.v.z;
	Triangle[0].z=c1.v.y;
	
	//retrieve second point of containing triangle (diagonal to base)
	c1= ent_getvertex(Terrain,NULL,SW-32);
	Triangle[1].x=c1.v.x;
	Triangle[1].y=c1.v.z;
	Triangle[1].z=c1.v.y;
	
	//determine third point of containing triangle (varying point)
	vec_set (temp_vec, P);
	vec_sub (temp_vec,Triangle[0].x);
	vec_to_angle (temp_ang.pan,temp_vec);
	
	//retrieve third point of containing triangle (varying point)
	if(temp_ang.pan>45)
	{
		c1= ent_getvertex(Terrain,NULL,SW-33);
	}
	else
	{
		c1= ent_getvertex(Terrain,NULL,SW+1);
	}
	Triangle[2].x=c1.v.x;
	Triangle[2].y=c1.v.z;
	Triangle[2].z=c1.v.y;


And turn it into THIS
Code:
//retrieve the three points of containing triangle

	//first, open the buffer
	ent_getvertex(Terrain,c1, 1);	ent_setvertex(Terrain,c1, 1);

	//retrieve the first point of containing triangle (diagonal to base)
	Triangle[0].x = c1.v[SW].x;
	Triangle[0].y = c1.v[SW].z;
	Triangle[0].z = c1.v[SW].y;
	
	//retrieve second point of containing triangle (diagonal to base)
	Triangle[1].x = c1.v[SW-32].x;
	Triangle[1].y = c1.v[SW-32].z;
	Triangle[1].z = c1.v[SW-32].y;
	
	//determine third point of containing triangle (varying point)
	vec_to_angle(temp_ang.pan, vec_sub( vec_set(temp_vec, P),Triangle[0].x));
	
	//retrieve third point of containing triangle (varying point)
	if(temp_ang.pan>45)
	{
		Triangle[2].x = c1.v[SW-33].x;
		Triangle[2].y = c1.v[SW-33].z;
		Triangle[2].z = c1.v[SW-33].y;
	}
	else
	{
		Triangle[2].x = c1.v[SW+1].x;
		Triangle[2].y = c1.v[SW+1].z;
		Triangle[2].z = c1.v[SW+1].y;
	}


Please bear in mind, Ive just done this in a text editor, so beware of syntax errors or typo's.

One thing that may hitch up is my referencing of the vertex array...
You may need to add parentheses like so...
Code:
this format
...  c1.v[SW].x  ...
may need changing to
...  (c1.v)[SW].x  ...


I can never remember that bit... grin ... until the compiler bitches at me...


"There is no fate but what WE make." - CEO Cyberdyne Systems Corp.
A8.30.5 Commercial
Re: Dumb terrain question.. Cannot get it to move... [Re: EvilSOB] #386555
11/04/11 19:18
11/04/11 19:18
Joined: Feb 2008
Posts: 3,232
Australia
EvilSOB Offline OP
Expert
EvilSOB  Offline OP
Expert

Joined: Feb 2008
Posts: 3,232
Australia
Oh... and you dont NEED to finish with an ent_setvertex unless you want
to SAVE any changes you made inside the buffer...


[EDIT] BTW... This seems a popular thread for lurkers...
Check the number views this thread has had...


Last edited by EvilSOB; 11/04/11 19:21.

"There is no fate but what WE make." - CEO Cyberdyne Systems Corp.
A8.30.5 Commercial
Re: Dumb terrain question.. Cannot get it to move... [Re: JibbSmart] #386556
11/04/11 19:22
11/04/11 19:22
Joined: Oct 2008
Posts: 513
Carlos3DGS Offline
User
Carlos3DGS  Offline
User

Joined: Oct 2008
Posts: 513
I am interested in the shader option both of you have suggested, but have no clue where to start. I have never worked with shaders before. When I started with 3dgs I downloaded one that someone contributed on the forum, and when opening it nothing made any sense to me and I have never looked at one since then.
Would it be faster for the computer to do it with a shader?
Would it be easier to program it with a shader?

If so, any help to get started with this shader would be awesome ;D


"The more you know, the more you realize how little you know..."

I <3 HORUS
http://www.opserver.de/ubb7/ubbthreads.php?ubb=showflat&Number=401929&page=1
Re: Dumb terrain question.. Cannot get it to move... [Re: Carlos3DGS] #386557
11/04/11 19:30
11/04/11 19:30
Joined: Feb 2008
Posts: 3,232
Australia
EvilSOB Offline OP
Expert
EvilSOB  Offline OP
Expert

Joined: Feb 2008
Posts: 3,232
Australia
I BELIEVE it would be hellishly faster, as it is being handled by
vertex and pixel dedicated hardware of the video card.

So to answer your questions ..
Faster to execute? Hell YES
Easier to program? GOD NO!

Programming shaders is a language all its own.
If you CHOOSE to get into it, it is a great advantage, but it is
LITERALLY like learning a new language. You gotta learn to speak before
you can sing lead role in an opera...

There are plenty of Opera singers who hide in the shader forums here,
so Im sure someone will help out purely for the mental exercise of it...


And dont look to me for help with shaders, it makes my brain hurt too much.


"There is no fate but what WE make." - CEO Cyberdyne Systems Corp.
A8.30.5 Commercial
Re: Dumb terrain question.. Cannot get it to move... [Re: EvilSOB] #386575
11/05/11 09:32
11/05/11 09:32
Joined: Oct 2008
Posts: 513
Carlos3DGS Offline
User
Carlos3DGS  Offline
User

Joined: Oct 2008
Posts: 513
If it is like a completely different language and will be much harder to program I am not so sure about taking the shader route then.
I really don't want to get myself into something like that now, so the only option would be to get someone to do it for me. And even if someone did do it for me... I like to tweak my settings ALOT. Mabe next week I decide I want grass to be drawn at a higer altitude than it does today, and mabe the week after that I decide I want a fifth texture for dirt to be in a new layer between the grass and stone, etc...
So even if I got someone to do it for me, if I don't understand the shader code I would be forced to stick with what I had initially and I don't want to end up in that situation either.


The example code you provided is very interesting, I had no idea you could access all the vertexes so easily like an array. Thanks alot! That will be very usefull to speed things up!

The only thing is that the height function gets called for each pixel. so it will still mean 512x512 ent_getvertex per terrain. I am thinking of mabe making the contact pointer a global variable. setting it at the start of my terrain paint function before the loops. And making my height function work the way you showed me but with that global contact instead. that way I would reduce even more the ent_getvertex calls to only one call per terrain.

P.S: I hadn't noticed that. almost up to 1500 views now!?!? Wow! Seems like alot of people are interested in this stuff

EDIT:
-the original speed tests with my old code were around 25.5 secs
-speed tests with your version around 23.9 secs
-speed tests with global c1 pointer around 22.5 secs

-old version = 786,432 ent_getvertex calls per terrain
-your version = 262,144 ent_getvertex calls per terrain
-my newest version = 1 ent_getvertex call per terrain

I just don't get it! Why such a little speed boost? I don't understand what is going on... Somebody help me from this nightmare! Anybody! Arrggggg
[rant]I thought this would be an incredible speed boost, this is sooooo frustrating! FFS! I feel like ripping my brain out (or just crying in a corner, lol)[/rant]



Last edited by Carlos3DGS; 11/05/11 12:28.

"The more you know, the more you realize how little you know..."

I <3 HORUS
http://www.opserver.de/ubb7/ubbthreads.php?ubb=showflat&Number=401929&page=1
Page 7 of 11 1 2 5 6 7 8 9 10 11

Moderated by  HeelX, Lukas, rayp, Rei_Ayanami, Superku, Tobias, TWO, VeT 

Gamestudio download | chip programmers | Zorro platform | shop | Data Protection Policy

oP group Germany GmbH | Birkenstr. 25-27 | 63549 Ronneburg / Germany | info (at) opgroup.de

Powered by UBB.threads™ PHP Forum Software 7.7.1