BoA Editor Remake

[KernelKnowledge12]

Most of what I did was fairly technical, but here it is:

 

- Created the set_vector<...> concept. Jeff seems to primarily depend on C-style arrays in all of his programming. The arrays are essentially filled with a set number of objects that may or may not be valid. Handling arrays like this is cumbersome and not especially good style, but since the .BAS file format uses this, I had to put a mask over such arrays that manages such arrays like C-style arrays but is implemented as an STL-like dynamic array. That mask being set_vector.

 

- Created the paired_container<...> concept. In addition to using C-arrays, Jeff did not deem it necessary to group certain arrays that should have been grouped. For example, for signs Jeff used an array for the signs' locations, and a separate array for the signs' text. This created the managing of one array into the managing two arrays. To simplify the handling of such paired concepts, without over-complicating the file i/o, the paired_container<...> concept was created. It essentially holds two separate containers, so they may be serialized separately, but handles them as one.

 

- Created a Red-Black Ternary Search Tree to use as the new editor's graphic library. The graphic library will use a char type of int, and will use the graphic_id_type as the key to individual graphics. Graphics will be loaded as individual tiles, and adjusted accordingly upon loading.

 

- Created a N-ary tree that should be useful in any future scripting programs.

 

- Cleaned up the mechanism used for serialization.

Works somewhat like Spirit's symbol_inserter. This should make switching to Boost.Serialization a bit easier.

 

- TODO:

 

- Re-implement Boost.Multiarray using the BGL, to support freer insertion and iteration and to clean up any terrain related algorithms.

 

This is all I can think up at the moment.

[Kelandon]

Where do we stand with regard to a release? I mean, is there still a lot left to do?

[*i]

For those less erudite in code, could you explain what all of the things really do for the designer?

[Xoid]

It seems that KernalKnowledge12 is mostly optimising routines already present - by using a better implementation of them.

[KernelKnowledge12]

Quote:

Where do we stand with regard to a release? I mean, is there still a lot left to do?

After I finish reimplementing Boost.Multi-Array, I'll go back to work on the gui. The big thing to do here is create an editing interface that works as independently of specific details as possible. As in, escaping an interface that requires separate town, outdoor and scenario menus. I should have a bit more time in about a week or two. Al my college application should be in by then.

Quote:

For those less erudite in code, could you explain what all of the things really do for the designer?

Not much, if anything. Those changes are for better, easier-to-write code.

Quote:

It seems that KernalKnowledge12 is mostly optimising routines already present - by using a better implementation of them.

I'm not optimising anything. Just conceptualizing someone else's code. Jeff wrote code that was meant to be finished, not changed. I am trying to make sure my code, at the very least, lasts.

[*i]

I figured as much, I thought I'd ask. Anyway, thank you for all the hard work you have put it. I enjoy using your tool profusely.

[Lilith]

Quote:

Originally written by *i:
I enjoy using your tool profusely.

Careful there, *i -- that's the sort of quote that has a tendency to get put in people's signatures.

[*i]

Haha, true, perhaps I should exchange tool with utility.

[Kelandon]

*prods*

 

After more than a year of work, where does this project stand? Is it ever going to be finished?

[KernelKnowledge12]

Changes to suncome:

- Created a modularization for the rendering algorithms, by creating a rendering package concept. Somewhat of a hack, but better than the original.

- The two dimensional drawing algorithms were ported to this modularization, as well as some of the three dimensional drawing algorithms. The porting of the three-dimensional drawing algorithms prompted some changes to remembrance, listed below.

- Solved the drawing problem created by wxWidgets, and added an illuminate_graphic algorithm used to apply lighting to a graphic.

- Found a way to represent tools such as Select, Paint, Flood Fill, etc. using the event handling DSEL I wrote for suncome.

 

Some of these changes should be in the CVS.

 

Changes to remembrance:

- Added an outdoor_cementer class that wraps a bas_file and treats the entire outdoors as one single terrain.

- Removed the can_travel algorithms as their equivalents in the Editor are never actually used.

- Removed the sight_map class, and generate_sight_map algorithm.

- Introduced a system to deduce and retain terrain properties such as cliff height and visibility. The system uses the terrain_property concept and the terrain_property_map concept.

- Added the light property (replaced the removed sight_map), cliff property, and corner property and their respective generation algorithms.

 

I don't believe any of these changes are in the CVS repository.

 

That was about one or two weeks ago. Given I have time next week, and there are no major compile-time bugs in remembrance, I may release v1.1 of remembrance.

 

As to when the entire project will be finished, I cannot say (which you should know by now). Once I get the 3D view done, I should be able to release a build that lets one view .BAS files, without doing a whole lot of editing. I do not know when this will be. It probably won't be soon, as I won't have very much time, if any at all, to work on it in the near future.

[Dahak]

A current bug in the 3D editor:

Floors 194 and 195 acts as if you placed a sign along with the floor when you actually didn't.

[Kelandon]

Even a better way to look at BoA scenarios would be appreciated, and, as I've been saying all along, the most important thing that you can do is release something, so yeah, I think that a preliminary release would not be a bad idea.

