Author Topic: OP2Mapper Update  (Read 50288 times)

Offline BlackBox

  • Administrator
  • Hero Member
  • *****
  • Posts: 3093
OP2Mapper Update
« on: April 11, 2006, 02:54:31 PM »
Well, I've decided that the current mapper's codebase (version 2) has gotten so out of order that it would be really hard to continue working on it, adding more features, etc. (Think bad hair day)

Because of this, I've decided to start a rewrite of the OP2Mapper code. The new mapper will be written in C++. (Currently, the project is about 35-50% C++, 50-65% VB6)

This should have a few (positive) implications for everyone.
  • It should make much of the code a lot simpler, which is good news for me, working on it and adding to it will be much easier.
  • It should be less crash prone. Most of the crashes in the current mapper are related to the interface between the C++ and VB sections of the program.
  • It should be a lot faster. VB is very slow compared to C++ (VB adds a lot of overhead, because it has to rely on the VB runtime for a lot of things (groan)) Lots of this is due to the C++ <--> VB interface.
  • Less bulky. I won't need to distribute those OCX / DLL files around with it (that means it will also install without admin / poweruser privileges, because it doesn't have to register these files)
  • I make no guarantees yet, but it might be crossplatform. Meaning, you might be able to run the mapper on Linux, Mac OS X, or some other system. Of course, I'm going to complete the Win32 version first before I even consider porting it. (Also considering OP2 only runs on Win32, so a mapper that runs on Linux might be sort of useless. Though I do know a couple of you out there run OP2 on WINE, so any native software could prove useful)
I do plan on having some new features, like allowing custom plugins, docking tool windows, and more

The only downside to this, is that I will not be working on version 2 anymore. Any new features will need to wait until version 3. However, I would say that this is long overdue and it will be well worth the wait.

By the way, if you were wondering, don't ask about a projected release date or anything like that. I don't give those out anymore (since I always end up overrunning the deadline, or worse, release something unfinished at that time).

If you have any comments, questions, whatever, post them here.

-- op2hacker

Offline TH300

  • Hero Member
  • *****
  • Posts: 1404
    • http://op3game.net
OP2Mapper Update
« Reply #1 on: April 12, 2006, 02:29:34 AM »
Can't wait for the Linux version, cous my windows install gets messed up more and more. However, despite some rumors I haven't found a way to get op2 fully functional on WINE. If someone has, please contact me.

Rewriting the whole thing in C++ is a very good idea, because of the points you mentioned.

Version 2 is at least useable, so its ok when 3 takes a bit longer.

Offline BlackBox

  • Administrator
  • Hero Member
  • *****
  • Posts: 3093
OP2Mapper Update
« Reply #2 on: April 12, 2006, 02:48:23 PM »
I ran OP2 on WINE once but it ran really slow (so much as to be unplayable).

I think the menus didn't work properly either (had to disable SpiffyDraw)

It might run on WineX / Cedega, I never took the time with that however.

Offline Leviathan

  • Hero Member
  • *****
  • Posts: 4055
OP2Mapper Update
« Reply #3 on: April 13, 2006, 06:53:45 AM »
sweet!

sounds great!

:D

Offline BlackBox

  • Administrator
  • Hero Member
  • *****
  • Posts: 3093
OP2Mapper Update
« Reply #4 on: April 18, 2006, 03:40:04 PM »
Another update:

I have written most of the system interfaces for the mapper. (Generic C++ classes that talk to the rest of the system, for example, to create a window or control, to read a file, and so on). This means that I can start writing the actual code that will make up most of the mapper, I'm done with generic classes that just give me a framework to build the rest of the program upon.

This approach also makes it easy to swap out the classes for building on Linux or another system where the GUI and rest of the system interfaces will be handled differently. If I were to just intermix calls directly to the system all over the main parts of my code, it would be hell later to port to another operating system.

(And yes, I know a few of you out there will ask me why didn't I just use wxWindows, Qt, GTK+ or some other windowing toolkit. Well, I've always felt that these are bloatware, lots of code that would be needed just to do something simple like creating a typical button or scrollbar on the screen. They also would create a lot of extra baggage that would impair performance. Also, it's more stuff I have to learn in order to start the 'real' coding {I would need to read some sort of developer's guide to start using one of these pre made systems}. I understand my system on the other hand and it does what I need it to do, without adding 500+ kb to my program or making it run 3x slower).

