"Tiki's Garden" (Real-Time Outdoor Terrain Engine) [NoteMe, Electroman]

Quote:

---

Originally posted by Electroman
I'm getting these errors back. It is probably caused by the GameThread not exiting before the WinThread, which I'm not sure why. I haven't spotted what could have changed to do this yet..

Code:

---

The thread 'Win32 Thread' (0xe10) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0xb04) has exited with code 0 (0x0).
Direct3D9: (ERROR) :Memory still allocated!  Alloc count = 142
Direct3D9: (ERROR) :Current Process (pid) = 00000c78
Direct3D9: (ERROR) :Memory Address: 0033856c lAllocID=1 dwSize=000047f8, ReturnAddr=00e63796 (pid=00000c78)
Direct3D9: (ERROR) :Memory Address: 00335bf4 lAllocID=9 dwSize=000019bc, ReturnAddr=00e5e1e9 (pid=00000c78)
Direct3D9: (ERROR) :Memory Address: 00335224 lAllocID=10 dwSize=00000008, ReturnAddr=00e5e289 (pid=00000c78)
Direct3D9: (ERROR) :Memory Address: 0033f24c lAllocID=11 dwSize=00000860, ReturnAddr=00e62f45 (pid=00000c78)
Direct3D9: (ERROR) :Memory Address: 0033cd9c lAllocID=20 dwSize=000006bc, ReturnAddr=00e6f12f (pid=00000c78)
Direct3D9: (ERROR) :Memory Address: 0033d48c lAllocID=22 dwSize=00001d88, ReturnAddr=00e6478b (pid=00000c78)
Direct3D9: (ERROR) :Memory Address: 003384ec lAllocID=24 dwSize=00000008, ReturnAddr=00e648bc (pid=00000c78)
Direct3D9: (ERROR) :Memory Address: 01020064 lAllocID=26 dwSize=00003500, ReturnAddr=00e63796 (pid=00000c78)
Direct3D9: (ERROR) :Memory Address: 00335834 lAllocID=27 dwSize=00000198, ReturnAddr=00e63796 (pid=00000c78)
Direct3D9: (ERROR) :Memory Address: 00335314 lAllocID=28 dwSize=00000030, ReturnAddr=00e63796 (pid=00000c78)
Direct3D9: (ERROR) :Memory Address: 0102359c lAllocID=29 dwSize=00001020, ReturnAddr=00e63796 (pid=00000c78)
Direct3D9: (ERROR) :Total Memory Unfreed From Current Process = 54608 bytes
The program '[3192] Basis.exe: Native' has exited with code 0 (0x0).
The program '[3192] Basis.exe: Direct3D HAL (HWVP) Device 1' has exited with code 0 (0x0).

---

---

And it only happens in fullscreen...:confused:

Quote:

---

Originally posted by Electroman
You should have known better than to do this :rolleyes:

Code:

---

if (D3DERR_DEVICENOTRESET == PostRender()){
                                //do any pre-cleanup
                                PreReset();
                               
                                //Let the device class reset the device
                                RestoreDevice();
                               
                                //Tell the rest of the app that this has happened
                                PostReset();
                        }

---

I've highlighted my chnage.....It now restores the device and the Input works once it gets focus back. However it still doesn't display :confused:

---

You are wrong here...if you see at "IDirect3DDevice9::Present Method" you can see that it is not returning any D3DERR_DEVICENOTRESET at all...just DEVICELOST, it is TestCooperativelevel that returns D3DERR_DEVICENOTRESET...;)

Quote:

---

Posted by NoteMe
I think has something to do with the Font object...;)...becuase I didn't find out a good way to free up the fon't object...so it doesn't do it at all..;)

---

:eek:

BTW I think the GameThread does exit yea, I added some extra code to the message loop:

Code:

---

while(1)
{
    if( PeekMessage(&msg, NULL, 0, 0, PM_NOREMOVE ) )
    {
        if( !GetMessage(&msg, NULL, 0, 0 ) )
        {
            if (g_bGameThreadActive == true)
            {
                g_bGameActive = false;
            }
           
            while (g_bGameThreadActive == true)
            {
                Sleep(10);
            }
           
            return (int)msg.wParam;
        }
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }
}

---

I also changed some Variables declarations so I'll have to upload it for you to use this change. Have you made any changes?

