Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / dbBuildTerrain keeps crashing, causing pain in head.

Author
Message
monotonic
18
Years of Service
User Offline
Joined: 24th Mar 2006
Location: Nottinghamshire, England
Posted: 12th Dec 2007 00:07 Edited at: 12th Dec 2007 00:13
Hi,

When I run the said command it crashes my application, with an error code of 6???

So I did a search and found one post! it suggested putting the executable one directory above the media, so I did, now it doesn't give me the error 6 jargon but instead locks up my machine.

Has anybody found a way around this, or is AT just another no-go-area for GDK?

Here is the entire code file that uses the advanced terrain commands.



The LoadImage function is my replacement dbLoadImage function that finds a free number for you, just to prevent any ambiguity.

Thanks in advance

The Sun is trying to kill me!
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 12th Dec 2007 15:51 Edited at: 12th Dec 2007 15:56
I'm having the same issue lately - only lately - I finally got it to compile - and run without the error - (By hardcoding all the "set up the terrain calls" prior to dbBuildTerrain - but then I couldn't find the LAND! I did a test with it all FLAT - Camera starts at 0,0,0 - I have code to move cam around - up/down etc - and I couldn't find it.

I HATE how DarkGDK terrain works. Even when I had it working in the past. You can't position it - its not an "OBJECT" - You can't use Sparky on it - Its not an Object - you [edit]can not[/edit] call object commands to manipulate it - and WORST of all - you can't POSITION it!

<grrrr> Using DarkBasic's Advanced Terrain was cool. A little limited - but for the framerates - and auto (actually works) culling - it was cool!

[edit]So it has the ability to have more than one - but if you can't position it - what's the point?[/edit]

monotonic
18
Years of Service
User Offline
Joined: 24th Mar 2006
Location: Nottinghamshire, England
Posted: 12th Dec 2007 17:59
Yeah AT in DBP is nice and easy to setup and you get fairly good results, but as for AT in GDK it sucks!

Looks like I'm gonna have to create memblock terrain(s), which isn't really hard, just a bit more work to get a terrain thats all. But it does have advantages.

What do you (or anybody else reading) use instead, mesh file, memblock.....?

The Sun is trying to kill me!
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 12th Dec 2007 19:16
I used Ted (sold here) It makes Direct.x "tiles" (meshs) that I can paint in the editor - and use either DBO "Vertex Alpha" (looks awesome - less ram - no shadowing that I can figure out without trying to manipulate stuff at a vertext level or some such wizardry) or my favorite - though less "optimal" is the Direct.X export with "Supertextures" (Has Shadows COOL - Supertextures use more ram than tiled "vertex alpha" Boo!) But the results are nice.

On my Web PAge for Iron Infantry (See my sig!) in the gallery section - you can see both DarkBasic "Advanced Terrain" and the other stuff - less ground detail - but nicer overall - IMHO - of the technique I mentioned.

Note I had to write a C++ loader for the Ted "EPR" file format - basically a text file - and do my best to translate obviously "BlitzBasic'ish" settings to as close as I could muster in DarkGDK to get the best possible appearance.

