OpenBOR Split Screen - Prototype Test

Well, screen lags behind characters when running, i didnr changed anything
I noticed that lag during some tests with NSX on the standard screen , i figured it was normal behavior, i made a really long level to test how far behind the screen would get & never found a fix
 
@bWWd

Man, please could you test this new code in your game? I changed the way that the script calculates the screen velocity, now it's based on how many times the code runs on each cycle instead of adding more pixels, which was causing lags.


Here's a small test with "scrollspeeds" from 1 to 5. I saw only 1 lag at 2:18 maybe due to the high screen velocity, but most time I can see only a screen tearing due to the v-sync disabled. It would be good to see how it will work in a high resolution game like yours.

Thanks!

 
Hi buddy, excellent work. I'll try to add the script to Star Wars Openbor, many thanks to you.
There are so many cool features to add to Openbor and yes this will be better if they are integrated into a game :) .
Maybye one day, a DBZ game will be possible with this fabulous script:
 
Hey i tested with that editpack mod you provided and changed mary walk to 29, then scrollspeed to 5, works perfectly, so i also quickly adapted it to my mod , to be honest you already did everything needed and just moved updated to my scripts folder , i used scrollspeed 8 and works very nice for walking or running , theres no screen tearing so looks like you fixed this , thanks a lot for that !!! This is totally useable to create games on top, are there some known issues ? I dont see any so far.
So what spawning methods do you recommend for these types of levels ? spawner entity that would be invisible nomove enemy type scrolling with the level ?

Oh i have one question, im using fglayers as hearts/lives and remove them each time player loses life, but they scroll with the level now in splitscreen mode, what should i change to make them work as a hud ? On the screen i attached you can see the hearts moved behind portrait cause i moved forward a bit with player1 character.
This is their fglayer commands:
###PLAYER1
fglayer data/bgs/heart.gif 1 1 1 230 -90 0 0 1 1 1 0
fglayer data/bgs/heart.gif 1 1 1 185 -90 0 0 1 1 1 0
fglayer data/bgs/heart.gif 1 1 1 140 -90 0 0 1 1 1 0
###PLAYER2
fglayer data/bgs/heart.gif 1 1 1 550 -90 0 0 1 1 1 4
fglayer data/bgs/heart.gif 1 1 1 505 -90 0 0 1 1 1 4
fglayer data/bgs/heart.gif 1 1 1 460 -90 0 0 1 1 1 4
###PLAYER3
fglayer data/bgs/heart.gif 1 1 1 870 -90 0 0 1 1 1 4
fglayer data/bgs/heart.gif 1 1 1 825 -90 0 0 1 1 1 4
fglayer data/bgs/heart.gif 1 1 1 780 -90 0 0 1 1 1 4
###PLAYER4
fglayer data/bgs/heart.gif 1 1 1 1190 -90 0 0 1 1 1 4
fglayer data/bgs/heart.gif 1 1 1 1145 -90 0 0 1 1 1 4
fglayer data/bgs/heart.gif 1 1 1 1100 -90 0 0 1 1 1 4
 

Attachments

  • bor - 0003.jpg
    bor - 0003.jpg
    200.3 KB · Views: 9
Last edited:
Hey i tested with that editpack mod you provided and changed mary walk to 29, then scrollspeed to 5, works perfectly, so i also quickly adapted it to my mod , to be honest you already did everything needed and just moved updated to my scripts folder , i used scrollspeed 8 and works very nice for walking or running , theres no screen tearing so looks like you fixed this , thanks a lot for that !!! This is totally useable to create games on top, are there some known issues ? I dont see any so far.
@bWWd
Great, thanks a lot for your tests! There's no known issues at the moment, only some improvements on my list.

Oh i have one question, im using fglayers as hearts/lives and remove them each time player loses life, but they scroll with the level now in splitscreen mode, what should i change to make them work as a hud ? On the screen i attached you can see the hearts moved behind portrait cause i moved forward a bit with player1 character.
I will develop an easy way to change layer properties. For now, you can disable any layer by replacing the "xOffset" with zero inside the script file. Don't forget to set it on both "splitScreen" and "normalScreen" codes.

