3D Blades of Avernum Editor 1.0 for Mac OS X released!

[Isaac]

Here it is.

 

Besides editing in 3D, you can:

• conveniently switch views by typing tab and option-tab
• view it like it is in game, with lighting and line of sight included, or a more convenient 3D editing view
• option-click to center on a location (especially useful when zoomed out)
• change outdoor dimensions
• et cetera... see the readme, there are lots of improvements

There are possibly some unresolved bugs, but I don't think they are there anymore (I never experienced them, so I can't be sure). I know porting it to the PC is greatly desired, but I have heard that there are technical difficulties. Just saying this so the thread doesn't get flooded with "pleeease make a PC version" or similar comments ... anyone who wants to attempt porting it is certainly welcome to do so. Also, I don't know why it doesn't work for Classic Macs but you who use one should definitely upgrade to OS X: it's a much better OS.

Of course, I don't think any of the responses are likely to be particularly useful, so feel free to say what you want.

 

Happy Holidays,

Isaac

[Kelandon]

I experience no crashes, so I think you've fixed the remaining bugs. Great program, and great job.

[Donald Hebb]

Where is Xcode? Do OSX users even have this by default?

[Kelandon]

If you have 10.3, I think so. Otherwise, no. Apple\'s site on the subject.

[wz. As]

I think you might be able to open the source in Project Builder if you're running 10.2 or earlier. If you're running 10.3 but don't have Xcode installed, you can install the developer tools with

/Applications/Installers/Xcode Tools/Developer.mpkg

[Notus]

I found next minor bugs on "3D Blades of Avernum Editor 1.0 for Mac OS X"

 

Bug fix

a) handle_action() (EdFcns.c)

if(clean_up_from_scrolling())

return; // this line should be 'return are_done;'

 

This code is found twice in handle_action(), both should be fixed as above.

Fixed - This bug causes an occasional application quit triggered by scrolling to the other section on outdoor.

Just Dahak reported as "Scroll & Crash" in "Betatesters for 3D Blades of Avernum Editor!"

 

handle_ter_spot_press() (EdFcns.c)

short current_terrain_type; // this line should be deleted

 

This declaration shadows global variable of the same name, which is used in handle_keystroke()

Fixed - The keyboard shortcut (a-z key) for custom terrain selection set by "te_shortcut_key" works correctly.

This bug is also found in the original Jeff's code (v1.1)

 

 

 

Dahak,

Please check on "Scroll & Crash".

The fixed version is uploaded on

--- deleted ---

To run this version, "3D Editor Graphics" included in Isaac's original version is needed.

I'll delete this link when Isaac releases the fixed version.

 

As for MacOS 9 support, compiling it with CodeWarrior will give a simple solution.

 

[Edit] deleted the link

[drafter]

ahh, looks great. any chance this'll be converted to windows too in the near future?

 

oops, noticed the older thread. i'll take a look at there first.

[Dahak]

I am iwthout a computer until my laptop comes back. I will download and check it out then.

[Dahak]

Notus:

I've gotten my laptop back, and the application works perfectly! Kudos.

 

Let us all give a big congratulations to Issac and Notus for their fine work.

[Notus]

Dahak:

Thank you for testing the bug fixed version.

Checked all compiler warnings and detected these two bugs only.

 

Currently working on code reorganization and preparing for the Windows port.

[Isaac]

Quote:

Originally written by Notus:
Currently working on code reorganization and preparing for the Windows port.

Great! Reorganizing the code could be a significant improvement. Hopefully you can manage the porting.

I've uploaded the fix as 1.0.1. Serves me right for ignoring the warnings just because there were too many already. Another 'bug' I happened to find was that using option-click to center on a place made the editor think it needed saving. Some code changes could fix that, but a good, comprehensive fix for that sort of thing would require significant code changes. handle_ter_spot_press() could set whether it needs saving directly, or return whether it needs saving, but that risks true modifications being missed. A better, more 'object-oriented' design would have modification methods for the terrain, etc., which would record that a modification has happened.

