OpenBOR v3.0 Build 4453 (Windows/Wii/PSP)

[O Ilusionista]

Dc, have the Manu position changed on this build? Look at this:

 

[DCurrent]

I didn't make any menu changes - at least not intentionally.

DC

 

[White Dragon]

Hello DC,
I agree on your change to make the mod strictly 32bit and make COLOURDEPTH deprecated
Instead I disagree on making deprecated REMAP.
The REMAP command is very different from ALTERNATEPAL (and useful).
I noticed that the convert_map_to_palette () function you also deleted that has some utility.
Also, REMAP was a useless function, in r4453.
So I restored convert_map_to_palette() and workable remap, also keeping your 32bit change intact.
I also think it might have been a mistake to delete convert_map_to_palette ().
Now everything is working in r4456.

 

[O Ilusionista]

So remap is working again? Its kinda confusing if one dev makes something and other changes it.
I think this modifications should be discussed before. And what is the use of remap, when alternatepal works way better?

 

[DCurrent]

So remap is working again? Its kinda confusing if one dev makes something and other changes it.
I think this modifications should be discussed before. And what is the use of remap, when alternatepal works way better?

In 8-bit mode, remap worked by shifting colors within a palette. That's very different from alternatepal, which actually switched the palette.

In any case, I cannot do anything right now - one my bike with a phone. When I get back, I'll be removing the Remap support, and I don't want to see it added back again.

DC

 

[White Dragon]

But why? It's a useful way in 32bit too.
I think that it's an important command that it exists in a 32bit mod too, please don't delete the convert_map_to_palette() function/remap cmd.
I don't agree with this choice for remap because this is a different and useful cmd..
For me it's useful to have both ways...

 

[White Dragon]

So remap is working again? Its kinda confusing if one dev makes something and other changes it.
I think this modifications should be discussed before. And what is the use of remap, when alternatepal works way better?

In 8-bit mode, remap worked by shifting colors within a palette. That's very different from alternatepal, which actually switched the palette.

DC

It works in 32bit and it's useful

 

[Mr.Din]

So remap is working again? Its kinda confusing if one dev makes something and other changes it.
I think this modifications should be discussed before. And what is the use of remap, when alternatepal works way better?

In 8-bit mode, remap worked by shifting colors within a palette. That's very different from alternatepal, which actually switched the palette.

DC

It works in 32bit and it's useful

If you don't mind me asking what makes remap useful in comparison to Alternatepal? I find the latter to be more useful and seamless as someone who makes palettes very often.

 

[DCurrent]

If you don't mind me asking what makes remap useful in comparison to Alternatepal? I find the latter to be more useful and seamless as someone who makes palettes very often.

I'd like to know this myself. I'm sorry you disagree WD, but in terms of functionality there is nothing you can do shifting within a color table that you can't do swapping the color table.

Just so everyone knows what we're talking about here, I'll provide a quick explanation of what the various terms mean, what the changes are, and why.

Remap - Remap is the original model text attribute to create alternate color sets. At the time, OpenBOR was still an 8bit color application only. In other words, everything on the screen was derived from one global 256 color table. To add color choices to an model, the alternate colors had to exist as entries elsewhere in that global table. This is where Remap came in. For each remap instance, two sprites identical to each other in every way except for colors would be compared to each other. Assuming the desired alternate colors could be found in the global table, then the pixels for sprites in that model would be "remapped" to display colors from these alternate entries.

It's a VERY finicky process, but a pretty brilliant solution for the time. When 16 and 32 bit color modes were introduced, Alternatepal was created as a replacement (more on that below). Since 8bit mode still existed and was the default, we had to keep Remap for backward compatibility. However, in 16 or 32bit mode, it would actually work similarly to Alternatepal below. Images are still read in by pixel, but then a new color table is created and applied (see below).  Recently, 8bit and 16bit modes were removed outright, so there is no requirement to keep Remap. Because of the extra code needed for backward compatibility support of Remap, and the confusion often noted by authors about having two different commands for alternate color set creation, I intend to remove Remap and all of its supporting code.

Remap Illustrated. Pixels start out pointing to a given entry in the color table, but as the name implies, are "remapped" to reference entries elsewhere in the same table. This process was mandatory at the time it was conceived, but has proven very confusing to use and is now obsolete.

Palette & AlternatePal - In either 16bit (discontinued) or 32bit color modes, every model, background layer, etc. is given its own 256 entry color table. From a technical standpoint, Palette and Alternatepal work by reading the color table from an image of your choice. The image's pixel contents are irrelevant - it could be single pink dot. All that matters is the color table within. OpenBOR extracts this color table and applies it to the model's sprites.

Palette allows you to determine a default color table (perfect for smart palette sprite sets). It's not required, but is highly recommended. Otherwise OpenBOR will use the color table from whatever image is in that model's very first frame. Alternatepal is to define color tables for the alternate color sets.

