Unreal Engine 4, Unity 5.. Torque 6?

  • 1
  • 2
  • 3
  • 4
  • 5
  • 8
71 posts Page 3 of 8
andrewmac
Posts: 295
Joined: Tue Feb 03, 2015 9:45 pm
 
by andrewmac » Mon Mar 09, 2015 9:32 pm
Here's a video of the editor I started on:



I only put about a day into it so it doesn't do much. I plan to revisit it soon once I finish up lighting and shadows.
jay1ne
Posts: 34
Joined: Thu Feb 19, 2015 2:24 am
by jay1ne » Tue Mar 10, 2015 9:59 pm
I'm gamed, not much of a programmer but everything sounds good. I can help in the suggestion area :)
rlranft
Posts: 306
Joined: Thu Feb 05, 2015 3:11 pm
 
by rlranft » Wed Mar 11, 2015 1:30 am
My opinion is that editor and feature dlls should be paired and not combined. That way you don't have to ship editors with your game - potentially saving a lot of space. You could then still make them available as a separately downloadable "toolkit."

Just an opinion - thought I'd throw it out there now so if you like the idea you can take advantage of it from the start....
Hutch
Posts: 42
Joined: Tue Feb 03, 2015 11:12 pm
by Hutch » Wed Mar 11, 2015 6:54 am
lookin' good andrew :)

+1 on what Richard said.
andrewmac
Posts: 295
Joined: Tue Feb 03, 2015 9:45 pm
 
by andrewmac » Wed Mar 11, 2015 2:45 pm
@
User avatar
rlranft
: what I was thinking was the bulk of the editor would be contained in the editor DLL/module so that, as you said, you could remove the editor DLL and module and remove the editors from a shipping build. What I was thinking though is that plugins such as Terrain, or Recast, etc. could check if the editor was loaded and register new menus and such within the editor. This way you wouldn't have to worry about dropping in modified editor files when installing the Recast plugin for instance since it could directly communicate with the editor ( if its loaded ) and modify the interface to add a "Recast" tab that lets you use the recast tools.

I think it covers all angles, does that sound good? I'm very open to input on anything I'm working on here. In fact, that's a lot of the reason I made this post. There's too much engine to design for just one person haha.
rlranft
Posts: 306
Joined: Thu Feb 05, 2015 3:11 pm
 
by rlranft » Wed Mar 11, 2015 4:02 pm
Sounds reasonable. In my experience, editor code is usually larger than the framework it is meant to support though. It might be worthwhile to separate them or it might not - have to see how much larger the files get when they're integrated, and you're still in the position of shipping unused code (which just offends my sense of neatness, really).

I was mainly thinking it would be preferable to keep everything as modular as possible to help reduce footprint - I mean, you do have a mobile platform target there. Are you planning to run the editors on iOS?

By the way - I'm just explaining my thought process here. Not trying to push or anything.
andrewmac
Posts: 295
Joined: Tue Feb 03, 2015 9:45 pm
 
by andrewmac » Wed Mar 11, 2015 6:31 pm
The main thing I'm trying to avoid is having every editor in one plugin. It makes the editor code bulky and discouraging so no one wants to work on it. It also makes it difficult for plugin authors to include unique editor tabs/pages/buttons for their plugin content.

You are right though, shipping unused code isn't cool. Presumably the custom editor pages may have icons and the like as well, so those would be in the plugin package, more unused content being shipped. Two potential solutions that come to mind:

1) a preprocessor flag along the lines of EXCLUDE_EDITORS_FROM_SHIPPING which would exclude editor code during compilation of shipping build. you would have to manually exclude unused assets though (side-note: I have plans for a function that will tell you all the unused assets in your projects directory)

2) Keep a plugin's editor code separate from the plugins main code and allow it to be loaded as a separate plugin by the editor itself. For instance terrain may have terrain.dll and terrain.editor.dll. When you load the editor package it'll look for editor DLLs to load.

Do either of those work?
elfprince13
Posts: 24
Joined: Mon Mar 09, 2015 3:41 am
 
by elfprince13 » Wed Mar 11, 2015 10:23 pm
This is actually pretty sweet!
About BGFX i'm not sure about this... i think i it's better a new GFX designed for new APis like Vulkan.
I'm not familiar enough with the various APIs to really write a good abstraction. The GFX system in T3D is too far behind for my needs, so I choose BGFX. I didn't want to get sucked into a hole of spending months/years perfecting my own abstraction only to still have to code the rest of the engine. Since this is mainly for fun I decided to skip all that and put my trust in Branimir's skill. He hasn't let me down yet as performance is where it should be with all the APIs in all my tests.
Do you know what implementation bgfx is using for instancing? I didn't look at the code too carefully but I'm hoping it's textures or vertex attributes with divisors and not uniforms....
andrewmac
Posts: 295
Joined: Tue Feb 03, 2015 9:45 pm
 
by andrewmac » Thu Mar 12, 2015 12:58 am
@
User avatar
elfprince13
: I didn't look through the implementation for each rendering API but from a quick look through the DX9 code looks like vertex attributes. He implemented instancing in a pretty generic but flexible way, I would imagine it differs behind the scenes based on what is the best way to handle instancing with that API.
rlranft
Posts: 306
Joined: Thu Feb 05, 2015 3:11 pm
 
by rlranft » Thu Mar 12, 2015 2:31 pm
I lean toward option 2, Andrew, though they are both completely valid and pretty common. I suppose I like the separate plug-in approach is because you're already making plug-ins to begin with. Having a separate "editor kit" that you could download would just be cool - and it would just live along-side your feature plug-ins. Down side: you have to manage versions more carefully. It could easily be that multiple versions of an editor plug-in would be compatible with an older feature plug-in, but you would have to have a smart versioning system, so more work.

So, if you're short on time I guess option 1 is better - and with the code partitioned in that manner it wouldn't be too hard to refactor if someone else got the itch.

Your party, which ever approach makes you most comfortable - remember, I am just thinking out loud in case I happen to think of something useful....
  • 1
  • 2
  • 3
  • 4
  • 5
  • 8
71 posts Page 3 of 8

Who is online

Users browsing this forum: No registered users and 24 guests