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 / Not a bug, just a request for startup instructions.

Author
Message
Zumwalt
17
Years of Service
User Offline
Joined: 1st Feb 2007
Location: Tampa, FL
Posted: 20th Feb 2007 15:00
Right now, when you generate a new scene and create an object, that object by default is visible, can this be switched in the core engine that the createobject creates the object with default as invisibile?

I switch mine to invisible after it is created and before I move it to its final position in the scene, but what I want, is to not worry about its visibility state since I will have a heartbeat thread that creates static objects on the fly in the game then positions them.

All objects coming into the game via createobject start out visible and at coordinates of 0,0,0 and I realize this is by design.

A horrible work around is to place a mountain at that spot, so nothing created is seen in the scene at that location, otherwise, I can get 'flicker' of the object, a very brief visual of the object between game loops.

Rather anoying.
Thanks
APEXnow
Retired Moderator
21
Years of Service
User Offline
Joined: 15th Apr 2003
Location: On a park bench
Posted: 20th Feb 2007 18:45
This behaviour is standard across all the product range, I'm not going to change this behaviour for just DGDK.NET. And the consequences of people posting to complain why their objects no longer appear after creation, would be rediculous.

Paul.

IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 20th Feb 2007 22:56
A reasonable workaround is to write a function that loads/creates your object and positions it out of sight, or hides it.

An unreasonable workaround is to change the library that everyone uses without problem to 'fix' a problem that isn't a problem.

Zumwalt
17
Years of Service
User Offline
Joined: 1st Feb 2007
Location: Tampa, FL
Posted: 20th Feb 2007 23:44
Moving it is not a solution, since hiding it when its created is just as good as moving it out of site, considering when it is created, its default location is 0,0,0

I can't beleive the flash back on this subject. This is the first and only engine i have used that doesn't start with loaded objects in a nonvisible state.

This is not an apparent problem if people don't use dynamic items in there games (create / destroy) objects on the fly. There are multiple states to a game.

Initialization, keep loading everything in while showing the user splash screens or place the camera in some arbitrary position in the world (like 1000,1000,1000) which makes the object out of site, out of mind as it loads in all the collection of every single object in the game until the game loop.

The game loop, obvious here, but lets say for instance, that you have a dynamic system generator that, based on certain circumstances, creates many objects via a thread, this thread loads in many 3ds or X objects while the game is running and places them in the world.

As we all know, a 'visible' object is rendered to the camera if it is in the camera's range of view. It reduces engine load if you, by default, have the loadobject load in all objects as non-visible.

I doubt this has been brought up before since people most likely load in there entire collection of objects up front and place them all before the player gets to see the playing field.

Its a reasonalbe request, thats all I am saying.
My current workaround shows blinking objects, which is simply when I do a loadobject, I then simply hide it. Its a blip on my screen for the moment that it is visible.

I don't know why everyone is getting so up in arms about this request. Product enhancements go hand in hand with customer requests. This request didn't even make it to a review to find out if it is a feasable and sensable request. Apparently it has merrit if other engines already do it.

Do all reqeusts get attacked this hard when they are made?
A simple answer of:
We thought about this before but decided not to do it because....
We decided functionally up front not to do it because....
This never crossed our minds...
There is to much code to do to make this happen so we can't adjust now....
Adding one more parameter to the method and then adding to the method a default of visible=false is not worth it at this time...

Answers like that make sense, the answers I have been given are not very flexible. All this would take is to update the method to add in an optional paramter for the visible state on load. This would not change anyones current working code and it would expand the method to allow the visible state to be adjusted on load without any intrusion.

Then people who have the desire to load in items dynamically to there game instead of having to preload them, don't have to worry about wether the item is rendered when loaded or not, and they don't have to worry about the blip of object on screen if the player "happens" to be facing 0,0,0 and sees a funny appear/disappear effect.
APEXnow
Retired Moderator
21
Years of Service
User Offline
Joined: 15th Apr 2003
Location: On a park bench
Posted: 21st Feb 2007 00:31
Quote: "Do all reqeusts get attacked this hard when they are made?"