[Notus]

Hi Isaac,

Please wait a little more for the reorganized code. I found priority to port your excellent work to Windows. Windows users should be able to wait no more

But the actual reason is that the Windows code doesn't immerse so much in Win API than Mac code does in Carbon API. It's suitable for the common code base.

 

I compared your 3D editor code with Jeff's original line by line (of course using file compare utility), and extracted the modification you made. It was almost 80-90 blocks, though some blocks contain only one line and others have a several hundreds lines.

Jeff's original BoA Editor for Win had already been ported to MS VC++.NET2003.

Now I can start the actual porting work. It may take a several weeks, but programmer's estimation is always uncertain as you know.

 

After the windows port, I'll return to the code reorganization for both platform.

[Custer]

Notus -- I'll be glad to see the windows version when it comes out! Great work, from what I've seen and heard.

[Isaac]

New (and hopefully better) screenshots uploaded!

 

And good luck, Notus, in bringing this editor to the other half of our community.

[Notus]

Thanks. The modification you made has been imported to the appropriate part on the Jeff's Windows version, including resources. Now converting Mac Carbon API to the equivalent Win API, preserving logic you made. Currently it is about 20% or so from the lines I converted to Windows. But the Graphics.cpp, the core part, remains still untouched.

[Dahak]

I hate to the bearer of bad news, but a bug has been found. I mentioned it before, but I thought (wrongly) it had been fixed. When I click on the Open, Canel, Save buttons of the outdoor windows (too vague?), I get a double (?) click. The first chooses an option, but the currently selected option is also drawn (height, terrain, floor) under the same spot that I clicked. I never noticed it 3D since it was out of bounds (and so a alert was played instead), but when I made a few tweaks in 2D, it was readily noticable. Some checking shows that it also occurs in 3D. That is what made the alert sound everytime I scrolled. I can of course save ahead of time, and so no dialog box is drawn, but I thought you should know.

[Notus]

Ya, a little vague. Please describe as follows.

 

Selecting "Outdoors" menu > "Load Different outdoor section", a confirming dialog with "Open", "Cancel" and "Save" button appears. In this dialog, clicking on the one of the button, such as "Cancel" dismisses the dialog immediately and draw a terrain to the edit screen just under the button. and so on.

 

It isn't reproduced on my system, but I found the mouse click to dialog buttons responds on the mouse down, not the mouse up. It is bad design for a dialog response. As the dialog code is Jeff's original, this problem should be found on both platform. I'll look in to change the dialog response to the ordinary one. It'll fix your problem.

[Dahak]

Make Change -> Scrolling to New -> Open/Cancel/Save Dialog Box -> Click Option -> Option Selected and Terrain/Floor/Height Changed Also.

[Notus]

Thank you for the precise description.

As the handling routine of the dialog button is common to every dialog, this problem may be found on another dialog.

 

In other applications, you'll find the dialog button respond when you release the mouse button on the same button you clicked. You can cancel mouse click to a dialog button with moving out mouse cursor from the dialog button without releasing the mouse button. It's the ordinary dialog button response.

 

Nowadays, we never code the dialog button handler directly, because plenty of GUI gadget is provided by the system or other framework. But in old days, the age of SE30, we sometimes made it by ourselves.

[Dahak]

Town mode, Realistic View: Corner Walls (L shaped ones) do not show as more than 1 height tall. Other walls segments show up as whatever height is defined in the town details.

[Notus]

Dahak,

Please check "Dialog Button fix".

The fixed version is uploaded on

--- deleted ---

 

This file only includes the application itself and modified sources.

To run this version, "3D Editor Graphics" included in Isaac's original version is needed.

I'll delete this link when Isaac releases the fixed version.

 

------ note -------

3DBoAEditor_v1.0.2b1

changed mouse click behavior on dialog buttons to prevent accidental click on the editor screen when the dialog is dismissed.

 

Modified

dlogtool.cpp: cd_process_click(), cd_process_keystroke(), cd_press_button()