Color table swap example. The pixels in each sprite set always point to the same color table entry number. To get different colors, just swap in another table with different RGB values.

Remap (entity property via script) - Don't let its name fool you. The remap entity property accessed by script is a naming artifact and doesn't have anything to do with actually creating the color sets. It simply indicates or selects the color set in use by index for an entity. 0 = default, 1 first alternate set, and so on... This property is not being removed or changed.

Remap (drawmthod) - Same as the remap entity property, except for drawmethod. No changes to this functionality are being made.

Hope this helps explain everything to you guys.

DC

[attachment deleted by admin]

 

[White Dragon]

If you don't mind me asking what makes remap useful in comparison to Alternatepal? I find the latter to be more useful and seamless as someone who makes palettes very often.

REMAP is a completely different function.
If I have the same palette for my alternate sprites and I want to change just the color map,
why should I change hand by hand the palette?
Is it not more useful to have an automatic function that does this for us?
Here is the utility of REMAP!! 

I'm sorry you disagree WD, but in terms of functionality there is nothing you can do shifting within a color table that you can't do swapping the color table.

DC but why I have to change hand by hand a new Table and I can't use an automate function (like remap)?

I confirm the utility of REMAP and I vote to leave it there, where it is, because it does not hurt anyone and I repeat: it's useful and it saves labor.
Often they never exceed 256 colors for an entity.
I am convinced that REMAP and ALTERNATEPAL should coexist, because they have different functions and different utilities.

 

[DCurrent]

...

WD, you have to be the first person in the history of graphic design to prefer editing by pixel over editing by palette. When you have the privilege of swapping tables, you always take it. You have to edit by hand either way - why in the world would you want to bother recoloring sprites when you can just edit the table directly and move on.

Removing Remap gets rid of superfluous code and confusing backward compatibility that has been an issue for years. It DOES hurt us, and always has because we have lost and continue to lose potential contributors specifically over the initial confusion and frustration Remap causes.