What on Earth are you talking about? Zum, no one has attacked your request... I certainly didn't. I've given my reason for not implementing the feature, and I'm pretty sure that TGC would agree.

Paul.

Milkman
18
Years of Service
User Offline
Joined: 30th Nov 2005
Location: United States
Posted: 21st Feb 2007 00:50 Edited at: 21st Feb 2007 00:52
Zumwalt, what you're trying to do should not be a problem. If you have DBP, here is some code to demonstrate how you can create objects in real time without seeing them "flash" at the origin. Once you create the object, just hide it or move it right away before the world is rendered, and you will never see it. Note that you need to have 'sync' on, so you render your world every loop manually with the 'sync' command (don't know how you'd do that in the gdk). I imagine if you don't enable manual sync, you could have the "flashing" problem.
Good luck



Who needs a signature?
Zumwalt
17
Years of Service
User Offline
Joined: 1st Feb 2007
Location: Tampa, FL
Posted: 21st Feb 2007 01:16
Thanks Milkman, going to go back through my dynamic code section and find out more about the hide, since in my method for the generation of these dynamic objects, I am doing a loadobject with an immediate hideobject, if this works in dbpro, then maybe my syncstate is not ballanced or something odd.

I don't see why it would work in dbpro but not in dgdk.net if this is the case. Been thinking about this the entire drive home, I figured what I would do is create a 'void' at 0,0,0 that is about 250,250,250 in size, place some arbitrary object like a 'dome' of sorts (only gm's, admins, and helpers allowed in it through a teleport command), then it would never be seen by the players anyway.
Milkman
18
Years of Service
User Offline
Joined: 30th Nov 2005
Location: United States
Posted: 21st Feb 2007 01:24 Edited at: 21st Feb 2007 01:31
The dome over the origin is not necessary. If you are hiding the loaded object immediately after creation and manual sync is on, you should not see the object at all. You must not have manual sync enabled; look for someone more familiar with the gdk and see how to enable it.

[edit]
apparently you would use 'odbcore.syncon()' to turn on manual sync and 'odbcore.sync()' every loop iteration to render the world. Hope that helps.
[/edit]

Who needs a signature?
APEXnow
Retired Moderator
21
Years of Service
User Offline
Joined: 15th Apr 2003
Location: On a park bench
Posted: 21st Feb 2007 01:30
oDBCore.SyncOn()

Paul.

CattleRustler
Retired Moderator
21
Years of Service
User Offline
Joined: 8th Aug 2003
Location: case modding at overclock.net
Posted: 21st Feb 2007 01:30
odbCore.SyncOn

Michael Moore needs this film:Aaron Russo's America: Freedom To Fascism
RonPaul'08
CattleRustler
Retired Moderator
21
Years of Service
User Offline
Joined: 8th Aug 2003
Location: case modding at overclock.net
Posted: 21st Feb 2007 01:31
lawl, apex beat me

Michael Moore needs this film:Aaron Russo's America: Freedom To Fascism
RonPaul'08
Milkman
18
Years of Service
User Offline
Joined: 30th Nov 2005
Location: United States
Posted: 21st Feb 2007 01:32
Lol, CattleRustler and Apex posted before i edited.

Who needs a signature?
APEXnow
Retired Moderator
21
Years of Service
User Offline
Joined: 15th Apr 2003
Location: On a park bench
Posted: 21st Feb 2007 01:32
sorry mate

Paul.

CattleRustler
Retired Moderator
21
Years of Service
User Offline
Joined: 8th Aug 2003
Location: case modding at overclock.net
Posted: 21st Feb 2007 01:36
hopefully this is sorted then
the engine DOES provide the needed functionality