Yeah one..::D..in the MakeFont function, change the - to a + (that will say, just get rid of the -...:D

Quote:

---

Posted by NoteMe
You are wrong here...if you see at "IDirect3DDevice9::Present Method" you can see that it is not returning any D3DERR_DEVICENOTRESET at all...just DEVICELOST, it is TestCooperativelevel that returns D3DERR_DEVICENOTRESET...;)

---

hehe...but this works ;). Doesn't it return DEVICELOST while its not got focus and can't be reset and if it returns DEVICENOTRESET then it means you can now reset it ;).

Quote:

---

Originally posted by Electroman
hehe...but this works ;). Doesn't it return DEVICELOST while its not got focus and can't be reset and if it returns DEVICENOTRESET then it means you can now reset it ;).

---

No that is TestCooperativeLevel....Present only return out of memory or device lost...;)

Quote:

---

Posted by NoteMe
No that is TestCooperativeLevel....Present only return out of memory or device lost...;)

---

ow well I suppose even if it works we should fix it to make it work right anyway :(. I will upload it in a second and I will let you sort that out cos I haven't figured out your device recovery stuff just yet......

Quote:

---

Originally posted by Electroman
ow well I suppose even if it works we should fix it to make it work right anyway :(. I will upload it in a second and I will let you sort that out cos I haven't figured out your device recovery stuff just yet......

---

Hehe..I took it more or less from the book Real Time Rendering Tips and Tricks...it was the same function as I tried to help you with when you asked in a VB thred some months ago...you resolved that one at least..

It was too big to upload here :(.
http://terrain.electromanuk.com/uplo...asisUpdate.zip

BTW if you ignore that I included the gametimer files this time...I haven't edited them yet and I plan it make it slightly different (I have a plan ;)).

I changed back the DEVICELOST thingy as well (And it doesn't work again :p )

Hehe...this is sooo bugging me....here is the "results"

Quote:

---

Direct3D9: (WARN) :Window does not have focus. TestCooperativeLevel fails
Direct3D9: (WARN) :Window does not have focus. TestCooperativeLevel fails
Direct3D9: (WARN) :Window does not have focus. TestCooperativeLevel fails
Direct3D9: :WM_ACTIVATEAPP: Ignoring while minimized
Direct3D9: (WARN) :Window does not have focus. TestCooperativeLevel fails
Direct3D9: :WM_SIZE hWnd=160518 wp=0000, lp=023F031A dwFlags=00000001
Direct3D9: (WARN) :Window does not have focus. TestCooperativeLevel fails
Direct3D9: (WARN) :Window does not have focus. TestCooperativeLevel fails
Direct3D9: (WARN) :Window does not have focus. TestCooperativeLevel fails

---

First the window is minimized, then I tried to get the focus back, and all the bold lines are written....but I don't understand fully what they mean...

OK..so the WM_ACTIVATEAPP is a flag sendt to use when we are trying to get the focus again...but the problem is that we are not catching it becuase we are minimized??? :confused:

Quote:

---

The WM_ACTIVATEAPP message is sent when a window belonging to a different application than the active window is about to be activated. The message is sent to the application whose window is being activated and to the application whose window is being deactivated.

WM_ACTIVATEAPP
fActive = (BOOL) wParam; // activation flag
dwThreadID = (DWORD) lParam: // thread identifier

Parameters
fActive
Value of wParam. Specifies whether the window is being activated or deactivated. This parameter is TRUE if the window is being activated; it is FALSE if the window is being deactivated.
dwThreadID
Value of lParam. Specifies a thread identifier. If the fActive parameter is TRUE, dwThreadID is the identifier of the thread that owns the window being deactivated. If fActive is FALSE, dwThreadID is the identifier of the thread that owns the window being activated.
Return

---

Quote:

---

Posted by NoteMe
Hehe...this is sooo bugging me....here is the "results"




First the window is minimized, then I tried to get the focus back, and all the bold lines are written....but I don't understand fully what they mean...

---

Maybe you can't test the Cooprative level while the window doesn't have focus :confused:, easily solved by putting that call inside the if (g_bWindowActive == true).


Can we recap whats still inanswered in this thread? Just I kinda lost track with all the posts before so is there anything you've asked me and I haven't answered?

Quote:

---

Originally posted by Electroman
Maybe you can't test the Cooprative level while the window doesn't have focus :confused:, easily solved by putting that call inside the if (g_bWindowActive == true).

---

I thought that was the whole idea. That you had to check it untill you get it back...thats why we have a loop, and Sleep(1000) in it, so we can check it ever second...

Quote:

---

Originally posted by Electroman

Can we recap whats still inanswered in this thread? Just I kinda lost track with all the posts before so is there anything you've asked me and I haven't answered?

---

Nope...just this problem. And then fixing a real timer, and then I thinkg I will wrap up a font class, so we can use it a bit easier then it is right now...


PS: And then there was those threads about the profiler app. You should realy try one of them...

ØØ

Yea I'll have to leave the Timer till tomorrow becuase I go to work in about an hour an and still gotta get something to eat and stuff.

BTW if you didn't see I reduced the Sleep(1000) to Sleep(100) I put a note next to it ;).

It was because checking every second is a rather long gap, if you think the person might click the game in the task bar and a second would seem long for it to pop up ;). With it as 100 it still is like basically doing a tiny test then giving the other programs a large slice compared to what it used ;).

Yea I guess it shoudl already be inside the WindowActive thing anyway yea :(.

I think I got it..:D

Quote:

---

Multithreading Issues

--------------------------------------------------------------------------------

Full-screen Microsoft® Direct3D® applications provide a window handle to the Direct3D run time. The window is hooked by the run time. This means that all messages passed to the application's window message procedure have first been examined by the Direct3D run time's own message-handling procedure.

Display mode changes are affected by support routines built into the underlying operating system. When mode changes occur, the system broadcasts several messages to all applications. In Direct3D applications, the messages are received on the window procedure thread, which is not necessarily the same thread that called IDirect3DDevice9::Reset or IDirect3D9::CreateDevice (or the final IUnknown::Release of IDirect3DDevice9, which can cause a display mode change). The Direct3D run time maintains several critical sections internally. Because at least one of these critical sections is held across the mode switch caused by IDirect3DDevice9::Reset or IDirect3D9::CreateDevice, these critical sections are still held when the application receives the mode-change related window messages.

This design has some implications for multithreaded applications. In particular, an application must be sure to strongly segregate its window message handling threads from its Direct3D threads. An application that causes a mode change on one thread but makes Direct3D calls on a different thread in its window procedure is in danger of deadlock.

For these reasons, Direct3D is designed so that the methods IDirect3DDevice9::Reset, IDirect3D9::CreateDevice, IDirect3DDevice9::TestCooperativeLevel, or the final Release of IDirect3DDevice9 can only be called from the same thread that handles window messages.

---

Yep...I will sort that out tomorrow....BTW I finish work at 3am tonight now, I have asked if I can start leaving early on Sat'days seen as though its not normally too busy and the morning are getting lighter :(.

Quote:

---

Originally posted by Electroman
Yep...I will sort that out tomorrow....BTW I finish work at 3am tonight now, I have asked if I can start leaving early on Sat'days seen as though its not normally too busy and the morning are getting lighter :(.

---

Nice if you can manage it..but as I have said, don't swet it, becuase it is a lot of code to be redone. And next week I can do a lot of work too....I am soo looking forward to work on this all night every day..:D

See you tomorow then.

ØØ

Hey it'll be a lot easier once we have this core part out the way, then we won't be both working on the same files :D.

Quote:

---

Originally posted by Electroman
Hey it'll be a lot easier once we have this core part out the way, then we won't be both working on the same files :D.

---

Yeah, I was thinking about that too...and also that we have posted 200 posts, and not even got the core up..:D...but I guess we can use this core for many games from now on...;)

Quote:

---

Posted by NoteMe
Yeah, I was thinking about that too...and also that we have posted 200 posts, and not even got the core up..:D...but I guess we can use this core for many games from now on...;)

---

Yea especailly the Thingy magiga in the Games Section I keep mentioning ;).

