KernelKnowledge12

As most of you know, a BoA Editor remake is in the works. JV was contacted for his thoughts on this. In the interests of gaining support for this project, here was his reply: Quote: My intention with making the source code public was to give people the information they needed to homegrow editors of their own. If people strip that source code and rebuild it so much that only the data structures remain in place, well, that still seems within the spirit of the thing. In other words, I have no intention of chasing with lawyers people who work hard to make a better version of my (admittedly imperfect) editor. When you have something usable, please let me know so we can link to it. Or, if it's cool enough, host it. - Jeff Vogel

Quote: Originally written by Notus: I'd like to get the project up first; we can then go looking for more participants. Right now we need to get organized. I pm'd Isaac, too, so when he replies I'll start the registration. If he doesn't by tomorrow, I'll have to send it in for registration (it takes SourceForge around two business days to review a proposal).

Quote: Originally written by Notus: OpenGL As for the OpenGL, I feel it's overkill. a) 2D graphic is plain. Isaac has already established 3D graphic algorithm. Do we need any other graphic method to display the map data? BoA accepts only BMP on Windows and PICT on Mac. Why the editor alone should accept another graphic data format? c) OpenGL only replaces drawing layer. It corresponds 20-30% of the current graphic code. Most of the code is dedicated to modeling. d) It's too heavy for low-end machine. Some users have complaint it's slow even in current 2D/3D editor. The reason I suggested OpenGL is because the code would be so much simpler, but if what you say is true we should probably go the original route. Quote: Scripting We cannot expand AvernumScript. It's already fixed except little improvement in future. Script parser is used to make our editor scriptable. Hence we should consider which script language the editor would be adapted to. I didn't mean to suggest expanding AvernumScript itself. I meant that we could put in a parser for AvernumScript and maybe turn our editor into a script editor also. Quote: Data format of Mac and Windows The difference is only next two point. a) "signature" Mac: 0x61d70721 Win: 0xc73d0235 Endian of the multi-byte data. It's possible to handle it on a stand-alone converter. I'm not sure you understand me, so I'll try to be a little clearer. (If you do understand me, then I'm sorry for repeating myself.) The .bas files are all stored in Big-Endian. To test this, I downloaded (from spiderwebsoftware.com) a windows scenario and mac scenario and compared the .bas files and they were completely identical. Here is a quote from the editor's commenting (you've probably seen this): Quote: Bl A Fileio.c: Code: // Note about windows and Mac file formats.// Windows and Mac write shirt (2 byte) integers differently. One does// high byte first, one does low byte first. In the Blades of Exile days, there// were two scenario formats, one Mac and one Windows, and the first four bytes// in a scenario file identified which was which.// Of course, the game was savvy enough to tell which sort of scenario it was loading and// adjust the value accordingly.// But this was stupid. In BoA, it is done a much smarter way. Every file is// written in Mac format, and only the Windows version has to flip the formats.// Just FYI. If your already know this, then I'm not sure I understand why we should create a stand-alone converter. This would just require windows users to edit their scenario and convert to mac format before submitting. Doesn't make sense to me, then again I could be misinterpreting your idea. EDIT: Isaac, Notus, check your PMs.

Quote: Originally written by Isaac: While the comments may say that, my understanding of the code is contradictory to that. In load_campaign() in the Mac editor, it checks whether it is a "windows scenario" and if so, ports it, and when saving, if it is a "windows scenario", ports it again before saving. I believe the type of a scenario, Windows or Mac, is determined upon creation. To check, I downloaded the mac version of Babysitting, and compared it to the windows version. The .bas files were completely identical. Also when I wrote my editor, I remember loading the .bas file (windows) without flipping, and getting a very screwy error. I believe the Editor does the check for endianness just in case it encounters something that may need to be flipped. Quote: Yes, extensibility is key. We want to get it usable quickly without hindering the addition of more advanced features. This is the main reason why I would favor focusing on graphics later. We need to get a generic system of editing the files first, then using that code to create views for the data. For OpenGL, we shouldn't need anything other than GLUT. Tile rendering in OpenGL is incredibly simple. Also I use the term OpenGL to cover the actual OpenGL library and lower-level libraries such as GLUT, GLu32 and GLaux as one entitity. My PICT reference meant basically that one of these lower-level libraries must have functions for loading PICTs, as they do for BMPs.

Quote: Originally written by Notus: a) As wxBitmap and wxDC doesn't support PICT, we need to make another wrapper class over these class. This is a serious problem. The code shouldn't be created as of now, but we should probably plan out how these wrappers will be coded. Quote: It can't enlarge or reduce bitmaps, this function should be implemented. I'm beginning to think we should use OpenGL for the bulk of image handling. Since it's cross-platform it might support PICT files, eliminating the first problem without any coding neccessary. If not, the work will at least be less than with wxWidgets alone. If we can find a good library, using OpenGL will significantly speed up our development and program. Quote: Also wxRect::Inside() returns true when given point is on whole boundary. PtInRect() (in both platform) returns true when given point hits top or left boundary, but it returns false when it hits bottom or right boundary. This could be a bug in the original BoA Source code. If not I don't see how it would be a problem, especially if we write a new wxRect class. Quote: Most of published and under-development scenarios use custom graphics for floor, terrain, creatures, items and introduction pictures. These graphics needs conversion to be ported to another platform. This conversion involves data format, file format and file name (resource ID) changes. It can be automated by a custom utility. If this utility also supports endian conversion on data (.bas) file, there is no need to implement the "flip blah" function to the editor. The resource conversion utility is a good idea, but there is only one type of .bas file (at least according to the Jeff's comments.) This file type is stored in Big-Endian. The windows editor (and I'm assuming the windows BoA) loads the .bas file and converts the Big-Endian to Little-Endian through the flip functions. They are needed in the windows editor, and there is no way (that I can see) to take them out, although they can be made a little cleaner (I made these functions as I was learning how to use Phoenix, so they're done in Phoenix style): Quote: Actually making GUI will be easy work with wxWidget. Only Tool/Item Palettes needs a little effort. Glad to hear it. Quote: Oh, I forgot about sound. wxWidget doesn't support 'snd ' resource. Isaac's right, we don't neccessarily need sound. And we could probably do it in another type of file, like wav files. Quote: Mac support on wxWidget (wxMac) is still behind Win and Linux support, as they said in their Web site. However, wxWidget seems better than other cross-platform frameworks among non-commercials. I think this selection is proper at this moment. If you know any other libraries, please mention them. We may not need them for this project, but I'd still like to know of them. Quote: Boost.Spirit seems to fit to the editor as a script parser. Anyhow, the script parser part of the current code is well packaged. It is surely better to rewrite it for maintenance, but it's not urgent. You're right, it's not a priority, but I think I might be able to do it pretty quickly. Also we might want to expand it so we can add on a script editor to the actual editor. Quote: Phoenix is certainly some framework, but it isn't application framework. Currently It doesn't have functions to support GUI. Just thought I'd mention it. EDIT: I e-mailed JV concerning the liscensing issues.

The first one is possible, but the rearranging part would most likely be a low priority. Same with the time-control. You'd have to ask Isaac about the other issue.

Quote: Originally written by Dahak: 1) Tint the side bar icons just as they are tinted in 3D mode. Quote: * Small pictures of the items and creatures next to their names in the menus. Finding these things would be much easier with images than with just text. If a remake comes into the works the entire look/feel will most likely change. The other three suggesstions will definitely be possible.

For liscensing issues, the GPL should be more than adequate, although before we start any coding, or even start a project on sourceforge, we should ask Jeff for express permission. Before this though, we should probably find out exactly how many people are willing to help. Actually we should decide on whether we should create a sourceforge project right now. I can create the project if neccessary, although I'm sure there are several people here that are also registered with SourceForge. On a side note, I just found out about this library a week ago, and IMHO it's brilliant: Phoenix (It is not yet part of the Boost distribution, but it probably will be in the future.) EDIT: Oh and about the C++/C thing, if we can write the code to completely separate the procedural part from the OO part, we can avoid the problem of confused C people. Also we can set a requirement for a certain amount of commenting/documentation. EDIT: I looked over the BoA Editor liscense, and would a remake of the Editor constitute a "Contribution"? Also, why does the last part, entitled "YOU MAY NOT:" seem to contradict the other parts?

Quote: Originally written by Notus: I agree to remake it from scratch and use a cross-platform framework. I don't know so much about cross-platform frameworks, but I suppose it'll provide so-called application framework, like MacApp, PowerPlant and MFC. It'll reduce our labor on the event dispatch, mouse/keyboard handling, menu, dialog and components on the main window such as tool/item palettes. Do you have any recommendation on a cross-platform framework? See how you like wxWidgets . It's extremely powerful and over 12 years in the making. Quote: As for the file I/O, "port", endian conversion on the datafork is incomplete in most case. It doesn't care about resources. A standalone utility for cross-platform data converter is desirable. Resource fork of Mac .cmg file will be temporally converted to .rsrc (Resource Manager-style resources) with StuffIt expander when a .sit file is expanded on Windows. This means we can make a data converter from Mac to Win using .sit file even on Windows. Not too sure why this would be needed. Please elaborate. Quote: In most of data classes, especially data saved in .bas file (scenario_data_type, outdoor_record_type, town_record_type, big_tr_type, ave_tr_type, tiny_tr_type) unsigned char is used. This reduces performance on the execution speed. Nowadays, PC has plenty of RAM. Saving a several hundred KByte memory is nonsense. These data types should be the natural size (int) for CPU. Even if we changes the data size, we only need dedicated serializing method for file I/O. Then we can freely add members to these classes. For example, adding two member variable, type and size, big_tr_type, ave_tr_type and tiny_tr_type are represented by one class. This will encapslate so many conditional branch on the source code. First I think we see if we can get inheritance on our side, but, yes, there are several ways the classes in the original source code can be bettered. Quote: On graphic routines, the problem is more serious. Even the basic data types are different on PC and Mac. Not only the size of data but the order of members. Code: Windows GDI defined in global.h Mac QuickDraw typedef struct { typedef struct { struct Point { LONG x; char x; short v; LONG y; char y; short h; } POINT, *PPOINT; } location; }; typedef struct _RECT { typedef struct { struct Rect { LONG left; short top; short top; LONG top; short left; short left; LONG right; short bottom; short bottom; LONG bottom; short right; short right; } RECT, *PRECT; } macRECT; }; a) Use only common data types defined explicitly on the source code in most of routine, except a several wrapper routines for porting. Do not use simple utility routines provided by the operating system, such as InflateRect(), PtInRect(). Make a compatible one on the source code. We should ignore most of the graphic routines ( except Isaac's code ) as the use of a framework will drastically change the way the underlying calls will work. The graphics code should wait for a while. On another note, since this is an editor, maybe we should split the entire application into two smaller projects: the "kernel", and gui. The "kernel" will deal with just basic totally cross-platform operations (such as porting, loading files, and editing the files). The gui will be mostly cross-platform, but will have to use different graphic loading code due to the different resource files inherent in BoA. Also the scripting engine used in the editor needs to be replaced. Fortunately, Boost.Spirit will make this incredibly easy. (We should be able to expand this to all types of scripts also.) All of these are suggestions; comments are welcome.