C:
//FGLAYER 1 - FRONT LAYER
layerID    = 1;
layerZ    = getlayerproperty("fglayer", layerID, "z");
layerV    = getlayerproperty("fglayer", layerID, "xratio");
drawspriteq(getglobalvar("screenP"+player), 0, maxZ+1, layerZ, 0, 0);


@kimono
Hi buddy. I need to finish some adjustments yet, I can apply the script in your game if you want after everything is working fine.
 
That fixes it for me :
drawspriteq(getglobalvar("screenP"+player), 0, maxZ+1, layerZ, getlayerproperty("fglayer", 1, "xratio"), getglobalvar("zOffset"+player));

interesting thing is that you need to set offscreenkill on projectile entities and probably a lot more entities to be like 999999 cause they wont spawn when youre too far from player1.Maybe this script could take care of that somehow and force offscreenkill for entities , but maybe its a bad idea and manual control is better ?

I think ill try to edit it for vertical and horizontal (which doesnt work for now , only vertical works), some games id like to have very wide view and some im fine with side by side.
Since xpos is not available, how do you recommend to detect screen borders on left/right to spawn enemies offscreen 200 pixels to left or right side ?
Yeah i have issues acquiring position of entity on the screen precisely, this doesnt work when you move into the level more cause xpos is not working, defaults to 0:
@cmd settextobj 1 (getentityproperty(getlocalvar("self"),"x")-openborvariant("xpos")) (getentityproperty(getlocalvar("self"),"z")-170) 1 0 "+1" openborvariant("elapsed_time")+120


Also any ideas how to prevent player from walking offscreen when panel just ends, they can run offscreen easily, a wall or maye script to hold them back ?
issues found :


- I think when player 2 was dead and player 1 was picking character then my screen blacked out, so i think that is an issue.
- when player 2 joins the game, then dies, split line still appears(without actual split screen) when player1 runs far away despite player2 being dead.So line should only be active when 2 screens are on.
- Theres an issue when theres only one screen and player walks/runs , the screen starts to follow him too late or too soon depending on direction cause it kinda behaves like if splitscreen was still there maybe ? You can see that when running left theres more screen on side of character than when running right, its not equally the same space on sides and player in the middle like it should be.
 
Last edited:
@bWWd

interesting thing is that you need to set offscreenkill on projectile entities and probably a lot more entities to be like 999999 cause they wont spawn when youre too far from player1.Maybe this script could take care of that somehow and force offscreenkill for entities , but maybe its a bad idea and manual control is better ?
I will do some tests with an automatic management for the offscreenkill, it's a thing that needs to be improved

Since xpos is not available, how do you recommend to detect screen borders on left/right to spawn enemies offscreen 200 pixels to left or right side ?
The original idea of this script was to make a "spawn mechanic" different from beat 'em up games. The idea is to make it more like Sonic or Mario games, where all enemies are spawned at the moment the level starts, similar to an open world, and they will stay on a defined area counting from your spawn location.

Although the xpos is not available, the "x" position of each entity in the level is working. However, I'm testing a code to spawn the enemies inside the "updatelevel" event instead of the level file. This way we can easily use the "xOffset" + "spawn01" instead of the native "xpos".

Also any ideas how to prevent player from walking offscreen when panel just ends, they can run offscreen easily, a wall or maye script to hold them back ?
Yeah, it's an feature on my "to do" list. It's possible to hold them back locking the "x" value, but I will try to use walls/platforms first.

- I think when player 2 was dead and player 1 was picking character then my screen blacked out, so i think that is an issue.
- when player 2 joins the game, then dies, split line still appears(without actual split screen) when player1 runs far away despite player2 being dead.So line should only be active when 2 screens are on.
- Theres an issue when theres only one screen and player walks/runs , the screen starts to follow him too late or too soon depending on direction cause it kinda behaves like if splitscreen was still there maybe ? You can see that when running left theres more screen on side of character than when running right, its not equally the same space on sides and player in the middle like it should be.
A lot of thanks for your bug reports, I will take a look in one by one :)
 