Thingy Magia???

:confused:


Do you mean the FAQ part so people can pick up a redy core? Or am I just lost?

Thingy Magia = Something ;).


That thing I was talking about adding to the Games Section so that people can get a head start with creating a working structure that this can use as a Basis (notice this is why the poject was named Basis ;)).
Like if you think how long we have spent getting this to work and not even started on the game yet then other people would probably give up becuase of it ;).

Quote:

---

Originally posted by Electroman
Thingy Magia = Something ;).


That thing I was talking about adding to the Games Section so that people can get a head start with creating a working structure that this can use as a Basis (notice this is why the poject was named Basis ;)).
Like if you think how long we have spent getting this to work and not even started on the game yet then other people would probably give up becuase of it ;).

---

Yeah I see your point. But we are making it much more difficult then we realy had to do...but it is fun tho...:D

Quote:

---

Posted by NoteMe
Yeah I see your point. But we are making it much more difficult then we realy had to do...but it is fun tho...:D

---

Gives people an even better basis to start from :D.

Woohooo :D:D.

I have sorted out the thread Prioritys now :D.

I havene't seen any performance gain but at least the WinThread shouldn't be using too much time now :D.

I also fixed the Release configuation so you can compile it in Release and it will work :D. Haven't noticed any gain there yet either though ;).


