Profile for KernelKnowledge12

Error message

Deprecated function: implode(): Passing glue string after array is deprecated. Swap the parameters in drupal_get_feeds() (line 394 of /var/www/pied-piper.ermarian.net/includes/common.inc).

Recent posts

Pages

AuthorRecent posts
Age Poll in General
KernelKnowledge12
Shock Trooper
Member # 4557
 written Saturday, January 29 2005 13:44 Profile #34
17. Hmm . . . I'm starting to notice a trend.
Posts: 264 | Registered: Wednesday, June 16 2004 07:00
Random Question in General
KernelKnowledge12
Shock Trooper
Member # 4557
 written Saturday, January 29 2005 13:37 Profile #6
m's provocation? I hope you set this.
Posts: 264 | Registered: Wednesday, June 16 2004 07:00
Random Question in General
KernelKnowledge12
Shock Trooper
Member # 4557
 written Friday, January 28 2005 19:55 Profile #4
quote:
Originally written by Lucrid:


Edie: Lucrid? did I change my name?
Seems like something you should notice.

[ Friday, January 28, 2005 19:56: Message edited by: KernelKnowledge12 ]
Posts: 264 | Registered: Wednesday, June 16 2004 07:00
Random Question in General
KernelKnowledge12
Shock Trooper
Member # 4557
 written Friday, January 28 2005 11:07 Profile #1
Don't know if this is what you're looking for, but:

quote:
11.8.2. Floating Exception
These are usually caused by incorrect mathematical constructions within your program or incorrect use of floating point numbers. Common errors of this type include:

* using a mathematical expression where there is a division by zero.
* printing out an integer in a printf statement, but using the `%f' (float) number format. For example: printf("%f\n", number); (where the variable `number' is an integer).
This is only applicable to your situation if the program was something you wrote. If not, then what program were you running?

[ Friday, January 28, 2005 11:08: Message edited by: KernelKnowledge12 ]
Posts: 264 | Registered: Wednesday, June 16 2004 07:00
BoA Editor Remake in Blades of Avernum Editor
KernelKnowledge12
Shock Trooper
Member # 4557
 written Friday, January 28 2005 07:09 Profile #10
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.
Posts: 264 | Registered: Wednesday, June 16 2004 07:00
BoA Editor Remake in Blades of Avernum
KernelKnowledge12
Shock Trooper
Member # 4557
 written Friday, January 28 2005 07:09 Profile #10
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.
Posts: 264 | Registered: Wednesday, June 16 2004 07:00
BoA Editor Remake in Blades of Avernum Editor
KernelKnowledge12
Shock Trooper
Member # 4557
 written Thursday, January 27 2005 18:17 Profile #7
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).
Posts: 264 | Registered: Wednesday, June 16 2004 07:00
BoA Editor Remake in Blades of Avernum
KernelKnowledge12
Shock Trooper
Member # 4557
 written Thursday, January 27 2005 18:17 Profile #7
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).
Posts: 264 | Registered: Wednesday, June 16 2004 07:00
BoA Editor Remake in Blades of Avernum Editor
KernelKnowledge12
Shock Trooper
Member # 4557
 written Thursday, January 27 2005 13:48 Profile #5
The original code should be packaged with the editor.
Look Here

[ Thursday, January 27, 2005 13:52: Message edited by: KernelKnowledge12 ]
Posts: 264 | Registered: Wednesday, June 16 2004 07:00
BoA Editor Remake in Blades of Avernum
KernelKnowledge12
Shock Trooper
Member # 4557
 written Thursday, January 27 2005 13:48 Profile #5
The original code should be packaged with the editor.
Look Here

[ Thursday, January 27, 2005 13:52: Message edited by: KernelKnowledge12 ]
Posts: 264 | Registered: Wednesday, June 16 2004 07:00
Root of all evil in General
KernelKnowledge12
Shock Trooper
Member # 4557
 written Thursday, January 27 2005 11:55 Profile #153
quote:
Originally written by Andrew Miller:

Given that, what's left to fill is not a crack so much as an infinitely yawning abyss. To put it in material terms, there's an infinitely vast amount of material out there that no one knows anything about! Given that, I think it is close-minded to weigh in so conclusively on the matter.
Ironically, its this kind of thinking that led to the Quantum Revolution. Doesn't mean I support it.

[ Thursday, January 27, 2005 11:56: Message edited by: KernelKnowledge12 ]
Posts: 264 | Registered: Wednesday, June 16 2004 07:00
BoA Editor Remake in Blades of Avernum Editor
KernelKnowledge12
Shock Trooper
Member # 4557
 written Thursday, January 27 2005 11:49 Profile #2
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?
Posts: 264 | Registered: Wednesday, June 16 2004 07:00
BoA Editor Remake in Blades of Avernum
KernelKnowledge12
Shock Trooper
Member # 4557
 written Thursday, January 27 2005 11:49 Profile #2
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?
Posts: 264 | Registered: Wednesday, June 16 2004 07:00
BoA Editor Remake in Blades of Avernum Editor
KernelKnowledge12
Shock Trooper
Member # 4557
 written Wednesday, January 26 2005 11:50 Profile #0
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
Posts: 264 | Registered: Wednesday, June 16 2004 07:00
BoA Editor Remake in Blades of Avernum
KernelKnowledge12
Shock Trooper
Member # 4557
 written Wednesday, January 26 2005 11:50 Profile #0
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
Posts: 264 | Registered: Wednesday, June 16 2004 07:00
3D Blades of Avernum Editor 1.0 for Mac OS X released! in Blades of Avernum Editor
KernelKnowledge12
Shock Trooper
Member # 4557
 written Wednesday, January 26 2005 10:45 Profile #64
