[Elektro-Omega]

I am currently getting my head around C++ (I don't know how many times I have said that) but I am looking to create a basic sprite editor and eventually a level editor of sorts.

Now say I want to create an editor that can create 8x8 sprites. I assume that I would create a simple palette of, say, 16 colours (for example) and then create a 2 dimensional array with 8 entries in each dimension. I would then populate the indexes of my 2 dimensional with each value of the index of the palette value (if that makes sense).

Would a level editor follow a similar rule whereby a 16x16 block would be a 2 dimensional array with 2 entries in each dimension, with it's indexes filled with the pixel array of the 8x8 sprite? Similarly, would a 128x128 chunk be a multi dimensional array formed of 8 entries in each dimension, with each index being the 16x16 array of blocks (which, in turn, is formed of the 8x8 arrays).

I know this is quite a convoluted explanation, I'm not sure how to word it better, I will definitely attempt to clarify it though.

Does the level editor concept sound theoretically correct or am I over-complicating it using so many arrays.

[Dario FF]

It would probably be a better idea to keep the tileset editing outside of the program you're doing. Are you really in need of a limited palette of colors as well?

The common approach to doing something like this is to just use a big tileset bitmap, and the indices on your 2-dimensional array that represent the "map" are used to represent what tile needs to be drawn. For example, from this RPG Maker tileset (48x48 tiles):


The code to calculate the coordinates to crop out of the tileset depending on the "index" of each cell in the 2D Map:

int t=map_data[x][y];
...
int cx, cy;
cx = (t % TILESET_WIDTH) * REAL_TILE_W;
cy = (t / TILESET_WIDTH) * REAL_TILE_H;

TILESET_WIDTH (12 in this example) being the max number of tiles that can fit in the width of this tileset, and REAL_TILE_W and REAL_TILE_H being 48 and 48 in this case. t is the index stored in each your 2D map cells. You can use this to calculate the coordinates of which part of the tileset you should render as a 48x48 tile on this case on the screen. To render them on screen, all you have to do is calculate which are the visible tiles on screen depending on where your camera's placed at, and iterate through the 2D dimensional array in those ranges. There's some more efficient ways to go about this, but this should be very easy to understand.

Notice that most of what I said here would be done in real-time while rendering the map, the only thing that would need to be set up beforehand is just the 2D Dimensional map array with indices, and load the tileset somehow. I assume you're already using some sort of library for this. If not, I recommend looking into either SDL or Allegro 5. Saving and loading the 2D Map as indices to a file should be super simple to do.

You might want to extend this whole 2D Map thing to have different layers as well (RPG Maker uses 3 and it tends to work on most cases). You'll likely need to place tiles that are background only, tiles that are props above the background but not above the player, and tiles that are above everything else.

This post has been edited by Dario FF: 13 February 2014 - 10:15 AM

[Black Squirrel]

C++ is not ideal for level editors - it generally involves extra work for very little gain. My advice is to use a higher level language - the C#, Java, whatever route, so you don't have to waste time on GUI widgets and the like.

And yeah, plenty of good graphics editors out there - no reason to reinvent the wheel. Paint.NET serves me well.


Although if you're not comfortable with C++ you shouldn't be making games - the learning curve is very steep and you'll end up backtracking and redoing things 53958032 times.

[Elektro-Omega]

@DarioFF - That information is quite useful, I will attempt to understand it a little better and properly implement it into my program. The tileset editing did not need to be included in the same project, I'm just passing some ideas back and forth.

@Black Squirrel - I am mainly just attempting to learn C++ and get some projects up and running, I may be a little too ambitious. I'm not planning to create an awesome program to replace anything existing, just looking to learn and attempt to get some projects working. Whilst I am not currently fully confident with C++, I have experience with Python and Java (I was building up to C++) and I feel that I personally need to learn it now as it seems to be the language that the majority of programming jobs require.

I'm going to keep attempting to learn C++ and attempt some projects from the knowledge here. Thank you for your help and if anyone else has any input, they are more than welcome

[MainMemory]

Elektro-Omega, on 13 February 2014 - 08:45 AM, said:

Would a level editor follow a similar rule whereby a 16x16 block would be a 2 dimensional array with 2 entries in each dimension, with it's indexes filled with the pixel array of the 8x8 sprite? Similarly, would a 128x128 chunk be a multi dimensional array formed of 8 entries in each dimension, with each index being the 16x16 array of blocks (which, in turn, is formed of the 8x8 arrays).

The way SonLVL does it is that the blocks and chunks contain a two dimensional array of indexes to the smaller data, along with flags for display and solidity. Then it reads the data from all the blocks to draw the tiles and creates a list of 16x16 bitmaps. Then it does the same for the chunks, using the 16x16 bitmaps it just generated to generate 128x128/256x256 bitmaps, which it can then draw on the level grid.

[Elektro-Omega]

@Main Memory - Oh wow. So rather than constantly recalculating pixel positions within vast amounts of arrays, you simply render to a bitmap and then use the bitmap within an array. It makes sense and I imagine it probably saves a lump of processing time too.

@Dario FF - is there any possibility of asking you to expand your code a little and possibly adding an example. I have looked over it a few times but I still don't seem to understand it. I realise this makes me look incredibly inexperienced with programming but it seems that if I try an example myself and substitute the variables for example figures, the value that is returned seems to be either inaccurate (to what I imagine) or seems to hold no relevance to the grand scheme. I thank you very much for your help and just request a little more clarity

[Dario FF]

Elektro-Omega, on 13 February 2014 - 01:45 PM, said:

is there any possibility of asking you to expand your code a little and possibly adding an example. I have looked over it a few times but I still don't seem to understand it. I realise this makes me look incredibly inexperienced with programming but it seems that if I try an example myself and substitute the variables for example figures, the value that is returned seems to be either inaccurate (to what I imagine) or seems to hold no relevance to the grand scheme. I thank you very much for your help and just request a little more clarity

Right now I'd ignore the tileset and try to make your own little array of loaded bitmaps just so you can get the concept down first of what the map data represents. Try to make it so 0 represents a green tile, and 1 represents a red tile. From there try calculating the screen coordinates as to how it would show up on the screen (x*TILE_WIDTH, y*TILE_HEIGHT) for each element of the map data (Iterate through it). Try drawing those to the screen based on the map data to see if you can get a good visual representation of it.

The code I gave you is just for calculating the coordinates of what part of the tileset you'd need to crop and render to the map, so those would be irrelevant for the simple example you should do first. Once you manage to get something working with the task I said above, you should be able to figure out the purpose of the tileset and why it looks like that fairly quickly. Not using a tileset and going for independent bitmaps that each represent type of cell is an option as well.

There is ways to be more efficient about this, but early optimization will just confuse you more at the learning stage. If you need more help, it's probably better to post your own code.

This post has been edited by Dario FF: 13 February 2014 - 03:49 PM

[.Luke]

As a random person reading this thread, I'm liking Dario's and Main Memory's approaches to a 2D level editor a lot. I've been thinking about making a simple one for my Shantae engine to streamline tile placement and layers, and using a linear series of sections in an INI file to contain object spawn flags, depth, and coordinates, (Which I did for my Sonic engine.) seems primitive in comparison. It also sounds faster for the game and editor to calculate, (?) especially on a high level language like GML. So this encourages me to explore arrays.

[Elektro-Omega]

I've decided I'm going to lay my cards on the table. I usually make vague posts in an attempt to hide my true intentions a large amount of the time, mainly in order to keep secret projects secret, but there is really no need here as it is personal learning for me.

I have finally decided what I want to be. I want to be a tools programmer in the games industry, this could also extend to general application programming outside of the industry.

My above theoretical proposition was for me to try to create a sprite editor and level editor in C++ as a way for me to learn about C++ doing a project that I feel would be very familiar to me, as I feel that I really need to know C++ as it seems to be a standard in the games industry (I know that people say don't learn a language because you feel you need to, do it when you want to, but honestly, this has actually helped me focus more on it). Now Black Squirrel mentioned that C++ is not very good for a level editor, which made me consider using C++ for tools in general.

So I have a supplemental question. I have seen multiple job postings online for tools programmers that require a strong knowledge of C++, would this be because they want tools coded in C++ or because they require a candidate that has knowledge of C++ as an output for some of the tools? I.e. writing a scripting language that goes in as a custom script, get's converted by the application and comes out as C++.

Thank you all for your answers so far and I look forward to more opinions.

[The Taxman]

I can weigh in on this, since I've programmed my fair share of tools and editors across different languages.

C/C++ is a standard in the games industry mainly due to the need for performance, specific memory management, and interfacing with hardware on a low-level. When you consider a lot of the tools and editors for games are actually running a component of the game engine itself (e.g. so you can play test the game immediately as you create content for it) it makes sense to use C++ for production versions.

My own Retro Software Development Kit (RSDK) for the Retro Engine is programmed in C++ and makes use of the Qt framework for UI widgets and form design. C++ is fine for developing tools, provided you work with a good widget library that has some sort of visual editor for GUI design. Anything else will slow you down as you won't see the results of your UI placement until it gets successfully compiled and executed.

If you're starting with zero experience and UI/Editors/Tools programming interests you as a career I'd suggest a few things:

- Start learning C++, but don't expect to use it to create an editor with it for a while, there's a whole lot of fundamental stuff to learn first and you'll want to keep tasks bite sized so you can make tangible progress in your learning.

- Start fiddling around with UI design using a RAD prototyping language like Xojo. Designing a good interface or 'front end' is an artform in itself and by using a simpler language you can focus on creating tools that let the user accomplish the task as best as possible.

[winterhell]

Regardless of the language you choose, you need to practice and learn the building blocks before moving to something big(ger). Just like you can't write a book when you've never written a sentence.
It is of great importance to have programmed the basic games like Pong, Snake, Tetris and a simple 8-bit side-scroller.
Additionally for tools you might want to make a Calculator, Paint, 14-15 puzzle.
Once you've accomplished those you'll have much much clearer vision as to making tools for games.
"But those are stupid, doh, waste of time". An experienced programmer can make all of those in one day. No matter how much time those can take YOU, they'll actually save you time in the long run when you move to a more complicated projects.
Really, if you havent, do those first.

As for the language, pick one and learn it. Its easy to transition from one C-like language to another (C++/Java/C#).
One last piece of advice - if you read on a forum that this language is faster than another- ignore it. There is usually a more to the story than synthetic benchmarks.

[MainMemory]

winterhell, on 18 February 2014 - 02:59 AM, said:

It is of great importance to have programmed the basic games like Pong, Snake, Tetris and a simple 8-bit side-scroller.

I've never made any of those, in fact the only games I have made have been 16-bit platformers. I don't see why you have to have written a game in order to write an editor, but what do I know, I'm not a professional.

[nineko]

I wrote some level editors in the past (for example, Slider, and a level viewer for Pengo (I didn't feel like adding editing capabilities to it since nobody was interested, even if it would have been trivial), not to mention my Sonic 3 & Knuckles Special Stage editor, and probably something else I forgot right now), all in Visual Basic, and I'd be willing to share the source code if anyone is interested, just give me some time to clean them up a bit beforehand, since my programming style is usually uncommented and confusing as hell.

And yes I did program a clone of Columns once :P

[Kroc]

I've been writing editors since 1999. My first was awful. It used an array of image controls, one for each tile, the size of the grid and repositioned the *thousands* of controls every scroll. It was slooow. But -- it worked. And that's the point.

Even if you have no knowledge of editors, go ahead and try. You'll learn a lot just by trying. You'll have to rewrite many times, getting better each time, you'll learn by doing. You can't be perfect on first try, don't ever try so hard to be right the first time that you never get anything finished.

It's far, far better to make something that's crappy but works out there than to have your perfect pet project remain in obscurity for ever.

Sometimes you don't know what you need to do until you try doing it. This is my advice to you.

[nineko]

Well, all my level editors still use an array of Image controls :P