Anyway, all of that aside, I'm now getting ready to go with writing the actual meat and bones of the program. This should be pretty straightforward since I can just copy a lot of the code that I use already in the 2.x mapper series (most of the core stuff for 2.x is written in C++ already). I wouldn't expect too much longer before I have something usable ready to roll.

Happy mapping!
-- op2hacker

Offline Eddy-B

  • Hero Member
  • *****
  • Posts: 1186
    • http://www.eddy-b.com
OP2Mapper Update
« Reply #5 on: April 20, 2006, 04:42:14 AM »
Quote
(Currently, the project is about 35-50% C++, 50-65% VB6)
... you poor soul!
What respected programmer codes in VB ???

Anywayz... i hope it will be a good mapper again. We'll probably be integrating mapper & scripter together into each other or something, so a map with predefined units (by the mapper) can be automaticly inserted into the scripter for code generation

 
Rule #1:  Eddy is always right
Rule #2: If you think he's wrong, see rule #1
--------------------

Outpost : Renegades - Eddy-B.com - Electronics Pit[/siz

Offline BlackBox

  • Administrator
  • Hero Member
  • *****
  • Posts: 3093
OP2Mapper Update
« Reply #6 on: April 20, 2006, 08:08:18 AM »
Lol, I used VB since it was easy to implement. VB is really simple to code (but of course you get all those other undesired side effects).

Besides, the first version of the mapper (1.x) was written in VB so I just continued with it (at that time I didn't want to spend the time to convert the entire codebase to C/C++).

Yeah, integrating with the scripter would be great. It would be pretty easy to do as well.

Offline BlackBox

  • Administrator
  • Hero Member
  • *****
  • Posts: 3093
OP2Mapper Update
« Reply #7 on: April 22, 2006, 09:50:08 AM »
Another update:

I've got the main window working with MDI support. You can see a screenshot here:


Also, I'd like to note the current EXE size. It's only 36 kb. (And 32kb of that is the C runtime, so 4kb is from my code) Had I used some other window system (like wxWindows or MFC) it would have made the final application size much larger.
« Last Edit: April 22, 2006, 09:50:34 AM by op2hacker »

Offline BlackBox

  • Administrator
  • Hero Member
  • *****
  • Posts: 3093
OP2Mapper Update
« Reply #8 on: May 11, 2006, 05:11:31 PM »
More updates:

- The mapper is now fully capable of loading and displaying a map. (This also means that the tileset loading code and the VOL loading code is complete, since the tilesets are loaded from maps.vol)

The drawing speed is about 2 or 3 times faster than it was in version 2.x of the mapper. (And I have plans to make it even faster yet. Currently it redraws the whole screen when the user scrolls the window, however I plan to add code that will only redraw the portions of the screen that have actually changed during scrolling). I've started 2.x to compare and the whole application seems sluggish. (There is also no delay when starting the 3.x version, whereas 2.x has a splash screen to tell you that the mapper is loading)

The memory usage is also a lot lower than in 2.x. In the screenshot (below) with 3 maps open, the mapper is using about 10 MB of memory. 2.x probably used double that when 3 maps were open. (This is also with debug mode turned on. In the release version memory usage should be lighter yet). However, this is with just the drawing features. Once more features are added memory usage will probably be a bit more.

Here's a screenshot to whet your interest in the new mapper. It also proves that I am making headway with a rewrite of the mapper in C++.


As for other features I plan 'above and beyond' 2.x:

- I plan to have real 'plugin' support. The mapper engine is very modular, making it very easy to add new features. My plans for plugin support are a C-style interface implemented in an external DLL. A lot of programming languages can produce C-style interface code (extern "C" functions), so you could use a language other than C / C++ to write an extension in. The plugin layer may even allow you to add your own editing tools which can appear in the mapper (this also keeps the main engine free of 'extra' code, for example automatic map generator tools, something we will probably see soon. This could be implemented in a DLL as an extension to the mapper)

- Another planned feature are docking tool windows, minimaps, and toolbars. This way, you could dock the editing tools on the sides of the window, or have them as a floating window if you prefer. The code to implement these doesn't look too difficult to write, so I plan on doing this (if not in the first 3.x release, early on).

- I plan for integration with Eddy-B's Scripter, and perhaps eventually direct compilation-to-DLL. This way you could place units using the mapper, let it generate a Scripter script, and then compile a DLL from the Scripter script.

- Better support for XP styles. (Currently, the toolbar looks a bit ugly in the screenshot. However, once I add a manifest to be compiled into the program, it should start looking better).

Offline Leviathan

  • Hero Member
  • *****
  • Posts: 4055
OP2Mapper Update
« Reply #9 on: May 12, 2006, 06:43:35 AM »
Great work!

Everything sounds great :)

Offline Sirbomber

  • Hero Member
  • *****
  • Posts: 3237
OP2Mapper Update
« Reply #10 on: May 15, 2006, 04:41:26 PM »
Yaaaay Hacker!
Or something like that...

Is it safe to assume the new new mapper won't explode as much as the old new mapper?
"As usual, colonist opinion is split between those who think the plague is a good idea, and those who are dying from it." - Outpost Evening Star

Outpost 2 Coding 101 Tutorials

Offline BlackBox

  • Administrator
  • Hero Member
  • *****
  • Posts: 3093
OP2Mapper Update
« Reply #11 on: May 15, 2006, 05:13:46 PM »
Hopefully so, yes.

The first version or two might be peppered with bugs though.

Offline Arklon

  • Administrator
  • Hero Member
  • *****
  • Posts: 1267
OP2Mapper Update
« Reply #12 on: May 15, 2006, 07:08:46 PM »
Is this version gonna have my generate-map-from-image feature I requested? Will it also allow me (and only me) to dominate the world?
« Last Edit: May 15, 2006, 07:11:47 PM by Arklon »

Offline CK9

  • Administrator
  • Hero Member
  • *****
  • Posts: 6226
    • http://www.outpost2.net/~ck9
OP2Mapper Update
« Reply #13 on: May 15, 2006, 07:42:17 PM »
Will it have a grid option?  Grids make things a lot easier, :heh:
CK9 in outpost
Iamck in runescape (yes, I still play...sometimes...)
srentiln in minecraft (I like legos, and I like computer games...it was only a matter of time...) and youtube...
xdarkinsidex on deviantart

yup, I have too many screen names

Offline BlackBox

  • Administrator
  • Hero Member
  • *****
  • Posts: 3093
OP2Mapper Update
« Reply #14 on: May 15, 2006, 08:30:09 PM »
There will be a grid.. I think the current version already has that.

Quote
Is this version gonna have my generate-map-from-image feature I requested? Will it also allow me (and only me) to dominate the world?

Well, it can.. You'll be welcome to code a plugin for the mapper that will allow you to do that. :P

Offline BlackBox

  • Administrator
  • Hero Member
  • *****
  • Posts: 3093
OP2Mapper Update
« Reply #15 on: June 07, 2006, 03:05:23 PM »
Another update:

Finally got the single-tile placement tool functions in. This time there is no floating palette, it's built into the left side of the window. There is a divider which you can use to resize the pane.



Fixed some various bugs which have been cropping up, for example divide by zero errors.

Also, I inserted a handler that will give me useful information about the state of the program when it crashes (which will allow me to actually find and fix the bug) rather than just showing a window with no useful info at all.

I also added an XP manifest so the toolbars and such look nicer.

Offline Leviathan

  • Hero Member
  • *****
  • Posts: 4055
OP2Mapper Update
« Reply #16 on: June 09, 2006, 08:56:05 AM »
Great work op2hacker :D

Offline dm-horus

  • Banned
  • Hero Member
  • *****
  • Posts: 1042
OP2Mapper Update
« Reply #17 on: June 16, 2006, 04:10:19 AM »
When can we start beta testing? Im anxious to start working with it. Also, how difficult will it be to make plugins? Ive been manipulating a number of plugins for other apps (in C++) that generate terrain by heightmaps. Id like to make something similar for the mapper. Maybe make up a short SDK for the mapper or at least provide links to resources that would help.

Offline BlackBox

  • Administrator
  • Hero Member
  • *****
  • Posts: 3093
OP2Mapper Update
« Reply #18 on: June 16, 2006, 08:03:34 AM »
Well as for beta testing it probably won't be for a while yet. Yes, the mapper can load files (including those from a VOL) and it can place tiles on the map, but that's purely all it can do. (It can't save maps yet. It can't load standard BMP tilesets yet, only the sierra format. It doesn't have undo, etc)

So I want to make it a little bit more complete before I release it as even an 'alpha'.

As for plugins, I'm pretty sure about how these will work (no API docs or headers yet, sorry since I haven't gotten there yet).

The plugins will use a C interface (as opposed to C++) since this is much more compatible. (If I used a C++ interface you would be locked into using Microsoft C++ and nothing else). On the other hand, C interface functions can be called from many languages so you could use your favorite programming language to develop them.

As for the functions of the plugins, I can see support for at least two types of plugins. The first, simpler, type is one that adds a menu item or toolbar button. When clicked the plugin's code is called and allowed to manipulate the open file.

The second type would be a plugin that creates a new tool that can be loaded on the left side of the screen (like the tile picker). This one will be a bit more complex to write since it will be intercepting things such as drawing and mouse events on the map window, and would need to supply its own window procedure (so it knows when the user clicks on it / resizes it / etc). It will also have to handle loading and saving of custom data if it modifies things that aren't built into the map format already (e.g. units or some other metadata).

The plugins will be able to access data like the map data itself, the drawing calls to paint the map and the tool window, so on -- so they won't be crippled compared to the internal classes (Well, with a few exceptions -- for example most of the interface to the global application object won't be accessible. A plugin would never need access to this code and it would introduce application instability / bugs / memory leaks if the plugin called this code).

