What to use for a map editor?

[filipe]

I'm currently writing an old school 2d RPG in my spare time. I use Direct3D 9 to do the rendering. Now I got to a point where I need an editor for maps/scripts. Since I was already using raw Windows API because it's needed to initialize D3D, I thought I would go with it. The more I look into it, though, the more it seems like too much trouble.

My questions are:

1- Is it possible to write it in Python using some library, or would it be too slow? I know a bit of Python and would love to write something useful with it.

2- If so, which libraries should I look into?

3- If not, what's the simplest tool you guys recommend to get the job done?

I would prefer to have native looking menus, but anything that looks good enough will do. FLTK is an example of something I wouldn't want to use, as the buttons look too ugly to my taste.

I'm not particularly interested in cross platform code, as the game already is Windows only.

[Disch]

0) There are some generic mapping tools available. I've been trying to find a good one, but all the ones I found really sucked and/or were really awkward to use and/or had map file formats that were poorly documented (what good is making a map if you can't load it!!!)

You might want to consider searching for premade maps before you start this. If you do happen to find something, I would really be interested in hearing about it.


1) I don't see why Python would be too slow. Simple map edtiors are not very computation heavy. The most taxing part would be the drawing, and that's something Python shouldn't be slow at, as it likely just passes it to another lib that's written in a faster langauge. I say go for it.