global.h: prototype of cd_press_button()

 

Added

dlogtool.cpp: cd_process_mousetrack()

-------------------

 

As for the "Town: Corner Wall display" problem, can you email a simple example to me?

My address is notosaurai_AT_yahoo.co.jp

Please replace _AT_ to @

[Dahak]

Now the problem is worse. The same problem still exists, but when I release the mouse button, the editor thinks I'm still holding it down. It wasn't a stuck mouse either.

 

Edit:

E-mail away.

[Notus]

Umm.. Isn't it mouse hardware trouble? I remember you are using a note. Dust may be filled the gap between mouse button and the body. I checked the revised version on a Powerbook also, it worked as I intended. If you have an external mouse, or you can borrow it from your friend, please check it connecting another mouse.

 

"Town: Corner Wall display in realistic mode" problem

Thank you for your example. I realized it exactly. Silly me, I tried it on surface. I'll look in it this weekend.

 

[Edit] This problem appears both in dungeon and surface.

[Dahak]

Edit:

 

Never mind. Found problem.

[Notus]

Dahak,

Please check "Town: Corner Wall display in realistic mode" fix.

The fixed version is uploaded on --deleted because of another bug.

As usual, this file only includes the application itself and modified sources (both in v1.0.2b1 and b2). To run this version, "3D Editor Graphics" included in Isaac's original version is needed. I'll delete this link when Isaac releases the fixed version.

 

This problem was twofold.

a) A routine that handles cutaway (Graphics.cpp: draw_terrain_3D) sets height to 1 on both walls of L-angle shape.

A bug was found in Terrain #6 (NW angle wall) definition, on corescendata2.txt

But why BoA can display NW and SW wall correctly? Maybe it is fixed in the application.

 

------ note -------

3DBoAEditor_v1.0.2b2

Fixed "Town: Corner Wall display in realistic mode" problem

L-shape walls, NW, SW and NE (terrain number, 6, 7, 9, 42, 43, 45), weren't drawn correctly in the realistic mode. Their height of both wall were always 1 when one of a wall was cut away. Fixed this problem.

 

Modified

Graphics.cpp; draw_terrain_3D()

 

corescendata2.txt

begindefineterrain 6; // nw wall

te_which_icon = 5;

te_ed_which_icon = 4;

te_cutaway_which_sheet = -1;

te_full_move_block = 0;

te_full_look_block = 0;

te_blocks_view_e = 0; <-- add this line

te_move_block_n = 1;

te_look_block_n = 1;

te_blocks_view_n = 1;

te_move_block_w = 1;

te_look_block_w = 1;

te_blocks_view_w = 1;

-------------------

 

[Edit] typo

[Dahak]

ALL Terrain (only terrain) in 3D edit mode show 4 copies of the original floating above the terrain.

 

In realistic mode, there are as many copies as the height of the wall. Also, some terrains are not displayed.

 

The problem exists for towns and outdoors.

 

E-mailed snapshots.

[Notus]

Aaah... Sorry, check was not enough. I was too much in hurry to release the version, as I wanted to finish this problem in the last weekend. The bug I newly introduced doesn't hurt the data loaded, only messes up display.

Withdraw v1.0.2b2 and repost v1.0.2b1 until this newly introduced problem will be fixed, maybe in this weekend.

 

-- deleted --

 

The bug fix on "corescendata2.txt" is still effective for the NW corner wall display on v1.0.2b1.

[Dahak]

Another bug:

 

Import Town for Large towns creates garbage in the town written over. No problems with Medium or Small towns. The problem exists for Jeff's Editor also.

 

At first I thought it was the custom graphics of the town, but even with a duplicate .cmg and data file, the problem exists. Also, medium and small towns with custom graphics have no problems. The problem is not consistant. I have had screw-ups from importing other peoples towns.

 

Outdoors imports okay.

 

If the town is imported into the scenario it came from, then the problem does not exist.

 

edit:

Height, floors, terrain, and even creatures become scrambled. Also, the imprted terrain is always a 48x48 square. It should be 64x64.

 