haha....They increased the upload limit :D:D.

BTW I fixed the problem that was bugging you where you are getting the Warning about Input Version not being defined. Basically I added : DIRECTINPUT_VERSION undefined. Defaulting to version 0x0800 before including the header file.

I realised this becuase I looked in the header file and found:

Code:

---

#define DIRECTINPUT_HEADER_VERSION  0x0800
#ifndef DIRECTINPUT_VERSION
#define DIRECTINPUT_VERSION        DIRECTINPUT_HEADER_VERSION
#pragma message(__FILE__ ": DIRECTINPUT_VERSION undefined. Defaulting to version 0x0800")
#endif

---

Which looks like its expecting you to define which version your using your self ;).

Aren't I good :D:D.

Hope your still revising BTW ;).

Seems prioritys might not be our solution....never mind I came up with a faster and more reliable solution.


Todo:
* Fix Memory Leak :grh:
* Figure out how to restore the device.

Quote:

---

Originally posted by Electroman

I also fixed the Release configuation so you can compile it in Release and it will work :D. Haven't noticed any gain there yet either though ;).


haha....They increased the upload limit :D:D.

---

I fixed that yesterday on my version too...I though I wrote that 5-6 posts up....;)


It only comes in handy when we have more C++ code, like calculations, and more functions where we are passing parameters...;)

Quote:

---

Originally posted by Electroman
BTW I fixed the problem that was bugging you where you are getting the Warning about Input Version not being defined. Basically I added : DIRECTINPUT_VERSION undefined. Defaulting to version 0x0800 before including the header file.

I realised this becuase I looked in the header file and found:

Code:

---

#define DIRECTINPUT_HEADER_VERSION  0x0800
#ifndef DIRECTINPUT_VERSION
#define DIRECTINPUT_VERSION        DIRECTINPUT_HEADER_VERSION
#pragma message(__FILE__ ": DIRECTINPUT_VERSION undefined. Defaulting to version 0x0800")
#endif

---

Which looks like its expecting you to define which version your using your self ;).

Aren't I good :D:D.

Hope your still revising BTW ;).

---

Yeah that is the defualt version. I guess that should do it anyway. Good job. I am proud of you...;)

Quote:

---

Originally posted by Electroman
Seems prioritys might not be our solution....never mind I came up with a faster and more reliable solution.


Todo:
* Fix Memory Leak :grh:
* Figure out how to restore the device.

---

The memory leak is probably the font thingy. But don't worry about that before we get the restore code up and going


But you understood what we have to do to get it working? I at least understood it, but I need to look more into how you start the game loop thread to find a solution, becuase you can't do it in the game loop...

First thing:
I'm not sure if I've stated this before but when refering to our two threads I find its a good idea to call them, WinThread & GameThread.
WinThread being the one that handles the Windows messages & GameThread being the one that does the game loop and stuff. ;)


The main thing I fixed though with the config was that we had it selected to "Single Thread (Debug)" instead of multi-thread.
http://www.vbforums.com/attachment.p...postid=1712694



With the DInput stuff I think 0x0800 is the defult for that header file because 0x0800 = Dx8 and that is the most recent when the header file was made.... cos above the bit I posted from the file it said other versions were:
0x0300
0x0500
0x0700

And I think new versions of DInput match this:
Dx3
Dx5
Dx7

More of a guess here though ;)

Well I got the Window to appear again but it doesn't take fullscreen :(.

I also improved the message loop a bit more. Not looked at the memory leak just yet.

