KernelKnowledge12

Which editor are you using, what version, and what platform?

Quote: Originally written by Notus: Even the clip file should include custom graphics, custom terrain script, custom item script, etc. Thumbnail and creator's name, comment also are desirable. Graphics need to be converted according to the platform. If we do this, maybe we should create a sort of package manager, similar to that featured in Dev-C++. Quote: As these basic data have a common character that is loaded from and saved to .bas file, we will probably make a superclass on these classes to handle streaming on them. If we make a superclass, these data objects cannot be declared as global (static) variables because of inheritance. They should be generated by new operator dynamically. This means we must access them through pointers. The initialization of static variables occurs on early phase of loading of an execute file. But in that phase, inheritance chain and RTTI are not established yet. Thus a static object that has inheritance aren't initialized properly. Would implementing the wxWidget's App class speed thinks up to any extent? (The globals would be encapsulated in the app class.) Quote: Graphic system buffer Graphic system buffer holds all of basic data to draw current view (window). If a town is the top window, it holds such as, scenario.start_in_what_town maybe 40kbytes or so. As I recall, the code loads images into memory temporarily to draw them. It then releases them. Would it speed things up to load these files at runtime, and hold these (by pointers or other means) in the definition types (creature_record_type, item_record_type, etc.)? Other than this, should we get started on the buffer class? Quote: I found wxglade as a candidate but not examined so much yet. I looked at it. Its a standalone metaprogram that is capable of generating C++ code based on a form design. It should work fine.

Quote: Originally written by Notus: As the next step of Copy/Paste, I considered "clip file". "Clip file" is a file data whose content is selected on the Copy procedure. After copying a part of the edit screen, save the copied data to "clip file" instead of pasting it. This "clip file" is used to exchange "landscape parts". These small landscape parts are uploaded to a sever like the louvre, and everyone can use it by the courtesy of the original creator. Well, this is just brilliant! I never even considered this! Perhaps we can extend this (if we make this) to make the editor behave as a link to a database full of maps/custom graphics/scripts etc. Quote: Originally written by Notus: Floating paste is realized on the graphic system buffer. a) We need a buffer between the graphic system and the actual objects to maintain the scroll (redraw) speed. During the development of Win 3D editor, I tried to convert global (static) definition of the basic data to pointer expression of the objects Is this really neccessary with the use of inheritance? Can't we use inheritance without changing the global variables to pointers, or am I missing something? Quote: Originally written by Notus: Thus we need a data buffer between data objects and the graphic system. I am a little confused by this notion. What exactly would the buffer do? Quote: From these facts, I conclude there is no padding within the recorded data. And we can safely use sizeof operator on these structures as the recorded data size on these compilers (IDE). But I don't recommend to use sizeof operator. Use above constant instead. Constant is compiler independent. I think I may be able to automate the constant size, using my class_base class. I developed it enough so that it automatically creates the default constructor, copy constructor, get/set functions, assignment operator and i/o routines given a class' "schematic". (The schematic is just a type sequence such as boost::vector< int, int, bool ... >.) I know this does not have too much to do with the application design, but it will make development much faster and easier. Look at the boa_primitives.hpp file in the CVS to see how its implemented. I'll put a static const size_t that tells the size of class that ignores any evident inheritance. Note: I was thinking about wxDev-Cpp, and I'm not too sure we should use it, since: a) It is based off of Dev-C++, not an actual plugin, although it says it is. It uses a slightly older version of Dev-C++. c) We don't really need it, since we should be able to do the code itself. Do you have any opinions on this matter?

Quote: Originally written by Notus: The "floating" state is needed, but by using Jeff's code this could get complicated. We should think of height in pasting later. Putting paste functions that copy just the terrain should be our first priority. Then we should try and put a paste function that copies the height. What we can do afterwards is place a "Paste Special" menu item to handle any other type of pasting. Quote: Copy/Paste function may bring another copyright problem, but the community will reach to some consensus. This'll only make it easier to violate copyright. Seeing as how the community seems ready to rip violaters limb from limb, I doubt the copy/paste function will really affect the desire to copy someone else's work. If anyone has any comments on this please post them. EDIT: Concerning the "floating" terrain, perahaps we should implement a layering system. This wouldn't have to much to do with actual terrain design, except that people could work on several pieces of terrain without having to actually change the terrain.

Quote: Originally written by Notus: Thanks, I got a hard disk and will repair my Mac this evening. Maybe I can use E-mail tomorrow. I received your E-mail. Mail log was on the data partition, and was salvaged successfully. Even if I didn't, mail server must hold it. Awesome. Concerning the idea of the copy/paste idea, I think we should just go ahead with the square selection. We can improve it later (My emails contain a suggestion for that). Will this be added to the current 3D Editor (Dev-C++ Project)? Also if you don't know by now, Isaac has joined the discussions concerning the planning of the application. He also has suggestions on the improvement of selection.

Quote: Originally written by Notus: KernelKnowledge12, Isaac Hard disk crashed on my Mac. Salvaged data partition but System partition is totally damaged. I must get another Hard disk. I cannot send/receive E-mail for a few days. Sorry for your inconvenience. Sorry to hear that . Can you still PM? Also, did you get the last two emails I sent you? If not, I can send them to you through PM, or just post them on the board.

