Torque 3D Community Edition Discussion Thread

#101 Would you all like to integrate the Mac port we have in our private repository?

From Eric in community hour IRC:

Quote:We did an initial round of the Mac port. It's been delivered but not implemented in the best way. I want to release it as a resource so that it will help some...but it wouldn't meet our mark as an official update. We are talking about the best way to get it out...but there's nothing stopping us from doing it ASAP aside from actually writing the resource. I could give it out today if you don't mind it being a code dump.

So, why not just hand it off to you guys to integrate in with the rest of your fixes/upgrades? Here are the caveats:

1. It will be a full code drop, all source, examples, and Xcode. It's going to be a large download.

2. It will be up to you all to integrate it into the CE repository and fix anything it might break in your builds.

3. We need a point of contact to send the files to. So someone volunteer.

#102 By the way, no need to rush this. Discuss among yourselves who might be the best person to perform the first commit. This is a standing offer with no time limit.

#103 I thinking we should integrate it! (one vote for Mac port)...

#104 I've been absent from home and the CE this week, but I could begin integrating the Mac port on Sunday if no one volunteers. Testing it however would have to be coordinated with a Mac user.

Also, keeping the Mac side of things maintained, as well as any fixes thereof, would have to be handed off to a Mac user. This is a chance for a savvy Mac devotee to step up and contribute for the good of all who desire the Mac port.

#105 I would love to raise my hand but I don't currently have a working mac partition anymore. :(

#106 It is definitely required that a Mac user, particularly with OS X 10.7, be available for immediate integration. I have a feeling that a straight merge might break the Windows build if you do not have access to Xcode. I'm still willing to hand it off, but I just thought you'd like to know. Michael Hall will be the likely recipient, but someon with a Mac might want to speak up now.

#107 I have a cleaned up version of the resource www.garagegames.com/community/resources/view/21471 for network object culling.


I can roll it into the CE version if the community wants, I'll just need write permission to do it.

Let me know.

#108 Come all folks, I was expecting more clamor and excitement for the oft requested improved Mac support. I'm willing to take the time (and chance) to integrate it for the CE and see how it goes, but if it ends up breaking the Windows build and we don't have a Mac developer on hand to coordinate with then there's really not much point in actually committing anything...


@Vince: you do have write permission for the CE.

#109 I am excited about Mac support. Maybe if it has the potential to disrupt the head it should be in a branch?

#110 @Frank: does that excitement equate to volunteering for testing and Mac-side maintenance?

#111 I think it's less that no one cares, and more of a 'that's awesome, but I can't help'. I know it's that way for me. I think getting mac support to speed would be completely awesome, but I don't have a mac or any way to contribute to that side of things.
I would agree with Frank's suggestion of setting up a branch for the Mac integration though. It'd be the easiest way to start getting it to speed without completely breaking the whole shebang. I'd imagine once the initial integration work is done, people would be more willing to make small tweaks and fixes to the mac build over time, as opposed to just jumping in head first to such a large project.

#112

Quote:I think it's less that no one cares, and more of a 'that's awesome, but I can't help'

I reckon that sums it up. I have a Mac and would be willing to assist - my time is a little constrained at the moment and I've been away for the last two weeks...but would be willing to assist until somebody more apt comes along.

I wouldn't necessarily feel comfortable about tackling this all on my lonesome tho...but testing - I can definitely offer some of my time there.

#113 @Michael,
I don't have a Mac that can run T3D. I just have an old 10.5 PPC Mac. If I had a good Mac I would.

#114 Optimizing the compiledEval.cpp CodeBlock::exec function:
I am slowly working through this. However, I am finding some interesting things. The code relies very heavily on global variables. That means the evaluation of compiled scripts is not thread safe. One of the things I am doing as part of my test is putting every variable used into the CodeBlock class itself as a non-static variables. That way theoretically you could call multiple exec calls in different threads. Now, I don't know what the rest of the code that supports this looks like so it may not make it thread safe, but it is a start. I am sure there would need to be some sort of queue or semaphore setup to share the console itself.

@Michael,
I am excited about Mac support because it adds potential customers in the future.

Edit:
I just took a look at the assembler the code produces to see if the compiler is optimizing out the function calls, and it is! I can't actually run the code yet as I still need to implement the rest of the opcodes, but I can start the debugger set a breakpoint and look at the opcode functions I am writing. This is with VC++ 2008 Express.

It is interesting because the code clearly calls a function is the C++ and after that point there is a RET in the assembler. However, that point will never be reached until the last opcode is run. I noticed that the assembler looks like it is modifying the instruction pointer rather than calling a function. That is what I want to see, I just find it interesting how it actually does it.