I havemanaged to get the debugger to let me step though both threads and I't seems even witht he RestoreDevice function being called with the message thread it still doesn't return DeviceNotReset :(.

Quote:

---

Originally posted by Electroman
Well I got the Window to appear again but it doesn't take fullscreen :(.

I also improved the message loop a bit more. Not looked at the memory leak just yet.

I havemanaged to get the debugger to let me step though both threads and I't seems even witht he RestoreDevice function being called with the message thread it still doesn't return DeviceNotReset :(.

---

This sucks...:D...I am sorry that I don't have time to look at it tonight...but when I finaly wake up tomorrow I will be full of energy to look at it. Just remember to post the "final" code before you go to bed tonight..;)=

Whos ya DADDY!!!!!!!!!!! :D:D:D:D:D:D:D:D:D:D:D




Fixed it...I am so gonna kill the people who made Dx this way.

Quote:

---

Originally posted by Electroman
Whos ya DADDY!!!!!!!!!!! :D:D:D:D:D:D:D:D:D:D:D




Fixed it...I am so gonna kill the people who made Dx this way.

---

Then you should probably kill those who made most apps...all OSes and many other apps do it this way...;)

BTW this is how it is done in Gaia:

Code:

---

FrameMove(){

  static Handle hTread = GetCurrentThread();

  //update the real time elapsed to our internal delay counter


      //Is there an update ready to happen?
      if{

        //bump up our priority for thread activation, while we are executing a game "tick"

        //Update the scene

      }
   
      //Return to normal priority for our thread

      //Let windows have the rest of our tick
      Sleep(0)

  }

}

---

Well here is what i have got now....

I did the timer class and made the FPS work "properly" it now gives me a frame rate of 5900(ish) when I run release mode and 5500(ish) when in debug mode. I know we got higher frame rates when using your code but you gotta understand that is because some frames were that little faster which made it appear we would get 6000 frames if they were all as quick ;). (but you knew that anyway ;))

Let me know what FPS you get though :D.


All the files are nice and tidy now so you can get to work and fix that memory error...I haven't had a chance to look at it yet :(.

Yet again the file is too big to upload (this time by only a couple of KB :().
The link is:
http://terrain.electromanuk.com/uplo...sisUpdate3.zip

I got 2835(ish) in debug mode.

and 2839(ish) in release..:D

I havn't looked at the code, but I can soo see that there is no sleep after you have tested the cooperative level, becuase it is testing about 100 times a second...:D...and the CPU is up 100% when you don't have the focus..

k, There was a Sleep() but it was only a contect Switch ( Sleep(0) ) so I uped it to Sleep(100) and now my processor runs at 50%


The start is when the game is running....the gap is it minimised......then I maximise it to close it ;)

http://www.vbforums.com/attachment.p...postid=1714178

Fixed the memory error ;)


I will post the code a bit later on....I'm gonna work on it a bit first.....let me know if you need it though ;)

So where are we standing?


I have found out that I have to work a LOT this summer. But I will try to use most of my spare time on this project tho'. But I can't work on it every day..:(


So what are your ideas from now one?

Maybe we should split up the project. So we can work on diffrent parts at the same time? Or is it better if both work on the same thing? What do you want, and what technique do we use for LOD, and so on....:D


Lets have a wrap up brainstorming..:D

Well I eventually put pen to paper at work on friday night and have a plan for the LOD kind of thing, I was gonna make some pics tomorrow and post them, mind I'm not totally sure yet on how all the "tiles" will fit together yet. I think I need to read more of the articles and the book first ;).

OK...fine...me too. But I was thinking about things like the SkyBox/Sky-Dome and things like that. Isn't that a one mans job? Do we have more of those jobs? Maybe we could split them up.


And yes I think you should read a bit more in the book before you deside on a solution. The book covers tricks for diffrent implementations that I never in 100years could have thought of.


ØØ

Quote:

---

Posted by NoteMe
OK...fine...me too. But I was thinking about things like the SkyBox/Sky-Dome and things like that. Isn't that a one mans job? Do we have more of those jobs? Maybe we could split them up

---

Ow right yea, emm I can't think of any at the moment but thats good idea to split those between us.....maybe if we make a list of them then when one of us can't work on whatever we are doing mainly for the project then they can dip in a do one of them until the other person has finished with the file they need or something ;). ?