2) no clue, sorry =(

as the game already is Windows only.

=(

D3D over SFML? for a 2D game? =( =( =(

[Athar]

2) SFML has Python bindings, so that is the best choice for both the map editor and the game itself.

It would be much less work if you just integrate the map editor into the game, as a lot of the necessary code (map rendering code, input handling, map (de)serialization etc.) is already there. You just have to add some code for the actual editing.

[filipe]

Thanks a lot for the answers.

Disch wrote:

There are some generic mapping tools available.

I'd like to roll my own because of the flexibility and also for the experience.

Disch wrote:

D3D over SFML? for a 2D game? =( =( =(

Athar wrote:

SFML has Python bindings, so that is the best choice for both the map editor and the game itself.

Well, I'm interested in doing some pixel shading later on. For some reason I assumed it would only be available for 3D libraries, but a google search shows I was very wrong. I'll have a serious look into SFML. I think most of the code I have so far wouldn't need much change anyway.

[Disch]

SFML sits atop OpenGL, so it is a 3D library underneath. It's just a 2D abstraction layer.

Athar wrote:

It would be much less work if you just integrate the map editor into the game, as a lot of the necessary code (map rendering code, input handling, map (de)serialization etc.) is already there

I disagree, actually.

map loading/etc code can be used in either program if you make it modular (which you should be doing), and having to write a map editor in a game means you're stuck with one of the following:

- having no widgets (which = you have a crappy, hard to use editor)
or
- you have to use an additional widget lib (adding bloat to the game)
or
- you have to write your own mini-widget lib (a wretched combination of the above 2)

[NGen]

Or you could implement that stuff via DLL, which, I'm assuming, is what Disch meant by "modular".

SFML's rendering system is a bit... meh... I prefer using SFML for getting a window up and whatnot, but the actual drawing I do in pure OpenGL since it only takes 4-5 lines of code to get 2D rendering set up anyways. After that, it's all calls to glVertex2x, glColorNx, glBegin/glEnd, etc. which is hardly complex or difficult to understand and is so much easier. You're not getting any special optimizations by using the built-in rendering functions and classes (the opposite actually, SFML does checks on practically everything it does, causing for a bit of overhead compared to regular OpenGL rendering) so it's not like you're going to be losing 15 FPS by using built-in rendering.

Setting up a fragment/pixel shader in OpenGL is just as easy to make in OpenGL as it is in Direct3D. Only difference is that you have to load the file into memory yourself, and then pass that data to OpenGL to get the shader compiled.

[Incubbus]

Why don´t You go with Direct2D?...

[filipe]

Because I want it to run on Windows XP.

[Disch]

but the actual drawing I do in pure OpenGL since it only takes 4-5 lines of code to get 2D rendering set up anyways.

Rendering text is way easier with SFML.

Loading textures is a bit easier too. Although it's not hard to write your own loader thing, and that rendering is pretty simple apart from that.

so it's not like you're going to be losing 15 FPS by using built-in rendering.

I find it very hard to believe that SFML would that much of an impact on performance unless you're have tons and tons of quads on screen.

[NGen]

I find it very hard to believe that SFML would that much of an impact on performance unless you're have tons and tons of quads on screen.

That was an exaggeration, but my point is that there's no advantage of using the SFML rendering system over the basic OpenGL implementations other than the few more lines of code needed to be written.

As for text, I forgot about that. But I was referring to rendering images, text is a whole different matter. That's the only automated thing that I really see as being an advantageous component. I'd still like to make my own implementation similar to printf, like what's available in HGE.

[chrisname]

@NGen,
I've not really used the OpenGL rendering features of SFML but from what I've read in this thread it seems to make sense. The SFML docs about OpenGL say that once you create a window for the OpenGL library to render on (the SFML documentation calls it a "rendering context") you can use direct calls.

NGen wrote:

I'd still like to make my own implementation similar to printf, like what's available in HGE.

That seems pointless. printf() isn't computationally expensive at all, and if you don't need formatted args you can just use puts().

[Disch]

but my point is that there's no advantage of using the SFML rendering system over the basic OpenGL implementations other than the few more lines of code needed to be written.

Well I would create something similar to sf::Sprite for my rendering purposes anyway, so I might as well use it since it's there.

[NGen]

I don't like it mostly because of lack of flexibility, along with how coordinates are internally managed. :< When DON'T you need quick access to the position of an image?

That seems pointless. printf() isn't computationally expensive at all, and if you don't need formatted args you can just use puts().

I don't mean for the console, I mean for rendering. Why would I make an implementation of printf for the console using an OpenGL rendering engine? I don't think that's even possible without a bit of window injection.

[Disch]

My biggest beef with SFML is that it keeps with traditional 2D style coordinates (Y grows downward) instead of the more logical 3D style (Y grows upward), but I guess that's to make it seem more like a 2D lib.

[chrisname]

@NGen,
Oh, nevermind. A simple misunderstanding on my part. Making a printf() function for graphical output is a good idea.

[NGen]

It's more a limitation of the rendering library than SFML. If you want y-up coordinates, you can do that on your own since you can edit the source (y: ScreenHeight-y). But honestly, I see that coordinate system being used in every possible 2D library I've ever seen. I don't know what it is, but that's just the way it's done for some reason.

[chrisname]

Maybe they could allow you to specify the direction of the y axis? I guess that overcomplicates matters, though.

[Disch]

But honestly, I see that coordinate system being used in every possible 2D library I've ever seen. I don't know what it is, but that's just the way it's done for some reason.

Because the raster gun draws downward on television sets. So old video game systems rendered the top scanline first, and other scanlines were rendered top-down.

But it's totally backwards because on every grid system, positive Y is always upward.

And game developers haven't had to care about scanlines and raster guns in years.

[hamsterman]

I haven't used sfml much myself, but if it allows using opengl, then wouldn't something like this work?

//create window
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glOrtho(/**/)//set up coordinate system the way you like it
glMatrixMode(GL_MODELVIEW);
//use sfml functions 

[helios]

It's because matrices in mathematics grow downwards.

Memory maps always confuse the hell out of me because they're tables that grow upwards. The worst part is when looking at a stack. You have memory growing upwards, stacks growing downwards, arrays growing upwards, little endian integers, "big endian" bytes. Jesus Christ, who came up with this? Couldn't we just call large memory indices "high memory" and still draw memory maps downwards?
Anyway, that's the only instance I've seen of a grid's y axis growing upwards.