3D Blades of Avernum Editor 1.0 for Mac OS X released!
Pages
| Author | Topic: 3D Blades of Avernum Editor 1.0 for Mac OS X released! |
|---|---|
|
Shock Trooper
Member # 4557
|
written Monday, January 24 2005 19:24
Profile
quote: quote:If a remake comes into the works the entire look/feel will most likely change. The other three suggesstions will definitely be possible. [ Monday, January 24, 2005 19:25: Message edited by: KernelKnowledge12 ] Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
|
Infiltrator
Member # 148
|
written Monday, January 24 2005 19:40
Profile
I would like to rearrange terrains in the editor without rearranging the terrains in the script. (break-out palette?) This would help so I can organize better. --- This is either a bug and/or a forgotten feature. Lighting in realistic mode does not match the game lighting. Also, could we have a time control so that we can get a look at the different light levels ? -------------------- My ego is bigger than yours. Posts: 480 | Registered: Thursday, October 11 2001 07:00 |
|
Shock Trooper
Member # 4557
|
written Monday, January 24 2005 19:48
Profile
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. Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
|
Infiltrator
Member # 148
|
written Monday, January 24 2005 20:09
Profile
Oh well. As is, the editor is pretty good. Most major issues have been fixed. -------------------- My ego is bigger than yours. Posts: 480 | Registered: Thursday, October 11 2001 07:00 |
|
Off With Their Heads
Member # 4045
|
written Monday, January 24 2005 20:31
Profile
Homepage
Oh, you know what would be neat, if you were re-making the user interface for the editor? Palettes, so that you could click on a terrain out of a terrain palette, a floor out of a floor palette, a monster out of a monster palette. Then each palette could be open at the same time and you could select everything with pictures, instead of long, gross menus. And then if you hold the mouse over each thing in each palette, the name of the thing would pop up in a little text box. That would be neat. Er, well, it's a thought, anyway. -------------------- Arancaytar: Every time you ask people to compare TM and Kel, you endanger the poor, fluffy kittens. Smoo: Get ready to face the walls! Ephesos: In conclusion, yarr. Kelandon's Pink and Pretty Page!!: the authorized location for all things by me The Archive of all released BoE scenarios ever Posts: 7968 | Registered: Saturday, February 28 2004 08:00 |
|
Warrior
Member # 5289
|
written Monday, January 24 2005 23:27
Profile
KernelKnowledge12, wxWidget seems well in most function as an application framework. It'll be helpful to make GUI. Unfortunately its graphic function requires considerable effort to fit to the editor code in Mac side. Also a several work around is needed on Windows. a) As wxBitmap and wxDC doesn't support PICT, we need to make another wrapper class over these class. b) It can't enlarge or reduce bitmaps, this function should be implemented. c) wxRect is defined as {x, y, width, height}. On the other hand, Rect (RECT) is defined as {top, left, bottom, right}. Rewriting Rect (RECT) to wxRect will introduce many bugs. 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. You'll find Isaac's code is filled with Rect operation. 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. And scenario designers are released from conversion, because users can convert the scenario. Also storage size in archive sites can be reduced to half. quote:Actually making GUI will be easy work with wxWidget. Only Tool/Item Palettes needs a little effort. Oh, I forgot about sound. wxWidget doesn't support 'snd ' resource. The graphic (.bmp or PICT) loader method is included in the bitmap class, as this class possesses all data, target file name (resource ID), decompression and the picture itself. wxImage has wxBMPHandler and wxImage::LoadFile() accepts .bmp on Windows. But it doesn't support PICT on Mac, we need to make up them. 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. 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. Phoenix is certainly some framework, but it isn't application framework. Currently It doesn't have functions to support GUI. Isaac, Don't complain ;) It's because we respect your work. And we cannot update your web site. I agree the mechanism such as SourceForge will save our time and effort. Does SourceForge accept the Editor's license ? Dahak and Kelandon, Thank you for many suggestion. I feel Copy/Paste function is definitely needed, too. And also Undo. Customizable palette is the idea brought to me when I touched this editor first. Independent floor, terrain, monster and item palettes would be neat. To realize these feature, we are collaborating now. But I think I should finish Windows port of Isaac's 3D editor first. -------------------- Project: BoA Editor Remake on SourceForge.net supports "3D BoA Editor" (Mac and Win), and creates advanced BoA Editor. Posts: 107 | Registered: Tuesday, December 14 2004 08:00 |
|
Warrior
Member # 4202
|
written Tuesday, January 25 2005 02:15
Profile
Homepage
quote:I tried to make it so that it was exactly the same as in the game when you had maximum light (and when wouldn't you, if you're trying to see?) If it does not, I need details. quote:When would the editor want to use sounds? Hmm, the current editor does for buttons and stuff. But we don't need to use 'snd ' resources for that, even if we want to keep it. quote:I can give a little help, probably mostly with improving my code. I did a number of bad things with it, trying to make it the same style as the old code, and just doing generally stupid things (putting 2 in a variable declared as Boolean, for example). quote:Best to ask Jeff... he should know what his license means... quote:I agree. It is unbelievable what can be done with C++ templates. Not terribly relevant to the issue at hand, though. quote:I think it would: it seems to be an open-source license. quote:Yes. Especially Undo. (but that's just because I've wanted Undo more than copy/paste.) quote:Yes, of course. -------------------- Creator of the 3D Blades of Avernum Editor for Mac. Get it at Ingenious Isaac's Illusion, my web page. Better yet, get Battle for Wesnoth, a wonderful free TBS game. Posts: 192 | Registered: Sunday, April 4 2004 08:00 |
|
Infiltrator
Member # 148
|
written Tuesday, January 25 2005 06:04
Profile
Lighting does not match max total darkness w/ light being impossible (Lighting option #4). -------------------- My ego is bigger than yours. Posts: 480 | Registered: Thursday, October 11 2001 07:00 |
|
Shock Trooper
Member # 4557
|
written Tuesday, January 25 2005 12:17
Profile
quote: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:[/b] 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: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:[/b] 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): For this to work, each data type (like boat_record_type) would need a function: This function would take in a functor and apply it to all of the classes members. This way the flip functions get a little cleaner, and in case we need to do something to all the members in a class, all we have to do is call the object.for_each(...) function. Also I wrote the code pretty quickly, so I'm sure it can be improved. quote:[/b] Glad to hear it. quote:[/b] Isaac's right, we don't neccessarily need sound. And we could probably do it in another type of file, like wav files. quote:[/b] 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: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:Just thought I'd mention it. :) EDIT: I e-mailed JV concerning the liscensing issues. [ Wednesday, January 26, 2005 12:48: Message edited by: KernelKnowledge12 ] Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
|
Warrior
Member # 4202
|
written Wednesday, January 26 2005 02:40
Profile
Homepage
quote:I agree. I have experience with it, and, well, it's cross-platform and can already do anything we want, besides being fast. It was a little hard for me to learn, but it's easy to use for simple 2D tasks. There are also lots of C++ layers that have been made for it, but using those would probably be overkill. The task of drawing the lines for border rectangles might be made simpler or more possible by using OpenGL's depth buffer, although it wouldn't make as much of a difference as it could because the graphics are flat. quote:Plain OpenGL doesn't do ANY image loading - it gets to be cross-platform by not doing anything platform-specific. And its native graphics format has the image's pixels arranged in a different order than either Cocoa (MacOSX) or SDL, the two libraries I've used for the purpose, deliver images in, so there has to be a function to re-order the pixel data. quote:I doubt it. That is a normal way to define what is inside a rect. quote: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. quote:Yes, extensibility is key. We want to get it usable quickly without hindering the addition of more advanced features. A good human interface design is an important thing (technically, it's the only reason we aren't editing the file's data directly :P ). We should probably have some reasonably detailed idea of what we're actually trying to make, although the more flexible the code is, the less is necessary to figure out in advance. One idea I had was a selection of the most recent things (floor, monster, item, terrain) that can be chosen from to place more of. The main view should be the same shape as the game's view, at least in 3D. We shouldn't restrict ourselves to too small a window. Just a few comments.... -------------------- Creator of the 3D Blades of Avernum Editor for Mac. Get it at Ingenious Isaac's Illusion, my web page. Better yet, get Battle for Wesnoth, a wonderful free TBS game. Posts: 192 | Registered: Sunday, April 4 2004 08:00 |
|
Shock Trooper
Member # 4557
|
written Wednesday, January 26 2005 05:55
Profile
quote: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: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. [ Wednesday, January 26, 2005 05:57: Message edited by: KernelKnowledge12 ] Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
|
Warrior
Member # 5289
|
written Wednesday, January 26 2005 06:52
Profile
quote:http://home.pacbell.net/atai/guitool/ 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? b) 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. 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. Data format of Mac and Windows The difference on .bas is only next two point. a) "signature" Mac: 0x61d70721 Win: 0xc73d0235 b) Endian of the multi-byte data. It's possible to handle it on a stand-alone converter. The point is not how we can use the smart tools, but how we can provide smart tools. First, Consider what kind of functions the editor should equip, the means to realize it is latter. [EDIT] I wrote AvernumScript is fixed. It's true, but we can make "Preprocessor" or even "template" handling on it. [ Wednesday, January 26, 2005 09:14: Message edited by: Notus ] -------------------- Project: BoA Editor Remake on SourceForge.net supports "3D BoA Editor" (Mac and Win), and creates advanced BoA Editor. Posts: 107 | Registered: Tuesday, December 14 2004 08:00 |
|
Shock Trooper
Member # 4557
|
written Wednesday, January 26 2005 09:16
Profile
quote: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: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: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: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. [ Wednesday, January 26, 2005 10:05: Message edited by: KernelKnowledge12 ] Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
|
Warrior
Member # 5289
|
written Wednesday, January 26 2005 10:07
Profile
quote:Hmm.. You are right. I also examined the original code on both platform, and found the editor makes Mac format .bas file even on Windows as the first blank one. When the "Worrior's grove" is used as a template, It's format is Mac type on both platform. Anyway, thank you for correcting me. I've examined only loader/saver part, but initializer. Well, then the stand-alone converter should convert only the resources (graphic and sound). [EDIT] KernelKnowledge12, I read your PM. I agree to it totally. Why don't you open the proposal on the board? We need more participant. [ Wednesday, January 26, 2005 10:38: Message edited by: Notus ] -------------------- Project: BoA Editor Remake on SourceForge.net supports "3D BoA Editor" (Mac and Win), and creates advanced BoA Editor. Posts: 107 | Registered: Tuesday, December 14 2004 08:00 |
|
Shock Trooper
Member # 4557
|
written Wednesday, January 26 2005 10:45
Profile
quote: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). Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
|
Warrior
Member # 5289
|
written Wednesday, January 26 2005 11:34
Profile
KernelKnowledge12, I sent my real name and contact to you over PM for SourceForge registration. You should open Jeff's reply at least. It'll encourage other people who thinks of similar project. -------------------- Project: BoA Editor Remake on SourceForge.net supports "3D BoA Editor" (Mac and Win), and creates advanced BoA Editor. Posts: 107 | Registered: Tuesday, December 14 2004 08:00 |
|
Warrior
Member # 5289
|
written Thursday, February 3 2005 00:24
Profile
The latest bug fix of 3D Blades of Avernum Editor is available from "Project: BoA Editor Remake" on SourceForge http://sourceforge.net/project/showfiles.php?group_id=129871 ---------------- note --------------- 3D Blades of Avernum Editor for MacOSX v1.0.2b4 For users, a) Fixed "Outdoor: drawing mode failure after moving section" bug. Just after scrolling to another section on outdoor, mouse drawing didn't work correctly. And sometimes it caused the 3D Editor crash. This bug occurred both on 2D and 3D mode. This bug was fixed. b) You can place the 3D Editor anywhere on the disk. The first time the 3D Editor runs, it asks you where is the "Blades of Avernum Files" folder and memorizes it in its preference. Another tips: If you start the 3D Editor just under the "Blades of Avernum Files" folder, it doesn't ask you the place of the folder, and simply starts. But it surely memorizes the place of the folder. Then you can move the 3D Editor anywhere. c) "3D Editor Graphics" file is included within the application itself. No need to place it on the same folder as a separate file. d) 3D Editor stability was improved. However, don't take it as "bug free". It means bugs are also reproduced stably. This is important for us programmers to fix the bug. For Programmers, a) Fixed "Outdoor: drawing mode failure after moving section" bug. EdFcns.cpp Added: check_scroller(), check_scroller_2D(), check_scroller_3D(), process_scroll_click(), handle_scroll(), handle_tenKey() Modified: clean_up_from_scrolling() global.h: modified clean_up_from_scrolling() parameter b) Preference for "Blades of Avernum Files" folder was added. It makes debug session more easy, as build and debug connects seamlessly. c) The application was adapted to the File Package structure. All resources are included within the application file package. d) Entire resources are moved to data-fork resource file to fit to the CVS system on SourceForge. e) The source code was cleaned up a little. e-1) All warnings are gone. e-2) Most of unused variables, both local and global, are removed. e-3) Local variables which shadow global variables, are renamed. -------------- end of note ------------ 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. It takes a while for me to adapt myself to SourceForge system (Mac client for CVS is worst :( ). But Mac version has been almost finished, and Windows version will be released soon. Please wait a little more. [ Thursday, February 03, 2005 21:42: Message edited by: Notus ] -------------------- Project: BoA Editor Remake on SourceForge.net supports "3D BoA Editor" (Mac and Win), and creates advanced BoA Editor. Posts: 107 | Registered: Tuesday, December 14 2004 08:00 |
|
Shock Trooper
Member # 4557
|
written Thursday, February 3 2005 11:40
Profile
quote:Thank you. quote: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: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? Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
|
Warrior
Member # 5289
|
written Thursday, February 3 2005 17:55
Profile
quote:I agree to divide it to GUI and “others”. To share a project, we must divide it in some way. I think there are two point to consider. a) Actual code structure b) How we are good at in that area. We can make groups of code such as GUI, File I/O, Data manipulation, Graphics. But objects work interactively in many way. The grouping on the code structure is not so strict. In many cases, it depends on only our decision which object (group) a given member or method should belong to. Hence, we can start on the part we want to write at the beginning. After we make an amount of code, we should reconsider on the interaction of objects we made. There are so many blank we should fill. quote:The data structure on the original editor is based on how they are recorded on the disk. In the disk I/O method, these structures are written or read as a whole block. Though this method is simple for disk I/O, this method restricts object’s function so much. It cannot be even inherited from super object because inheritance adds an extra invisible pointer to the class structure and increase bytes size of the class structure. Another restriction is the data type of class members. To reduce the data size on the disk, in most case one byte type (unsigned char) is used. But on 32 (or 64) bit CPU, one byte type is not efficient on the processing speed, because it should be expanded to “natural” size to feed to the arithmetic unit in CPU. And also, on memory, CPU cannot access to odd address directly. On 32 bit bus, memory is accessed by 4 bytes unit. Thus, one byte type is inefficient on the 32 or 64 bit CPU. Disk I/O doesn’t occur so much. On the other hand, data manipulation is the main part of the code. Hence, I propose to use “int” type as the member type on the “internal” data structure, and make a converter for disk I/O. It surely increases the memory usage, but it is only a several mega bytes at most. Nowadays, a several mega bytes are small part of the whole memory, a hundredth or so even on the old Win95 machine. quote:Umm, I cannot understand what you mean. Please elaborate more. 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. Next is the data size of .bas data zakhazi.bas is the largest but only 812k bytes. If it is expanded by using "int" type, by four, only 3 Mbytes as a whole. If someone makes a huge scenario in the future, I cannot imagine it is over ten times larger than zakhazi.bas. -------------------- Project: BoA Editor Remake on SourceForge.net supports "3D BoA Editor" (Mac and Win), and creates advanced BoA Editor. Posts: 107 | Registered: Tuesday, December 14 2004 08:00 |
|
Shock Trooper
Member # 4557
|
written Thursday, February 3 2005 18:27
Profile
quote: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: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? Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
|
Warrior
Member # 5289
|
written Thursday, February 3 2005 20:41
Profile
quote:It sounds like only a problem of taste. If you like it, do it. Iteraters such as for_each function can be realized as a stack object when we need it. But it can be a virtual function. I don't have any taste on this. Either will do. 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. [ Thursday, February 03, 2005 23:47: Message edited by: Notus ] -------------------- Project: BoA Editor Remake on SourceForge.net supports "3D BoA Editor" (Mac and Win), and creates advanced BoA Editor. Posts: 107 | Registered: Tuesday, December 14 2004 08:00 |
|
Shock Trooper
Member # 4557
|
written Friday, February 4 2005 07:32
Profile
quote: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'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? [ Friday, February 04, 2005 10:54: Message edited by: KernelKnowledge12 ] Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
|
Warrior
Member # 4202
|
written Friday, February 4 2005 13:42
Profile
Homepage
I support the modularization such as the "GUI/kernel split". I want it to be easy to, for example, write a keyboard-driven interface. I don't understand what this "for_each" would actually be supposed to do, but I don't see anything wrong with having a common base class like that. I just don't see anything you could want to do with it that couldn't be achieved better by, say, templates. -------------------- Creator of the 3D Blades of Avernum Editor for Mac. Get it at Ingenious Isaac's Illusion, my web page. Better yet, get Battle for Wesnoth, a wonderful free TBS game. Posts: 192 | Registered: Sunday, April 4 2004 08:00 |
|
Shock Trooper
Member # 4557
|
written Friday, February 4 2005 14:02
Profile
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. [ Saturday, February 05, 2005 20:55: Message edited by: KernelKnowledge12 ] Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
|
Apprentice
Member # 2733
|
written Saturday, February 5 2005 03:45
Profile
Hi, I've just downloaded the 1.0.2b4 version of the 3D editor, I've had the original for a while, but have little time to play with it. I notice that the release notes say that the new version contains the graphics in the application - yet the PDF readme file still refers to installing it - do you need to update the PDF file? Will it cause problems if you still have the original graphics file in the folder? Sorry to be boring, but I'd just like to thank all you good people for making this 3D editor work so well - maybe I'll actually get to finish a scenario now!! P.S. Isaac - hadn't realised you were 'Invisible Philosopher' on BfW forums - warmest greetings from 'Star Gazer'! Posts: 8 | Registered: Monday, March 3 2003 08:00 |