The code I created was lost in a computer foul up, and I wasn't too concerned for how clean the code was when I created it. (The code was still much cleaner than the original.) Also the code was not in the least bit cross-platform (it used MFC and DirectX). I do, however, remember what I did and since I stopped working on it I've had several ideas. Either way, it should first be decided whether the code should be reorganized, or restarted. I vote for the latter as reoganizing it would just amount to more than double the work. Remaking it would also make it easier to update, as it would be a our code.

Well, I'd like to help, although I'm currently working on quite a few other things, so I'm not sure how much actual time I may be able to commit.

Might I suggest moving this project to SourceForge.net . This would help get the entire community involved in development, and there are quite a few programmer's here with the capacity to contribute.

Quote: Originally written by Arenax: Are you guys actively trying to get me not to do this? If you don't want any help/suggestions, than make your program any way you see fit and stop wasting people's time.

Quote: Originally written by Arenax: And I'm sure you just glossed over that I didn't care to spend weeks doing it, but hey. If you're not going to do it well, don't do it.

Quote: Originally written by Dastal: KernelKnowledge, if it's such an easy process, and you have already figured it out, you should have no problem quickly converting the Mac 3D BoA editor to Windows. I never said it was easy. I screwed around with the original editor for a month over the summer and started working on a 3D editor using MFC/DirectX. (Before I started thinking cross-platform.) After a little I got an idea for a project that could potentially make me some money, so I dumped the editor.