As for the API itself, I can give you a sample although it is by no means complete. (Read: the code I'm about to write isn't guaranteed to work when I do actually release a plugin SDK).

C++ classes inside the program will probably be represented as opaque pointers or handles to the real class. Functions will allow you to manipulate the classes thru the pointers.

My code will represent a simple menu plugin, nothing special yet. (Since I don't even know how it's going to work yet, I haven't written code for plugins).
Code: [Select]
// called when the plugin is loaded
bool __stdcall plugin_init()
{
   // register a menu item in the mapper.
   // obtain a handle to the application object.
   MHApp *pApp = Mapper_GetAppObject();

   // register the menu so we can get called back when the user activates it.
   MApp_RegisterMenuHandler(pApp, "Test Plugin", plugin_testmenu);

   // destroy the app handle.
   Mapper_DeleteHandle(pApp);

   return true; // init succeeded
}

// called when the plugin is supposed to clean up
void __stdcall plugin_cleanup()
{
   // do nothing. I'll make it easy on you guys and not require you to unregister the menu items or do other annoying things most plugin toolkits force you to do. I'm sure I can keep track of all that stuff within the app and unregister them myself.
}

// our custom menu handler
bool __stdcall plugin_testmenu(MHMapWindow *curMap)
{
   // let's set (20,20) on the map to the blue tile (index 0).
   // first we need to obtain the map file object from the window object.
   MHMapFile *pMapFile = MMapWindow_GetMap(curMap);

   // now we can set the tile. first we have to get the tile object, change the field, and then set it back.
   MapTile t = MMapFile_GetTile(pMapFile, 20, 20);
   t.tileIndex = 0;
   MMapFile_SetTile(pMapFile, 20, 20, t);

   // done, destroy the handle we created
   Mapper_DeleteHandle(pMapFile);
   // no need to destroy the map window instance passed as a parameter, the mapper will take care of that.

   return true; // success, keep the plugin loaded
}

And that's about it. In fact, I might make the destruction of the handles unnecessary. (The handle will be nothing more than a pointer to the internal class). Thus the pointer can be thrown away so long as it doesn't point to newly allocated data. (which it won't if you're referencing the already-existing map class and such).

Sound good?

Offline dm-horus

  • Banned
  • Hero Member
  • *****
  • Posts: 1042
OP2Mapper Update
« Reply #19 on: June 16, 2006, 11:40:31 PM »
It sounds like youre moving along quickly. What time frame do you think it has? I dont mean to push you along, Im just curious. Is there anything I can help with? Im not much of a programmer tho....

Offline BlackBox

  • Administrator
  • Hero Member
  • *****
  • Posts: 3093
OP2Mapper Update
« Reply #20 on: June 25, 2006, 06:18:43 PM »
Time frame? I don't want to give one since that has gotten me before (I'm a bad procrastinator).