[Skatje]

Oh, nevermind here. Found out where to find the answer to my question.

[Kelandon]

*poke* *prod*

 

Two months later, where do we stand? Is there any possibility of you releasing an application that will at least allow us to look at bas files in a more reasonable manner? After a year and a half, do you have anything to show us?

[Dintiradan]

Semi-related question: is there (or can there) be a way to look at and manipulate .SAV files (this would help tremendously with a scenario idea floating around in my head right now).

 

I'd be able to write an application to modify the .SAVs, if I only know for sure what was what.

 

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

IF I EVER BECOME AN EVIL OVERLORD:

The passageways to and within my domain will be well-lit with fluorescent lighting. Regrettably, the spooky atmosphere will be lost, but my security patrols will be more effective.

[KernelKnowledge12]

Quote:

Originally written by Kelandon:
*poke* *prod*

Two months later, where do we stand? Is there any possibility of you releasing an application that will at least allow us to look at bas files in a more reasonable manner? After a year and a half, do you have anything to show us?

I have not had a whole lot of time to work on it, since last I posted here. About two-three weeks ago I found myself with enough time to finish/compile/test libremembrance, which took about three days (the changes are below). This would've have been released/in CVS, but SourceForge decided to change some aspects of their CVS service, which I'll be using as an excuse to switch to SVN. I have not worked on the GUI since last time. In about a week, I should have a lot more time in which to work on this.

Quote:

Semi-related question: is there (or can there) be a way to look at and manipulate .SAV files (this would help tremendously with a scenario idea floating around in my head right now).

Jeff did not release any code that worked to this effect, nor did he release the file format, so first you'd have to ask him if it would be permissible then ask for the format.

Changes to libremembrance (from the changelog):

- Version 1.1.0.1
- Changed the bas_file class name to scenario
- Removed the scenario_header class
- Moved all the data that must be stored into the scenario (was bas_file) class
- Moved temporary data (num_towns, town_size, town_starts_hidden) to the new class,
scenario_meta_data, which the streampos iterators now link to
- Removed the storage_shortcut class as that is used only in the Editor, and not BoA
- Changed the serialization wrappers (convert, bytes, etc.) to templated inline free functions
- Removed virtuality from the scen_data objects, so scen_data_type may be declared global
- Changed parts of avs_data_parser that dealt with this
- Started using Boost.MultiIndex for the town and outdoor containers in scenario (was bas_file)
- Towns are now indiced sequentially and ordered by name
- Outdoors are now ordered by location and by name
- cleaned boa/iterator/scen_data_iterator.hpp considerably
- Uses boost::iterator_adaptor<...>
- Removed scen_data_iterator<game_object>
- Removed signed_numeric<...> as it does little that numeric_mask<...> doesn't
- Removed the use of operator bool() in the determination of a serialized object's validity
- Added a scen_data_typed_object<...> base type
- Towns/Outdoors now derive from basic_terrain instead of holding an instance of them
- Removed the paired_container class and replaced it with the paired_fixed serialization wrapper
- Removed the detail::serialize free functions and replaced them with the appropriate serialization
wrappers
- Put a serialize method inside set_vector
- Cleaned up (removed superfluous methods) boa/class/std/set_vector.hpp
- Added several specialized pair types in boa/primitive, such as special_rect, info_rect,
sign...
- Removed the num_dims metafunction, as it has not been used for some time
- Moved some constants in boa/primitive/graphics.hpp to boa/detail/constants.hpp
- Added a more descriptive, useful exception class
- Removed set_string and replaced it with a fixed_string serialization wrapper class.
fixed_string is used explicitly in certain pair specializations
- Added a serialization method to introduction
- Changed the arg type for move_block/look_block from scen_data_iterator<terrain_type> to
terrain_type &
- Added a utility module
- Added a utility that glues outdoor sections into a multi_array
- Added a mechanism for the creation/storing of terrain properties through the use
of terrain_property_maps. The supported properties are: light, corner and cliff

(UBB mangled the indentation)

[Khoth]

Quote:

Originally written by KernelKnowledge12:
This would've have been released/in CVS, but SourceForge decided to change some aspects of their CVS service, which I'll be using as an excuse to switch to SVN.

Surely they haven't changed it enough that you can't commit the changes you do have? In fact, changing to SVN gives even more reason to commit - whatever script you use to convert your history will work much better if you don't have a load of uncommited changes lying around, surely?

I'm with Kelandon here. Release something, anything, even if it's not particularly useful yet.

[Kelandon]

*prod*

 

Signs of life?

[KernelKnowledge12]

Quote:

Originally written by Kelandon:
*prod*

Signs of life?

I have not had much time to work on this, contrary to what I expected. I cannot remember when, but I added menu generation to the DSEL, cleaned it up, added a very quick document abstraction and factored it out into its own package. The view concepts and the directory tree for suncome were changed a bit. The document handling function objects were replaced by the document abstraction. I think that is all. I will not have any time to work on this for at least a few months.