Out of respect for you as a coder, I would prefer not to "pull rank" and override you, so I'll do this - we'll give Plombo a week to weigh in (I'll send him a msg). If he agrees to keep Remap, then I'll do it. But if he doesn't or doesn't answer at all, it has to go.

DC

 

[Plombo]

Wow. This is a lot to take in. But the biggest thing, to me, is the news that 8-bit and 16-bit color modes were removed recently. I really should keep up with these things better!

Anyway, what this really comes down to is: are we still trying to maintain backwards compatibility at all? Specifically, BC with games made for the original BOR engine.

If so, we should keep remap for the sake of compatibility with existing games. Most games with 8-bit color should more or less work in 32-bit mode, but removing remap would break those games much more visibly.

To me, the BC argument is the main reason to keep remap around; I don't really buy White Dragon's argument that it's easier to use than alternatepal for new games.

The other thing that would factor into my opinion here is: how much maintenance burden is remap adding? And if it's a lot, could that maintenance burden be lifted with a different implementation instead of removing the feature entirely? I'll need to actually look at the code to answer those questions, so it'll be a little longer before I have an answer to this. Sorry.

 

[DCurrent]

...

Thanks for the answer...

Anyway, what this really comes down to is: are we still trying to maintain backwards compatibility at all? Specifically, BC with games made for the original BOR engine.

Personally I've always hated maintaining BC at the cost of moving forward, but as a responsible developer I believed we should do it anyway. However, some recent epiphanies changed my mind.

• I've noticed that for the most part, authors refuse to switch to the new engine if there is even the slightest BC issue, and because we're only human, there always is. This is understandable on their part, but it also means, at least to me, that we are spinning our wheels on the BC thing for no reason at all.
• Just recently, we had an influx of promising new blood, and every single one of them ran smack into the same issue - the legacy Remap system. I've seen this happen over and over through the years - especially with people coming from other engines like Mugen wanting to give OpenBOR a try. They hit the Remap wall, and it gives them a bad impression right off the bat. Us saying, - "oh don't worry, that's not the REAL OpenBOR, just add colordepth 32, and do this thing instead..." it doesn't cut it. They're already gone.

So essentially, my opinion is that we have now reached the point BC hurts much more than it helps. Why work so hard to make the engine play old BOR clones when we can just offer up the old engine? People tend to be more understanding of that than they are of pointless overlap and obfuscation because of BC.

Now all that said, I don't think we just break BC any time it slightly inconveniences us... but if there is a specific issue that BC is causing us, then I think BC should take a back seat to forward development. Remap is one of those issues, and thus why I think it should be removed. That's my opinion on the BC caveat.

The other thing that would factor into my opinion here is: how much maintenance burden is remap adding?

To be perfectly honest, there's not much overhead at all code wise. There WAS a ton for running the three separate modes, but its all gone now that we're 32bit only. What remains is a ~30 line function that converts Remap to palettes for BC in 32bit mode, and obviously the command interpreter inputs. I just happen to think because of the issues above, less is always more.

DC

 

[erf_beto]

just adding my probably-not-even-worth 2 cents here but...

Good explanations for reasoning. My suggestion would be to remove remap from manual and no longer mention it officially (but still keep it in code) this should fix new starters issues ?

I think this would be ground zero for the change. There are many "legacy" features and tutorials in the manual and forums that probably confuses the new modders. You could keep both alternatepallete and remap that way.

Backwards compatibility is nice, but I feel it has cramped the development of the engine at some points during its history. Either way, removing remaps don't just affect very old mods - even those made yesterday won't work anymore. But it's like DC said, usually modders stay with the version they started development, only moving forward when a new feature is added and they (desperatly) need it.

For instance, zvitor's mod has over 80 playable characters, all of which use remap. I really don't see him changing all that just to say his mod works in the new version, unless there's an incentive to move forward (like increasing the skipselect/allowselect limit that has prevented him from doing a proper player select screen).

If the change does happens, and since this seems such a divisive issue, what if you start calling this new version 4 .0  (or at least 3.1)? I'm not sure what's the proper naming convention though...

 

[White Dragon]

The other thing that would factor into my opinion here is: how much maintenance burden is remap adding? And if it's a lot, could that maintenance burden be lifted with a different implementation instead of removing the feature entirely? I'll need to actually look at the code to answer those questions, so it'll be a little longer before I have an answer to this. Sorry.

Thanks Plombo!

I don't really buy White Dragon's argument that it's easier to use than alternatepal for new games.

Not easier but different from alternatepal and useful, depending from kind of entitiy. For a simple entity <256 color it's very useful (example misc entities, etc..)

In photoshop no need to recolor whole sprite, just change color with paint bucket tool with contiguous unchecked for comfort.

Furthermore removing REMAP it breaks many recent mods too..

 

[DCurrent]

I haven't prepared a release, but it is tested and in source code - Palette and Alternatepal model attributes will now directly accept .act files. Adds a bit of consistency with Palette level attribute which has always required .act file type. This should also help out people coming from other engines since that's the standard.

 

[Mr.Din]

My vote goes to removal. There's plenty of previous versions to use for the older features, at some point the engine is going to have to move on. I wasn't very convinced by WD's argument either to be honest, remap just sounds more trouble than it's worth to work with when the 8bit and 16bit modes now gone.

 

[bWWd]

IMO taking newcomers issues as some actual reason to change engine is a bit strange, how about moving "remap" position in manual and place it somewhere lower so its after "alternatepal" and explain that "remap" is old version not used that much anymore but kept for complatibility reasons with older mods.
I dont even know if original BOR plays right on current builds, but removing feature is weird if it doesnt really collide with implementing other features, theres little info on why its being removed , no actual reason like "i wanted to code in XYZ but dealing with "remap" makes this very hard and almost impossible" is better explanation than "it was alot of code and now exe will be smaller" - we dont care how big that exe is but if it means something else i would like to know more, maybe some color related feature is planned and "remap" command is interfering a lot.
New users will have to learn anyway, mugen was left with its docs and manuals and nobody changed anything to make it easier on newcomers.
Im not so active around at the moment , i have i think only 1 mod using remap but it doesnt bother me that much personally, but there are some other mods out there with "remap" command inside which will simply crash which is very bad.
If it works then dont fix it, just leave it , if its hard to keep it up to date with new features then dont keep it up to date, just keep "alternatepal" up to date and old versions of"remap" , but i realize its not always that simple so im wondering whats the actual reason to remove such basic  command completely.

 

[Plombo]

Thanks for your input, everyone. In the end, my opinion is that we should keep the remap command.

I've noticed that for the most part, authors refuse to switch to the new engine if there is even the slightest BC issue, and because we're only human, there always is. This is understandable on their part, but it also means, at least to me, that we are spinning our wheels on the BC thing for no reason at all.

I agree with all of this except the conclusion. It's true that many authors won't switch to the latest engine, but breaking BC more often won't improve that situation. If anything, it will make it worse by increasing the effort needed to migrate from an old version to a new one.

Just recently, we had an influx of promising new blood, and every single one of them ran smack into the same issue - the legacy Remap system. I've seen this happen over and over through the years - especially with people coming from other engines like Mugen wanting to give OpenBOR a try. They hit the Remap wall, and it gives them a bad impression right off the bat. Us saying, - "oh don't worry, that's not the REAL OpenBOR, just add colordepth 32, and do this thing instead..." it doesn't cut it. They're already gone.

If they ran into the legacy "remap" command, that means they were looking at some old games, right? Removing the "remap" feature won't change the content of those games; it will just break them. And even if deprecation is confusing to new people, won't it be more confusing if those games just don't work properly? It's also not a great look for the engine when a bunch of games designed for it don't work -- I wouldn't expect most players to keep track of which games are supposed to work with which engine versions.



And in the end, that's why I think we should keep remap. Removing old features is likely to just make things more confusing and alienate more people. It makes sense to remove legacy features if they make the code harder to develop and maintain, but that doesn't seem to be the case here.

 

[DCurrent]

...

So be it. In which case, at the very least, we need to build new basic tutorials and nuke anything that mentions Remap.

That said, I've already moved on to something that IS a huge maintenance nightmare and growing bigger - those ridiculous mapstrings. I think I've found a fairly elegant solution for them, one that doesn't require hundreds of micro-functions like my original idea. I started implementing last fall before being forced to step away from heavy development for a while.

[list type=decimal]
[*]No more mapstrings. No more strings period. That should never have been allowed, but it is what it is. Anyway, list items are accessed directly by integer constants. This puts the load onto openborconstant(), which gives us a "one stop shop" place to optimize. As a little side benefit, it also enables enumerating property collections, though that's probably not too useful outside of debugging experiments.
[*]Elimination of multiple arguments and single line access to sub properties. Accessing sub properties in the same function call as parent properties was a monumentally stupid idea, and I can say so because I'm the one who did it. Instead, sub properties are now child properties accessed by pointer. The parent property is used to get a handle (pointer) for the sub property collection, then you use that to access the child property, and so on down the line. I'll provide an example below. It's more on screen steps, but faster, simpler, and most importantly, future proof. Expansion is just adding something to the list, or a new child if its a collection. Check out the new animation, attack, body, or level properties in progress within the source code to see what I mean.
[*]Breaking down the files themselves. Openbor.c and openborscript.c are just silly. I'm in process of breaking openborscript.c down, and have already reduced it to "only" ~14,000 lines. Smaller, dedicated function libraries will go a long way to helping development.
[/list]

Accessing child properties by handle. In this case, we want some level properties, which is a child of level sets. We get the level set handle by index, and from there continue breaking down further until we get to the properties we need.

int     text_font;
int     text_index;
int     text_x;
int     text_y;
int     text_z;    
    
int     set_current_index;
int     level_current_index;
void    set_handle;
int     set_levels_count;
void    set_levels_handle;
void    level_handle;
float   level_auto_scroll_x;
float   level_auto_scroll_y;
float   level_gravity;

// Get the current set, and level indexes.
set_current_index   = openborvariant("current_set");
level_current_index = openborvariant("current_level");

// Get the handle of current set.
set_handle = get_set_handle(set_current_index);

// How many levels are in the set?
set_levels_count = get_set_property(set_handle, openborconstant("SET_PROP_LEVELS_COUNT"));

// Get the levels collection handle, 
// then get level handle of the current
// level in play.
set_levels_handle   = get_set_property(set_handle, openborconstant("SET_PROP_LEVELS_HANDLE"));
level_handle        = get_level_handle(set_levels_handle, level_current_index);        

// Let's grab some level properties.
level_auto_scroll_x = get_level_property(level_handle, openborconstant("LEVEL_PROP_AUTOSCROLL_X"));
level_auto_scroll_y = get_level_property(level_handle, openborconstant("LEVEL_PROP_AUTOSCROLL_Y"));
level_gravity       = get_level_property(level_handle, openborconstant("LEVEL_PROP_GRAVITY"));

// Output information to user.
text_font   = 1;
text_index  = 0;
text_x      = 10
text_y      = 40;
text_z      = openborconstant("HUD_Z");

settextobj(text_index++, text_x, text_y += 10, text_font, text_z, "Current Set: " + set_current_index);
settextobj(text_index++, text_x, text_y += 10, text_font, text_z, "Level Count: " + set_levels_count);
settextobj(text_index++, text_x, text_y += 10, text_font, text_z, "Current Level: " + level_current_index);
settextobj(text_index++, text_x, text_y += 10, text_font, text_z, "Autoscroll X: " + level_auto_scroll_x);
settextobj(text_index++, text_x, text_y += 10, text_font, text_z, "Autoscroll Y: " + level_auto_scroll_y);
settextobj(text_index++, text_x, text_y += 10, text_font, text_z, "Gravity: " + level_gravity);

Now that I think about it, I might go even further and return the handle of the specific property itself rather than a value - then a single "get" and "set" method can return or mutate values respectively . It would add a step to accessing properties, but would mean only one case list per property set instead of two, and potentially MUCH more sophisticated error trapping to help out module authors.

Either way, When it's all finished - I'm for wiping the mapstrings and all associated property access off the planet. It's a backward compatibility break I think is well worth the benefit.

DC