Quote: Originally written by Khothie: Actually, I think the parts of the editor dealing with the file format are the nastiest and most arcane parts, with the possible exception of the script parsing. The saving and loading functions (for scenario files) are very simple, and its pretty easy to see how the files are stored: Scenario Info Struct (Can't remember the real name) Outdoor Sections Towns (the size of each town differs based on the stored town size) The editor's scripting functions are total and utter crap, but a more extensive one isn't neccessarily needed. Quote: Originally written by Khothie: There is some weird magic for dealing with endian-ness that I don't want to touch with a bargepole, for a start. I think you're talking about the flipShort function. All it does is switch the two bytes contained in the given short. The following function would probably be better, if somewhat slower: template< class _Ty > _Ty& flipData( _Ty& d)

The scenario-saving parts are extremely simple. Only the several simple classes (located I believe in global.h) in Jeff's code need to be copied and screwed with. There is a scripting engine ( technically an engine) that loads the editor's global data (from the corescendata.txt files) that should not be copied. A quick lexer and parser should be created using the Script Checking program's grammar files, with FLEX++ and Bison++. The Bison++ input file should be tweaked to actually edit a ScenData object. The graphical interface should use OpenGL, if it's meant to be fast. (An easier alternative, however, would be just to use a toolkit's graphical classes.) Using OpenGL would allow for shaders and therefore more flexible tinting code, but would take much longer to implement.

It would be rather difficult. Fortunately there are several libraries that would make it easier (wxWidgets, Boost, WideStudio, the famous STL and its many add-ons). Also much of file handling/scripting code can be copied and tweaked to favor a more object oriented approach.

Quote: Originally written by Walker, Texas Corpse: Why not use a cross-platform toolkit like wxWidgets that works in a decent language? Then you wouldn't have to port anything. (Don't make your software suck just to port it to the Mac.) People are starting to catch on.

Quote: Originally written by Mortimer: Possibly because I don't believe he has a PC available to test it on. Hence the term, cross-platform library. If he uses one and it works on a Mac, it should work on any platform the library supports. He'd just have to get it to a PC to build the executable, which shouldn't be too hard considering the amount of programmers in this community. Quote: Originally written by Mortimer: Arenax's current projects sound far more interesting to me as well, I haven't had much problem with the 2D editor, a 3D one is just a nice want rather then a need. A need would be an editor (3D or not) with plugin capabilities for the various smaller programs people are working on. Quote: Originally written by Arenax: Because Jeff's code, to be very frank, sucks. Graphics are handled entirely differently and the mechanism for putting them on the screen is weird on a Mac. Of course it sucks. It's complicated and entirely too messy, but getting the gist of it isn't too hard, if you look at the right parts. Ignore the Mac graphic's code; it shouldn't matter. Look at how the program itself loads, and then the format of the scenario files.

Why not just get the maker of the Mac 3D Editor to port his own/Jeff's code using a free cross-platform class library?

Quote: Originally written by +t: At last something more valuable, than senseless talks about law(s)! What people do on their own time (stupid, pointless and illegal or otherwise) is none of my concern. Quote: Originally written by +t: But well i'll not use that library. I reckon that what I'll gain from it will be much less that I'll spend... The wxWidgets framework is free.

Quote: Originally written by +t: 2. Using that specification, I'll make my own BoA Editor for Windows. If you do plan on making your own BoA Editor, please consider using the wxWidgets (fromerly wxWindows) framework to power your application, as it is an incredibly comprehensive, cross platform UI.

You should also make sure the icon adjust variable is set to the correct value.

I added an extra semicolon to the "clear" statement at the beginning of scenario data script, and got about thousands of "structural errors" on almost every line. This has to be an error. I am using the Windows version.