Mutiple-Resolution Display Discussion

[DCurrent]

Yeah, I think it's a very useful trick for huds, it can be currently done easily in the engine without distortion if you are using proportions of 200% or 50%. In my case it's harder because I need a hud 30% smaller or the battlefield 30% bigger.

I could even double all my assets size and increase the resolution, but will still need to adjust it by 30%. In addition, I will need to remake the entire game, which can be a pain due to many "at" adjustments in the levels, scripts based on screen size, etc.

However, it sends me to a second idea that could be applied easier than the resample feature. Some time ago I was doing tests in the engine trying to separate the level resolution from the screen resolution, because currently both are always connected. As an example, if both works separately I could double the base resolution in the video.txt and instead of updating all my levels, I can simply define a openborvariant called "level resolution" to half of the main resolution but putting the entire battlefield in a new screen and double it using drawmethod.

May looks confuse in my description but I recorded a video showing it. In the video below I doubled the SORX resolution from 480p to 960p and put the battlefield into a screen with size x2 using drawmethod. However, you can see that some things like camera will act following the 960p behaviour, not 480p, and here is where the separated level resolution variant will act. This way we can easily avoid resizing at least all the level assets, only the ones related to menu, bgs, select screen, etc.

PS: The battlefield is around 30% bigger, you can see the difference compared with the second test in the same video.

Here's the script I'm using as a draft for experiments, in case you want to make some tests. Simply calling it in the updated.c and filtering using openborvariant("in_level") is enough to make it work. Use 0 to apply on hud or 1 to apply in the level.

void drawLevel()
{//Used to test different HUD sizes
    void vScreen    = openborvariant("vscreen");
    int draw        = 0; //0=HUD OR 1=LEVEL

    //CREATE A SCREEN AND SAVE IN A VARIABLE
    if(getglobalvar("allocScr_levelScreen") == NULL()){
        setglobalvar("allocScr_levelScreen", allocscreen(openborvariant("hResolution"), openborvariant("vResolution")));
    }
    if(getglobalvar("allocScr_hudScreen") == NULL()){
        setglobalvar("allocScr_hudScreen", allocscreen(480, 272));
    }

    //CLEAR ANY PREVIOUS SCREEN VALUE
    clearscreen(getglobalvar("allocScr_levelScreen"));
    clearscreen(getglobalvar("allocScr_hudScreen"));

    //DRAW EVERYTHING TO THE SCREEN (DRAW HUD)
    if(!openborvariant("pause")){

        //HUD
        if(draw == 0){
            drawspriteq(getglobalvar("allocScr_levelScreen"), 0, openborconstant("MIN_INT"), openborconstant("MAX_INT")/1000000, 0, 0);
            drawspriteq(getglobalvar("allocScr_hudScreen"), 0, openborconstant("MAX_INT")/1000000, openborconstant("MAX_INT")-10, 0, 0);
            changedrawmethod(NULL(),"reset", 1);
            drawscreen(getglobalvar("allocScr_levelScreen"), 0, 0, openborconstant("MAX_INT")-5);
            changedrawmethod(NULL(),"enabled", 1);
            changedrawmethod(NULL(),"transbg", 1);
            changedrawmethod(NULL(),"scalex", 210);
            changedrawmethod(NULL(),"scalex", 210);
            drawscreen(getglobalvar("allocScr_hudScreen"), 0, 0, openborconstant("MAX_INT")-4);
            drawspriteq(vScreen, 0, openborconstant("MAX_INT")-5, openborconstant("MAX_INT"), 0, 0);
            clearspriteq();
        }else

        //LEVEL
        {
            drawspriteq(getglobalvar("allocScr_levelScreen"), 0, openborconstant("MIN_INT"), openborconstant("MAX_INT")/1000000, 0, 0);
            changedrawmethod(NULL(),"reset", 1);
            changedrawmethod(NULL(),"enabled", 1);
            changedrawmethod(NULL(),"scalex", 512);
            changedrawmethod(NULL(),"scaley", 512);
            drawscreen(getglobalvar("allocScr_levelScreen"), 0, 0, openborconstant("MAX_INT")/1000000);
            drawspriteq(vScreen, 0, openborconstant("MAX_INT")/1000000-1, openborconstant("MAX_INT"), 0, 0);
            clearspriteq();
        }
    }
}

This is really cool @Kratus.

 

[DCurrent]

@Kratus, I assume you already know the following, but just in case it helps:

In OpenBOR the screen and the world are very much separated. That's the reason you have to change at markers and such to adapt for higher res.

Other than a few exceptions like spawn drop ins adapting to V res, the resolution has absolutely nothing to do with how the game world works. At the time OpenBOR was conceived, that was actually a pretty unique approach to engines. In consoles, the screen and the world are essentially the same thing, and most engines (Ex. Mugen) largely mimicked this. That's why in consoles or Mugen the vertical position is inverse. There are advantages and drawbacks to both, but over time, the idea of separate worlds with logical up/down orientation has become the norm.