Hey guys, I did some updates and fixes to the split screen code. Many issues were solved and now I added some level file's functionality to the update level event.
In the current state it's possible to develop a game normally, the code has the basic functions to start the level, spawn enemies and finish after all of them are defeated.

Of course, there's many things to improve like changing the player's spawn location, zoom and others. I will gradually adding these features.

@bWWd
I used your reports as a reference to fix the previous issues:

interesting thing is that you need to set offscreenkill on projectile entities and probably a lot more entities to be like 999999 cause they wont spawn when youre too far from player1.Maybe this script could take care of that somehow and force offscreenkill for entities , but maybe its a bad idea and manual control is better ?
After many tests, I think that for projectiles it's better to set the offscreenkill individually, it can be inside the entity's header or directly inside the spawn script (this second option I'm using on SORX to automatically apply many other properties to projectiles).

For enemies, now the level update event can handle it automatically.

Since xpos is not available, how do you recommend to detect screen borders on left/right to spawn enemies offscreen 200 pixels to left or right side ?
Now the "artificial xpos" is fully working, you can call it using getglobalvar("xPos") instead of using openborvariant("xpos").

Also any ideas how to prevent player from walking offscreen when panel just ends, they can run offscreen easily, a wall or maye script to hold them back ?
For now, I manually created two walls at the beginning/ending of the levels, I think it's more simple to handle. Note that the split screen script doesn't support the mid-level blockades used during the "waits".

However, once you are using the level update instead of the native "level file", you have more freedom to use scripts and can create it manually using scripted platforms/walls/obstacles easily.

- I think when player 2 was dead and player 1 was picking character then my screen blacked out, so i think that is an issue.
- when player 2 joins the game, then dies, split line still appears(without actual split screen) when player1 runs far away despite player2 being dead.So line should only be active when 2 screens are on.
Fixed.

- Theres an issue when theres only one screen and player walks/runs , the screen starts to follow him too late or too soon depending on direction cause it kinda behaves like if splitscreen was still there maybe ?
It didn't happen to me yet, but I think it was solved after the last fixes. Please, it would be good if you could do a test.

You can see that when running left theres more screen on side of character than when running right, its not equally the same space on sides and player in the middle like it should be.
Fixed, now the screen is automatically centered according to how many screens are active.

Here's the new file:

Here's a test:
 
Last edited:
Due to the big size of the updated.c code, I will post only the new added events.

Update level, this is an example of how you can code a level inside the update level event.
C:
void main()
{//Simulate the native level files functionality
    float xPos = getglobalvar("xPos");
    void vSpawn;
    int xSpawn;
    int ySpawn;
    int zSpawn;
    int at;

    at = 300;

    if(xPos > at){
        if(!getlocalvar(at)){
            vSpawn = "Ralf";
            xSpawn = 520;
            ySpawn = 0;
            zSpawn = 230;
            spawn01(vSpawn, xSpawn, ySpawn, zSpawn);

            //USED ONLY TO FINISH THE PROCESS
            setlocalvar(at, 1);
        }
    }

    at = 600;

    if(xPos > at){
        if(!getlocalvar(at)){
            vSpawn = "Ralf";
            xSpawn = 520;
            ySpawn = 0;
            zSpawn = 230;
            spawn01(vSpawn, xSpawn, ySpawn, zSpawn);

            //USED ONLY TO FINISH THE PROCESS
            setlocalvar(at, 1);
        }
    }

    at = 900;

    if(xPos > at){
        if(!getlocalvar(at)){
            vSpawn = "Heavy";
            xSpawn = 520;
            ySpawn = 0;
            zSpawn = 230;
            spawn01(vSpawn, xSpawn, ySpawn, zSpawn);

            vSpawn = "Heavy";
            xSpawn = 560;
            ySpawn = 0;
            zSpawn = 210;
            spawn01(vSpawn, xSpawn, ySpawn, zSpawn);

            //USED ONLY TO FINISH THE PROCESS
            setlocalvar(at, 1);
        }
    }

    at = 1200;

    if(xPos > at){
        if(!getlocalvar(at)){
            vSpawn = "Yashiro";
            xSpawn = 520;
            ySpawn = 0;
            zSpawn = 210;
            spawn01(vSpawn, xSpawn, ySpawn, zSpawn);

            vSpawn = "Yashiro";
            xSpawn = 560;
            ySpawn = 0;
            zSpawn = 220;
            spawn01(vSpawn, xSpawn, ySpawn, zSpawn);

            vSpawn = "Yashiro";
            xSpawn = 600;
            ySpawn = 0;
            zSpawn = 230;
            spawn01(vSpawn, xSpawn, ySpawn, zSpawn);

            //USED ONLY TO END THE CURRENT LEVEL AFTER THE LAST ENEMIES ARE KILLED
            endLevel();

            //USED ONLY TO FINISH THE PROCESS
            setlocalvar(at, 1);
        }
    }
}

void spawn01(void vName, float fX, float fY, float fZ, int dir, int map, int mp, int layer, void anim)
{    //spawn01 (Generic spawner)
    //Damon Vaughn Caskey
    //07/06/2007
    //
    //Spawns entity next to caller.
    //
    //vName: Model name of entity to be spawned in.
    //fX: X location adjustment.
    //fZ: Y location adjustment.
    //fY: Z location adjustment.
  
    void vSpawn;
    float xPos = getglobalvar("xPos");

    clearspawnentry();
    setspawnentry("name", vName);
  
    fX = xPos+fX;
    vSpawn = spawn();

    changeentityproperty(vSpawn, "position", fX, fZ, fY);
    changeentityproperty(vSpawn, "direction", dir);
    changeentityproperty(vSpawn, "offscreenkill", 99999);

    //SET CUSTOM MAP
    if(map != NULL()){setspawnentry("map", map);}

    //SET CUSTOM MP
    if(mp != NULL()){setspawnentry("mp", mp);}
  
    //SET CUSTOM LAYER POSITION
    if(layer != NULL()){changeentityproperty(vSpawn, "setlayer", layer);}

    //SET CUSTOM ANIMATION
    if(anim != NULL()){changeentityproperty(vSpawn, "animation", openborconstant(anim));}
  
    return vSpawn; //RETURN SPAWN.
}

void endLevel()
{//Script used to detect the level manager entity and kill him, causing the end of the current level

    /*
    * Caskey, Damon V.
    * 2022-01-26
    *
    * Example function to enumerate the entity
    * collection and take action on each
    * if they meet specfifc conditions.
    */

    void entity_cursor    = NULL();
    int entity_count    = openborvariant("count_entities");
    int entity_index    = 0;
    int exists            = 0;

    for(entity_index = 0; entity_index < entity_count; entity_index++){

        entity_cursor = getentity(entity_index);

        if(!entity_cursor){
            continue;
        }

        exists = getentityproperty(entity_cursor, "exists");

        if(!exists){
            continue;
        }

        if(getentityproperty(entity_cursor, "defaultname") != "Manager"){
            continue;
        }

        /* Take your actions here. Sucking in, doing damage, etc. */
        killentity(entity_cursor);
    }
}

Level file, now it doesn't has too many things to configure, it's used more for layers and walls.
In addition, now all the layers (bglayers/fglayers) are automatically detected by the script, all you need to do is to define how many of them are active by changing the variable "max_fglayer" or "max_bglayer".
Code:
background    data/bgs/street/back.gif 0.5 0 0 0 0 0 -1 1 0 0
panel        data/bgs/street/n01.gif    data/bgs/street/neon01.gif    data/bgs/street/s01.gif
panel        data/bgs/street/n02.gif    data/bgs/street/neon02.gif    data/bgs/street/s02.gif
panel        data/bgs/street/n03.gif    none                none
panel        data/bgs/street/n04.gif    none                none
panel        data/bgs/street/n05.gif    none                data/bgs/street/s05
panel        data/bgs/street/n06.gif    none                none
panel        data/bgs/street/n07.gif    none                none
panel        data/bgs/street/n05.gif    data/bgs/street/clubk        data/bgs/street/s05
fglayer        data/bgs/street/f01.gif 0 1.2 0 0 0 0 0 -1 1 1 0
fglayer        data/bgs/street/f01.gif -200 0.4 0 0 -100 0 0 -1 1 1 0

## DEFINES THE PANEL ORDER
order    fdefecdhfecggdab

## DEFINES THE SCROLLING SPEED
scrollspeed 1

## WALLS USED AT THE BEGINING/ENDING OF THE LEVEL TO AVOID PLAYERS TO GO OFF-SCREEN
wall 0 240 -100 -100 0 0 480 1000
wall 1920 240 0 0 100 100 480 1000

## THIS SCRIPT IS THE CORE FOR THE SPAWN SYSTEM AND OTHER TASKS
updatescript data/scripts/updatelevel.c

## THESE ARE ALL THE MODEL LOADED IN THIS LEVEL (ONLY FOR THE ONES WITH "KNOW" AT THE MODELS.TXT), FLAG 3 IS USED TO UNLOAD ENTITY AFTER THE LEVEL ENDS
load Ralf 3
load Yashiro 3
load Heavy 3

## THIS GROUP IS USED TO STOP THE NATIVE XPOS VARIANT
group 1000 1000
at 0
wait
at 0

## THIS ENTITY IS USED TO MANY TASKS IN THE LEVEL MANAGEMENT, INCLUdING KEEPING THE LEVEL ACTIVE
spawn Manager
coords 0 0
at    0

## THIS SCRIPT DEFINE HOW MUCH FGLAYERS ARE ACTIVE, REPEAT THE SAME FOR THE BGLAYERS
@script
void main(){setglobalvar("max_fglayer", 2);}
@end_script
at    0

Level manager entity, in short this is an enemy that holds the level active and dies when the defined requiriments are reached.
Code:
name            Manager ## THIS ENTITY IS USED TO MANY TASKS IN THE LEVEL MANAGEMENT
type            enemy
health            1
shadow            0
offscreenkill    999999

anim idle
    loop    0
    offset    1 1
    delay    4
    frame    data/chars/manager/empty.gif
 
Last edited:
It looks like most of the stuff is fixed, even centering of the screen is fixed.Thats great !
I only have issues so far with fglayers and setting their number, i use fglayers to display HUD/hearts , theres actually 6 hearts but i have to use max_fglayer , 1 , all other numbers arent working properly and display cloned hearts that wont scroll with the screen, number 1 works fine tho.
When i use snow falling fglayers and heart HUD fglayers then it drops frames a A LOT like crazy + messes up hearts again so they get cloned and some will stay behind (Wont scroll with screen), maybe something is off with the fglayers code and its autoupdating all the time.Worked smoother previously.
Also i compared splitscreen version and non split screen version ( no split screen scripts at all)both have resolution 1600x720, version without splitscfreen code runs at 60fps with one falling snow layer active but the one with split screen code already dropped 20 frames from 60fps so its about 40 frames from getgo with only 1 player onscreen and no snow layer active so kinda without split screen activated, why such drop in performance even tho split screen is not active ?

So i have it like this :
@script
void main(){setglobalvar("max_fglayer", 1);}
@end_script
at 0

And this is how much fglayers i really have ( these are all HUD hearts) so i should set them probably as 6 but that just doesnt work right so i left it at max fglayer 1 and disabled snow falling fglayers
###PLAYER1
fglayer data/bgs/heart.gif 1 0 1 230 -90 0 0 1 1 1 0
fglayer data/bgs/heart.gif 1 1 1 185 -90 0 0 1 1 1 0
fglayer data/bgs/heart.gif 1 2 1 140 -90 0 0 1 1 1 0
###PLAYER2
fglayer data/bgs/heart.gif 1 1 1 1030 -90 0 0 1 1 1 4
fglayer data/bgs/heart.gif 1 1 1 985 -90 0 0 1 1 1 4
fglayer data/bgs/heart.gif 1 1 1 940 -90 0 0 1 1 1 4

## snow falling

fglayer data/bgs/s3.gif 111 -0.5 -1 220 270 30 120 -1 -1 2 1 1 0 0 0 0.4
fglayer data/bgs/s2.gif 111 -1 -1 220 270 30 120 -1 -1 2 1 1 0 0 0 0.4
 
Last edited:
@bWWd,

I get what you are doing, and it does work, but you'd be much better off defining screen objects for your hud sections and drawing the hearts or whatever to it as sprites. This is how my HUDs work. Each player's HUD is a screen object. It conserves sprite resources because each screen object is effectively one sprite no matter how much stuff you put in it. It also just makes life easier because sprites drawn to a screen object are positioned relative to the screen object itself, not the main screen.


As for snow, there's probably ways to optimize it as well, but I wouldn't know for sure without seeing it. I certainly wouldn't make it a layer.

DC
 
It looks like most of the stuff is fixed, even centering of the screen is fixed.Thats great !
I only have issues so far with fglayers and setting their number, i use fglayers to display HUD/hearts , theres actually 6 hearts but i have to use max_fglayer , 1 , all other numbers arent working properly and display cloned hearts that wont scroll with the screen, number 1 works fine tho.
When i use snow falling fglayers and heart HUD fglayers then it drops frames a A LOT like crazy + messes up hearts again so they get cloned and some will stay behind (Wont scroll with screen), maybe something is off with the fglayers code and its autoupdating all the time.Worked smoother previously.
Also i compared splitscreen version and non split screen version ( no split screen scripts at all)both have resolution 1600x720, version without splitscfreen code runs at 60fps with one falling snow layer active but the one with split screen code already dropped 20 frames from 60fps so its about 40 frames from getgo with only 1 player onscreen and no snow layer active so kinda without split screen activated, why such drop in performance even tho split screen is not active ?

So i have it like this :
@script
void main(){setglobalvar("max_fglayer", 1);}
@end_script
at 0

And this is how much fglayers i really have ( these are all HUD hearts) so i should set them probably as 6 but that just doesnt work right so i left it at max fglayer 1 and disabled snow falling fglayers
###PLAYER1
fglayer data/bgs/heart.gif 1 0 1 230 -90 0 0 1 1 1 0
fglayer data/bgs/heart.gif 1 1 1 185 -90 0 0 1 1 1 0
fglayer data/bgs/heart.gif 1 2 1 140 -90 0 0 1 1 1 0
###PLAYER2
fglayer data/bgs/heart.gif 1 1 1 1030 -90 0 0 1 1 1 4
fglayer data/bgs/heart.gif 1 1 1 985 -90 0 0 1 1 1 4
fglayer data/bgs/heart.gif 1 1 1 940 -90 0 0 1 1 1 4

## snow falling

fglayer data/bgs/s3.gif 111 -0.5 -1 220 270 30 120 -1 -1 2 1 1 0 0 0 0.4
fglayer data/bgs/s2.gif 111 -1 -1 220 270 30 120 -1 -1 2 1 1 0 0 0 0.4

@bWWd Thanks for the tests and report.

About the layer's codes, the changes I did were to avoid repeating many equal lines by using a loop counter, but it seems that it does not worked well for layers.I will try other ways to do it, but it would be good if I could test directly in your game once it uses more resources than the default BOR.

The layers doesn't affet the overall functionality of this script, I can handle this without affecting the rest of the code.
 
Heres the data folder , im not super set on using fglayers as hearts hud so feel free to change it , whatever works better, its still in early wip stage
Im using fglayers as falling snow cause it gets me smoothest 60fps result.
So main issue is that im not able to have hearts as fglayers and falling snow fglayers at the same time, its one or the other.
 
Last edited:
Hi friends! I need to finish some things on the split screen code before sharing, but I can say that it's fully operational at least using basic features.
In the video below I mixed both zoom and split screen codes as an experiment, next time I want to make the same but for separated screens.


@bWWd
I did a sequence of tests in your game, starting with the split screen code disabled and gradually enabling all features one by one. I can certainly say that the performance start to drop after the video mode 6 and higher depending on how many characters are on the screen.

However, the great villain for the performance is the "fglayer". Even if I completely deactvate the split screen code, the performance drops hugely if the snow effect are active, something around -70 fps (stays around 130) depending on how many enemies are on the screen.

If I fully activate all fglayers (around 20 in the total) and put the video mode to your custom value of 1600x720, even with no split screen code the performance drops to around 40-50 fps. Considering that the split screen code works with 3 screens at the same time, now we can understand why the performance strongly drops if the script is fully activated.

Maybe replacing these layers with drawsprite functions using script could increase the performance. I'm using this method in my HUDs, I think it's less costly to the engine overall.
During the development of the split screen code I can help you to code these scripts, I will create some to make tests.

Bouli test, split screen disabled
 
yeah fglayers with alpha fx enabled kill the performance, i think ill try to make the snow animated gif, you think the hearts/lives hit the cpu as well ? i have quite a lot of fglayers in heman labirynth stage and it works fine but these dont use alpha fx .
It is still strange how alpha 2d effects can hit cpu so hard and gta IV works fine on same pc , i think im gonna use one alpha fx per stage max unless theres going to be some rewrite of fglayers alpha code but i doubt that it will be, not a lof of people use it.
So you say that while 2 screens of split screen are active and calcuilated by cpu, the third one is also calculated for non split screen underneath them at all times ?
 
Maybe @Kratus the problem is to use scripts ? And not adding it for real on engine ?
Because some other engine like it, have a smooth split screen function on 2D game that works fine on a little pi3.
Not exactly, the performance drop depend on other factors too like a high resolution or many fglayers active (the bWWd's game uses a resolution of 1600x720).

The game worked well in my tests using video mode from 0 (320x240) to 6 (960x540) and a few layers, the same as I shown in the Star Wars or in the original BOR videos. In fact other games have a performance drop while multiple screens are active, we can see it mainly in racing games.

In the case of the OpenBOR, all the script does is to replace the native engine sprite queue by a custom process created externally.

i have quite a lot of fglayers in heman labirynth stage and it works fine but these dont use alpha fx
This is a good idea, I didn't disable the alpha fx in your layers, only enabled them. I will test again all layers with alpha fx disabled.

So you say that while 2 screens of split screen are active and calcuilated by cpu, the third one is also calculated for non split screen underneath them at all times ?
Yes, the 3 screens need to be active to maintain everything synched in order to make a smooth transition from split to non-split. I'm testing a new code that turn off the unused screens but I don't know if will help too much on the performance.
 
Not exactly, the performance drop depend on other factors too like a high resolution or many fglayers active (the bWWd's game uses a resolution of 1600x720).

The game worked well in my tests using video mode from 0 (320x240) to 6 (960x540) and a few layers, the same as I shown in the Star Wars or in the original BOR videos. In fact other games have a performance drop while multiple screens are active, we can see it mainly in racing games.

In the case of the OpenBOR, all the script does is to replace the native engine sprite queue by a custom process created externally.
Ok i understand better. The real test for me will be to try it on a little board, like a pi3b+ with a game in 320x240 to verify if all is smooth :)
With 3 or 4 layers max and a few sprites ... for the game i want to create this year i hope.

Will it working fine with 6412 build, or i will must use a 7xxx build ?
 
Will it working fine with 6412 build, or i will must use a 7xxx build ?
Yes, I'm using the build 6391 as base because this way the code can be used on most BOR games.

The real test for me will be to try it on a little board, like a pi3b+ with a game in 320x240 to verify if all is smooth :)
Certainly it's a good test. Please, it would be good to know the results, any feedback is always welcome :)
 
Back
Top Bottom