E-mailing snapshot.

[Isaac]

Could it be an endianness bug: Do you know whether the relevant scenarios were created on a different platform from the one being used to import with, or anything like that?

[Dahak]

Hm. The scenarios were made on Macintosh computers I believe (mine, TM, Vogel, and Stareye).

 

I could not find a common thread among those that import correct and those that do not.

 

I even tried making a new scenario via the 3D editor and another via the Vogel editor. I placed a spot of cave floor, tried to import, BAM. Screwy terrain and heights (I had heights of 255 mostly). And yet again a 48x48 square was affected. The rest of the town is unchanged. The unchanged is what was there before import.

[Notus]

"Import Town bug":

 

Dahak,

Can you specify exactly which town of which scenario causes this error?

 

I found one potential cause on import_boa_town() (Bl A Editor.cpp). This routine lacks kludge_correct_old_bad_data(), on the other hand the original, load_town(), has this routine. This explains imported terrain map may have illegal data, but the town size, height, floor and lighting map are irrelevant to this routine. Another cause should exist, but I cannot reproduce it.

 

"Town: Corner Wall display in realistic mode"

Finished fix and checking now. I'll post it afterward.

[Dahak]

Code:

 	switch (scenario.town_size[which_town]) {		case 0:			len =  sizeof(big_tr_type);			error = FSRead(file_id, &len, (char *) &t_d);			if (error != 0) {FSClose(file_id); oops_error(204);}			if (this_is_windows_scenario)				t_d.port();			break;					case 1:			len = sizeof(ave_tr_type);			error = FSRead(file_id, &len, (char *) &ave_t);			if (error != 0) {FSClose(file_id); oops_error(205);}			if (this_is_windows_scenario)				ave_t.port();			for (i = 0; i < 48; i++)				for (j = 0; j < 48; j++) {					t_d.terrain[i][j] = ave_t.terrain[i][j];					t_d.floor[i][j] = ave_t.floor[i][j];					t_d.height[i][j] = ave_t.height[i][j];					t_d.lighting[i][j] = ave_t.lighting[i][j];										}			break;					case 2:			len = sizeof(tiny_tr_type);			error = FSRead(file_id,&len , (char *) &tiny_t);			if (error != 0) {FSClose(file_id); oops_error(206);}			if (this_is_windows_scenario)				tiny_t.port();			for (i = 0; i < 32; i++)				for (j = 0; j < 32; j++) {					t_d.terrain[i][j] = tiny_t.terrain[i][j];					t_d.floor[i][j] = tiny_t.floor[i][j];					t_d.height[i][j] = tiny_t.height[i][j];					t_d.lighting[i][j] = tiny_t.lighting[i][j];										}			break;		} 

You mean this? The problem happens with every scenario.

I haven't had any problems with the original scenarios (Vogel's), but all others released have trouble. Also, no scenario has trouble importing from itself.

Edit:
Case for the large towns seems incomplete.

[Notus]

Quote:

Case for the large towns seems incomplete.

It's OK. On the case for the large towns, the imported data is loaded directly to t_d. In other cases, the data is loaded to ave_t or tiny_t once and transfered to t_d. This handling is needed because the array sizes are different in two dimensional arrays, terrain, floor, height and lightning.

Quote:

but all others released have trouble

I see, I'll check it.

[Dahak]

I wanted to check something else so I did the following:

 

Test A was made with the Vogel editor

Test B was made with the Vogel editor

Test C was made with the 3D editor

Test D was made with the 3D editor

 

A - D are NOT using custom floors/terrains

 

Vogel & Vogel

Large town imported from A to B using the Vogel editor : Good

 

Large town imported from A to B using the 3D editor : Good

 

Large town imported from B to A using the Vogel editor : Good

 

Large town imported from B to A using the 3D editor : Good

 

3D & 3D

Large town imported from C to D using the Vogel editor : Good

 

Large town imported from C to D using the 3D editor : Good

 

Large town imported from D to C using the Vogel editor : Good

 

