legacy "hole" not supported anymore

pimax

Member
Hi guys, in legagy openbor, a level could spawn a standard hole using hole.gif with just "hole xpos"

it seems it was supported for a very long time alongside with the new hole syntax "hole xpos zpos etc......" but now I cant figure how to display the old hole.gif or even spawn the hole itself. the engine just ignores the old hole syntax and from what I understand the new syntax will not make use of hole.gif sprite but requires you to creates new panes with holes in it instead ?

is there an equivalent to use the old "hole" without creating new panes now?

Thanks a lot.
 
I could restore them by simply uncommenting the openbor.c code that used managed them, however it would be great to make it work with new hole management so both world could work .
3 places to uncomment, just search for keyword "holesprite" in the code and you will find them quickly.


suggestion:
+update the hole method to handle a sprite to load for the hole so we can detect if we use a panel hole or a sprite hole that needs to be drawn on top of any panel.
+make default values to keep original bor game intact and displaying holes
+store if its a sprite hole of panel hole in the addhole method so we can identify how to draw them
 
Working solution that i built and tested.
it works for level commands:
hole 1900 (bor legacy)
hole 2300 244 11 0 199 287 45 (current build, invisible hole)
hole data/sprites/hole2 490 244 11 0 199 287 45 (upgrade i did to load any custom sprite hole anywhere in the level instead of using panels with holes)



in openbor.h change the s_terrain struct to accept a sprite identifier (to be optionally drawn later)
typedef struct
{
/*
Hole/Wall structure.
2013-12-07
Damon Caskey
*/
float depth;
float height;
float lowerleft;
float lowerright;
float upperleft;
float upperright;
float x;
float z;
int type;
int sprite; // store a sprite to be drawn if != -1
// Meta data.
s_meta_data* meta_data; // User defiend data.
int meta_tag; // User defined int.
} s_terrain;


in openbor.c change the addhole function to store a sprite identifier
static void addhole(float x, float z, float x1, float x2, float x3, float x4, float depth, float alt, int type, int sprite)
{
__realloc(level->holes, level->numholes);
level->holes[level->numholes].x = x;
level->holes[level->numholes].z = z;
level->holes[level->numholes].upperleft = x1;
level->holes[level->numholes].lowerleft = x2;
level->holes[level->numholes].upperright = x3;
level->holes[level->numholes].lowerright = x4;
level->holes[level->numholes].depth = depth;
level->holes[level->numholes].height = alt;
level->holes[level->numholes].type = type;
level->holes[level->numholes].sprite = sprite;
level->numholes++;
}

in openbor.c change the handling of "hole" command case to handle: legacy bor.pak + loading of any new hole sprite + invisible hole (current build)
case CMD_LEVEL_HOLE:
if (arglist.count == 2) //bor legacy with default hole sprite
{
float wall_x = GET_FLOAT_ARG(1);
int default_hole_sprite = loadsprite("data/sprites/hole", 0, 0, pixelformat);
addhole(wall_x, 244.0f, 11, 0, 199, 287, 45, 0, 0, default_hole_sprite);
}
else if (!isdigit((unsigned char)GET_ARG(1)[0])) //upgrade use any hole sprite
{
const char* sprite_path = GET_ARG(1);
int custom_hole_sprite = loadsprite((char *)sprite_path, 0, 0, pixelformat); // Cast to char *
addhole(GET_FLOAT_ARG(2), GET_FLOAT_ARG(3), GET_FLOAT_ARG(4), GET_FLOAT_ARG(5), GET_FLOAT_ARG(6), GET_FLOAT_ARG(7), GET_FLOAT_ARG(8), GET_FLOAT_ARG(9), GET_FLOAT_ARG(10), custom_hole_sprite);
}
else // invisible hole
{
addhole(GET_FLOAT_ARG(1), GET_FLOAT_ARG(2), GET_FLOAT_ARG(3), GET_FLOAT_ARG(4), GET_FLOAT_ARG(5), GET_FLOAT_ARG(6), GET_FLOAT_ARG(7), GET_FLOAT_ARG(8), GET_FLOAT_ARG(9), -1);
}
break;


in openbor.c change the exit_hole condition to add -1 at the end of the addhole function call :
if(exit_hole)
{
addhole(level->width, PLAYER_MAX_Z, -panel_height, 0, 1000, 1000, panel_height, 0, 0, -1);
}

in openbor.c and the void draw_scrolled_bg, replace the commented code with :
s_drawmethod *pscreenmethod = &screenmethod;
for (i = 0; i < level->numholes; i++)
{
if (level->holes.sprite >= 0)
{
spriteq_add_sprite((int)(level->holes.x - screenx + gfx_x_offset), (int)(level->holes.z - level->holes.depth - screeny + gfx_y_offset), HOLE_Z, level->holes.sprite, pscreenmethod, 0);
}
}
 
Last edited:
looks like the forum doesnt like to copy paste code and removes "" so here is a screenshot. I hope this can help devs to resotre bor legacy holes that are simply not active with current build and gives the game more flexibility to draw holes from any sprite and anywhere in a level.

1720046580248.png
 
looks like the forum doesnt like to copy paste code and removes "" so here is a screenshot. I hope this can help devs to resotre bor legacy holes that are simply not active with current build and gives the game more flexibility to draw holes from any sprite and anywhere in a level.

View attachment 8527