I like it because unlike Advanced Terrain (Making an editor would be a %$@%$%@##$%# - for various reasons - one - its a moving target - 2 - the actual build terrain takes to long - and it takes a height map and makes MANY verts to get that smoothed look - Best thing Advanced does is true CULLING.... Which brings me to my next point.

I have these Ted "Direct.X MEshes in my "Gallery right? Look Pretty? I start adding models and stuff - and FRame Rates are an Issue. Ok - So work out some culling with the InScreen Function Right? Sure. But that's the real issue.

The REAL issue is that trying to do the same thing for the Direct.X Meshes is JUST "PLAIN" FLAWED.

1:Try Making a - say 64x64 vertice - 500wide (Dark gdk units) "Terrain'ish" basically Flat Mesh. A Flat Plain - would work for this test.

2:Now add code so that you can fly around.

3: Now - in your loop - try making it so if your "object" is Inscreen you Show it - and if its not Hide it (Exclude is the TRUE optimization way to speed things up... but whatever...)

What Happens? When you fly toward the Plain - Its ok - go go over it - Seems Ok - Get more than half way - it disappears - Now you aren't flying over terrain anymore - because it vanished.

Keep flying all the way PAST it - Now Turn around and go back - ITS WORSE depending on the "way you approach it" - Results will vary - You'll see why its hosed.

THIS was not a problem with Advanced terrain in Dark Basic - nor any other issues - so you could get decent reults - Tile if you wanted to - auto culling made frame rates nice alongside nice terrain - (some say kinda boring) - but smooth and fast nonetheless.

Now - I'm having trouble "Optimizing" because I can't trust the InScreen Function to tell if a object is being drawn on the screen or not.

I tried LIT Frustrum culling bit - and I didn't have to much luck with it in DarkGDK - that is likely my fault - but frankly - if InScreen worked - I could move on - and not have to get bogged down in matrix math - vector + Vector and ViewPort * World MAtrix - and all that crazy stuff I try to avoid - like I avoided (I thought) by skipping DirectX directly and getting a decent Game Lib.

This is my BIGGEST frustration - and is the whole arena I've been wrestling with. I've learned some neat stuff about GPS "Terrain" thanx to VisiGoth - I haven't finished that endeavor - but I'm starving for some missle flying - FPS - and Heli War Action - but Terrain is a Chore boy!

monotonic
18
Years of Service
User Offline
Joined: 24th Mar 2006
Location: Nottinghamshire, England
Posted: 12th Dec 2007 19:51
Yeah the auto-culling in AT was a distinct advantage.

The dbObjectInScreen command checks to see if the middle of the object is within the screen. If the objects' centre is in the hemisphere behind you, its not in the screen etc.

The only way around this is to create a memblock terrain where by every triangle is a seperate object. I'm not sure if this has any impact on speed due to massive amounts of objects. It does however give you an Ok culling system (auto) because any object not in screen (using the above rule) is automatically culled. Also, I have never done this but it may allow you to easily implement an occlusion culling system for the terrain.

The Sun is trying to kill me!
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 12th Dec 2007 20:17
I thought that Center object thing was how it was - and I TRIED to make a "solution" that would move a hidden object to various parts of the model to kind of "Check" likelyhood of eing on screen - results were nothing to write home about - and frankly - the extra checks - add overhead - so - it didn't pan out (YET) as a way to do it.

We really need TWO simple Commands IMHO:

bool InScreenAtAll(ObjectID) and LimbInScreenAtAll(ObjectID, LimbID)

monotonic
18
Years of Service
User Offline
Joined: 24th Mar 2006
Location: Nottinghamshire, England
Posted: 12th Dec 2007 20:22
Agreed, It sure would be nice.

I've just read the help doc's on the dbObjectInScreen function, it says it returns a non-zero value if an object is wholly or partially in the screen! But this is not the case.

I was wondering if maybe it calculates an objects centre based on its bounding box. I don't know, all I know is that its not a good way of culling.

The Sun is trying to kill me!
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 12th Dec 2007 20:25 Edited at: 12th Dec 2007 20:27
There isn't a "Good Way" that I'm aware of

I guess I'll have to REVIST that Frustrum Culling thing YET AGAIN - and Try to get it to work in DarkGDK.

It's complex enough that - one screwup - is enough where if it compiles and doesn't work - I can only take "Stabs" at trying to fix it because I don't 100% understand how it works.

[edit]spelling[/edit]

jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 13th Dec 2007 16:12
P.S. (Double post so you see it bro) I thought about your solution - the poly thing - WAY bad idea! Well - good idea - but BAD in DarkGDK - I understand that TO Many "Objects" really starts hosing things when the count gets up high - something about how they are managed internally. So - though your idea would cull probably - I think the overhead of culling that many "Objects" would be an issue (just trying to loop through that many "Things" etc) and from the point of view stated above about internal objects etc.

What would be interesting would be making SMALLER terrain blocks - so that Object Inscreen MIGHT work. MAYBE

monotonic
18
Years of Service
User Offline
Joined: 24th Mar 2006
Location: Nottinghamshire, England
Posted: 13th Dec 2007 16:24
Yeah, we really need a nice terrain system.

I have a book called Game Programming Gems IIRC it has a terrain system that uses occlusion culling. Its written in C++ for OpenGL, shouldn't be that hard to convert it for GDK. When I get home for christmas break I might have an attempt at getting it working.

The Sun is trying to kill me!
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 13th Dec 2007 16:43
Can't Wait!

I'm currently going to take another stab at both the "Stock Terrain" and seeing what I can do with that - as well as maybe a cheap way of moving a hidden object around - to try to discern whether or not to hide other objects - via inscreen. Like place hiiden object to four corners of terrain "Tile" and then again at height - but - if even tests like this FAIL - portions of the terrain object might be visible - so - hmm... Going to try DarkGDK (not so Advanced) Terrain again

jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 13th Dec 2007 23:29 Edited at: 13th Dec 2007 23:32
I got it. Bro - Much to my Chagrin - in a way - I got it working. Here's the Deal.

It IS an object # - not a terrain Number. Error 6 - is from "missing" files. But Just blank? Try some ludicrous Terrain ID -- like 1000. See how that does ya - plus - sbObjectExist(ObjID) Will find it!

What annoys me is I had a very long thread about this before and was struggling - and was even debating this very point - and I was convinced it was separate. Meaning - TerrainID not same as ObjectID's... but I just found today they are... ugh...

[edit]
After reading this - I feel silly about using the words "Debate" but I was performing tests at the time that suggested Terrain 1 and Some object like a Box with an ID could coexist - and I had stuff that suggested that it could...hence I debated... now I'm just perplexed. Now I wond if one can move the DarkGDK terrains around. If so - cool - if not...grrrrrr

So - How would one put a shadow on a DarkGDK Terrain? Shader Right? Hmmm
[/edit]
[/edit]

Login to post a reply

Server time is: 2024-11-17 00:17:53
Your offset time is: 2024-11-17 00:17:53