Large town imported from D to C using the 3D editor : Good

 

3D & Vogel

Large town imported from A to C using the Vogel editor : Good

 

Large town imported from A to C using the 3D editor : Good

 

Large town imported from C to A using the Vogel editor : Good

 

Large town imported from C to A using the 3D editor : Good

 

Odd thing is that I had no problems. I made other test scenarios via the 3D editor and I had problems galore. I remember having this issue last summer when the 3D editor first came out. I found a solution, but I can't remember. I'll check the posts.

 

Edit:

Found it

Quote:

Another bug: Imports of large towns become corrupted. This problem exists in Spiderweb's Editor and Issac's, so I will e-mail Jeff about the problem.

 

EDIT:

Never mind about the corruption. I just had to open the scenatio I import from and save the scenario while each large town was loaded in memory. I don't know only the import would corrupt, but it isn't the editor's fault.

I'll double check.

 

Dang. I forgot. I had this problem when importing from within the scenario (i.e. B town1 to B town2). I was so hoping that would fix the problem.

 

Notus:

Download this and import any large town (2, 3, 4, 5, 6, 7, or 8).

[Notus]

It reproduced on the Resistance Cave (#4) on APF. Once it is reproduced on the debugger, it can be traced

 

[EDIT}

OK, I catch it. On import_boa_town() (Bl A Editor.cpp)

switch (scenario.town_size[which_town]) {

should be

switch (temp_scenario.town_size[which_town]) {

 

Dahak, you are very close to the cause, the culprit is the first line you've quoted!!

 

After checking no other cause, I'll post both fix.

[Dahak]

Thanks. Maybe you should e-mail Jeff. He has the same problem.

[Notus]

The fixed version is uploaded on here,

 

---- deleded -----

 

As usual, this file only includes the application itself and modified sources (v1.0.2b1-b3). To run this version, "3D Editor Graphics" included in Isaac's original version is needed. I'll delete this link when Isaac releases the fixed version.

 

------ note -------

3DBoAEditor_v1.0.2b3

 

Fixed "Import Town bug"

Sometimes the imported town has different size from the original, map data (terrain, floor, height and light) are messed up.

 

Modified

Bl A Fileio.cpp import_boa_town()

 

Fixed "Town: Corner Wall display in realistic mode" problem

L-shape walls, NW, SW and NE (terrain number, 6, 7, 9, 42, 43, 45), weren't drawn correctly in the realistic mode. Their height of both wall were always 1 when one of a wall was cut away. Fixed this problem.

 

Modified

Graphics.cpp draw_terrain_3D()

EdParser.cpp load_core_scenario_data()

 

Added

EdParser.cpp patch_corescendata2()

 

Actually, the patch to EdParser.cpp is to correct the bug on corescendata2.txt ( see below ). This bug affects not only terrain 6, but terrain 7, 42 and 43. And because of this bug, NW corner wall display in realistic mode becomes odd.

It's better to fix this bug on corescendata2.txt itself, but it may cause unpredictable errors on the BoA Game. For this reason, correct them on EdParser.cpp.

 

corescendata2.txt

begindefineterrain 6; // nw wall

te_which_icon = 5;

te_ed_which_icon = 4;

te_cutaway_which_sheet = -1;

te_full_move_block = 0;

te_full_look_block = 0;

te_blocks_view_e = 0; // this line is needed

te_move_block_n = 1;

te_look_block_n = 1;

te_blocks_view_n = 1;

te_move_block_w = 1;

te_look_block_w = 1;

te_blocks_view_w = 1;

 

3DBoAEditor_v1.0.2b2

Withdrawn because of a bug.

 

3DBoAEditor_v1.0.2b1

"Dialog Button fix"

changed mouse click behavior on dialog buttons to prevent accidental click on the editor screen when the dialog is dismissed.

 

Modified

dlogtool.cpp: cd_process_click(), cd_process_keystroke(), cd_press_button()

global.h: prototype of cd_press_button()

 

Added

dlogtool.cpp: cd_process_mousetrack()

-------------------

[KernelKnowledge12]

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.

[Dahak]

Import is good!

 

? Bug:

After I scroll, I DO NOT have a accidental click occurring (yay!). However, unless I click again (nothing happens!) the editor assumes I am holding down the mouse. I borrowed a USB mouse from another computer and had the same problem. What happened?

 

If it weren't for the USB mouse having the same trouble, I'd say it was a touchy trackpad.

 

Edit:

Nevermind what I said about the corner walls.

[Notus]

KernelKnowledge12,

 

I don't think we can get so many participants. It's almost torture to track down the source code, as you know.

 

Dahak,

Quote:

Nevermind what I said about the corner walls.

Finally, it passed your strict test? Congratulation.

 

Quote:

However, unless I click again (nothing happens!) the editor assumes I am holding down the mouse.

In which mode does it occur?

3D/Realistic or 2D

outdoor or town

[KernelKnowledge12]

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.

[Dahak]

Outdoors, 2D or 3D. Usually 2D.

 

Edit:

Remember, you cannot scroll from town to town. You have to load them. Personally, I'm just saving and loading instead of scrolling outdoors. If you do that or save before you cross-over, then no problem (no dialog box).

[Notus]

KernelKnowledge12,

 

There are a several things we can contribute to the community

a) Porting Isaac's 3D editor to Windows and OS9 Mac

Bug fix on the 3D and original editor

c) Reorganize the source code or remake it from scratch

d) Add more smart functions to the editor

 