quote:
Originally written by Notus:

[QUOTE]
KernelKnowledge12,
I read your PM. I agree to it totally.
Why don't you open the proposal on the board?
We need more participant.
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
3D Blades of Avernum Editor 1.0 for Mac OS X released! in Blades of Avernum
KernelKnowledge12
Shock Trooper
Member # 4557
 written Wednesday, January 26 2005 10:45 Profile #64
quote:
Originally written by Notus:

[QUOTE]
KernelKnowledge12,
I read your PM. I agree to it totally.
Why don't you open the proposal on the board?
We need more participant.
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
3D Blades of Avernum Editor 1.0 for Mac OS X released! in Blades of Avernum Editor
KernelKnowledge12
Shock Trooper
Member # 4557
 written Wednesday, January 26 2005 09:16 Profile #62
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?
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.
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
b) 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:
// 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.

[ Wednesday, January 26, 2005 10:05: Message edited by: KernelKnowledge12 ]
Posts: 264 | Registered: Wednesday, June 16 2004 07:00
3D Blades of Avernum Editor 1.0 for Mac OS X released! in Blades of Avernum
KernelKnowledge12
Shock Trooper
Member # 4557
 written Wednesday, January 26 2005 09:16 Profile #62
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?
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.
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
b) 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:
// 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.

[ Wednesday, January 26, 2005 10:05: Message edited by: KernelKnowledge12 ]
Posts: 264 | Registered: Wednesday, June 16 2004 07:00
3D Blades of Avernum Editor 1.0 for Mac OS X released! in Blades of Avernum Editor
KernelKnowledge12
Shock Trooper
Member # 4557
 written Wednesday, January 26 2005 05:55 Profile #60
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.

[ Wednesday, January 26, 2005 05:57: Message edited by: KernelKnowledge12 ]
Posts: 264 | Registered: Wednesday, June 16 2004 07:00
3D Blades of Avernum Editor 1.0 for Mac OS X released! in Blades of Avernum
KernelKnowledge12
Shock Trooper
Member # 4557
 written Wednesday, January 26 2005 05:55 Profile #60
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.

[ Wednesday, January 26, 2005 05:57: Message edited by: KernelKnowledge12 ]
Posts: 264 | Registered: Wednesday, June 16 2004 07:00
3D Blades of Avernum Editor 1.0 for Mac OS X released! in Blades of Avernum Editor
KernelKnowledge12
Shock Trooper
Member # 4557
 written Tuesday, January 25 2005 12:17 Profile #58
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:
[b]
b) It can't enlarge or reduce bitmaps, this function should be implemented.
[/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:

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:
[b]
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.
[/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):

/** *
* Changes the endianness of a given primitive
*
* **/
struct flip_primitive_impl {

template <typename _DataT>
struct result {typedef _DataT& type;};

/** *
* Iterates from the first byte of __x, until the middle of __x and swaps the current byte
* with its reflected byte:
* swaps current_byte with
* end_byte - (current_byte - begining_byte)
*
* **/
template <typename _DataT>
_DataT& operator()( _DataT& __x ) {
char* __end = (char*) (&__x + 1);
for ( char* __i = (char*) &__x; __i != (char*) (&__x) + sizeof(_DataT)/2; ++__i )
std::iter_swap( __i, __end - __i + (char*) &__x - 1 );
return __x;
}

/** *
* one byte cannot be flipped, so function overloads follow:
*
* **/
char& operator()( char& __x ) {
return __x;
}

unsigned char& operator()( unsigned char& __x ) {
return __x;
}

/** *
* a short is two bytes and flipping it only needs one swap, so:
*
* **/
short& operator()( short& __x ) {
std::swap( *( (char*) &__x ), *( (char*) &__x + 1) );
return __x;
}

unsigned short& operator()( unsigned short& __x ) {
std::swap( *( (char*) &__x ), *( (char*) &__x + 1) );
return __x;
}
};

// declares flip_primitive lazy function
function<flip_primitive_impl> flip_primitive;

/**
* Changes the endianness of data that contains an iterator type.
* Should work with static data structures, given they have a
* function for_each.
*
**/
struct flip_data_impl {

private:

template < typename _IsArithmeticT = __false_type >
struct apply_f
{
template <typename _DataT>
static inline void apply( _DataT& __x ) {
__x.for_each( function<flip_data_impl>(arg1) );
}

template <typename _DataT>
static inline void apply( std::vector<_DataT>& __x ) {
std::for_each( __x.begin(), __x.end(), function<flip_data_impl>(arg1) );
}
};

struct apply_f<__true_type>
{
template <typename _DataT>
static inline void apply( _DataT& __x ) {
flip_primitive(arg1)(__x);
}
};

public:

template <typename _DataT>
struct result {typedef _DataT& type;};

template <typename _DataT>
_DataT& operator()( _DataT& __x )
{
apply_f< typename __type_traits<_DataT>::is_POD_type >::apply( __x );
return __x;
}

};

// declares flip_data lazy function
function<flip_data_impl> flip_data;
For this to work, each data type (like boat_record_type) would need a function:
template <_Functor>
for_each( _Functor __f ) {
__f( ... )
... }
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]Actually making GUI will be easy work with wxWidget. Only Tool/Item Palettes needs a little effort.
[/b]