Anyway, in OpenBOR, the game world is always the same "resolution": 34,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000. I didn't make that number up. It's floating point, and 3.4E+38 pixels in all directions. The display resolution just controls how much of that you're showing at once. So obviously if you show more of it at once, levels will appear to behave differently with earlier spawns, lower jumps, and all that, but it's just an illusion.

In practical terms, you're limited to a world size of 2.1 billion pixels in each direction per axis (so a total range of just over four billion each), because the display variables and scroll positions are integers, so there's obviously no way to display anything outside of those boundaries. Just for fun I ran the math. That's enough for 1,093,750 screens worth of content in any given direction at 1080p resolution.

HTH,
DC

 

[Kratus]

In OpenBOR the screen and the world are very much separated

Yeah, I noticed that, but my point is to create an optional way to separate the pixel resolution from the "practical" resolution (I don't know if this is the correct term).

As an example, currently the offscreenkill will get the video.txt resolution to kills a certain entity, but in my proposed concept we could optionally change it to a different resolution in which corresponds to a possible custom screen rescaled using drawmethod, and making not necessary to rescale all the sprites/images manually.

I go even further, we could use this concept to rescale the hud/battlefield according to how many players are active, it would be amazing. I could for example define the video.txt resolution to HD (1280x720) but work with many screens and each one using its own practical resolution (320x224, 480x270, 960x540, etc).

Current


Proposed

 

[Kratus]

@DCurrent I found a Mugen video and now I can explain better the effect I was talking about. In short, it's like if the camera moves closer/far and not a resample/resize/drawmethod operations. This way the pixel is never distorted, I think this is the same feature Unity does once it works with camera management too.

Look at the first seconds of the video how the author used it a lot in the Ken's stage.

 

[oldyz]

@Kratus

those zoom effects that mugen or ikemen can pull off are fantastic, i always wondered how those engines pull it off.

the big difference tho, is that those games mostly use only 2 entities, the rest are just layers -
its 2D flat &
the one demo where you can see multiple "true" entities on screen is that one smash brothers thing with 8 or 12 characters, that as far as i know has not gone anywhere.

my only guess is that ikemen is more like a 3dish engine and treats the layers as projections on flat poly rectanglest that always face the player (mario 64 trees), or maybe in some ways no polys at all and they more akin to doom/duke nukem engines???

anyway, i was looking for an explanation for about an hour yesterday and found nothing that explains in laymans terms how it does those effects that rival the zoom effects of KIgold on the n64 (an actual 3D engine)

 

[DCurrent]

Guys, these don't have a thing to do with resolution. They're just carefully planned zooms.

I can't be more clear on these points:

1. There is no such thing as changing resolution mid frame.

2. It is absolutely 100% mathematically impossible to resample an image without quality loss.

You just have to set your game up so that the loss is minimal and hidden. Just look what early SNK games could do, and all they had was an 8bit nearest neighbor lookup table reduction (no upscale).

Generally, you design the game so your default view is partially zoomed out, and so when zoomed in, you're no longer resampling. Then you adjust items vertically (i.e. layers) as you zoom to create forced perspective. It isn't changing resolutions, it isn't polygons, and it isn't some secret sauce other engines have that we don't.

Mugen has a native Zoom factor for stages that will do a lot of the work for you. In OpenBOR you need to use sub-screens. It's more complicated but also much more versatile.

Guess I'll just have to make a demo of it to make my point.

DC

 

[Kratus]

Guys, these don't have a thing to do with resolution. They're just carefully planned zooms.

I can't be more clear on these points:

1. There is no such thing as changing resolution mid frame.

2. It is absolutely 100% mathematically impossible to resample an image without quality loss.

You just have to set your game up so that the loss is minimal and hidden. Just look what early SNK games could do, and all they had was an 8bit nearest neighbor lookup table reduction (no upscale).

Generally, you design the game so your default view is partially zoomed out, and so when zoomed in, you're no longer resampling. Then you adjust items vertically (i.e. layers) as you zoom to create forced perspective. It isn't changing resolutions, it' isn't polygons, and it isn't some secret sauce other engines have that we don't.

I keep explaining you can do these in OpenBOR and it isn't taking. Guess I'll just have to make a demo of it.

DC

Hmm maybe we are talking about different things. The zoom effect is easy to replicate in the OpenBOR, screens+drawmethod scale does the job.

My point is to find a way to not lose quality (or at least losing less quality), in the same way as when we change the resolution in the video.txt (I'm using resolution just as an example because this is the closest I have).
I would like to see the same Mugen/Unity effect replicated in the OpenBOR, maybe my script is wrong but clearly it's not the same if we compare my video with the one in my previous post. This is just a brainstorm about the idea.