Quote: Originally written by Isaac: I found a cross-platform C++ library that uses OpenGL: http://plib.sourceforge.net/ . I'm not sure how good it would be to use, but the abilities that it claims to have seem good. Looks okay. Not as powerfull as others I've seen, but much easier to use. Here are some other libraries. As for using OpenGL in the Remake, its pretty much been decided that this would complicate matters. This does not mean that the idea is dead as wxWidgets does have support for OpenGL. Isaac - Check your PMs.

Was messing around, and I think I found a bug. I was editing a town and changed of the terrain of the very edge of the town. Instead of drawing the new terrain in just that one spot, it draws the terrain in the spot, and in a line that proceeds from that spot and goes out of the town. Not a serious bug, but a bug nonetheless. EDIT: I checked, and this happens in all modes. May not be a bug. EDIT 3: I checked in the game. Its not a bug. Notus - Do you get emails from the SourceForge Bug Tracking System? Quote: (at least) one more problem, though. scrolling in the normal 3d-mode is fine (the speed, i mean), but it's way too fast on the 'in-game-3d-mode'. that mode is almost useless as of now. Worked fine for me, so others might not experience this problem. Would a timer slow it in all cases? EDIT 2: I uploaded the Dev-C++ version of the project into a module called DevBoA3DEditor. The warnings issued by MingW are gone (commented out in case their removal results in problems).

Oops, guess I was too lazy to look through the code .

Notus, I just recently downloaded the code for this particular project and tried to compile it using Dev-C++. The compiler reported an incomplete list of warnings that numbered in the dozens. If you are not already aware of this, I thought I'd tell you, as these could be the reasons for certain bugs. I'll go ahead and fix as many as I can, but I won't upload it to the CVS until I get it to build and am certain it does not cause any more bugs. EDIT: Got rid of all the warnings brought up by MingW, and I found out how to fix the error posted on SourceForge. This is not in the current build, nor in the CVS Repository. EDIT 2: Quote: i check the 'start with surface terrain' button, the outdoors are then fine. but when i go and edit the town, it's cave floored! Couldn't understand what you meant at first, but I think I do now. If I'm understanding you right, this is not a bug. The start with surface button only applies to outdoors. When you create a town there is a separate button that you need to press in order for said town to be on the surface. Kind of odd, but there you go.

I meant the CVS part of the Summary Page.

Concerning SourceForge's CVS: I believe they are currently upgrading their CVS servers, which is why there are no evident CVS adds/commits.

Quote: Originally written by High-Voltage Opinion: >>The only SF project I could find was boaedremake . ...? It is the site of the 3D editors as well as the remake of the BoA Editor. That is the correct link.

Quote: Originally written by Notus: If you want the current source code, I'll send it to you. It is developed on MS VC++ .NET 2003. Discussing on the problem of the current code will be useful to consider our new version. Or it's better to mount it on the CVS of SourceForge? I'd be in favor of putting it on SourceForge so anyone can look at it. Also, the code will compile using GCC (Dev-C++), right? Quote: a) Essential bug was found on the file I/O system. Please provide more information on this. EDIT: Perhaps we should put the screenshots on SourceForge. Any thoughts? Notus, check your PMs.

The 3D editor is essentially an improved version of the regular editor. All it does is just give you the option of viewing the terrain in 3D. Although there is no need, you can use both for one scenario. It should make no difference.

The for_each function is meant as a way to iterate through a static class where an iterator cannot be made (unless Notus knows how to make this possible). For example, the switching of endianness in the original program was done by a universal port() function in all classes that essentially called flip_short() on all its short members. This takes up quite a bit of source code, and limits the extensiblity of the code. The for_each function would take a functor as an argument and apply it to all its elements. This way a universal functor flip_data can be made (like the one I posted above) and used to flip all classes with a for_each function. Also, anytime you want to do something to all of the class' members, you can just create a functor to do it on a primitive, and call object.for_each( specified_functor() ). Inheritance is very important and is almost always used in templating, most excessively in template metaprogramming, due somewhat to virtual inheritance. Not sure how templating could mimic inheritance. Look into expression templating (an article can be found on the intro to Boost.Spirit's document) and then how Boost.Spirit uses inheritance to store these expressions (the rule<> class). EDIT: Also, templating is mainly used in the construction of libraries. To my knowledge its not usually used to any great extent in application development.