Glad to hear it.

quote:
[b]
Oh, I forgot about sound. wxWidget doesn't support 'snd ' resource.
[/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]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.
[/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:

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.

[ Wednesday, January 26, 2005 12:48: Message edited by: KernelKnowledge12 ]
Posts: 264 | Registered: Wednesday, June 16 2004 07:00
3D Blades of Avernum Editor 1.0 for Mac OS X released! in Blades of Avernum
KernelKnowledge12
Shock Trooper
Member # 4557
 written Tuesday, January 25 2005 12:17 Profile #58
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:
[b]
b) It can't enlarge or reduce bitmaps, this function should be implemented.
[/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:

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:
[b]
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.
[/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):

/** *
* Changes the endianness of a given primitive
*
* **/
struct flip_primitive_impl {

template <typename _DataT>
struct result {typedef _DataT& type;};

/** *
* Iterates from the first byte of __x, until the middle of __x and swaps the current byte
* with its reflected byte:
* swaps current_byte with
* end_byte - (current_byte - begining_byte)
*
* **/
template <typename _DataT>
_DataT& operator()( _DataT& __x ) {
char* __end = (char*) (&__x + 1);
for ( char* __i = (char*) &__x; __i != (char*) (&__x) + sizeof(_DataT)/2; ++__i )
std::iter_swap( __i, __end - __i + (char*) &__x - 1 );
return __x;
}

/** *
* one byte cannot be flipped, so function overloads follow:
*
* **/
char& operator()( char& __x ) {
return __x;
}

unsigned char& operator()( unsigned char& __x ) {
return __x;
}

/** *
* a short is two bytes and flipping it only needs one swap, so:
*
* **/
short& operator()( short& __x ) {
std::swap( *( (char*) &__x ), *( (char*) &__x + 1) );
return __x;
}

unsigned short& operator()( unsigned short& __x ) {
std::swap( *( (char*) &__x ), *( (char*) &__x + 1) );
return __x;
}
};

// declares flip_primitive lazy function
function<flip_primitive_impl> flip_primitive;

/**
* Changes the endianness of data that contains an iterator type.
* Should work with static data structures, given they have a
* function for_each.
*
**/
struct flip_data_impl {

private:

template < typename _IsArithmeticT = __false_type >
struct apply_f
{
template <typename _DataT>
static inline void apply( _DataT& __x ) {
__x.for_each( function<flip_data_impl>(arg1) );
}

template <typename _DataT>
static inline void apply( std::vector<_DataT>& __x ) {
std::for_each( __x.begin(), __x.end(), function<flip_data_impl>(arg1) );
}
};

struct apply_f<__true_type>
{
template <typename _DataT>
static inline void apply( _DataT& __x ) {
flip_primitive(arg1)(__x);
}
};

public:

template <typename _DataT>
struct result {typedef _DataT& type;};

template <typename _DataT>
_DataT& operator()( _DataT& __x )
{
apply_f< typename __type_traits<_DataT>::is_POD_type >::apply( __x );
return __x;
}

};

// declares flip_data lazy function
function<flip_data_impl> flip_data;
For this to work, each data type (like boat_record_type) would need a function:
template <_Functor>
for_each( _Functor __f ) {
__f( ... )
... }
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]Actually making GUI will be easy work with wxWidget. Only Tool/Item Palettes needs a little effort.
[/b]

Glad to hear it.

quote:
[b]
Oh, I forgot about sound. wxWidget doesn't support 'snd ' resource.
[/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]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.
[/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:

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.

[ Wednesday, January 26, 2005 12:48: Message edited by: KernelKnowledge12 ]
Posts: 264 | Registered: Wednesday, June 16 2004 07:00
3D Blades of Avernum Editor 1.0 for Mac OS X released! in Blades of Avernum Editor
KernelKnowledge12
Shock Trooper
Member # 4557
 written Monday, January 24 2005 19:48 Profile #52
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
3D Blades of Avernum Editor 1.0 for Mac OS X released! in Blades of Avernum
KernelKnowledge12
Shock Trooper
Member # 4557
 written Monday, January 24 2005 19:48 Profile #52
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

Pages