Thats an excelent idea. I have skimmed trhough a lot of the book by now. And it has given me a lot of ideas. Might be scary though. Becuase I don't want it to be exactly the same. But the way it wraps up things makes the whole thing smart, and it is so elegant. Things fit so perfecty togheter.

Before I read it I thought it was more like read the map, display it, turn it around when the user presses the button, and clear up the memory. But the way this books wraps up things and makes the rendering queue, and the quad tree implementation that is the same as in my Game Programming Gems 2 book, and the use of pools, and effect files with shaders and so on. It's realy neet (forgot the spelling AGAIN:D).

So maybe if you read some more in it. Just read it fast the first time, and get the ideas. Don't look too close on the code, just understand how it works. Then it might be easier for us to find out what classes we need, and what functions to go with it. And if we then find out how they should work togheter, then it is realy easy to give each other work to do.

Thats at least my 2 cents..:D

I don't think it will turn out exactly the same, like there will be extra features I have read about which he hasn't included :D.

Quote:

---

Originally posted by Electroman
I don't think it will turn out exactly the same, like there will be extra features I have read about which he hasn't included :D.

---

Like what??? Read in the Terrain book? And he hasn't included it? Hmmm...thinking hard...what do you mean?


BTW Have you seen that he is using his own data types? Do you think there is any advantage to do this? If so should we do it too?


And I had all ready nearly fogot about the DataPool he is using. Do you think that is a good idea. It sounds smart. But I have problem at this time to understand how it is working. Looking forward to hear your thought about it. Or maybe you are not that far in the book yet?