Quote: Originally written by Notus: Iteraters such as for_each function can be realized as a stack object when we need it. Not exactly sure how an iterator can be created in a class such as boat_record_type to iterate through its members while keeping type data, and I have tried quite a bit. Can you explain specifically how? Quote: I also consider on the muti-document editing, because it's Copy/Paste requirement. We should handle multiple documents at the same time to realize copy/paste between two scenarios. Loading all the data into the memory doesn't limit extensibility, except on the memory size. In most of application framework, document class is used to handle multiple documents. In the BoA Editor, a document class will own all scenario data class derived from one scenario data file (.bas). When we expand the feature, the document class will also own extra script data class. It is common concept. I think splitting data between memory and disk introduces another complexity, though the data should be handled as a whole. As for disk I/O, surely it'll increase the loading time but it was within 1-2 sec for the largest zakhazi.bas. On the Windows version of 3D Editor, I’ve already rewritten to load whole scenario on memory temporarily. And saving time will be faster than the original method. To save town/outdoor, first make a copy of whole scenario replacing the edited town/outdoor. Then delete the original and rename the new data. That is, whole scenario data is scanned on the disk to save a town/outdoor. This is a prfered method for data safety. If the whole scenario is loaded on memory, no need to scan it on the disk. I'll have to go with you on this since you have by far more programming experience. Is there a reason why that method of saving is safer?

Quote: Originally written by Notus: Quote: 3) I believe all objects having directly to do with BoA's non-visual data should derive directly from an unnamed class that has virtual functions such as for_each( _FunctorT __f ). Comments? Umm, I cannot understand what you mean. Please elaborate more. Just an ADT with virtual functions and no pure virtual functions (I don't like pure virtual functions. They tend to make the code messier.). All classes having to do with the game, such as item_record_type, and boat_record_type would derive from this object. No objects having to do with the GUI, or objects such as standalone functors would derive from it. The for_each function is just an example of a function that would increase how generic the overall code is, and therefore make extraneous algorithms easier for others to write. I just wanted to make sure there were no arguments for the ADT. Quote: I think that whole data (all towns and all outdoors) from a scenario should be expanded on the memory at the same time. It will release us from allocation problem on disk I/O every time we handle the town/outdoor data. And also the reallocation becomes so easy, only we prepare index array to convert the order on the memory to that on the disk. [/QB] Its not neccessarily the size I'm worried about. Loading all of the .bas file into the memory limits extensibility. I was thinking we could give the program an Multiple Document Interface. By doing this the way I said, or something of the like, the user can work on more than one project at once. Also saving/loading would be done much faster, as only one chunk of the file needs to be loaded. Hmmm, this sounded better in my head. Perhaps I'm not considering something?

Quote: Originally written by Notus: Kernelknowledge, Thank you for organizing our effort on making BoA editors and finding the best place to support our project. Without your proposal and quickness, we might still work inconsistently. Thank you. Quote: It takes a while for me to adapt myself to SourceForge system (Mac client for CVS is worst ). Yes, well CVS clients are in general, well, horrible. Tortoise CVS is the only easy one I know of, and it took me a whole two weeks to become somewhat competant in it. (The Help files didn't help much.) As I'm not too competent in CVS (the actual program), I was wondering if its possible to remove a module from the cvs server. Anyone know how? Quote: But Mac version has been almost finished, and Windows version will be released soon. Please wait a little more. Sorry if I'm being impatient, I'll wait as long as is needed, but in the meantime, there are a few things I would like to get your/Isaac/other developers' opinions on: 1) Is the idea of separating the project into a GUI and a "kernel" a good one, or will it create problems I'm not thinking of? 2) Notus, you said something about changing the BoA structures' (such as boat_record_type) data members to ints. Is this correct? 3) I believe all objects having directly to do with BoA's non-visual data should derive directly from an unnamed class that has virtual functions such as for_each( _FunctorT __f ). Comments? 4) For loading towns/outdoor sects from a .bas file, should we create town/outdoor sect structures that keep track of what file they came from, so they can save/load to/from the file without reallocation?

I gave you developer access. Also Notus suggested you release the OS X version of the 3D Editor via SourceForge. Also I PM'd my contact info to you.

You'll have to tell me the UNIX username (not the publicly shown one) you choose, then I'll give you developer access to the files. This lets you directly change the files, but does not give you administrative control. If you want administrative access, I'll give it to you, but you'll have to be more active than you plan to be. Also to get/change/commit the code you'll have to get a cvs client (if you don't have one already). If you don't know how to use cvs, well, this'll be a problem, as cvs is very hard to learn, but its not impossible. Since I used windows, I could get Tortoise CVS which is much easier to use than regular CVS, though it doesn't take advantage of advanced features. Don't know what clients there are for OS X, but the information is all on SourceForge.net. Also you can look up "The CVS Book." (Its free and online.)

Isaac: I still need your SourceForge.net user name (UNIX username) so I can give you developer access to the project. If you want to give it to me, email it or pm it.

The BoA Editor Remake Project has currently been accepted at SourceForge, and the site is currently ready for at least discussing the Project: Remake Site If you want to suggest a feature, offer help, etc., please do it at the above site. Kelandon: There is a chance we could use your help, but as of now, I do not know if the other two lead developers of this project (Isaac and Notus) are even aware of this project's acceptance. I'd like to wait for them before doing anything significant (including asking for help).

The original code should be packaged with the editor. Look Here

The project is almost underway, and we'll soon be officially asking for support. If anyone believes they may be of help, please say so, but keep in mind that something may not go as planned with SourceForge. Be sure to include how you intend to help. Also, anybody have any thoughts on what to name it?