Level Editor Interface

Started by
18 comments, last by catch 14 years, 10 months ago
Quote:Original post by MJP
Managed C++ is dead by the way, C++/CLI is the replacement

You've also mentioned "pure managed code". Could you please explain the differences between the three? Also, what's a good resource to get started with the last approach you outlined?

Almost off-topic, I'm close to finishing my own editor (I'm calling it the Angel3D Editor) to a usable "or rather showable" state next couple of weeks. It uses a thin library above the win32 API that I put together while working on it. I'll make this library available for public use then, along with an article or two on how to use it to write an editor.. not that I'm expecting you to wait though, just felt like shamelessly pimping it :D
Advertisement
Quote:Original post by DekuTree64
I was imagining moving the player around rather than using a scrollbar. So you can just go into "edit mode" wherever you are in the game, place down some enemies, maybe move the player back a bit, and start back up again. Probably reset all the enemies to their starting positions whenever you go into edit mode, because it could get confusing if you could modify enemies that had moved from their starting positions.


Ya... some ideas there I hadn't thought of. Reminds me of the debug mode in Sonic.

I think I might go with wxWidgets.

I've a question though... when I'm making a level editor and drawing the tile set or whatever, do I use the image-related stuff in the GUI API itself or Direct3D/OpenGL/whatever? I mean, do GUI APIs tend to have all you need for image manipulation like drawing certain sections of an image? Bah, I'm so confused with GUIs -_-
Quote:Original post by Sean_Seanston
I've a question though... when I'm making a level editor and drawing the tile set or whatever, do I use the image-related stuff in the GUI API itself or Direct3D/OpenGL/whatever? I mean, do GUI APIs tend to have all you need for image manipulation like drawing certain sections of an image? Bah, I'm so confused with GUIs -_-


They do, but you'll probably want to draw your actual maps and tiles using the same rendering engine you're using for the game. This ensures things look the same in both your editor and in your game.

Quote:Original post by hikikomori-san
You've also mentioned "pure managed code". Could you please explain the differences between the three? Also, what's a good resource to get started with the last approach you outlined?


By that I mean code written in a language that will only produced managed assemblies (C#, VB.NET, etc.). C++/CLI can produce assemblies that contain a mix of native and managed code, while regular C++ can only produce executables that contain native machine code.

For starters, there's some information on MSDN such as this, this, and this. I'm sure there's much more to be found on Google.
Quote:Original post by MJP
They do, but you'll probably want to draw your actual maps and tiles using the same rendering engine you're using for the game. This ensures things look the same in both your editor and in your game.


I see...

That sounds kind of complicated. Would the actual window then be made using Direct3D, for example, or the GUI API?

How might the 2 APIs be combined? I suppose it's mostly the window creation that I'm worrying about... since DirectX needs so much Windows API stuff and presumably any GUI API you look at is going to have a way to create its own window.

Are there any links you know of about something to this effect? I wouldn't really know where to start TBH.
Quote:Original post by Sean_Seanston
I see...

That sounds kind of complicated. Would the actual window then be made using Direct3D, for example, or the GUI API?

How might the 2 APIs be combined? I suppose it's mostly the window creation that I'm worrying about... since DirectX needs so much Windows API stuff and presumably any GUI API you look at is going to have a way to create its own window.

Are there any links you know of about something to this effect? I wouldn't really know where to start TBH.


It's a lot less complicated than you think it is. [smile]

Remember that Direct3D provides no means of creating a window. When you create a device you say "hey, here's a handle to a window that you should draw to" and then Direct3D draws to its client area. It doesn't care where that window came from or how you made it, as long as you have its window handle. It also won't mess with that window at all as long as you don't go fullscreen.

So typically what you'll do is you'll have your main window, you'll have your stuff like your menu and status bar and maybe a a splitter with a toolbar on the side. Then you'll have a large control (child window) embedded in the main window that you tell D3D to draw to.
Quote:Original post by MJP
Remember that Direct3D provides no means of creating a window. When you create a device you say "hey, here's a handle to a window that you should draw to" and then Direct3D draws to its client area. It doesn't care where that window came from or how you made it, as long as you have its window handle. It also won't mess with that window at all as long as you don't go fullscreen.


Oh yeah... suppose I never really looked too deeply at the connection between Win API and DirectX since Win API wrecked my head enough when I was originally trying to learn it :p

So should it be just as easy with something like wxWidgets as using the actual Win API? Or do most GUI APIs actually just provide a wrapper around the Win API window system anyway? Just curious since you'd obviously need a window handle of the same kind as the Win API one to pass to Direct3D.

Quote:Original post by MJP
So typically what you'll do is you'll have your main window, you'll have your stuff like your menu and status bar and maybe a a splitter with a toolbar on the side. Then you'll have a large control (child window) embedded in the main window that you tell D3D to draw to.


So you just pass the window handle of the child window to Direct3D... nice.

Should be quite easy then to set up an array of tiles on the side and have it let you paint them onto the Direct3D window once you have a grasp of WinAPI, right?

Sweet, thanks. Though I might go with the in-game editor this time... I was thinking about that today. More complicated things in future will probably need WinAPI or something to be practical though.
Quote:Original post by Sean_Seanston
So should it be just as easy with something like wxWidgets as using the actual Win API? Or do most GUI APIs actually just provide a wrapper around the Win API window system anyway? Just curious since you'd obviously need a window handle of the same kind as the Win API one to pass to Direct3D.

Yes, it should be pretty easy. There are ways to access the window handle in MFC, Qt, wxWidgets, and most likely all of the other native windowing toolkits. If you set up your engine to have an abstract render window interface that only requires a handle to render to, then it becomes trivial to support multiple windowing toolkits since you just create a new render window subclass that knows how to get the handle from the appropriate widget/window control.

I use wxWidgets, but I've been looking at win32++ and it looks pretty cool. You'd probably still have to learn a little regular win32, but not the hard parts.

wxWidgets is tricky to setup until you understand its build system, which is designed to allow you to keep multiple build configurations of it around.
www.clanlib.org
"Creativity requires you to murder your children." - Chris Crawford

This topic is closed to new replies.

Advertisement