#115 I'm going to suggest to Alfio that we dump all example projects but the Full Template (for the time being) from the CE -- unless someone wants to maintain them? Between the two of us, we're only keeping the Full Template up to date. As a result of that I've found several problems with the Empty Template, and likely the other projects as well. I've slowly been tracking these problems down, I just don't feel very enthusiastic about keeping all of the different example projects maintained.

I've been rewriting/rearranging/refactoring a new Starter Template which led to me wanting to dump the existing projects due to some hardcoded filepaths (core/art, core/art/gui, and art/gui) in the source, and some in the tools module. If I change them, that means making a series of recursive edits for every existing project... yet not making the changes means conforming to the atrocious organization scheme that GG has indulged in.

Basically, the new Template can start up, load missions, has tool support, mod support, includes all stock GUI dialogs and menus, and does it all with a stripped down script base -- what the "core" should have been. Would you guys rather keep the familiar directory structure so that all existing projects don't become broken, or actually clean that crap up and have a CE specific Starter Template removing all others?

#116 One simple template.

We can always get more complicated later. Likely we can create scripts down the road that create other templates from the single template.

Edit:
The only caveat I can think of is when the in game editors modify scripts. Just make sure that stuff does not get moved.

#117 I would suggest leaving the script directory in with the basic hooks, so developers can readily drop their game-specific code in without wondering where it should go, but the core functions really should be delegated to the core folder.
Core should be what the game initializes itself off of, and scripts and art are what the game actually uses to go.

#118 @michael I'm totally in favor of a new base template and removing the core folder and dependencies...there's a lot of bloat there. It also gives a better chance for client/server separation...and is much easier to both maintain and extend IMO.

There's multiple ways to cut it, and just to add to the discussion more than anything -I've attempted this before myself with a folder structure like:

+art
+client
-+postf
-+lighting
-+profiles
-+audio
+levels
+server
+shaders
+tools

It also depends on how people want to extend from the template. For the above I set the default scripts directory to the client dir, and I use packages to inject things... for example there's the onStart and onExit aclls - but I've also added clientOnInit..which allows the Parent::clientOnInit to be called when I'm extending.

I prefer packages for this, seems to keep things cleaner - but others might not...

#119 I agree with a new CE starter template and get rid of all the bloat. In the long run, it will make things easier.

#120 In my own projects I've completely reorganized things for a new Template and have found it much more beneficial when prototyping and developing with than the current bloated setup which continually seems to confuse newcomers.

I admit that it was a reasonable setup way back in TGE when Garagegames distributed the example project directory with a common script base and several mods that worked on top of that common package. MY game is not a mod however. With the advent of the project generator there is no need to keep this separation, as the Template itself should serve as a basic framework that you build a game from.

The stripped down and re-purposed Template that I'm considering for the CE can do everything that the Full Template can do, but is much cleaner and easier to develop upon in my opinion. The only major difference between the Full Template, Physics Template, FPS Tutorial, FPS Example, Pacific Demo, Sector T3D, etc, are the assets and project specific Datablocks. They all use the same set of similar scripts, the same overrides of the core, etc, etc, in fact they all (even the Full Template) were built from the FPS Example in which I specifically added the overrides for! So why not move all of that into the core since they ]i]could[/i] be considered core functions? What exactly is a core function? And why are things that should be considered game specific assets and GUIs cluttering up the core? It's definitely a mess regardless of how any of us could want to argue the separation vs merge schism -- I saw this when I asked this question before about a new Template I was planning at the time as a Resource.


Since there is only one art file(the initial startup splash -- why is this one not in the core?) within the art directory that has a hardcoded filepath in the source I'm tending towards to moving everything into the core directory and reorganizing it, moving everything but those files that do suffer from the hardcoded nuisance.

The core would then break down like this:

ART:

• datablocks *
• gui **
• shapes:
• sound:
• textures: decals | groundCover | lights | particles | precipitation | roads | skies | terrains | water

SCRIPTS: This would be all server & client scripts that control the game.

USER: I kind of want to call this the config directory. These would be user/client specific prefs, saved keybinds, server banlist, badwords list, graphic card profiles, etc -- used for configuration


SYSTEMS: This would be the various script files needed to initialize and control the various sub-systems in Torque. Audio, PostFX, Lighting, etc.

* I really want to move the datablocks out of the art directory and into scripts, or maybe have a data directory that contains datablocks and level files? The tools have some paths that point here.

**I also would really like to move the GUIs and related scripts into a separate UI directory.... however the bulk of the hardcoded filepaths have to do with GUI assets so I'm willing to be somewhat more flexible about this one.

I feel that the above distinctions in script directories would in turn make it easier for those who desire to further separate things into standalone server and client packages easier than it is with the current Template structure.


Once I do commit it, the existing Templates and hardcoded paths will remain in place for a period of time. This way everyone can have a chance to critique and make further suggestions before deciding whether or not to accept it as the CE Starter Template. Only at that point would I alter the source (and tools) and remove the existing example projects -- this way we don't break them.