Michael Moore needs this film:Aaron Russo's America: Freedom To Fascism
RonPaul'08
APEXnow
Retired Moderator
21
Years of Service
User Offline
Joined: 15th Apr 2003
Location: On a park bench
Posted: 21st Feb 2007 01:39
In the famous words of Samuel L. Jackson.... "I thought so!"

Paul.

James Bondo
17
Years of Service
User Offline
Joined: 12th Nov 2006
Location: Denmark
Posted: 21st Feb 2007 01:53
I think you are all minsunderstanding eachother.

Zumwalt has created a multithreaded game. Thread one is handling everything that has to do with the game (camera/character movement, world interraction, etc). The second thread is dynamically loading in the world as you walk around in it.

Imagine a HUUUGE world (world of warcraft world size). There would be no reason to load in every single character model and tree model and house model (and so on) in the world when you only see a tiny fraction of it.

Zumwalts has implementet this extra thread for loading objects with no visual feedback by making the new thread handle loading while the main game loop is handling everything else.

Now imagine this.
thread one has completed everything is needs to EXCEPT the sync command at the end of the game loop.
Right before the sync command, the second game thread gets instructed to load an object, but before the seperate thread can hide the object, the main thread has already synced.
This makes the newly loaded object visible for exactly 1 frame, even if the seperate thread has a hide object command immediately after the load command. This is the blinking Zumwalt is talking about.

The functionality isnt here because DGDK.Net is based on GDK. GDK is based on DBPro. There would never be a need for this functionality in DBPro due to the nature of the language.

Using Dark GDK.NET
CattleRustler
Retired Moderator
21
Years of Service
User Offline
Joined: 8th Aug 2003
Location: case modding at overclock.net
Posted: 21st Feb 2007 03:11
ah, missed the threaded bit. Oh well, back under the dome then.

Michael Moore needs this film:Aaron Russo's America: Freedom To Fascism
RonPaul'08
Zumwalt
17
Years of Service
User Offline
Joined: 1st Feb 2007
Location: Tampa, FL
Posted: 21st Feb 2007 03:15 Edited at: 21st Feb 2007 03:16
Thats exactly the problem.
Yea, going to have to deal with a dome in my case.
Mike Johnson
TGC Developer
22
Years of Service
User Offline
Joined: 13th Sep 2002
Location: United Kingdom
Posted: 21st Feb 2007 10:17
I set up a small project to see this for myself. The code I wrote does the following:

* switches sync on and turns the automatic camera off
* positions the camera
* creates a new thread, this thread is responsible for loading in objects over time, for now it loads them in right in front of the camera and then increments the position so we have a long line of othese objects in view, directly after the object is loaded it is hidden
* the main loop prints some info to screen and calls sync

All of this works fine and I don't see any of the objects on screen. I don't get to see the objects flickering on screen like Zumwalt has mentioned.

The only suggestion I can make right now is to post a small example program that demonstrates this problem. We can then determine if it's an issue with the program itself or the GDK and find a solution to it.
APEXnow
Retired Moderator
21
Years of Service
User Offline
Joined: 15th Apr 2003
Location: On a park bench
Posted: 21st Feb 2007 10:43
I too missed the thread bit, although this is certainly and interesting thing to chase up. Certainly would be interested to see where this leads. Would it also be possible to use a Mutex on the thread that loads, to ensure that the inivisibility flag for the object has been set? I.e. Sync waits until the mutex has been unlocked?

Paul.

Miguel Melo
19
Years of Service
User Offline
Joined: 8th Aug 2005
Location:
Posted: 21st Feb 2007 10:48
Quote: "I.e. Sync waits until the mutex has been unlocked?"


Yeah, I was going to suggest a semaphore too.

I have vague plans for World Domination
Mike Johnson
TGC Developer
22
Years of Service
User Offline
Joined: 13th Sep 2002
Location: United Kingdom
Posted: 21st Feb 2007 10:53
I tried out a few different things and as expected it wasn't hard to make the program crash. Once I had enclosed dbSync with WaitForSingleObject and ReleaseMutex it worked well.