Where did you get the idea the forum won't take code? We have specific functionality built entirely around posting code samples. See here:


As for supporting legacy functionality - sorry, but that's a flat no. We towed that line for almost twenty years. We're not doing it any more.

DC
 
Current hole spawning with custom dimensions is 999 times better than a the og beats of rage pre stablished dimensions hole.
in the code I also gave solution for "custom hole dimension" and spawn from any sprite and anywhere in the level, you don't have to draw them in your panels. so this is an improvement to give more flexibility.
What if you want to have 5 different holes in you level ? instead of making tons of panels, just make 5 holes and put them where you want.

I get that people are allergic to mentioning "legacy support" but lets present things differently and forget about the title of this topic as the solution provided best feature is actually an improvement
You can put a hole from any sprite, anywhere in the level.

Correct me if I am wrong but right now you have to draw the holes in your panels. I personally find this very cumbersome as a hole should be an entity and not a panel with invisible hole.

So It does it all, support original BOR game, support current hole spawning (invisible hole, the actual hole must be drawn in panels),
plus new feature: instead of having panels with your holes, you can spawn them from any sprite and dimensions that you want and anywhere.
if you want to change your hole location, you don't have to redraw full panels, you just need to move the hole coordinates.


Current engine hole usage (doesn't draw hole sprite and only creates an invisible hole):
hole {xpos} {zpos} {upperleft} {lowerleft} {upperright} {lowerright} {depth} {alt} {type}

Suggested code above can handle:

hole {spritePath} {xpos} {zpos} {upperleft} {lowerleft} {upperright} {lowerright} {depth} {alt} {type} (will draw sprite of spritePath where you want it)
hole {xpos} {zpos} {upperleft} {lowerleft} {upperright} {lowerright} {depth} {alt} {type} (identical to current engine making invisible hole, no change for users )
hole {xpos} (with just 4 extra lines of code you can add back support to original BOR game)


Again this is just a suggestion for fix /improvement. I personally don't mind if you want it or not. I can keep this for my own work.
 
Last edited:
I get that people are allergic to mentioning "legacy support"
This is a claim that has no support. If this were true, the devs would have already dropped all support for legacy content.

If I can give you some advice, bring a suggestion for an addition to the engine at the same time that you make a statement - notice that you don't say "you think people are allergic to support for legacy content", you state that, firmly - makes no sense. In fact, it is somewhat disrespectful to the devs who work on it.

I can't speak for the official team as I'm no longer part of it but, for as long as I've known the team, this type of behavior is not very well regarded.

Suggestions are always welcome, but they can be denied and it is part of the game. But asserting/imputing something in the community is not a good thing to do.

Just my two cents
 
And just to make my opinion clear, I even find it interesting to be able to have a separate sprite from the scene for the hole. What bothers me is not your idea itself, it's the way you present it.
 
@O Ilusionista,

I don't think any offense was meant on his part. The words may seem a bit harsh in certain cultures, but here it doesn't really come off that way. However, to address the point...

Correct me if I am wrong but right now you have to draw the holes in your panels.

There's no need to draw holes in your panels at all, and we'd never advise you do that. There are several ways to insert visual holes, the simplest being fglayers, which are unlimited and part of the level sheet right next to holes, with pixel placement, priority control, optional special effects, repetition, etc. already available. Everything you need to add a hole.

Your proposal isn't bad or anything, there's just no justification for it. The engine already provides the functionality you want. Using layers is simple and direct. It's not a hack, it's not a workaround, it's exactly how we intend for it to be - the maximum possible separation of design and content.

DC
 
@O Ilusionista,

I don't think any offense was meant on his part. The words may seem a bit harsh in certain cultures, but here it doesn't really come off that way. However, to address the point...



There's no need to draw holes in your panels at all, and we'd never advise you do that. There are several ways to insert visual holes, the simplest being fglyaers, which are unlimited and part of the level sheet right next to holes, with pixel placement, priority control, optional special effects, repetition, etc. already available. Everything you need to add a hole.

Your proposal isn't bad or anything, there's just no justification for it. The engine already provides the functionality you want. Using layers is simple and direct. It's not a hack, it's not a workaround, it's exactly how we intend for it to be - the maximum possible separation of design and content.

DC

thanks a lot, i will look into fglayers, its something I completely overlooked and it seems to be an amazing feature that could help me a lot.

I agree with @O Ilusionista, please forgive my hastyness and not proper wording. You can delete this thread to avoid confusion.

To give you a bit more context, I actually started to work with the first orginal DOS version of openbor (because it could run in webrowser via a light weight emulator) and used the original BOR game as reference to build my own. unfortunatly, original engine is too limited for todays standard so I tried different newer version of the engine that could run the BOR.pak without issue but always met bugs. I started to look into the current code just very recently. This is probably my mistake because I am not educating myself enough on latest openbor features. I am trying to catch up. I also have very pressuring time constraint to complete my simple game with all the features I really need within a month, but I will reconsider and take more time to look at the best current practices and likely much better ways to build a game compared to the orginal one.

My intentions were first trying to find help with some problems I encounter or make suggesstions with things i thought were usefull for the engine, trying to contribute. I am just too hasty but very rational and will always be in favor of what is in the best interest of the engine or look at the better solution.

Don't take offense please, I will try to apply myself more and present things better.
 
Back
Top Bottom