I remembered seeing something about a Datapool, nothing in detail though :(.

Yea I still gotta read a bit more though :(.


The things I was on about was things like morphing, he doesn't use that, you can see the poping when you get close to parts. And I don't think he uses Frame Cohearance (SP?) either.

Yeah he is using the datapool. Rather smart I think. We don't have to implement it the same way he does. But the way he is suing is very dynamic. Even if you don't know how many objects you need in the data pool you can still use it, and then you can port it to an array later on when you know it. I am starting to think that this is a kind of structure I would use in any game, not just in this one.


Don't think he is using any morphing. What do you want to use it for? To make your nynamic terrain?

And ehh...hmmm...Frame Cohearance...what was that again. I think I have asked you once before. But I still can't remember.

And he is using a random terrain. We will probably read the terrain from a picture or something. SO we can easily make a map editor in VB or something? Or what? We can more or less start to make the loading code, but I am still not sure on what we are going to load it too. Is it a BIG VB or something? Or many small ones. I have to read a bit more too I think....but remember the resource pool. It's great. Still reading about it.


But what about the datatypes. You never answered on that question. Don't think he is mentioning it in the book. Not sure, becuase I havn't read it all...

Been reading a bit more. Looks like cTerrain stores the whole terrain in it. It is then divided into section, and store in cTerrainSection. But he says (hav not looked into these classes yet) that the whole terrain actualy stored in a cTerrain object.

cTerrainSection is derived from cSceneObject. Think he does that so he can put it in the QuadTree or the DataPool or something. Have to look into the code to be sure about this.

So if we can have a look on how he stores the terrain, we are more or less ready to read in our terrain from a height map and into our own classes.


PS: Are we going to have wather in our engine?

You realy need to look at the screen shots from this terrain engine. The pictures looks realy great. At least some of them.

http://www.d-strict.com/main.php?lang=eng&page=gallery

Hope he releases it soon, at least some of the code or write some articles....

I've got a question for you guys and that is how do you share the coding for your project? Do you each stick to a particular module/class/etc. or do you share the code? If it's the latter how do you go about doing that? Do you use some software that allows you to checkout the files over the net from some common library?

Quote:

---

Posted by MartinLiss
I've got a question for you guys and that is how do you share the coding for your project? Do you each stick to a particular module/class/etc. or do you share the code? If it's the latter how do you go about doing that? Do you use some software that allows you to checkout the files over the net from some common library?

---

We had looked at using "GotDotNet" but we decided against it in the end. The plan is that certain files will be only used by one of us so we shouldn't trip over each other there. However the Main Core of the project, which is now done we were both working on, we got over that by taking turns on who was using/modifing it at anytime. We hit a couple of snags when I gave Note the final version and he started using it then I updated it but that wasn't too bad.

The thing is witht he files that we will both be editing then we should be able to do without a tracking program seen as though theres only two of us. As for say Initialisation of our individual code and things alike we will try and group them together the calls to these in the Cores initialisation which should mean if the core is updated then we only have to check this area is the same after updating it.

Thanks.

Quote:

---

Posted by NoteMe
You realy need to look at the screen shots from this terrain engine. The pictures looks realy great. At least some of them.

http://www.d-strict.com/main.php?lang=eng&page=gallery

Hope he releases it soon, at least some of the code or write some articles....

---

Looks really good, mind I think the grass is rendered alot better in the sample you showed me the other day. This screen shot is totally what i want ours to look like, http://www.d-strict.com/gallery.php?shot_id=18.

BTW if we can avoid using VS & PS 2.x then I think that will be best because like loads of articles have said they don't seem to run at Real-time speeds very well on most cards.

Quote:

---

Posted by NoteMe
Yeah he is using the datapool. Rather smart I think. We don't have to implement it the same way he does. But the way he is suing is very dynamic. Even if you don't know how many objects you need in the data pool you can still use it, and then you can port it to an array later on when you know it. I am starting to think that this is a kind of structure I would use in any game, not just in this one.


Don't think he is using any morphing. What do you want to use it for? To make your nynamic terrain?

And ehh...hmmm...Frame Cohearance...what was that again. I think I have asked you once before. But I still can't remember.

And he is using a random terrain. We will probably read the terrain from a picture or something. So we can easily make a map editor in VB or something? Or what? We can more or less start to make the loading code, but I am still not sure on what we are going to load it too. Is it a BIG VB or something? Or many small ones. I have to read a bit more too I think....but remember the resource pool. It's great. Still reading about it.


But what about the datatypes. You never answered on that question. Don't think he is mentioning it in the book. Not sure, becuase I havn't read it all...

---

Frame Cohearance: I think thias must be the tenth time or something I have had to tell you this :rolleyes: :D. Its when the mesh is created over several frames progressivly, so this way we can keep improving the detail on the mesh right upto the limit of the frame then render it as is. The next frame it uses what it already has and improves it further, if the camera moves then this is better used but when the camera stays still it might only take 2-3 frames before the optimum mesh is created.

Morphing: We will use this when we increase(or decrease) the amount of triangles being used. Like say the camera moves toward a small hil, as the camera approaches it it will want to increase the detail, everytime a new vert is added it will make the shape suddenly change, instead we will introduce the new verts position gradually over several frames. This way the user will not notice the detail is being altered ;).

Map Editor: Don't think we can start making this until we decide on a data structure, I guess we could if we know we will be using a standard bitmap however I think it would be an idea if we get the rendering code done first then the map editor can use this rendering code so you can see the terrain as you edit/create it ;).

Dynamic Terrain: I think we will be best leaving my dynamic terrain thing to another iteration because I think it will need quite a bit of work. Mind the thing is adding it later means we will need to make major changes to the structure so it could be a better idea to take it into account at this earlier stage. The thing being we can't use a normal bitmap to describe a dynamic terrain of this nature due to the possibility of more than one height at each location :). Let me know what you think on this though.

Quote:

---

Originally posted by Electroman
Looks really good, mind I think the grass is rendered alot better in the sample you showed me the other day. This screen shot is totally what i want ours to look like, http://www.d-strict.com/gallery.php?shot_id=18.

---

OK...but you can't see any grass on that picture.....at least not close to the camera. I think it would be cool to have some grass like in my sample, but you can only "see" the grass when you are close to it. If we have to much of it, and over big areas, like in the background of your picture,then I think it will kill our eninge.

Quote:

---

Originally posted by Electroman

BTW if we can avoid using VS & PS 2.x then I think that will be best because like loads of articles have said they don't seem to run at Real-time speeds very well on most cards.

---

There is two ways to avoid it. Not use HLSH and write all VS and PS in the ASM look alike language. Or write it in HLSL and then deasembly it, and check what it is compliet too. If I am not wrong, the deasempler app will add a comment in the head of the file what version it is using.

PS: My GPU can do PS VS nicely...at least VS..;)

Quote:

---

Originally posted by Electroman
Frame Cohearance: I think thias must be the tenth time or something I have had to tell you this :rolleyes: :D. Its when the mesh is created over several frames progressivly, so this way we can keep improving the detail on the mesh right upto the limit of the frame then render it as is. The next frame it uses what it already has and improves it further, if the camera moves then this is better used but when the camera stays still it might only take 2-3 frames before the optimum mesh is created.