I'm working mainly on and a) now. Windows porting is about 70% complete.

Anyhow, I cannot imagine how to cooperate on the current source code.

We need more ordered source code to share our project. I remember you tried to remake it. Can you open it, as we discuss how to cooperate on it.

 

Dahak,

It was reproduced on my side.

 

"Outdoor: drawing mode failure after moving section" bug.

Just after scrolling to another section on outdoor, mouse drawing doesn't work correctly.

If there is no change on the previous section, the transition to the another section goes without save dialog. Just after the transition, mouse click to the edit screen results nothing. No drawing occurs.

If there is any change on the previous section, a save dialog appears on the transition. Just after the transition, moving mouse on the edit screen causes continuous drawing.

This bug occurs both on 2D and 3D mode.

 

I'll look into this bug, but please wait until next weekend. (It's Sunday evening now in Japan)

[KernelKnowledge12]

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.

[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?

 

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.

 

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.

 

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.

[KernelKnowledge12]

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.

[Isaac]

Quote:

Originally written by KernelKnowledge12:
See how you like wxWidgets . It's extremely powerful and over 12 years in the making.

Probably a good idea, although I haven't looked at it much.

Quote:

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.

There are two things to consider:
1) More people know C than C++. The more people who can understand/modify the code, the better.
2) C++ is better than C for many things.

I think that using Sourceforge would probably be a good idea. What we're doing now is not good. It is too much of a bother for me to update my version when other people make improvements. And if there is more involvement than a single person, we will need a better system for dealing with modifications than uploading modified source files.

If we rewrite it completely, I think we can choose our own open-source license, although I'm not sure we'd want one different from the original's. I believe the current editor's license is not GPL-compatible. (I'm not sure of any of this though because I'm not a lawyer.... )

[KernelKnowledge12]

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?

[Dahak]

If this get off the ground, then I request a few features.

 

1) Tint the side bar icons just as they are tinted in 3D mode.

 

2) Add a "tinting" test. You load an icon/graphic and check off the tints you want. You may also include a numerical tester. This way you do not have to edit and reload for every tint. The tester would do it, and you could refresh until you get a good value, and paste that value into the data script.

 

3) Create a copy feature that lets you copy a terrain/floor pattern and paste it. Lets you organize better if something is off.

[Kelandon]

Two features I would love to see:

• Copy/paste for objects (terrain scripts, monsters, items). I get sick of writing the same name into a terrain script, putting in the same numbers into the memory cells, etc.
• 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.