If you want to help, I need icons for things like the main window, map icons, maybe toolbar icons if you're interested. A splash screen would be nice if you wanted to make one.

Offline BlackBox

  • Administrator
  • Hero Member
  • *****
  • Posts: 3093
OP2Mapper Update
« Reply #21 on: August 20, 2006, 06:03:38 PM »
Okay, an update.

Maybe 'bad news' if you want to call it that.

I was looking at the Mapper3 codebase and thought, blargh, what a mess! The way ithe drawing was implemented was really slow, since I was using all sorts of code to try to keep the core of the program compatible with platforms other than Windows.

At that point I realized, "There's really no point to having a crossplatform map editor when the game it creates maps for only runs on Windows."
I figured, if a user can run OP2 (even on WINE or whatever) the mapper should be just as easy to run on WINE as well.

So I restarted on OP2Mapper 3. This should result in a lot of decluttering of the code (also I should be able to reach much higher speeds than I was before).

Also, I've probably talked about this already, but there will be very few (if any) special or fancy UI effects like the menus and toolbars of OP2Mapper 2, considering that OP2Mapper 2 won't run on Windows 95 without a common control update (and even then I hear that it's kinda iffy from those of you who have tried to run it on 95).

I plan on making even the toolbar completely optional. This way it should guarantee that the program will run on minimal environments (e.g. Win95, as well as WINE).

I also took a couple ideas for handling the windowing through code from OP2 (not that the internal design of the game really impresses me, but I did see one thing that I thought was pretty nice). For example, my code supports 'message filters' like OP2 does with its internal IWnd window objects. This way, the editing tools themselves will be able to easily 'plug in' and catch all events from the map window itself, thus giving a high degree of flexibility.

I pushed it farther than OP2's developers did, since my code will catch any type of message (not just mouse and keyboard events).

I also plan on using much faster drawing code (the 'old' Mapper3 redrew the entire window whenever it was scrolled, instead of just caching the existing data on the screen and drawing only the new parts on screen). This should lead to a huge performance gain when drawing.

I also used vectors and lists from the C++ STL (not sure why really, when I could have written my own 'dynamic array' and linked list implementations). Needless to say I am not using the STL anymore and I plan to just use my own linked lists / arrays. This will make the code a lot faster and decrease memory usage.

Anyway, now that I've rewritten a lot of OP2Mapper 3, expect me to be able to push forward faster with it than I could before.

Offline TH300

  • Hero Member
  • *****
  • Posts: 1404
    • http://op3game.net
OP2Mapper Update
« Reply #22 on: August 21, 2006, 08:23:15 AM »
Sounds good. And yea - don't make a Linux version just for me. WINE runs many windows programs already, it will run the mapper too.

One thing though: use other drawing code than in mapper2, cous that does definitely not work.

Offline Leviathan

  • Hero Member
  • *****
  • Posts: 4055
OP2Mapper Update
« Reply #23 on: August 21, 2006, 09:22:29 AM »
Great work :)

Looking forward to it.

Offline BlackBox

  • Administrator
  • Hero Member
  • *****
  • Posts: 3093
OP2Mapper Update
« Reply #24 on: August 27, 2006, 05:46:49 PM »
Okay, here's a pic of what I've got so far for the mapper:



This version is a LOT faster than the previous version. I've clocked the drawing code and it takes <15ms to redraw the map.

The map 'tools' on the left are also a lot better written (in the first version of mapper3 I had to basically hack across the engine to be able to do certain things (partly because I wanted to keep it platform-independent), making it a lot less of a pain in the butt for me.

On a smaller note, I'm also using custom cursors (The tile picker is a pencil icon).