---

OK...will try to remember it now. It is a bit like progressive meshes or using many mipmap levels. If you know what I mean.

Quote:

---

Originally posted by Electroman

Morphing: We will use this when we increase(or decrease) the amount of triangles being used. Like say the camera moves toward a small hil, as the camera approaches it it will want to increase the detail, everytime a new vert is added it will make the shape suddenly change, instead we will introduce the new verts position gradually over several frames. This way the user will not notice the detail is being altered ;).

---

Have you read about the diffrent LOD techniques now? This is exactly what all of them does. Like ROAM. It uses more triangles for the terrain close to the camera and the terrain parts that have big hills and stiff. They need it to look nice. Flat land far away from the camera seldom need more triangles.

Quote:

---

Originally posted by Electroman

Map Editor: Don't think we can start making this until we decide on a data structure, I guess we could if we know we will be using a standard bitmap however I think it would be an idea if we get the rendering code done first then the map editor can use this rendering code so you can see the terrain as you edit/create it ;).

---

Maybe we could use a two parted Map Editor. What about using a bitmap (bitmap is a good file format, becuase it is not using any compression, and you can save them over and over again withoug changing any pixels), to store a grey scale (or in colors) picture that we can use as a height map. If we can make height maps with it, we can load the terrain into the engine, and show it without tiles and stuff like sample 6 in the Gaia book.Then we could have an other part of the demo, where we could add small "bitmaps" to that heightmap, for trees, and grass and so on. That could be extended to add houses, and menn and so if we ever need that.

Quote:

---

Originally posted by Electroman

Dynamic Terrain: I think we will be best leaving my dynamic terrain thing to another iteration because I think it will need quite a bit of work. Mind the thing is adding it later means we will need to make major changes to the structure so it could be a better idea to take it into account at this earlier stage. The thing being we can't use a normal bitmap to describe a dynamic terrain of this nature due to the possibility of more than one height at each location :). Let me know what you think on this though.

---

Yeah I know it will be some major changes. But if it is ok for you I agree to make it later. If it at least is a bit classed up it won't be that hard to do the changes later on. But since we are so new to this, I think it is better to get the core up first.

Quote:

---

Originally posted by MartinLiss
I've got a question for you guys and that is how do you share the coding for your project? Do you each stick to a particular module/class/etc. or do you share the code? If it's the latter how do you go about doing that? Do you use some software that allows you to checkout the files over the net from some common library?

---

Not sure if you ever will read this, but will add a bit to what Electroman said.

We also looked at some free group wares on the internet. But most of them needs a lot of changes on the server to work.

If we where more then 2 persons then we definitly had to make one of those groupwares or the realy slow GotDotNet to work, but since we are only 2 persons we can manage.

It would definitly be easier to work on this project if we classed everything up sice we are two persons, but we can't get to an agreement over how usefull it is over the speed. So it can be very exiting to see how it will work when we get furuther into the project. At least it will be a good experience for both of us.

ØØ

Quote:

---

Posted by NoteMe
OK...but you can't see any grass on that picture.....at least not close to the camera. I think it would be cool to have some grass like in my sample, but you can only "see" the grass when you are close to it. If we have to much of it, and over big areas, like in the background of your picture,then I think it will kill our eninge.

---

Yea I didn't mean the grass on that picture, I ment on the second page it shows a picture of the grass close up on that engine and it looks pretty rubish in my opinion :).

Yea I agree we will need some kind of method to get a LOD kinda thing going for our grass effect (remember the wind ;)).

Quote:

---

Posted by NoteMe
There is two ways to avoid it. Not use HLSH and write all VS and PS in the ASM look alike language. Or write it in HLSL and then deasembly it, and check what it is compliet too. If I am not wrong, the deasempler app will add a comment in the head of the file what version it is using.

PS: My GPU can do PS VS nicely...at least VS..;)

---

By this do you mean your card does V2.x good or just in general? cos I am still saying we should use V1.x ;)


Ow and I forgot to mention it just in the other post but I have done before: about the Volumetric Fog things, I think we should really look into that article about using the shaders to allow real modelling or fog volumes :). i think the main problem is the precsion though :(.

I think it will be ok to use the ASM look alike language. As a lot of sampes are given like that too :).