tobi453 and I were Talking in another thread and both times I didn't realize it was not the correct thread... so I'm moving the conversation here.
tobi453 Wrote:
Quote: "hi jason,
I counted your lines (FoundationClasses && Game Classes): 36943. Awesome.
That's nearly twice my star wars game.
It took me 10 minutes or so to compile all your example projects. I haven't looked at all the examples in detail yet, but it looks very good so far.
I noticed that the text input seems to lag a bit. Is this intended or a problem with my vista?
Keep up the good work!
"
Awesome! Input Lagging... Well.. there is a delay on the keyboard... see jgc_configuration.h but before changning note that for the GUI especially, I'm using native GDK to get those fancy keypresses like CNTL+C, CNTL+V, SHIFT+END, SHIFT+HOME etc.
I need to throttle those dbKeyState(??) functions' frequency so I don't get rthousands of messages going through the gui if you hold down shift key or something. However the text you type uses dbEntry, so that is a buffer that GDK (seems like) manages by getting window messages - in the REAL WinMain. So, this buffer gets filled even when I'm not polling, then when I do POLL - it snags the whole buffer and clears it for another go around.
Now those settings in jgc_configuration.h can be changed, however its like balancing a ball trying to get the right balance of Frame Rates per Second and KeyBoard Poll Frequency (mostly due to the need to scan for special keys like CNTL and SHIFT.. I can't rely on the dbEntry() buffer alone.)
So its probably not your Vista so much as what I explained. I do think its certainly good enough for a game menu, game editors, utilities etc.
Morcilla answered a post I had made recently about this very subject. I was wondering if we could subclass or whatever without losing the control we haave for many key combinations with simulatanesous keypresses.
He didn't refer to losing or not losing that but he did point me to some code IanM wrote that seems to more or less use PeekMessage to get the OS messages without processing them. This would give the responsiveness I would need - as its not unlike interrupt programming in that I can process the keys in real time, withouth needing to adversely effect FPS .. at least that's the theory.
Have you checked out the Demo VMesh (Big Terrain) Demo Yet? USGS Data for an island in Hawaii (tweaked a bit to utilize the full heightmap bitmap "square") ... but... Curious what you or anyone else thought of that one!
Best Regards,
Jason P Sage
tobi453 Wrote Again:
Quote: "
Yes I checked it out. First I thought that it was only a plane but then I realized after moving around a bit that there are actually hills. Amazing.
I think you should definitely increase the moving speed ( the terrain is so huge, more than 1.3 million polys! ). I increased camera range and fog range and there were some strange clipping problems, but I think this is a directx problem.(Screenshot attached.)
I haven't looked at the code in detail. How have you done the terrain? With memblocks or is it advanced terrain or something else?
"
--------------
(BTW - thats the attached Pic in this post)
My Response Below
--------------
Quote: "Yes I checked it out."
LOL AWESOME!
Quote: "First I thought that it was only a plane but then I realized after moving around a bit that there are actually hills. Amazing."
Thanx! Yeah - That "plain" is just the black edges around the heightmap - it's pretty freaking huge! LOL)
Quote: "I think you should definitely increase the moving speed"
Well, you can hold SHIFT to go faster, and its inside the test_jgc_vmesh_bigterrain1.cpp file... near the bottom... (line 615 before changes) looks like:
JGC::Daddy->Update();
float cx; float cy; float cz;
if(!JGC::UserInput->MouseButton2 ){
JGC::Cam0->Control(0.05f,0.50f,0.1f,0.05f,JGC::Clock->Time_ElapsedFloat);
};
Those Cam Control Values effect speed... its an advanced version of the camera command that moves with the arrows(
dbControlCameraUsingArrowKeys() I think its called).
So you can speed it up.
Quote: "the terrain is so huge, more than 1.3 million polys!"
I presume you counted them by maxing out the camera LOL... yeah... Its big...
Quote: "I increased camera range and fog range and there were some strange clipping problems, but I think this is a directx problem.(Screenshot attached.)"
Never seen that before - I think it might of really pushed directX to the limit with the camera range out far enough to count 1.3 million POLY! Glad you're having fun with it!
Quote: "I haven't looked at the code in detail. How have you done the terrain? With memblocks or is it advanced terrain or something else?"
It starts in a memblock. That JGC_VMESH class is a multi-object, multi-limbed, "Matrix" on steroids
It has Welded Verts and a poly layout (modeled after Visigoth's USGS terrains.) That mesh is created by FIRST making a single poly for a "root" object (due to anomalies with how root behaves a bit different than limbs - and can look awful... for example... working on the mesh - if root 0 seems to be whole object - same for uv.. ) So I then create a mesh CellsX x CellsY (per limb) in a memblock.. then make a mesh from it, and then carbon copy it to fill the rest of the requested mesh size asked for. Cells are per limb - and need to even numbers due to the poly arrangement... 2x2, 4x2, 4x4, 16x2... Whatever ya need just even numbers for the cells. You also pick how many limbs per object (x,y), and how many objects (x,y) .... So its pretty dynamic.
There is also command to control UV and reset UV (to stock) for individual cells, and naturally, per limb, and per object, and per ENTIRE MESH... so makinging a level where you recycle a textures... and just
replace use detail textures where you need them.. well.. I suspect when I get to the level editor potion of all this for iron infantry - it'll be pretty neat.
Sorry to go on an on but you asked.
The reason the frame rates are so high with that mesh is because of the frustrum culling and that's BEFORE I added any quad or Oct tree processing to optimize it...however its using my frustrum "Regions" stuff ... which basically works like a 1 tiered Quadtree in that particular demo.
the Terrain (as far as frustrum is concerned) is broken into FOUR SQUARES... And these are each a region. if the REGION is not on the screen... then all the objects in the region are excluded - PERIOD, if the REGION is in the frustrum - then normal frustrum processing (Limb Frustrum culling in this case) is performed to see what (in that region) is really on the screen or not, hiding limbs that are not visible ...cuz it helps... and excluding objects that aren't visible... helps alot more LOL
.
So I hope that at least gives you some idea of what I'm doing so when you read the code - you'll know where its heading before you start.
Thanx for the report!
Best Regards,
Jason P Sage