List of True 16:9 Resolutions

rafhot

Member
i found on this site
http://pacoup.com/2011/06/12/list-of-true-169-resolutions/

Width Height Standard Dividable by 8
16 9
32 18
48 27
64 36
80 45
96 54
112 63
128 72 Yes
144 81
160 90
176 99
192 108
208 117
224 126
240 135
256 144 Yes
272 153
288 162
304 171
320 180
336 189
352 198
368 207
384 216 Yes
400 225
416 234
432 243
448 252
464 261
480 270
496 279
512 288 Yes
528 297
544 306
560 315
576 324
592 333
608 342
624 351
640 360 Yes
656 369
672 378
688 387
704 396
720 405
736 414
752 423
768 432 Yes
784 441
800 450
816 459
832 468
848 477
864 486
880 495
896 504 Yes
912 513
928 522
944 531
960 540
976 549
992 558
1008 567
1024 576 Yes
1040 585
1056 594
1072 603
1088 612
1104 621
1120 630
1136 639
1152 648 Yes
1168 657
1184 666
1200 675
1216 684
1232 693
1248 702
1264 711
1280 720 720p HD Yes
1296 729
1312 738
1328 747
1344 756
1360 765
1376 774
1392 783
1408 792 Yes
1424 801
1440 810
1456 819
1472 828
1488 837
1504 846
1520 855
1536 864 Yes
1552 873
1568 882
1584 891
1600 900
1616 909
1632 918
1648 927
1664 936 Yes
1680 945
1696 954
1712 963
1728 972
1744 981
1760 990
1776 999
1792 1008 Yes
1808 1017
1824 1026
1840 1035
1856 1044
1872 1053
1888 1062
1904 1071
1920 1080 1080p HD Yes
2560 1440 27″ Monitor Yes
3840 2160 4K UHDTV

Yes
7680 4320 8K UHDTV
Super Hi-Vision Yes
Interesting Mathematical Observations

While every simultaneous multiple of 16 by 9 generates a true 16:9 resolution, those dividable by 8 are only generated every simultaneous jump of 128 by 72 pixels, which is the lowest true 16:9 resolution to be dividable by 8.

should be useful for people who are searching for some non standard openbor 16:9 resolution
 
And can we use, say, 1664 x 936 resolution on bor?

Btw, there is no usage if you use a 1280x720 resolution if the sprites just get smaller. The resize need to use the advantage of HR (like Mugen does).
 
those are resolutions that support widescreen like the 480x272 and 960x540  stored on bor config flags
but since i dont remember wich update it is suported more values than the ones from 1 to 6

here a screenshot of my mod at 1664x936 : https://www.dropbox.com/s/3hcm46ycrpmoewc/fantasticfour%20-%200054.png

and it at 960x540 that is his current project resolution : https://www.dropbox.com/s/xsu0i2d6tojeu0d/fantasticfour%20-%200057.png


by the way those values are more for people who are creating hd sprites like i remember a guy drawing samurai warriors or something like that

i just post as refference as most of projects still use 4:3 format that make black spaces under people who have widescreen 16:9 displays
 
My question is:
Does the OpenBor HD scaling works as Mugen does? Can you use a 2x (or 4x) times bigger sprite, scale it to 0.5 (or 0.25) and it won't be pixelated?
 
you cant scale like that cause bboxes and attack boxes arent scaled, i think it scales with regular nearest pixel method.Theres no such thing as openbor HD, its just many resolution types are enabled from some time and basically you can use whatever resolution if its not slowing down gameplay for you, i dont remember any mods that used scaling feature, in mugen its in header so its easy but here you need to add drawmethod to every animation, its not really useable because of hitboxes problem, only for asthetics and graphical effects.
 
bWWd said:
i dont remember any mods that used scaling feature, in mugen its in header so its easy but here you need to add drawmethod to every animation, its not really useable because of hitboxes problem, only for asthetics and graphical effects.

This is not entirely true. Though I never released it, my prototype Fatal Fury Chronicles module used sprite scaling in regular gameplay. Entities closer on Z axis to the "camera" appeared larger and scaled in real time. This does not require a drawmethod in every animation or even an update script. Movez and some other checks here and there (on spawn for instance) will do the job just fine.

It IS true that collision boxes are not hard coded to adjust with the sprite (this is actually a good thing in the long run), and for this reason the zooming was limited to +/- 10% while entities are on the active play field. That kept collision boxes still precise enough that you couldn't tell even if you were looking for it. Once out of the play field (i.e. the classic "thrown into the camera" fatality) all bets were off and scaling vector was unlimited.

It's still available for use here, though I have since been working on an slimmed down update.

As for boxes, I was also working on allowing script access to collision boxes. ATM they are read only, but it shouldn't be too difficult to add write as well.

DC
 
in mugen its in header so its easy but here you need to add drawmethod to every animation, its not really useable because of hitboxes problem, only for asthetics and graphical effects.

Sorry to disagree, but in mugen is not "in the header". There are several ways to archive the same thing on mugen, but each method have different good and bad points:

- by CNS scalling:
xscale = 1 ;Horizontal scaling factor.
yscale = 1 ;Vertical scaling factor.
The most common usage. This scales only the sprites, not all the CLSN (colision boxes)  and Mugen can have - and its better to - more than one clsn. Neither the position ("spawn position" in BOR).

So, if we wanna have this:
pos = 35,45 ;X and Y position
scale = 0.5,0.5 ; X and Y scales

you need to use this:
pos = ceil(35*const(size.xscale)),ceil(45*const(size.yscale))
scale = 0.5*const(size.xscale),0.5*const(size.yscale)

The bad point is that you need to use those multipliers to get the things done, you need to draw CLSN size * the scale factor (so a 0.5 char should have CLSN at the double size).

- by the HIRES = 1
Works for stages (for chars, its built in on the engine). The sprites are always at half size, so the game resolution is not 320x240 anymore, but 640x480). Unil this point, you can't change the screen resolution

- by loocalcord
Added on Mugen 1.0 (the latest public release) http://elecbyte.com/mugendocs/coordspace.html
 
Back
Top Bottom