Also tried a small test where I had split up dbLoadObject and made it do the work over several frames as a way of trying to stream in the data without bringing the main program to a grinding halt. It turned out really well. Will have to look into it in more detail at some point and see what we can do to the GDK to improve support for threads.
Zumwalt
17
Years of Service
User Offline
Joined: 1st Feb 2007
Location: Tampa, FL
Posted: 21st Feb 2007 14:20
I'll work on breaking apart my application to just post the thread and the method the thread is working on and post it along with a game loop like I do all the other examples I post. I'll post it at some point today (sooner than later hopefully so you can see what I am doing)
Zumwalt
17
Years of Service
User Offline
Joined: 1st Feb 2007
Location: Tampa, FL
Posted: 22nd Feb 2007 04:12
Sorry for the delay, here it is, a working example with flashing object.

Just change the initialization to use the generic tutorial version.
This is simple enough example, should be easy to follow.

Attachments

Login to view attachments
Mike Johnson
TGC Developer
22
Years of Service
User Offline
Joined: 13th Sep 2002
Location: United Kingdom
Posted: 22nd Feb 2007 21:11
Zumwalt, can you try something like this:



I'm uncertain of the exact syntax so you will need to check your compiler documentation but I expect it to be very similar. Making these changes may solve the problem of the flickering objects.

Has anyone else tried using multi threading in the GDK / GDK .NET?
Zumwalt
17
Years of Service
User Offline
Joined: 1st Feb 2007
Location: Tampa, FL
Posted: 23rd Feb 2007 00:28 Edited at: 23rd Feb 2007 17:23
I tried this both in the game loop before and after the sync like you are requesting, and i also tried it within the object thread itself, in both cases I still got flicker, not as often, but it still exists.

Just to note, I do NOT want to stop the main game loop while the addObject is doing its work, this would hault my game, otherwise, I wouldn't create it in a thread at all.

Added to Imports


Before Sub Main()


Tall end of Loop
HandK
18
Years of Service
User Offline
Joined: 24th Jun 2006
Location:
Posted: 23rd Feb 2007 04:24 Edited at: 23rd Feb 2007 04:27
Why not just make the base level for terrain a lot higher than 0
Say x,250,z then rather than having to put a mountain at 0,0,0, it wouldnt matter, cos its underground.

Yes I know this isnt an answer, just a hack, but Im trying to be helpful

H&K
Zumwalt
17
Years of Service
User Offline
Joined: 1st Feb 2007
Location: Tampa, FL
Posted: 23rd Feb 2007 05:38
That had crossed my mind, its early enough in the project to do some adjustments like this, I am just dreading going through the initial level object stacks and shift them. I have 1 of two options for that shift. Either do it within the game engine or do it in the editor first.

It is a hack, but it would work short term.
Zumwalt
17
Years of Service
User Offline
Joined: 1st Feb 2007
Location: Tampa, FL
Posted: 24th Feb 2007 04:29
FYI: I worked with CR and Apex today in the mIRC chat and changed over from .Net 2003 to .Net 2005 and recompiled my applications, I still have the flicker. This eliminates the possiblity that it could be framework related. I am no longer using 1.1 but using 2.0 for the application. Just wanted to drop this update.
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 24th Feb 2007 13:51
Silly question, but I haven't seen any code in this thread for locking the mutex around the create/position object code. You have been doing that too, haven't you?

Zumwalt
17
Years of Service
User Offline
Joined: 1st Feb 2007
Location: Tampa, FL
Posted: 26th Feb 2007 17:48
I put it in the thread that does the ADDOBJECT also to see if it made a difference, and it didn't.

I put it before the loadobject and after the hideobject.
No change, still flashes.

Login to post a reply

Server time is: 2024-09-28 23:14:23
Your offset time is: 2024-09-28 23:14:23